X 25030：2012 (ISO/IEC 25030：2007)
（1）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
序文 ··································································································································· 1
1 適用範囲························································································································· 3
2 適合性···························································································································· 3
3 引用規格························································································································· 3
4 用語及び定義 ··················································································································· 3
5 品質要求事項に対する基本的な概念 ····················································································· 4
5.1 ソフトウェア及びシステム ······························································································ 4
5.2 利害関係者及び利害関係者要求事項··················································································· 5
5.3 利害関係者要求事項及びシステムの要求事項 ······································································· 6
5.4 ソフトウェア品質モデル ································································································· 7
5.5 ソフトウェアの特徴 ······································································································· 8
5.6 ソフトウェア品質測定（measurement）モデル ···································································· 9
5.7 ソフトウェア品質要求事項 ····························································································· 10
5.8 システム要求事項の分類 ································································································ 11
5.9 品質要求事項ライフサイクルモデル·················································································· 12
6 品質要求事項のための要求事項 ·························································································· 14
6.1 一般的な要求事項及び前提 ····························································································· 14
6.2 利害関係者要求事項 ······································································································ 14
6.3 ソフトウェア要求事項 ··································································································· 16
附属書A（規定）用語及び定義 ······························································································ 20
附属書B（参考）JIS X 0170:2004からのプロセス規定の引用 ······················································· 29
参考文献 ···························································································································· 31
X 25030：2012 (ISO/IEC 25030：2007)
（2）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法に基づき，日本工業標準調査会の審議を経て，経済産業大臣が制定した日本
工業規格である。
この規格は，著作権法で保護対象となっている著作物である。
この規格の一部が，特許権，出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意
を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許権，出願公開後の特許出願及び実
用新案権に関わる確認について，責任はもたない。
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格
JIS
X 25030：2012
(ISO/IEC 25030：2007)
ソフトウェア製品の品質要求及び評価（SQuaRE）−
品質要求事項
Software engineering-Software product Quality Requirements and
Evaluation (SQuaRE)-Quality requirements
序文
この規格は，2007年に第1版として発行されたISO/IEC 25030を基に，技術的内容及び構成を変更する
ことなく作成した日本工業規格である。
なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。
ソフトウェア製品に対する要求事項を仕様化することの一部として，ソフトウェア品質要求事項を識別
して仕様化することが重要である。ソフトウェアは，通常，より大きなシステムの一部である。システム
要求事項及びソフトウェア要求事項は密接に関連しており，ソフトウェア要求事項だけを切り離して考え
ることはできない。この規格は，ソフトウェアの品質要求事項に着目しているが，システムの観点を取っ
ている。ソフトウェア品質要求事項は，例えば，JIS X 0129-1:2003（JIS X 25010）で定義される品質モデ
ルを利用することによって分類することができる。これらの品質特性及び品質副特性の属性に対する測定
量（measures）は，ソフトウェア品質要求事項の仕様化及びソフトウェア製品の品質評価に利用できる。
ソフトウェア品質要求事項は，ソフトウェア製品に対する品質の重要な課題に取り組んでいる。ソフト
ウェア製品の品質要求事項は，次に示す活動のために必要である。
− 仕様化（契約上の合意及び入札を含む。）
− 計画（実現性の分析及び外部品質要求事項の内部品質要求事項への変換を含む。）
− 開発（開発期間中の潜在的な品質課題の早い段階での識別を含む。）
− 評価（ソフトウェア製品の品質の客観的総合評価及び認証を含む。）
ソフトウェア品質要求事項が明確に記述されない場合，ソフトウェア品質要求事項は，異なる人による
異なる見方，解釈，実装及び評価がなされるかもしれない。これによって，次のような結果になるかもし
れない。
− 利用者の期待に合わないソフトウェアで，品質の低いソフトウェアができあがる。
− 利用者，顧客及び開発者が満足しない。
− ソフトウェアを作り直すために時間及び費用が超過してしまう。
この規格は，ソフトウェア品質要求事項の品質を向上することを目的としている。そのために，品質要
求事項に対する要求事項及び推奨事項，並びに品質要求事項の定義及び分析に用いるプロセスの手引を提
供する。
この規格の適用は，ソフトウェア品質要求事項が確実に次のようになることを支援することが望ましい。
− 利害関係者のニーズに合致する。
− 明確かつ正確に記述される。
2
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 正しく，完全でかつ矛盾がない。
− 検証可能で測定可能である。
この規格は，SQuaREシリーズ（JIS X 250nn）の他の規格とともに使用されることを意図している。こ
の規格は，JIS X 0133及びJIS X 0129-1がSQuaREシリーズによって置き換えられるまでは，JIS X 0133
及びJIS X 0129-1と併せて使用されることを意図している。この規格は，品質要求事項の定義及び分析に
関連してJIS X 0170で識別されているテクニカルプロセスに従う。
図1−SQuaREシリーズ規格の構成
図1（JIS X 25000から引用し修正した。）に，SQuaREシリーズの構成を示す。
SQuaREモデルの“各部門”には，次のものがある。
− ISO/IEC 2500n 品質管理部門 この部門の規格は，SQuaREシリーズの，他の全ての規格から参照さ
れる共通モデル，用語及び定義を規定する。規格を特定の応用事例に適用する場合の参照経路（SQuaRE
シリーズ全体の手引）及び高水準の実際的な提案は，全ての種別の利用者への手助けを提供する。こ
の部門は，ソフトウェア製品の品質要求事項の仕様化及び評価の管理に責任のある支援機能のための
要求事項及び手引も提供する。
− ISO/IEC 2501n 品質モデル部門 この部門の規格は，内部ソフトウェア品質，外部ソフトウェア品
質及び利用時のソフトウェア品質のための品質特性を含む詳細な品質モデルを提供する。さらに，内
部ソフトウェア品質特性及び外部ソフトウェア品質特性は，品質副特性に分解される。また，品質モ
デルの実際的な利用のための手引も提供する。
− ISO/IEC 2502n 品質測定（measurement）部門 この部門の規格は，ソフトウェア製品の品質測定
（measurement）の参照モデル，品質測定量（measures）の数学的な定義及び適用のための実際的な手
引を含む。提供する測定量（measures）は，内部ソフトウェア品質，外部ソフトウェア品質及び利用
時のソフトウェア品質に適用する。後に続く品質測定量（measures）のための基礎となる品質測定
（measurement）の要素を定義し提供する。
− ISO/IEC 2503n 品質要求部門 この部門の規格は，品質要求事項の仕様化に役立つ。これらの品質
要求事項は，開発するソフトウェア製品の品質要求事項の導出又は評価プロセスのための入力として
利用することができる。要求定義プロセスは，JIS X 0170に定義された技術プロセスに対応付けられ
る。
− ISO/IEC 2504n 品質評価部門 この部門の規格は，評価者，取得者又は開発者が実施するかどうか，
ソフトウェア製品評価のための要求事項，推奨事項及び手引を提供する。評価モジュールとして測定
量（measure）の文書化のための支援も提供する。
ISO/IEC 25050〜ISO/IEC 25099 SQuaRE拡張部門
ISO/IEC 2503n
品質要求部門
ISO/IEC 2501n
品質モデル部門
ISO/IEC 2500n
品質管理部門
ISO/IEC 2502n
品質測定（measurement）部門
ISO/IEC 2504n
品質評価部門
3
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− ISO/IEC 25050〜ISO/IEC 25099 SQuaRE拡張部門 この部門の規格は，特定の応用範囲を取り扱う
ソフトウェア製品品質の規格，標準仕様書（TS）及び／又は標準報告書（TR）を含むように指定さ
れている。また，一つ以上のSQuaRE規格を補完するために利用できるソフトウェア製品品質の規格，
標準仕様書及び／又は標準報告書を含むように指定されている。
1
適用範囲
この規格は，ソフトウェア製品の品質要求事項の仕様化のための要求事項及び推奨事項を提供する。
この規格は，その役割が取得者及び供給者のいずれの組織にも適用できる。
JIS X 0129-1:2003（JIS X 25010）での品質モデルは，ソフトウェア品質要求事項を分類し，ソフトウェ
ア品質測定量（measures）に関して，品質要求事項を定量化する基盤を提供するために利用する。
この規格は，JIS X 0170が定義するテクニカルプロセスのうち，特に，利害関係者の製品品質に対する
ニーズの識別及びソフトウェア製品品質要求事項の分析に関連があるプロセスに従う。
この規格は，その他の要求事項（機能要求事項，プロセス要求事項，ビジネス要求事項など）の仕様化
を対象としていない。
この規格は，特定のソフトウェア品質測定量（measures）もどのような特定の開発プロセスも規定して
いない。
注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC 25030:2007，Software engineering−Software product Quality Requirements and Evaluation
(SQuaRE)−Quality requirements（IDT）
なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”こ
とを示す。
2
適合性
ソフトウェア品質要求事項は，箇条6に規定する要求事項を満たす場合，この規格に適合する。
3
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの
引用規格は，記載の年の版を適用し，その後の改正版（追補を含む。）は適用しない。
JIS X 0129-1:2003 ソフトウェア製品の品質−第1部：品質モデル
注記1
対応国際規格：ISO/IEC 9126-1:2001（ISO/IEC 25010），Software engineering−Product quality
−Part 1: Quality model（IDT）
注記2
この規格は，JIS X 25010が発行された時点で廃止する。
JIS X 25000:2010 ソフトウェア製品の品質要求及び評価（SQuaRE）−SQuaREの指針
注記 対応国際規格：ISO/IEC 25000:2005，Software engineering−Software product Quality
Requirements and Evaluation (SQuaRE)−Guide to SQuaRE（IDT）
ISO/IEC 25020:2007，Software engineering−Software product Quality Requirements and Evaluation
(SQuaRE)−Measurement reference model and guide
4
用語及び定義
この規格で用いる主な用語及び定義は，JIS X 25000:2010による（附属書Aによる。）。この規格に対す
4
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
る特定の用語及び定義はない。
5
品質要求事項に対する基本的な概念
箇条5は，この規格で使用されるソフトウェア品質要求事項に関係した概念を規定している。箇条5に
は，要求事項を含まない。
5.1
ソフトウェア及びシステム
ソフトウェアは，この規格の主要な対象である。しかし，ソフトウェアは，通常，より大きなシステム
の一部を構成する。したがって，システムの視点に立つことが役立つ。システムは，一つ以上の明記され
た目的を達成するために，組織化された，相互に作用する要素の組合せとして定義されている。この定義
は，システムを構成するもの及びシステムの要素を決定することに高い自由度を許容している。システム
の境界は，視点によって決まる。
注記 システムの境界は，次の三つの例で示すような視点によって決まる。第一の例は，航空機のエ
ンジンの制御システムである。第二の例は，航空機のエンジン全体であり，第三の例は，航空
機の全体である。航空機は，エンジン，翼などの要素の組合せと考えることができる。それら
の要素は，また，それ自身でシステムとみなすこともできる。
図2−システムモデルの例
図2は，システムの階層構造を示すシステムモデルの例であり，情報システム，機械システム，人間系
の業務プロセス及びそれらのインタフェースを含むものである。
システムの要素を定義するためには，幾つかの異なる適切な方法があってもよい。ソフトウェアは，シ
ステムの要素の一つとみなしてもよい。コンピュータシステムは，ソフトウェアを含むシステムの例であ
る。コンピュータシステムの要素は，ソフトウェアを用いるために必要となるコンピュータハードウェア，
オペレーティングシステム及びデータを含む。ワードプロセッサのように，ソフトウェアを一人で利用す
る場合には，コンピュータシステムは，対象システムの適切なモデルを表している。クライアントサーバ・
ソフトウェア又はインターネットアプリケーションは，より緊密なコンピュータシステム同士の通信を含
エンタープライズシステム
情報システム
コンピュータシステム
人間系の業務
プロセス
機械システム
コンピュータ
ハードウェア
オペレーティ
ングシステム
アプリケーション
ソフトウェア
データ
情報伝達
情報伝達
コンピュータシステム
コンピュータ
ハードウェア
オペレーティ
ングシステム
アプリケーション
ソフトウェア
データ
情報伝達
情報伝達
5
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
めた情報システムのような，より複雑なシステムモデルを必要とする。同様に，電子商取引アプリケーシ
ョンは，人間系の業務プロセスを含むことが多い。多くの装置は，自動車のアンチロックブレーキングシ
ステム（ABS）のように，コンピュータシステムと機械システムとの両方を含む。空港の旅客手荷物取扱
いシステムは，コンピュータシステム，機械システム（ベルトコンベアなど）及び人間系の業務プロセス
を含む。この例は，人間がシステムの一部になり得ることを示している。
5.2
利害関係者及び利害関係者要求事項
システムには，そのライフサイクルを通して，システムに関心がある様々な利害関係者が存在している。
システムの利害関係者は，システムに正当な関心をもつ全ての人々（例えば，エンドユーザ），組織（例え
ば，エンドユーザ組織又は開発組織）及び団体（例えば，法定機関及び規制機関又は一般公的団体）を含
む。利害関係者は，システムに対して，それぞれ異なるニーズ及び期待をもっている。そのニーズ及び期
待は，システムのライフサイクルを通して，変化してもよい。
利害関係者のニーズは，明確に記述することができるが，暗黙のこともある。暗黙のニーズは，ソフト
ウェア製品が使用される状況によってしばしば暗示される。そして，暗黙のニーズは，類似ソフトウェア
製品又は既存の決められた作業，通常の作業手順及び業務，法律又は法規による操作，などに基づいてい
る。利害関係者が自らのニーズに気づかないことが時々ある。多くの場合，ソフトウェア製品及び関係す
る業務プロセス又はタスクを試行することができて，初めて，利害関係者のニーズが明らかになる。開発
プロジェクトの初期段階で，暗黙のニーズ及び利害関係者が気づかないその他のニーズ（気づかないニー
ズ）を識別するために使用することができる方法の例として，シナリオ，ユースケース及びプロトタイプ
がある。場合によっては，利害関係者の真のニーズと利害関係者が表明しているニーズとが異なることが
ある。
利害関係者のニーズ及び期待は，図3に示す要求事項の抽出及び定義プロセスを通して識別される。プ
ロセスは，全ての利害関係者のニーズ，要望，願望及び期待を考慮に入れる。このことには，社会から求
められるニーズ及び要求事項，取得者からの制約，並びにエンドユーザのニーズを含む。
異なる立場の利害関係者は，異なるニーズ及び期待をもつことがよくある。場合によっては，利害関係
者は，矛盾したニーズをもつことがある。利害関係者間の要求事項の不一致は，例えば，異なるエンドユ
ーザの観点間の不一致，又は取得者のニーズと開発組織での利用可能なスキル，経験若しくは資源との不
一致のことである。
この規格では，特定のソフトウェアライフサイクルプロセスを指定しないが，JIS X 0170にあるシステ
ムライフサイクルプロセスに従う。JIS X 0170では，利害関係者の要求事項の定義及びシステムの要求事
項の分析を狙いとする，次の二つのテクニカルプロセスを定義している。
a) 利害関係者要求定義プロセス（JIS X 0170の5.5.2を参照。）
b) 要求分析プロセス（JIS X 0170の5.5.3を参照。）
注記 JIS X 0160:1996が品質要求事項については，JIS X 0170より明確ではないことから，JIS X
0170を優先して用いる。
これら上記のa)，b)の二つのプロセスは，論理的な順序になっているが，これらの二つのプロセスを繰
り返し使うことはよくある。この規格の附属書Bには，関連するプロセスのアクティビティが提供されて
いる。
次のような特定の状況又は要因を満たすために，JIS X 0170附属書Aの規定に沿って，二つのプロセス
を修整してもよい。
a) 合意の中でJIS X 0170を採用している組織を取り巻く状況又は要因
6
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b) JIS X 0170を参照しているという合意を満たすことを要求されるプロジェクトに影響を与える状況又
は要因
c) 製品又はサービスを提供するために組織のニーズを反映する状況又は要因
JIS X 0170に定義された二つのプロセスがシステム要求事項を取り扱うのに対し，この規格では，ソフ
トウェア品質要求事項を取り扱う。ソフトウェア品質要求事項は，システムの観点で考慮することが望ま
しいが，JIS X 0170に規定されるアクティビティで，ソフトウェア品質要求事項の視点からは関連性がな
いアクティビティ又はほんの僅かしか関連性がないアクティビティがあってもよい。
図3−利害関係者要求定義及び要求分析
利害関係者要求定義プロセスの結果を利害関係者要求事項という。要求事項分析プロセスの結果をシス
テム要求事項という。
5.3
利害関係者要求事項及びシステムの要求事項
図3に示すように，分析プロセスでは，利害関係者の要求事項を，要望されたシステムの実現に使用で
きるシステムの要求事項の技術的視点へと変換する。要求事項の技術的視点をシステム要求事項という。
利害関係者の要求事項を満たすために，システム要求事項は，検証可能であり，かつ，システムが保有し
なければならない特性はどれかを記述する。
システムは，多くの場合，様々な要素から構成される。それぞれ特定の特性をもち，システム全体の中
でそれぞれの目的を遂行する。システムを実際に使えるようにするために，システム要求事項を各システ
ム要素のための要求事項として体系化しなければならない。異なる要素は，システムの能力を提供するた
めに相互に作用するので，異なるシステム要素に対する要求事項は，単独ではなく，他のシステム要素に
対する要求事項を含む，より広い視点で見ることができる。
利害関係者の要求事項は，例えば，ソフトウェアに対する要求事項を暗示してもよい。しかし，利害関
係者の要求事項が常にソフトウェアへの要求事項を暗示しているわけではない。利害関係者の要求事項は，
他の方法でも実現できる。例えば，ハードウェアの中若しくはソフトウェアの中で，又はビジネスプロセ
ス（手作業プロセスとしても）として実現できる。そのような実現に関する決定は，高レベルの設計プロ
セスの一部である。図2に示すシステムモデルを適用する，システム設計の決定に基づく要求事項の階層
構造を図4に示す。
利害関係者の
ニーズ及び期待
・明記されたもの
・暗黙のもの
・気づかないもの
システム要求事項
形式化された
システム要求事項
及び制約事項
利害関係者要求事項
関連する利害関係者
から抽出された要求
事項
利害関係者
要求定義
プロセス
要求事項
分析プロセス
7
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図4−システム及びソフトウェア要求事項の階層
5.4
ソフトウェア品質モデル
システムの品質は，システム要素の品質及びそれらの相互作用の結果である。この規格は，システムの
一部としてのソフトウェアの品質に着目している。
ソフトウェア品質は，特定の条件の下で利用されたとき，明示的及び暗示的なニーズを満たすソフトウ
ェア製品の能力である。JIS X 0129-1:2003（JIS X 25010）で規定したソフトウェア製品の品質モデルは，
次の六つの品質特性を定義している。
− 機能性：ソフトウェアが指定された条件の下で利用されるとき，明示的及び暗示的なニーズを満たす
機能を提供するソフトウェア製品の能力。
− 信頼性：指定された条件の下で利用するとき，指定された達成水準を維持するソフトウェア製品の能
力。
− 使用性：指定された条件の下で利用するとき，理解でき，習得でき，利用でき，かつ，利用者にとっ
て魅力的であるソフトウェア製品の能力。
− 効率性：明示された条件の下で，使用する資源の量に対比して適切な性能を提供するソフトウェア製
品の能力。
− 保守性：修正のしやすさに関するソフトウェア製品の能力。修正には，環境並びに要求事項及び機能
仕様における変更へのソフトウェアの是正，改善又は適合を含めてもよい。
− 移植性：ある環境から他の環境に移すためのソフトウェア製品の能力。
この規格は，システムレベルの追加的な品質特性を定義する。
− 利用時の品質：指定された利用者が，指定された利用の状況で，有効性，生産性，安全性及び満足度
に対する指定された目標を達成できるソフトウェア製品の能力。
品質特性は，定義された副特性をもっている。さらに，この規格は，階層構造において利用者が副副特
性を定義することを許容している。定義された品質特性は，ほとんどのソフトウェア製品に対して，関連
のある品質側面を網羅している。それ自体は，品質の完全な網羅性を高めるためのチェックリストとして
使用できる。
品質モデルは，品質の三つの異なる視点を定義する。
システム
要求事項
人間系の業務プロセスの
要求事項
コンピュータ
ハードウェアの
要求事項
オペレーティング
システムの
要求事項
アプリケーション
ソフトウェアの
要求事項
データの
要求事項
コンピュータシステムの
要求事項
情報システムの
要求事項
機械システムの
要求事項
コンピュータシステムの
要求事項
コンピュータシステムの
要求事項
8
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 利用時のソフトウェア品質
− 外部ソフトウェア品質
− 内部ソフトウェア品質
特定の利用者による特定のタスク実行に関して，利用時のソフトウェア品質という視点は，運用環境に
おいてソフトウェアを適用することに関係している。外部ソフトウェア品質は，ソフトウェアの“ブラッ
クボックス（暗箱）”化という視点を提供し，コンピュータハードウェア上でのソフトウェアの実行及びオ
ペレーティングシステムの適用に関する特徴を取り扱う。内部ソフトウェア品質は，ソフトウェアの“ホ
ワイトボックス（透明箱）”化という視点を提供し，主として開発期間中に利用可能となるソフトウェア製
品の特徴を取り扱う。内部ソフトウェア品質は，主にソフトウェアの静的な特徴に関係している。内部ソ
フトウェア品質は，外部ソフトウェア品質に影響を与え，同じく，外部ソフトウェア品質は，利用時の品
質に影響を与える。図5は，様々な品質モデルとシステムとの関連を示す。SQuaREシリーズは，ソフト
ウェア品質モデル及びデータ品質モデルを対象としており，図中のその他の品質モデルは，対象としてい
ない。
図5−システムモデル及び品質モデルの例
品質モデルは，品質の全ての側面が内部品質，外部品質及び利用時の品質の視点から考慮されることを
確実にするための枠組みとして役立つ。
5.5
ソフトウェアの特徴
ソフトウェアの特徴には，ソフトウェア固有のもの（ソフトウェアが本来もっているもの）もあり，ソ
フトウェア製品に割り当てられたものもある。ソフトウェア製品の能力は，ソフトウェア固有の特徴によ
って決まる。
注記1 “〜に割り当てられた”に対する“固有の”という言葉は，特に恒久的な特性又は特徴とし
て何かの中に存在することを意味している。
注記2 ソフトウェア固有の特徴の例としては，コード行数及びソフトウェアによって提供された数
システム
情報システム
コンピュータシステム
コンピュータ
ハードウェア
オペレーティ
ングシステム
ソフトウェア
データ
人間系の
業務プロセス
機械システム
機械システムの
品質モデル
コンピュータ
ハードウェア
の品質モデル
データ品質
モデル
人間系の
業務プロセス
の品質モデル
内部ソフトウェア
品質モデル
外部ソフトウェア
品質モデル
利用時のソフトウェア
品質モデル
その他の
品質モデル
ソフトウェア
品質モデル
9
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
値計算の正確性がある。割り当てられた特徴の例としては，ソフトウェア製品の所有者及び
ソフトウェア製品の価格がある。
ソフトウェア固有の特徴は，機能面の特徴又は品質面の特徴のいずれかに分類できる。機能面の特徴は，
ソフトウェア製品に何ができるかを決定する。品質面の特徴は，そのソフトウェア製品がどれくらいうま
く実行できるかということを決定する。いいかえると，品質面の特徴は，どの程度ソフトウェア製品が指
定されたサービスを提供でき，維持できるかを示している。品質は，ソフトウェア製品に固有の特徴であ
る。したがって，ソフトウェアの変更なしに変えることができるので，割り当てられた特徴は，ソフトウ
ェアの品質特性とはみなされない。図6は，ソフトウェアの特徴についてのこうした分類を示している。
ソフトウェアの特徴
固有の特徴
機能面の特徴
品質面の特徴：機能性，信頼性，効率性，使用性，保守性，
移植性，利用時の品質
割り当てられた特徴
管理面の特徴：例えば，価格，出荷日，製品の将来性，製品
供給者
図6−ソフトウェアの特徴
5.6
ソフトウェア品質測定（measurement）モデル
ソフトウェアの固有の特徴は，定量的又は定性的に区別することができるものであり，属性と呼ばれる。
品質属性は，一つ以上の品質特性及び品質副特性に分類される。
品質属性は，測定方法（measurement method）を適用することによって測定する。測定方法（measurement
method）は，特定の尺度に関して属性を測定するために使用される論理的な操作の順序である。測定方法
（measurement method）を適用した結果を基本測定量（measure）という。品質特性及び品質副特性は，測
定（measurement）の関数を適用することによって定量化できる。測定（measurement）の関数は，品質測
定量（measure）要素を組み合わせるために使用されるアルゴリズムである。測定（measurement）の関数
を適用した結果をソフトウェア品質測定量（measure）という。このようにして，ソフトウェア品質測定量
（measures）は，品質特性及び品質副特性の定量化になる。一つ以上のソフトウェア品質測定量（measure）
が品質特性又は品質副特性を測定するために利用される。
ISO/IEC 25020から流用した図7は，JIS X 0129-1:2003（JIS X 25010）の品質モデル，ISO/IEC 2502n
の測定量（measure）及びISO/IEC 15939:2002に提案された測定（measurement）モデルの間の関連を表し
ている。
図7−ソフトウェア製品品質測定（measurement）の参照モデル
ソフトウェア製品品質
品質特性
品質副特性
ソフトウェア品質測定量
品質測定量の要素
測定の関数
10
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.7
ソフトウェア品質要求事項
測定（measurement）の関数は，ソフトウェアの品質面の特徴について，ある解釈を示す。すなわち，そ
れは特徴に値を与える。ソフトウェア品質測定量（measure）の目標値は，ソフトウェア品質要求事項を表
す。すなわち，特徴の要求される値は何かを表す。同様に，品質測定（measurement）の実績値は，ソフト
ウェアの観察された品質を表している。
ソフトウェア品質要求事項は，他の要求事項と同様に，単独では存在できず，より広い状況で見なけれ
ばならない。ソフトウェア品質要求事項は，機能要求事項と特に密接な関係がある。機能要求事項は，こ
の規格の主題ではないが，ソフトウェア品質要求事項を仕様化するために重要な役割を果たしている。
注記1 機能性は，JIS X 0129-1:2003（JIS X 25010）の内部品質特性及び外部品質特性の六つの特性
のうちの一つである。機能性の要求事項は，機能要求事項と混同しないことが望ましい。機
能性とは，ソフトウェアの機能要求事項を満たす機能を提供するためのソフトウェアの能力
のことである。機能性の要求事項は，ソフトウェア製品が目的にあっており，正確で，相互
運用ができ，機密性があり，関連する機能基準及び規範に適合するための要求事項に詳細化
される。
ある場合には，完成したソフトウェア製品全体に対するソフトウェア品質要求事項を明確にすることが
重要である。一方，その他の場合には，ソフトウェア品質要求事項がソフトウェア製品の一部に適用され
るだけである。例えば，幾つかの機能は，特定の利用者に関係しているだけであり，特定のソフトウェア
品質要求事項をもっている。これらの機能は，他の目的及び他の利用者のために意図した他の機能のため
の品質要求事項とは異なっている。したがって，ソフトウェア製品のどの部分がソフトウェア品質要求事
項に関係しているかということを明確にすることが重要である。いいかえれば，ソフトウェア品質要求事
項は，（機能の集合である）ソフトウェア製品の一部に適用される。例えば，幾つかの機能は，一般的なエ
ンドユーザが使用することを想定してもよく，それゆえ，低いエラー許容度を要求してもよい。一方，別
の機能群は，専門家が使用することを想定してもよく，それゆえに，高いエラー許容度を容認している。
いずれの場合でも，エラー許容度の仕組み及び要求されるエラー許容度の度合いを厳格に明確化すること
が望ましい。
ソフトウェア品質要求事項は，結果的に，ソフトウェア品質要求事項を支援する付加的な機能要求事項
をもたらしてもよい。例えば，使用性の要求事項は，利用者のためのオンラインヘルプを提供する付加的
な機能を結果としてもたらすことができる。
図8は，ソフトウェア品質要求事項がどのようにして，JIS X 0170に規定された要求事項プロセスの一
部として導出されていくかを示している。定義プロセスは，システムに対する利害関係者の要求事項に焦
点を当てている。分析プロセスは，システムのソフトウェア要素に対する関連する要求事項を識別できる
ようにする幾つかの方式の決定を前提としている。利害関係者の品質ニーズに着目するとき，JIS X
0129-1:2003（JIS X 25010）で規定された品質モデルは，利害関係者の品質要求事項を定義するために有用
である。同様に，TS X 0110-2，-3及び-4（ISO/IEC 2502n）で規定された（ソフトウェア品質）測定量（measures）
は，利害関係者のソフトウェア品質要求事項を正式なものにするために役立つ。
11
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図8−ソフトウェア品質要求事項の定義及び分析
注記2 図8において，利害関係者要求事項及び利害関係者品質要求事項は，課題となっているシス
テム全体を取り扱っており，ソフトウェアだけを取り扱っていないということを強調してい
る。
5.8
システム要求事項の分類
システムは，多くの相互に作用する要素から構成されている。これらのシステムの要素は，様々な異な
る方法で定義でき，分類できる。図2は，システム要素の分類例を示している。システム要求事項の同様
の分類を図9に示す。システム要求事項は，例えば，ソフトウェア，コンピュータハードウェア，データ，
機械システム，人間が行う業務組織のプロセスなどに対する要求事項を含むことができる。それらは，エ
ンドユーザ，組織及び公的機関を含む様々な利害関係者からもたらされてもよい。この規格は，主にソフ
トウェアに着目しているので，図9は，ソフトウェア要求事項を強調したものになっている。
ソフトウェア要求事項は，ソフトウェア製品又はソフトウェア開発プロセスのいずれかについて対応し
ている。
ソフトウェア製品要求事項は，機能要求事項，品質要求事項及び管理要求事項を含む。機能要求事項は，
アプリケーション分野の特定の要求事項と同様に品質要求事項を支援する機能要求事項も含む。品質要求
事項は，方式の要求事項及び構造の要求事項を含んでもよい。
ソフトウェア開発プロセスの要求事項は，例えば，作業生産物，プロセス，プロジェクト，開発組織及
び開発者への要求事項を含んでもよい。ソフトウェア開発要求事項とソフトウェア製品要求事項との間に
は，しばしば，依存関係が存在するが，図9でその関係は示していない。
システム
要求事項
システム品質
要求事項
ソフトウェア
要求事項
25030
ソフトウェア
品質要求事項
利害関係者
ニーズ
利害関係者
要求事項
利害関係者
品質ニーズ
利害関係者
品質要求事項
25010
品質モデル
2502n
品質測定量
（measure）
定義プロセス
分析プロセス
12
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
システム
要求事項
ソフトウェア
要求事項
ソフトウェア
製品要求事項
ソフトウェア固有の特
徴の要求事項
機能的要求事項
ソフトウ
ェア品質
要求事項
利用時の品質要求事項
外部品質要求事項
内部品質要求事項
割り当てられた特徴の
要求事項
例えば，価格，配布日，製品の先行き及び
製品の供給者に対する要求事項を含め，管
理面での要求事項
ソフトウェア
開発要求事項
開発プロセス要求事項
開発組織要求事項
その他のシス
テム要求事項
例えば，コンピュータハードウェア，データ，機械部品及び人手による業務プロセス
への要求事項を含む。
図9−システム要求事項の分類
5.9
品質要求事項ライフサイクルモデル
利害関係者要求事項は，多くの情報源からもたらされる。図10は，類似システムが既に存在し，利用さ
れている状況を示している。その場合，既存システムの特徴及び利用者は，新しいシステムの要求事項へ
の主要な情報源となる。利害関係者要求事項は，主として，既存システムの実際の利用からくる経験に基
づいて識別することができる。課題になっているシステムが完全に新規の場合，すなわち，類似したシス
テムが存在しない場合，利害関係者の真のニーズを識別することは，より困難になるかもしれない。
5.4に規定したように，ソフトウェア品質には三つの視点がある。これらの異なる視点は，ソフトウェア
品質要求事項を三つの類型に分ける。
− ソフトウェアの利用時の品質要求事項
− ソフトウェアの外部品質要求事項
− ソフトウェアの内部品質要求事項
利用時の品質要求事項は，通常，次のような利害関係者の要求事項から導出される。
a) 事業要求事項（企業方針，競合他社など）
b) 機能要求事項
c) アプリケーション領域に特化した要求事項
利用時の品質要求事項は，通常は，ソフトウェアの妥当性確認（すなわち，ソフトウェアがその意図さ
れた目的に合致するかどうか。）に利用される。ソフトウェアの外部品質要求事項は，通常，次を含む多く
の情報源から導出される。
a) 利害関係者要求事項
b) 法的な要求事項
c) 関係のあるアプリケーションに対する標準及び指針
d) 利用時の品質要求事項
e) 機能要求事項
f)
アプリケーション領域に特化した要求事項
g) リスク分析から導かれるセキュリティ要求事項
ソフトウェアの外部品質要求事項は，ソフトウェアの妥当性確認及び検証（すなわち，仕様に従ってソ
フトウェアが作成されているかどうか。）に利用される。ソフトウェアの内部品質要求事項は，通常，次を
含む多くの情報源から導出される。
a) 外部ソフトウェア品質要求事項
13
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b) 企業方針
c) 開発方針及び制約
d) ベストプラクティス指針
ソフトウェアの内部品質要求事項は，通常は，開発期間中の品質の監視及び制御に利用される。
ソフトウェア利用時の品質要求事項は，ソフトウェアの外部品質要求事項を暗示してもよい。同様にソ
フトウェアの外部品質要求事項は，ソフトウェアの内部品質要求事項を暗示してもよい。ソフトウェア実
装プロセスは，ソフトウェア品質要求事項を実現する。新しいシステムの品質は，別の新しいシステムへ
の入力として再び利用でき，その結果として，図10に示すサイクルが完成する。
ソフトウェアのある一つの版が次の新しい版の要求事項を決定するための基礎として利用される場合，
ソフトウェア要求事項は，反復型開発プロセスの一部として仕様化できる。一般に，ソフトウェア品質要
求事項が確定されているのに対して，このようにして進化するのが機能要求事項である。しかし，品質要
求事項も版が進むとともに進化することができる。
図10−品質要求事項のライフサイクル
利害関係者要求事項
関連する利害関係者
から抽出された要求事項
ソフトウェア品質
要求事項
ソフトウェア製品
利用時の品質
要求事項
外部品質要求事項
内部品質要求事項
利用時の品質
外部品質
内部品質
実装
利害関係者ニーズ
14
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6
品質要求事項のための要求事項
箇条6は，ソフトウェア製品の品質要求事項について，この規格の要求事項及び推奨事項を提供する。
6.1
一般的な要求事項及び前提
ソフトウェアは，多くの場合，より大きなシステムの一部分である。システムの階層構造のより高い位
置でなされた方式決定は，ソフトウェアとの境界及びインタフェースを定義する。
注記1 システムのどの部分を実際にソフトウェアに実装するかについての方式は，利害関係者の品
質要求事項が仕様化される時点で決定されなくてもよいし，部分的に決定されてもよい。し
たがって，品質要求事項がソフトウェアに関係しているかどうかを，システムライフサイク
ルの早い時点で決定することは，不可能であるかもしれない。
注記2 品質要求事項は，単独では理解することはできず，他の種類の要求事項との関係によってだ
け理解できる。
注記3 JIS Q 9001:2008では，製品への品質要求事項を決定することを要求している。より具体的に
は，JIS Q 9001:2008の7.2.1は，製品に関係する要求事項の決定に関する次の要求事項を規
定している。組織は，次の事項を明確にしなければならない。
a) 顧客が規定した要求事項。これには，引渡し及び引渡し後の活動についての要求事項を
含む。
b) 顧客が明示していないが指定された用途又は意図された用途が既知である場合，それら
の用途に応じた要求事項
c) 製品に適用される法令・規制要求事項
d) 組織が必要と判断する追加要求事項全て
この規格は，JIS X 0129-1:2003（JIS X 25010）の品質モデルと同様の構造をもつソフトウェア品質モデ
ルが使用されているということを前提にしている。適用するソフトウェア品質モデルは，文書化されなけ
ればならない。
注記4 JIS X 0129-1:2003（JIS X 25010）で規定された品質モデルの利用を提案する。このモデルは，
多くの状況で利用してもよい。また，この規格の基礎となっている。しかしながら，場合に
よっては，特定の品質側面を重視する他の品質モデルを使用することが適切な場合もある。
この規格は，特定の開発モデルも測定量（measures）も規定していないし，想定もしていない。
注記5 この規格は，JIS X 0170で規定された包括的なライフサイクルプロセスの枠組みを適用する。
利害関係者の要求定義プロセス及び要求分析プロセスは，この規格に最も関係がある。
注記6 一般的な要求事項に含まれるプロセス及びアクティビティと特別なソフトウェア製品の品質
要求事項との間には，多くの類似点がある。多くの場合，アクティビティは，組み合わされ
ている。
6.2
利害関係者要求事項
利害関係者要求事項は，システムに関係している。幾つかの利害関係者要求事項は，ソフトウェアに関
連していなくてもよい。システム方式を決定するとき，どの利害関係者要求事項がソフトウェアに影響す
るかを決めることができる。6.2は，システム視点を採用しており，ソフトウェアに特化したものではない。
注記 JIS X 0170の5.5.2は，利害関係者要求事項定義のプロセスアクティビティについて規定してい
る。より詳細については，この規格の附属書Bを参照。
15
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.2.1
システムの境界
6.2.1の要求事項及び推奨事項は，システム品質に関連するシステムの境界及び制約が文書化されている
ことを確実にすることを目指している。
システムの境界は，文書化されなければならない。
注記1 5.2にシステム概念の例を示す。
システムの意図する目的を文書化しなければならない。文書は，利用，便益，システムの定められた寿
命，システムの重大性及び，安全性問題又は危険性問題のようなリスク依存性を含んでいることが望まし
い。
システムの制約を文書化しなければならない。
注記2 システム制約は，既存の合意，管理の決定及び技術的決定からくる必然的な結果である。こ
れらは，次のことから導かれる。
1) 利害関係者が定義した解決策の事例又は領域
2) システムの階層構造のより高いレベルでなされた実装決定
3) 定義された使用可能なシステム，資源及び要員を利用するという要求
システム品質要求事項の誤解を避けるため，使用された特定の概念及び用語を定義し，説明することが
望ましい。
6.2.2
利害関係者の品質要求事項
6.2.2の要求事項及び推奨事項は，“文書化した品質要求事項が全ての利害関係者のニーズ及び期待を考
慮したものであること”，を確実にすることを目指している。
利害関係者の品質要求事項を仕様化する目的は，文書化されなければならない。
注記1 目的は，新規開発，既存システムの拡張，既存システムの改造又はシステム評価であっても
よい。
全ての関係する利害関係者を列挙しなければならない。
注記2 5.3は，利害関係者及びその要求事項に関係する概念を説明している。
列挙した利害関係者の役割及び関心事項を文書化しなければならない。
注記3 利害関係者について必要な情報は，状況に依存している。ある場合には，年齢が非常に重要
となる。他の場合には，例えば，国籍，職業，性別，学歴，経験が重要となる。
利害関係者の品質要求事項を識別する場合，各利害関係者について，考慮するかどうかを文書化しなけ
ればならない。考慮しない利害関係者については，その論理的根拠を文書化することが望ましい。
注記4 市販の成功したソフトウェア製品では，その製品の要求事項から特定の利害関係者の要求事
項を除外していることがある。例えば，意思決定者の要求事項を満たすように決定し，幾つ
かのエンドユーザの要求事項を採択していないことがある。そうした決定について明確にし
ておくことも重要であるが，結果として，利害関係者の中に，そのソフトウェア製品に満足
しない人がいることがある。
識別されたが記述されていない利害関係者要求事項は，文書化されなければならない。
適切な場合，利害関係者の品質要求事項を識別するため，シナリオ及び利用者との対話を使用すること
が望ましい。今後予想される使用可能な支援シナリオ及び環境に対応する，全ての要求されたサービスを
識別するために，シナリオは，一連の代表的なアクティビティの順序を含むことが望ましい。利用者とシ
ステムとの対話は，文書化することが望ましい。可能ならば，利害関係者の品質要求事項は，シナリオ及
び利用者の対話の記述を追跡できることが望ましい。
16
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
各利害関係者の品質要求事項は，独自のものとして識別されなければならない。
注記5 個々の利害関係者は，不明確な，不明瞭な，非現実的な又は矛盾する要求事項をもつことが
ある。異なる利害関係者の要求事項間には，不一致があることがある。利害関係者の品質要
求事項は，こうした課題が全て解決された要求事項の統合された集合として表現される。5.3
は，利害関係者についての情報を提供している。
重大な品質に関係する，健康，安全，セキュリティ，環境並びにその他の利害関係者の要求事項及び機
能は，文書化することが望ましい。
注記6 重大な側面の範囲を確かにするために，リスク分析を適用することができる。
各利害関係者の品質要求事項は，対応する利害関係者又はいろいろな立場の利害関係者を追跡できるこ
とが望ましい。
注記7 経営陣は，顧客の要求事項を決定し，それらが顧客の満足度を向上させるための狙いを満た
すことを確実にしなければならないということを，JIS Q 9001:2000の5.2は，要求している。
注記8 JIS Q 9001:2008の7.2.1は，要求事項（利用者のニーズ）を，次のように分類している。
a) 顧客が規定した要求事項
b) 顧客が明示してはいないが，指定された用途に応じた要求事項
c) 法令・規制要求事項
d) 開発組織が必要とする追加要求事項全て
6.2.3
利害関係者品質要求の妥当性確認
6.2.3の要求事項及び推奨事項は，利害関係者品質要求事項の品質を確保することを目指している。
利害関係者の品質要求事項は，妥当性を確認し，承認されなければならない。
利害関係者の品質要求事項の妥当性を誰が確認し，承認したかを文書化しなければならない。
6.3
ソフトウェア要求事項
6.3は，システムのソフトウェア要素を識別するような，より高いレベルの方式決定が行われることを前
提としている。
注記 JIS X 0170の5.5.3は，要求分析プロセスのアクティビティを規定している。より詳細な内容に
ついては，この規格の附属書Bを参照。
6.3.1
ソフトウェアの境界
ソフトウェアの意図する目的を文書化しなければならない。文書化では，そのソフトウェアが構成要素
となっているシステムでのソフトウェアの役割を記述することが望ましい。
注記1 ソフトウェア品質要求事項は，取得者と開発者との間の契約合意の一部であってもよいし，
又はソフトウェア製品品質評価への入力であってもよい。
提供される機能の振る舞い及び特徴に関して，ソフトウェアの機能的な境界を文書化しなければならな
い。文書化には，どの機能をソフトウェアの部分として実装するかということについて，システムの構造
においてより高いレベルでの設計によって割り振られた方式決定を含むことが望ましい。
ソフトウェア品質要求事項に関わるシステムソリューションの制約を文書化しなければならない。シス
テムソリューションの制約に対する理論的根拠及び情報源を可能な限り文書化することが望ましい。
ソフトウェア品質要求事項に関連する実装の制約を文書化しなければならない。
注記2 実装の制約は，利害関係者の品質要求事項から導かれる。又は，解決が不可避な制限である。
これには，システムの構造のより高いレベルでの設計によって割り振られた実装の決定を含
む。
17
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.3.2
ソフトウェア品質要求事項
6.3.2の要求事項及び推奨事項は，選択した品質モデルに従って，ソフトウェア品質要求事項が文書化さ
れることを確実にすることを目指している。
ソフトウェア品質要求事項は，一意に識別されなければならない。
ソフトウェア品質要求事項は，利害関係者要求事項に対して追跡可能でなければならない。
ソフトウェア品質要求事項は，全ての関連する利害関係者の品質要求事項を考慮に入れなければならな
い。
注記1 幾つかの利害関係者の品質要求事項は，ソフトウェアとは異なる手段で実現されてもよい。
ソフトウェア品質要求事項は，適用する品質モデルで定義したように品質特性（又は品質副特性）と関
連付けを行わなければならない。
注記2 品質モデルは，全ての品質側面を確実に網羅するためのチェックリストとして利用すること
ができる。
どのソフトウェア品質要求事項も品質モデルの特定の品質特性（又は品質副特性）に対応しない場合，
このことを文書化しなければならない。
ソフトウェア品質要求事項は，次のいずれかの品質モデルに従って分類することが望ましい。
− 利用時のソフトウェア品質要求事項
− 外部ソフトウェア品質要求事項
− 内部ソフトウェア品質要求事項
ソフトウェア品質要求事項は，ソフトウェア品質測定量（measure）及び関係する目標値に関して仕様化
しなければならない。
TS X 0111-2，-3及び-4（ISO/IEC 2502n）の記載事項に従って，使用するソフトウェア品質測定量
（measures）を文書化しなければならない。
注記3 使用に供する品質測定量（measures）の一覧表を作成し，保守することを推奨する。異なる
プロジェクトに測定量（measures）の同じ集合を適用することによって，JIS X 0133-3（ISO/IEC
25042）で規定した測定経験データベースを生成することが可能となる。この進め方は，見積
りをより信頼できるものにする。これに変わる手法として，GQM［目標（Goal）−質問
（Question）−測定法（metric）］又はそれと類似の進め方を，特定の状況に応じて適切な測
定量（measures）を識別するために適用してもよい。
注記4 測定量（measure）の目標値は，ソフトウェア品質要求事項を満たすものであると判断できる
値である。目標値は，単一の値であってもよいし，値の範囲であってもよい。
注記5 TS X 0111-2，-3及び-4（ISO/IEC 2502n）は，多くの測定量（measures）を提供している。そ
れらは，そのままで又は特定の組織のニーズに適応させて使用してもよい。
注記6 品質要求事項は，他の一連の品質要求事項の観点から仕様化してもよい。JIS X 5070は，こ
の方法（進め方）の事例を提供している。この事例において，（セキュリティに関係する。）
ソフトウェアの外部品質要求事項は，ソフトウェアの内部品質要求事項の集合として仕様化
される。
ソフトウェアに要求された機能のうち，どの機能にソフトウェア品質要求事項が適用できるかを文書化
しなければならない。
注記7 ソフトウェア機能とソフトウェア製品の品質要求事項との関係に関するさらなる情報は，5.7
を参照。
18
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ソフトウェア品質測定量（measures）を選択するために適用する基準を文書化しなければならない。
注記8 基準には，関連性，データ収集の実現可能性及び容易さ，個人情報保護，解説のしやすさ，
並びにライフサイクル段階の適用性を含めてもよい。ISO/IEC 25020は，代わりの測定量
（measures）を選択するため更に詳細な基準を提供している。
ソフトウェア品質要求事項のための操作側面は，関係がある場合，仕様化しなければならない。
注記9 ソフトウェアが特定の水準でのサービスを維持できなければならないという条件の下に，操
作側面は，作業負荷（仕事量），利用者側面及びトランザクションの種類を仕様化する。異な
る操作側面は，結果として異なる測定（measurement）をもたらしてもよい。それゆえに，操
作側面の仕様化なしでは，要求事項は，一意に仕様化されない。利用の状況は，この概念を
代わりに表現した用語である。
注記10 この要求事項は，主として外部品質属性及び利用時の品質属性に関するソフトウェア品質要
求事項に適用される。ソフトウェアの内部品質属性の測定量（measures）は，多くの場合は
静的である。この場合，操作側面は，関係しない。
ソフトウェア品質要求事項の目標値を仕様化する場合，受入れ可能な許容範囲を文書化しなければなら
ない。
注記11 ISO/IEC 25020のA.2.1は，品質測定量（measure）の要素についての測定（measurement）の
信頼性に影響する課題の一覧を提供している。
6.3.3
ソフトウェア品質要求事項の検証
6.3.3の要求事項及び推奨事項は，ソフトウェア品質要求事項の品質を確実にすることを目指している。
ソフトウェア品質要求事項は，検証可能でなければならない。
特別なツール，技術又は労力（工数），時間などの他の資源を検証するために必要とする場合，このこと
を文書化することが望ましい。ソフトウェア品質要求事項を検証するために必要な時間及び労力（工数）
は，文書化することが望ましい。ソフトウェア品質要求事項を検証するために特別な資源又は能力を必要
とする場合，これらの要求は，文書化されなければならない。
ソフトウェア品質要求事項間に存在する識別された矛盾を文書化しなければならない。
注記1 開発プロジェクトで二つ以上のソフトウェア品質要求事項を達成できるかどうかを理解する
ために，基本的な品質モデルについての深い理解が，多くの場合，必須である。例えば，信
頼性に対する高い要求事項，保守性に対する高い要求事項及び効率性に対する高い要求事項
を同時に満たすことは困難であるかもしれないということを，実際の経験は，示している。
JIS X 0129-1:2003（JIS X 25010）の品質モデルは，このような関係を示唆する情報を提供し
ていない。要求事項に一貫性があった場合でも，実際にそれを全て満たすのは困難である。
何が達成できるかどうかは，ほとんどの場合，ソフトウェア開発者の能力によって決まる。
また，利用する手法，ツール及び技術にも，依存している。
注記2 要求事項間の整合性を確保するプロセスは，異なる使用状況に対して異なる要求事項を使用
するだけでなく，優先権及び優先順位を設定することを含んでいてもよい。
ソフトウェア品質要求事項と実装の制約との間の識別された矛盾を文書化しなければならない。
ソフトウェア品質要求事項に関して識別された課題を解決するという追加的な又は変更されたソフトウ
ェア品質要求事項は，元々のソフトウェア品質要求事項に対して追跡可能でなければならない。差し替え
られた又は削除されたソフトウェア品質要求事項は，それ自体を書き留めなければならない。
ソフトウェア品質要求事項をレビューし，承認しなければならない。
19
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ソフトウェア品質要求を誰がレビューし，承認したかを文書化しなければならない。
注記3 ソフトウェア品質要求事項は，契約合意の一部であってもよい。
注記4 開発組織によるソフトウェア品質要求事項の承認は，組織が品質要求事項を満たす能力（技
術的，管理的及び経済的な能力）を保有していることを暗示している。
注記5 JIS Q 9001:2000の7.2.2は，製品要求レビューのための要求事項を提供する。
ソフトウェア品質要求事項は，構成管理システム及び変更管理システムに従って管理できるような（所
定の）様式で文書化されなければならない。
注記6 構成管理プロセスは，JIS X 0170の5.4.7に規定されている。
注記7 ソフトウェア品質要求事項の保守は，次に示す方法の幾つか又は全てを使って実施すること
ができる。
a) 個々の要求事項が変更されたときには，必ず版を更新する。
b) 最後に変更した日付を表示する。
c) 最後に変更した人を明記する。
d) 変更の論理的根拠を提供する。
e) 承認された変更実施事実（仕様書の所有者）を明記する。
20
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書A
（規定）
用語及び定義
この規格で使用する用語及び定義は，JIS X 25000で規定した用語及び定義を適用する。
注記 定義は，SQuaREシリーズの全ての規格において共通である。
A.1
取得者（acquirer）
供給者から，システム，ソフトウェア製品又はソフトウェアサービスを，取得又は調達する個人又は組
織（JIS X 0160:1996参照。）。
A.2
分析モデル（analysis model）
一つ以上の基本測定量（measures）及び／又は導出測定量（measures）を，関連する判断基準に結び付け
るアルゴリズム又は計算。
A.3
属性（attribute）
人手又は自動的な手段によって，定量的又は定性的に識別できる固有の特性又は特徴（JIS X 0141:2009
参照。）。
A.4
品質測定量のための属性（attribute for quality measure）
ソフトウェア製品自体，ソフトウェア製品の使用又はソフトウェア製品の開発に関わる属性。
注記 品質測定量（measures）の属性は，測定（measurement）の根源を得るために使用する。
A.5
基本測定量（base measure）
単一の属性とそれを定量化するための方法とで定義した測定量。
注記 基本測定量（measures）は，他の測定量（measures）と機能的に独立した測定量（measures）で
ある（JIS X 0141:2009参照。）。
A.6
商用既製ソフトウェア製品，COTSソフトウェア製品（commercial-off-the-shelf software product）
市場からのニーズを取り入れ，商品として利用でき，広範囲の一般利用者によって利用のしやすさが実
証されているソフトウェア製品。
A.7
利用の状況（context of use）
利用者，仕事，装置（ハードウェア，ソフトウェア及び資材），並びに製品が使用される物理的及び社会
的環境（JIS Z 8521:1999参照。）。
A.8
カスタムソフトウェア（custom software）
利用者の要求定義に基づいて特定の用途のために開発されたソフトウェア製品。
21
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
A.9
データ（data）
基本測定量（measures），導出測定量（measures）及び／又は指標に割り当てられた値の集合（JIS X
0141:2009参照。）。
A.10
判断基準（decision criteria）
アクション若しくは追加調査の必要性を決めるため又は与えられた結果の信頼度のレベルを記述するた
めに使う，しきい（閾）値，目標又はパターン（JIS X 0141:2009参照。）。
A.11
導出測定量（derived measure）
複数の基本測定量（measures）の値の関数として定義した測定量（measures）（JIS X 0141:2009参照。）。
注記 数学的関数を用いた基本測定量（measures）の変換も導出測定量（measures）として扱うことが
できる。
A.12
開発者（developer）
ソフトウェアライフサイクルプロセスを通して，開発作業（要求分析，設計及び受入れテストを含む。）
を遂行する組織（JIS X 0160:1996参照。）。
A.13
規格の部門（division of standards）
規格の集合であって，他の規格集合とは補完的な目的にかなうもの。
A.14
エンドユーザ（end user）
システムの結果から最終的な利益を得る人。
注記 エンドユーザは，ソフトウェア製品の専任の運用者又は公共の一員のような一時的な利用者で
もよい。
A.15
実体（entity）
その属性を測定することによって特徴付けが行われる対象。
例 実体としては，プロセス，製品，プロジェクト又は資源がある（JIS X 0141:2009参照。）。
A.16
評価方法（evaluation method）
特定の製品構成要素又は製品全体に対して，仕様化された測定（measurement）の結果を得るために，評
価者によって実行される行為を記述した手続。
A.17
評価モジュール（evaluation module）
ソフトウェア品質特性，品質副特性又は属性を測定するための評価技術の組。
注記 評価モジュールは，評価方法及び技法，評価対象入力及び測定し収集すべきデータ，並びに支
援手続及びツールを含む。
A.18
評価者（evaluator）
22
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
評価を行う人又は組織。
A.19
外部ソフトウェア品質（external software quality）
システムが特定の条件の下で使用されたときに，明示的ニーズ及び暗黙のニーズを満たすように，シス
テムが行動できるようにするソフトウェア製品の能力。
注記 行動の属性は，ソフトウェア製品の試験中及び運用中にソフトウェア製品を実行することによ
って検証及び／又は妥当性確認ができる。
例 試験中に見つかった故障数は，プログラムに現存している障害数に関連した外部ソフトウェア品
質測定量（measure）をいう。ただし，試験では全ての障害を見つけられないし，障害は異なった
状況では明らかに異なった故障を引き起こすかもしれないので，試験中の故障数とプログラム内
の障害数とは，一致するものではない。
A.20
故障（failure）
要求された機能を遂行する製品の能力が尽きる状態，又は事前に仕様化された制限内で機能を遂行する
製品の能力がない状態（IEEE 610.12-1990参照。）。
A.21
障害（fault）
計算機プログラム内の不正確なステップ，プロセス又はデータの定義（IEEE 610.12-1990参照。）。
A.22
機能要求（functional requirement）
システム又はシステムの構成要素が実行できなければならない機能を指定する要求（IEEE 610.12-1990
参照。）。
注記 “機能性”というソフトウェア品質特性は，合目的性，正確性，相互運用性，セキュリティ及
び機能性標準適合性の仕様化又は評価に使用することができる［JIS X 0129-1:2003（JIS X
25010）参照。］。
A.23
暗黙のニーズ（implied needs）
明示されていないが，事実上のニーズ。
注記 暗黙のニーズには，ソフトウェア製品が特定の条件下で利用されて初めて明らかになるものが
ある。
例 暗黙のニーズには，次のものがある。
− 提示されていないが，他の明示的ニーズによって暗示されたニーズ
− 明らかで，いうまでもないとみなされているので提示されないニーズ
A.24
指標（indicator）
定義された情報ニーズに関するモデルから導出した特定の属性の見積り又は評価を示す測定量
（measure）（JIS X 0141:2009参照。）。
注記 JIS X 0133では，この定義は，“他の測定値（measure）の見積り又は予測に使うことができる
測定値（measure）”とされている。
23
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
A.25
情報ニーズ（information need）
目的，目標，リスク及び問題点を管理するために必要となる見解（JIS X 0141:2009参照。）。
A.26
情報成果物（information product）
ある情報ニーズに着目した一つ以上の指標及びそれに関連する解釈。
例 欠陥率の実績を予測と比較して，その違いが問題となるかどうかを総合評価したもの（JIS X
0141:2009参照。）。
A.27
情報システムニーズ（information system needs）
品質要求について外部測定量（measures）及び，ときには内部測定量（measures）によって規定できるニ
ーズ。
A.28
中間ソフトウェア製品（intermediate software product）
ソフトウェア開発プロセスの他の段階に入力として利用されるソフトウェア開発プロセスの製品。
例 中間ソフトウェア製品は，静的及び動的モデル，他の文書並びにソースコードを含んでいる。
A.29
ソフトウェア中間製品へのニーズ（intermediate software product needs）
内部測定量（measures）によって品質要求として規定することができるニーズ。
A.30
内部ソフトウェア品質（internal software quality）
ソフトウェア製品が特定の条件の下で使用されたときに，明示的ニーズ及び暗黙のニーズを満たす能力
をもたらすソフトウェア製品の静的な属性の集合の能力。
注記1 静的な属性は，ソフトウェアアーキテクチャ，構造及びその構成部品に関係する属性を含む。
注記2 静的な属性は，レビュー，検査及び／又は自動化ツールによって検証することができる。
例 コード行数，複雑度の測定量（measures）及びウォークスルーで発見した障害の数は，全て，ソ
フトウェア製品そのものに作りこまれた内部ソフトウェア品質測定量（measures）をいう。
A.31
保守者（maintainer）
保守活動を実施する個人又は組織（JIS X 0160:1996参照。）。
A.32
測定量（名詞）［measure (noun)］
測定（measurement）の結果として値が割り当てられる変数。
注記 “測定量（measure）”という用語は，基本測定量（measure），導出測定値（measure）及び指標
をまとめて参照するために使う（JIS X 0141:2009参照。）。
A.33
測定する（動詞）［measure (verb)］
測定（measurement）を行う行為（JIS X 0133-1:1999参照。）。
A.34
測定（measurement）
24
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
測定量（measure）の値を決定するという目的をもった操作の集合（JIS X 0141:2009参照。）。
注記 測定（measurement）は，ソースプログラムの言語（例えば，ADA，C，COBOL）などの定量
的分類を指定することを含むことができる。
A.35
測定の関数（measurement function）
複数の基本測定量（measure）を結合するために遂行するアルゴリズム又は計算（JIS X 0141:2009参照。）。
A.36
測定方法（measurement method）
特定の尺度に関して属性を定量化するために使う一連の操作の論理的な順序を一般的に記述したもの
（JIS X 0141:2009参照。）。
A.37
測定手続（measurement procedure）
与えられた方法に従って，ある特定の測定（measurement）を遂行するときに使う具体的に記述した操作
の集合（JIS X 0141:2009参照。）。
A.38
測定プロセス（measurement process）
プロジェクト全体又は組織における測定（measurement）の仕組みの中でソフトウェアの測定
（measurement）を確立，計画，遂行及び評価するためのプロセス。
A.39
観測（observation）
基本測定量（measure）に対する値を得るために測定（measurement）手続を適用する実現例（JIS X
0141:2009参照。）。
A.40
運用者（operator）
システムを運用する個人又は組織（JIS X 0160:1996参照。）。
A.41
プロセス（process）
インプットをアウトプットに変換する，相互に関連する又は相互に作用する一覧の活動（JIS Q 9000:2006
参照。）。
A.42
利用時の品質（測定量）［quality in use (measure)］
特定の利用者の使用する製品が，特定の利用の状況において，有効性，生産性，安全性及び満足度に関
して特定の目標を達成するための利用者ニーズを満たす程度。
A.43
品質測定量の要素（quality measure elements）
ソフトウェア品質測定量（measure）を構成する測定量（measure）。基本測定量（measure）又は導出測定
量（measure）のいずれかである。
注記 ある実体のソフトウェア品質特性又は品質副特性は，ソフトウェア品質測定量（measure）を計
算した後，導出される。
25
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
A.44
品質モデル（quality model）
品質要求の仕様化及び品質評価に対する枠組みを提供する特性の定義された集合及び特性間の関係の集
合。
A.45
評定（rating）
測定値を適切な評定水準に対応付ける行為。特定の品質特性に対して，ソフトウェア製品に関連する評
定水準を決定するために使用される。
A.46
評定水準（rating level）
順序尺度上の点のことで，測定（measurement）尺度を分類するために使用される。
注記1 評定水準は，明示的ニーズ又は暗黙のニーズに基づいて，ソフトウェア製品を分類（評定）
することを可能にする。
注記2 適切な評定水準は，例えば，利用者，管理者，開発者のような異なる品質の視点に関係付け
てもよい。
A.47
要求（requirements）
何かを達成して欲しい，又は何かを実現して欲しい，というはっきりしたニーズの表現。
注記 要求は，契約の一部として仕様化してもよい。また，例えば，消費者向けソフトウェアのよう
な不特定の利用者のために製品を開発する場合のように，開発組織が仕様化してもよい。利用
者が比較及び選択する目的のために製品を評価する場合のように，より一般化してもよい。
A.48
尺度（scale）
連続的若しくは離散的な値の順序集合又は分類の集合で，それに属性を対応付けるもの（JIS X 0141:2009
参照。）。
注記 尺度の種別の例を，次に示す。
− 分類の集合に対応する名義尺度
− 尺度上の点の順序に対応する順序尺度
− 順序付けられた等間隔の点をもつ尺度である間隔尺度
− 順序付けられた等間隔の点と絶対値ゼロの点とをもつ尺度である比率尺度（比例尺度，比
尺度とも呼ぶ。）
測定量（measures）は，定性的なデータを扱う場合には，名義尺度又は順序尺度を使用し，
定量的なデータを扱う場合には，間隔尺度又は比率尺度を使用する。
A.49
ソフトウェア製品（software product）
計算機プログラム，手続並びにその関連する文書及びデータを含めたまとまり（JIS X 0160:1996参照。）。
注記1 製品は，開発者，保守者などの利用者向けに作成された製品及び中間製品を含む。
注記2 SQuaREシリーズでは，ソフトウェア品質はソフトウェア製品品質と同じ意味をもつ。
A.50
ソフトウェア製品評価（software product evaluation）
26
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
特定の手続に従って，ソフトウェア製品の一つ以上の特性の総合評価を行うことによって構成される技
術的操作。
A.51
ソフトウェア品質（software quality）
特定の条件で利用する場合の，明示的ニーズ又は暗黙のニーズを満たすためのソフトウェア製品の能力。
注記 この定義は，JIS Q 9000:2006の品質定義と異なる。主な理由は，ソフトウェア品質の定義が明
示的ニーズ又は暗黙のニーズの満足に言及しているのに対し，JIS Q 9000の品質定義が要求の
満足に言及していることによる。
A.52
ソフトウェア品質特性（software quality characteristic）
ソフトウェア品質に影響を及ぼすソフトウェア品質属性の分類。
注記 ソフトウェア品質特性は，複数の階層の副特性及び最終的にはソフトウェア品質属性に改善し
てもよい。
A.53
ソフトウェア品質評価（software quality evaluation）
ソフトウェア製品が，明示的ニーズ又は暗黙のニーズをどれだけ満たすことができるかの程度を示すた
めの体系的な審査。
A.54
利用時のソフトウェア品質（software quality in use）
特定の利用者が，特定の利用の状況において，有効性，生産性，安全性及び満足度に関する特定の目標
を達成できるためのソフトウェア製品の能力。
注記 製品を引き渡す前は，試験環境で，対象とする利用者，目標及び利用の状況のために，利用時
の品質を特定し測定することができる。利用時は，実際の利用者，目標及び利用の状況のため
に，利用時の品質を測定できる。実際の利用時の品質が試験環境で，より早い段階に測定した
利用時の品質と異なることがあるので，利用者の実際のニーズが，要求として予期したものと
同じでなくてもよい。
A.55
ソフトウェア品質測定量（software quality measure）
内部ソフトウェア品質，外部ソフトウェア品質又は利用時のソフトウェア品質の測定量（measure）。
注記 内部ソフトウェア品質，外部ソフトウェア品質又は利用時のソフトウェア品質は，JIS X
0129-1:2003（JIS X 25010）の品質モデルに記述されている。
A.56
利害関係者（stakeholder）
システムに，権利，持分又は請求権をもっている関係者。又は，関係者のニーズ及び期待に合う特性を
システムがもっていることに，権利，持分又は請求権をもっている関係者（JIS X 0170参照。）。
注記 利害関係者には，エンドユーザ，エンドユーザの組織，支援者，開発者，製作者，教育訓練者，
保守者，廃棄者，取得者，供給者組織及び規制団体を含むが，それだけには限定はされない。
A.57
供給者（supplier）
取得者と契約を交わし，その条項に基づいてシステム，ソフトウェア製品又はソフトウェアサービスを
27
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
提供する組織（JIS X 0160:1996参照。）。
A.58
システム（system）
一つ以上の明記された目的を達成するために編成された相互に影響する要素を組み合わせたもの。
注記1 システムとは，それが提供する製品又はサービスとみなしてもよい。
注記2 実際には，その意味の解釈は，例えば，航空機システムのように組み合わされた名詞の使用
によってしばしば明確にされる。別の表現として，システムという言葉を使わずに，例えば，
航空機という，文脈に依存する同義語によって単に置き換えられる可能性がある。ただ，こ
れは，システム原則の全体像が曖昧になる（JIS X 0170参照。）。
A.59
プロセス対象（target of process）
測定（measurement）プロセス又は評価プロセスが適用される，ソフトウェア製品，又はソフトウェア製
品によって実行されるタスク。
A.60
測定の単位（unit of measurement）
取決め又は慣習に従って定義し採用した特別の量で，同じ種類の他の量をそれと比較することによって，
その量の相対的な大きさを表現するためのもの（JIS X 0141:2009参照。）。
A.61
利用者（user）
ある機能を果たすシステムを利用する個人又は組織。
注記 利用者には運用者，ソフトウェアがもたらす結果の受給者，又はソフトウェアの開発者若しく
は保守者を含めてもよい（JIS X 0141:2009参照。）。
A.62
妥当性確認（validation）
客観的証拠を提示することによって，特定の意図された用途又は適用に関する要求事項が満たされてい
ることを確認すること。
注記1 “妥当性確認済み”という用語は，妥当性確認が済んでいる状態を表すために用いられる（JIS
Q 9000:2006参照。）。
注記2 設計及び開発において，妥当性確認は，利用者のニーズへの適合性を決定するために製品を
検査するプロセスに関与する。
注記3 妥当性確認は，通常，定義された運用条件の下で最終製品に対して実施される。妥当性確認
は，より早期の工程が必要となってもよい。
注記4 複数の異なる意図された用途があるときには，複数の妥当性確認を実行してもよい。
A.63
値（value）
測定（measurement）することによって，ある実体がもつ属性へ割り付けられた数値又は分類。
A.64
検証（verification）
客観的証拠を提示することによって，規定要求事項が満たされていることを確認すること。
注記1 “検証済み”という用語は，検証が済んでいる状態を示すために用いられる（JIS Q 9000:2006
28
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
参照。）。
注記2 設計及び開発において，検証は，与えられた活動に対する明示された要求との適合性を決定
するために，与えられた活動の結果を検査するプロセスに関与する。
29
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書B
（参考）
JIS X 0170:2004からのプロセス規定の引用
B.1
概要
この附属書中の文章は，JIS X 0170からの引用抜粋である。JIS X 0170の5.5.2からの情報はB.2に記載
し，JIS X 0170の5.5.3からの情報はB.3に記載している。
B.2
利害関係者要求定義プロセス
利害関係者要求定義プロセスは，定義された環境において，利用者及び他の利害関係者によって必要と
されるサービスを提供できるように，あるシステムに対して要求を定義することを目的とする。利害関係
者要求プロセスでは，システムのライフサイクルを通じて，システムに関係している利害関係者又は利害
関係者のクラス並びに彼らのニーズ及び要望を識別する。利害関係者要求定義プロセスでは，これらを分
析し，利害関係者の要求の共通集合に変換する。利害関係者の要求は，システムがその運用環境との間に
もつ意図された相互作用を表現する。利害関係者の要求は，システムがニーズを満たすことを確かめるた
めに，結果として生まれた各運用サービスの妥当性を確認するときに参照される。
利害関係者要求定義プロセスは，次のアクティビティを識別する。
a) システムのライフサイクルを通じて，システムに正当な関係をもつ個々の利害関係者又は利害関係者
のクラスを識別する。
b) 利害関係者の要求を引き出す。
c) システムソリューション上の制約事項，すなわち，既存の合意，管理上の決定及び技術上の決定の結
果がもたらす不可避な影響を定義する。
d) 予想される運用及び支援のシナリオ並びにそれらの環境に合致して，要求される全てのサービスを識
別するために，そのアクティビティの順序の代表的な集合を定義する。
e) 利用者とシステムとの間の相互作用を識別する。
f)
健康，安全，セキュリティ，環境及び他の利害関係者の要求及び重大な品質に関する機能を明示する。
g) 引き出された要求の完全な集合を分析する。
h) 要求に関する問題を解決する。
i)
ニーズ及び期待が適切に捉えられ，表現されていることを確実にするために，分析された要求を該当
する利害関係者へフィードバックする。
j)
利害関係者の要求が正確に表現されていることを，利害関係者とともに確立する。
k) ライフサイクルを通して，及びその後も，要求の管理に適した形式で利害関係者の要求を記録する。
l)
利害関係者の要求から利害関係者のニーズの源への追跡可能性を維持する。
利害関係者要求定義プロセスの実施に成功すると次の状態になる。
a) サービスで要求される特性及びサービスで要求される利用のコンテキスト（内容，状況，背景）が明
記されている。
b) システムソリューションにおける制約が定義されている。
c) 利害関係者の要求から，利害関係者及び利害関係者ニーズへの追跡可能性が樹立されている。
30
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
d) システム要求を定義するための基礎が記述されている。
e) サービスの適合の妥当性を確認するための基礎が定義されている。
f)
サービス又は製品を供給するための交渉及び合意のための基礎が提供されている。
B.3
要求分析プロセス
要求分析プロセスは，望まれたサービスの利害関係者の要求主導の視点を，これらのサービスが提供で
きる要求された製品の技術的な視点へ変換することを目的とする。このプロセスは，利害関係者の要求と
合致し，制約が許す限り，いかなる特定の実装も示さない，将来のシステムの表現を作り上げる。それは，
利害関係者の要求を満たすために，開発者の観点から，将来のシステムがもつべき特性及び規模を明示す
る測定可能なシステム要求を作成することになる。
要求分析プロセスは，次のアクティビティを識別する。
a) 提供される振る舞い及び性質の観点から，システムの機能的な境界を定義する。
b) システムが実行を要求されている各機能，システムが運用者を含めてどのように良好に機能を実行す
ることが要求されているか，システムが機能を実行することができる条件，システムが機能の実行を
開始する条件及びシステムが機能の実行を停止する条件を定義する。
c) 利害関係者の要求によってもち込まれるか，又は回避できないソリューションの制限である，必要な
実装制約を定義する。
d) 技術的な達成度のアセスメントを可能にする，技術的な尺度及び利用時の品質についての測定量
（measures）を定義する。
e) システムのリスクの識別又は重大性によって正当化される，健康，安全，セキュリティ，信頼性，可
用性及び支援可能性のような，重大な品質に関係のあるシステム要求及び機能を明示する。
f)
各要求，要求の対又は要求の集合が，全体としてリスク抑制のための完全性をもつことを確実にする
ために，システム要求のリスク抑制のための完全性を分析する。
g) システム要求と利害関係者の要求との間の追跡可能性を明示する。
h) システムライフサイクルを通して，関連する論理的根拠，決定及び前提とともに，システム要求の集
合を維持する。
要求分析プロセスの実施に成功すると次の状態になる。
a) 製品ソリューションに対して要求される特性，属性並びに機能及び性能への要求が明示されている。
b) システムの方式設計及びそれを実現する手段に影響を及ぼすであろう制約が明示されている。
c) システムの方式設計に影響を及ぼす追跡可能性及び方式設計を実現する方法を特定する。
d) システム要求から利害関係者の要求へのリスク抑制のための完全性及び追跡可能性が樹立されてい
る。
31
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
参考文献
JIS Q 9000:2006，品質マネジメントシステム−基本及び用語
注記 対応国際規格：ISO 9000:2005，Quality management systems−Fundamentals and vocabulary（IDT）
JIS Q 9001:2000，品質マネジメントシステム−要求事項
注記1 対応国際規格：ISO 9001:2000，Quality management systems−Requirements（IDT）
注記2 ISO 9001:2000の最新版はISO 9001:2008である。ISO 9001:2008を対応国際規格としたJIS Q
9001:2008が発行されている。
JIS X 0001:1994，情報処理用語−基本用語
注記 対応国際規格：ISO/IEC 2382-1:1993，Information technology−Vocabulary−Part 1: Fundamental
terms（MOD）
JIS X 0133-2:2001，ソフトウェア製品の評価−第2部：計画及び管理
注記 対応国際規格：ISO/IEC 14598-2:2000，Software engineering−Product evaluation−Part 2: Planning
and management（IDT）
JIS X 0133-4:2001，ソフトウェア製品の評価−第4部：取得者のプロセス
注記 対応国際規格：ISO/IEC 14598-4:1999，Software engineering−Product evaluation−Part 4: Process
for acquirers（IDT）
JIS X 0133-5:1999，ソフトウェア製品の評価−第5部：評価者のプロセス
注記 対応国際規格：ISO/IEC 14598-5:1998，Information technology−Software product evaluation−Part
5: Process for evaluators（IDT）
JIS X 0133-6:2002，ソフトウェア製品の評価−第6部：評価モジュールの文書化
注記 対応国際規格：ISO/IEC 14598-6:2001，Software engineering−Product evaluation−Part 6:
Documentation of evaluation modules（IDT）
JIS X 0141:2009，システム及びソフトウェア技術−測定プロセス
注記 対応国際規格：ISO/IEC 15939:2007，Systems and software engineering−Measurement process（IDT）
JIS X 0160:1996，ソフトウェアライフサイクルプロセス
注記 対応国際規格：ISO/IEC 12207:1995，Information technology−Software life cycle processes（IDT）
JIS X 0170:2004，システムライフサイクルプロセス
注記 対応国際規格：ISO/IEC 15288:2002，Systems engineering−System life cycle processes（IDT）
JIS X 25001:2012，ソフトウェア製品の品質要求及び評価（SQuaRE）−計画及び管理
注記 対応国際規格：ISO/IEC 25001:2007，Software engineering−Software product Quality Requirements
and Evaluation (SQuaRE)−Planning and management（IDT）
JIS Z 8530:2000，人間工学−インタラクティブシステムの人間中心設計プロセス
注記 対応国際規格：ISO 13407:1999，Human-centred design processes for interactive systems（IDT）
IEC 61508，Functional safety of electrical/electronic/programmable electronic safety-related systems
ISO/IEC 25021，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)−
Quality measure elements
ISO/IEC 25022，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)−
Measurement for internal quality
32
X 25030：2012 (ISO/IEC 25030：2007)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ISO/IEC 25023，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)−
Measurement for external quality
ISO/IEC 25024，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)−
Measurement for quality in use
ISO/IEC 25025，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)−
Documentation of evaluation modules
ISO/IEC 25042，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)−
Process for acquirers
ISO/IEC 25043，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)−
Process for evaluators
ISO/IEC TR 9126-2:2003，Software engineering−Product quality−Part 2: External metrics
注記 対応標準仕様書：TS X 0111-2:2009 ソフトウェア製品の品質−第2部：JIS X 0129-1による外
部測定法（IDT）
ISO/IEC TR 9126-3:2003，Software engineering−Product quality−Part 3: Internal metrics
注記 対応標準仕様書：TS X 0111-3:2009 ソフトウェア製品の品質−第3部：JIS X 0129-1による内
部測定法（IDT）
ISO/IEC TR 9126-4:2004，Software engineering−Product quality−Part 4: Quality in use metrics
注記 対応標準仕様書：TS X 0111-4:2009 ソフトウェア製品の品質−第4部：JIS X 0129-1による利
用時の品質測定法（IDT）