X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

（1） 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

目 次 

ページ 

序文 ··································································································································· 1 

1 適用範囲························································································································· 1 

2 適合性···························································································································· 2 

2.1 意図した用途 ················································································································ 2 

2.2 プロセスへの適合性 ······································································································· 2 

2.3 情報項目内容への適合性 ································································································· 3 

2.4 完全適合性 ··················································································································· 3 

2.5 修整適合性 ··················································································································· 3 

3 引用規格························································································································· 4 

4 用語及び定義並びに略語 ···································································································· 4 

4.1 用語及び定義 ················································································································ 4 

4.2 略語 ···························································································································· 8 

5 概念······························································································································· 9 

5.1 序文 ···························································································································· 9 

5.2 要求事項の基本 ············································································································· 9 

5.3 実践上の考慮 ··············································································································· 16 

5.4 要求事項の情報項目 ······································································································ 18 

6 プロセス························································································································ 20 

6.1 要求プロセス ··············································································································· 20 

6.2 利害関係者要求事項定義プロセス····················································································· 21 

6.3 要求事項分析プロセス ··································································································· 29 

6.4 他の技術プロセスにおける要求エンジニアリングアクティビティ ··········································· 35 

6.5 要求事項管理 ··············································································································· 40 

7 情報項目························································································································ 44 

8 情報項目に対する指針 ······································································································ 45 

8.1 要求情報項目のアウトライン ·························································································· 45 

8.2 利害関係者要求仕様書 ··································································································· 45 

8.3 システム要求仕様書 ······································································································ 46 

8.4 ソフトウェア要求仕様書 ································································································ 48 

9 情報項目の内容 ··············································································································· 50 

9.1 序文 ··························································································································· 50 

9.2 一般的内容 ·················································································································· 50 

9.3 利害関係者要求仕様（StRS）書 ······················································································· 51 

9.4 システム要求仕様（SyRS）書 ························································································· 53 

9.5 ソフトウェア要求仕様（SRS）書 ····················································································· 57 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 目次 

（2） 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

ページ 

附属書A（規定）システムレベルの運用概念 ············································································ 64 

附属書B（参考）組織レベルの運用概念··················································································· 75 

附属書C（参考）JIS X 0170及びJIS X 0160からのプロセスマッピング ········································ 77 

附属書D（規定）修整の方針 ································································································· 81 

参考文献 ···························································································································· 83 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

（3） 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

まえがき 

この規格は，工業標準化法第12条第1項の規定に基づき，一般社団法人情報処理学会情報規格調査会

（IPSJ/ITSCJ）及び一般財団法人日本規格協会（JSA）から，工業標準原案を具して日本工業規格を制定す

べきとの申出があり，日本工業標準調査会の審議を経て，経済産業大臣が制定した日本工業規格である。 

この規格は，著作権法で保護対象となっている著作物である。 

この規格の一部が，特許権，出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意

を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許権，出願公開後の特許出願及び実

用新案権に関わる確認について，責任はもたない。 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

日本工業規格          JIS 

X 0166：2014 

(ISO/IEC/IEEE 29148：2011) 

システム及びソフトウェア技術− 

ライフサイクルプロセス−要求エンジニアリング 

Systems and software engineering-Life cycle processes- 

Requirements engineering 

序文 

この規格は，2011年に第1版として発行されたISO/IEC/IEEE 29148を基に，技術的内容及び構成を変

更することなく作成した日本工業規格である。 

なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。 

この規格は，システム及びソフトウェアの全ライフサイクルの中で，要求エンジニアリングに関連する

プロセス及び製品を統一的に扱う。この規格は，次の規格を調和させた結果である。 

JIS X 0160:2012 ソフトウェアライフサイクルプロセス 

注記1 対応国際規格：ISO/IEC 12207:2008 (IEEE Std 12207-2008)，Systems and software engineering

−Software life cycle processes（IDT） 

JIS X 0170:2013 システムライフサイクルプロセス 

注記2 対応国際規格：ISO/IEC 15288:2008 (IEEE Std 15288-2008)，Systems and software engineering

−System life cycle processes（IDT） 

ISO/IEC/IEEE 15289:2011，Systems and software engineering−Content of life-cycle information products 

(documentation) 

注記3 対応する日本工業規格が制定される予定である。 

ISO/IEC TR 19759，Software Engineering−Guide to the Software Engineering Body of Knowledge 

(SWEBOK) 

IEEE Std 830，IEEE Recommended Practice for Software Requirements Specifications 

IEEE Std 1233，IEEE Guide for Developing System Requirements Specifications 

IEEE Std 1362，IEEE Guide for Information Technology−System Definition−Concept of Operations 

(ConOps) Document 

ISO/IEC TR 24748-1，Systems and software engineering−Life cycle management−Part 1: Guide for life 

cycle management 

ISO/IEC/IEEE 24765，Systems and software engineering−Vocabulary 

1 

適用範囲 

この規格の適用範囲を次に示す。 

− システム・ソフトウェア製品（サービスを含め）に対する要求事項を工学的に扱うためにライフサイ

クル各段階において実施することが必要なプロセスを規定する。 

2 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− JIS X 0160:2012及びJIS X 0170:2013に記述されている要求事項を扱う諸プロセス（以下，要求プロ

セスという。注記1参照）及び要求事項に関連する諸プロセス（以下，要求関連プロセスという。注

記1参照）を適用するための指針を与える。 

注記1 要求プロセスとは，利害関係者要求事項定義プロセス（JIS X 0160:2012及びJIS X 

0170:2013），要求事項分析プロセス（JIS X 0170:2013），及びソフトウェア要求事項分析プ

ロセス（JIS X 0160:2012）を指す。要求関連プロセスとは，要求に関連するアクティビテ

ィ・タスクをもつ技術プロセス及びプロジェクトプロセスで，方式設計，検証，妥当性確

認，構成管理，情報管理及び測定プロセスである（6.1及び附属書Cを参照）。 

− 要求プロセスの実施を通じて作成することが要求される情報項目を規定する。 

− 情報項目に要求される内容を規定する。 

− 要求される情報項目及び関連情報項目の様式に対する指針を与える。 

この国際規格は，以下のような人が利用することを想定している。 

− 人が作るシステム，ソフトウェア中心システム，ソフトウェア・ハードウェア製品，及びこれらのシ

ステム・製品に関連したサービス，を取り扱うプロジェクトにおいて，JIS X 0160:2012及びJIS X 

0170:2013を使用する又は使用を計画している人（プロジェクトの適用範囲，製品，方法論，規模，

又は複雑さは問わない。）。 

− 適用しようとしている要求エンジニアリングプロセスがJIS X 0170:2013及び／又はJIS X 0160:2012

に適合することを保証する助けとなるよう，要求エンジニアリング活動を実行しようとする人。 

− 人が作るシステム，ソフトウェア中心システム，ソフトウェア・ハードウェア製品，及びこれらのシ

ステム・製品に関連したサービス，を取り扱うプロジェクトにおいて，ISO/IEC/IEEE 15289:2011を

使用する又は使用を計画している人（プロジェクトの適用範囲，製品，方法論，規模，又は複雑さは

問わない。）。 

− 要求エンジニアリングプロセスを適用する間に開発する情報項目がISO/IEC/IEEE 15289:2011に適合

することを保証する助けになるよう，要求エンジニアリング活動を実行しようとする人。 

注記2 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。 

ISO/IEC/IEEE 29148:2011，Systems and software engineering−Life cycle processes−

Requirements engineering（IDT） 

なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”

ことを示す。 

2 

適合性 

2.1 

意図した用途 

この規格は，JIS X 0170:2013及びJIS X 0160:2012の中で要求エンジニアリングを扱うプロセスを実行

するための指針を提供する。この規格は，また，これらのプロセスを実施した結果得られる情報項目，又

は文書化に対して，必須内容の規定及び推奨様式を提供する。この規格の利用者は，プロセス規定若しく

は情報項目規定，又はその両方への適合性を主張することができる。 

2.2 

プロセスへの適合性 

この規格は，システム，製品，又はサービスのライフサイクルでの利用に適した要求エンジニアリング

3 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

プロセスに対する要求事項を規定する。 

この規格のプロセスに対する要求事項は，5.2.4，5.2.5，5.2.6，5.2.7及び6.1に含まれる。 

注記1 この規格の利用者がJIS X 0170:2013及び／又はJIS X 0160:2012への完全適合性を主張する

場合，暗黙り（裡）にこの規格におけるプロセスへの適合性も主張することになる。 

注記2 JIS X 0170:2013及び／又はJIS X 0160:2012への修整適合性を主張した場合でも，この規格

におけるプロセスへの適合性を必ずしも意味しているわけではない。 

2.3 

情報項目内容への適合性 

この規格は，システム，製品，又はサービスの全ライフサイクルで作成する要求エンジニアリングの情

報項目に対する要求事項を規定する。この規格の情報項目規定への適合性の主張とは次のことを意味する。 

利用者がこの規格に示す規定情報項目を作成し，かつ，要求エンジニアリング活動を通じて作成される

情報項目がこの規格で定義する内容の要求事項に適合していることを利用者が実証する。 

この規格の情報項目に関する規定は，箇条7に含まれている。この規格の情報項目内容に関する要求事

項は，箇条9及び附属書Aに含まれている。 

注記1 この規格の利用者がISO/IEC/IEEE 15289:2011への完全適合性を主張しても，この規格の情

報項目及び情報項目内容への適合性を主張してもよいことにならない。その理由は，この規

格が情報項目を追加しているからである。 

注記2 この規格において，参照を単純化するため，各情報項目をあたかも一つの独立した文書とし

て発行するかのように記載している。しかし，情報項目を発行しなくとも参照可能な場合，

別々の文書に分割される場合，又は他の情報項目と一つの文書に結合して発行する場合でも，

情報項目が適合するとみなされる。 

2.4 

完全適合性 

この規格への完全適合性を主張することは，次の全ての事項への適合性を主張することと等価である。 

− 5.2.4，5.2.5，5.2.6及び5.2.7に含まれる規定 

− 6.1に挙げるJIS X 0170:2013及びJIS X 0160:2012の要求エンジニアリング関連プロセス 

注記 要求エンジニアリング関連プロセスは，要求プロセス及び要求関連プロセスの総称である。 

− 箇条7に挙げる情報項目 

− この規格の箇条9及び附属書Aの情報項目の内容規定 

2.5 

修整適合性 

2.5.1 

プロセス 

この規格は修整プロセスを規定しない。JIS X 0170:2013の附属書Aはシステムライフサイクルの修整に

関する規定としての指示を提供する。JIS X 0160:2012の附属書Aはソフトウェアライフサイクルの修整に

関する規範的指示を提供する。 

2.5.2 

情報項目 

完全適合が主張できない場合でも，この規格を基にして情報項目の集合を確立する場合，修整適合性を

主張できる。そのためには，この規格の箇条を選択するか又は附属書Dにある修整プロセスに従って変更

する。さらに，修整されたテキスト，つまりこれに修整適合性を主張するもの，がどれかを宣言する。そ

の上で情報項目への要求事項が，修整してもなお満たされていることを修整プロセスの成果を証拠として

実証すれば，修整適合性は達成される。 

4 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3 

引用規格 

次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの

引用規格は，記載の年の版を適用し，その後の改正版（追補を含む。）は適用しない。 

JIS X 0160:2012 ソフトウェアライフサイクルプロセス 

注記 対応国際規格：ISO/IEC 12207:2008（IEEE Std 12207-2008），Systems and software engineering

−Software life cycle processes（IDT） 

JIS X 0170:2013 システムライフサイクルプロセス 

注記 対応国際規格：ISO/IEC 15288:2008（IEEE Std 15288-2008），Systems and software engineering

−System life cycle processes（IDT） 

ISO/IEC/IEEE 15289:2011，Systems and software engineering−Content of life-cycle information products 

(documentation) 

注記 対応する日本工業規格が制定される予定である。 

4 

用語及び定義並びに略語 

4.1 

用語及び定義 

この規格で用いる主な用語及び定義は，JIS X 0170:2013及びJIS X 0160:2012によるほか，次による。 

4.1.1 

取得者（acquirer） 

供給者から，製品又はサービスを取得又は調達する利害関係者（JIS X 0170:2013及びJIS X 0160:2012）。 

注記 取得者（acquirer）に対して通常用いられている用語には，ほかに納入先（buyer）・所有者

（owner）・購入者（purchaser）がある。 

4.1.2 

属性（attribute） 

人手又は自動的な手段によって，定量的又は定性的に識別できる固有の特性又は特徴（JIS X 25000:2010）。 

注記 ISO 9000では二つの属性のタイプを区別する。一つは何かに本来備わった永続的な特性，もう

一つは製品，プロセス，又はシステムに付与された特性（例えば，製品の価格，製品の所有者）。 

4.1.3 

ベースライン（baseline） 

公式にレビューされ，合意された仕様又は製品で，以降の開発の根拠として使用されるもの。その変更

は，公式の変更管理手順を通してだけ認められる（JIS X 0170:2013及びJIS X 0160:2012）。 

4.1.4 

組織レベルの運用概念（concept of operations） 

運用又は一連の運用に関する組織の前提条件・意図を，言葉及び図で，全体像として記述するもの

（ANSI/AIAA G-043-1992）。 

注記1 組織レベルの運用概念（ConOps）は，しばしば長期戦略計画及び年間運用計画の形で具体化

される。後者の場合，その計画内の運用の概念は，同時に実施する又は順次実施する連結し

た一連の運用を網羅する。この概念は，組織の運用の全体像を与えるために設計される。シ

ステムレベルの運用概念（OpsCon）も参照。 

注記2 これは，運用スペース・システム能力・インタフェース・運用環境を制限するための根拠に

なる。 

5 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

4.1.5 

条件（condition） 

要求事項を規定する測定可能な定性的属性又は定量的属性。 

4.1.6 

制約（constraint） 

システム要求事項，設計若しくは実装に，又はシステムの開発・変更に用いるプロセスに，外から求め

られる制限。 

注記 制約は，ソリューションに対して絶対的又は強制的に求められる要因であり，設計変更を制限

又は修正させることがある。 

4.1.7 

顧客（customer） 

製品又はサービスを受け取る組織又は人（JIS X 0170:2013及びJIS X 0160:2012）。 

注記 顧客は利害関係者の部分集合である。 

4.1.8 

導出要求事項（derived requirement） 

要求事項の集合及び組織から演えき（繹）又は推量して得られ，特別なシステム構成及びソリューショ

ンを導く要求事項。 

4.1.9 

開発者（developer） 

ライフサイクルプロセスを通して，開発作業（要求事項分析，設計，受入れテストなどを含む。）を遂行

する組織（JIS X 0160:2012）。 

注記 開発者は利害関係者の部分集合である。 

4.1.10 

文書（document） 

人が利用する上で一意に識別される情報単位で，例えば，紙若しくは電子形式のレポート，仕様，マニ

ュアル，又は本（ISO/IEC/IEEE 15289:2011）。 

4.1.11 

人間システム統合（human systems integration） 

多分野の協働を必要とする技術・管理プロセスで，全てのシステム要素での人間的側面の考察を統合す

るプロセス。システムエンジニアリング実践に不可欠なものである。 

注記 INCOSE SEHbk 3.2.2010から改変。 

4.1.12 

抽象度（level of abstraction） 

特定の詳細レベルで対象を見る視点。 

4.1.13 

モード（mode） 

製品に関する特徴又は機能的能力の集合（IEEE Std 1362-1998）。 

4.1.14 

システムレベルの運用概念（operational concept） 

一つのシステム又は関連する一組のシステムの，運用又は一連の運用に関して，組織の前提条件・意図

6 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

を言葉及び図で記述するもの（ANSI/AIAA G-043-1992）。 

注記 システムレベルの運用概念（OpsCon）は，一つ以上の特定システム，又は関連する一組のシス

テム，を利用する運用の全体像を与えるために設計する。組織の運用環境の中で利用者及び運

用者の視点から全体像を与えるものである。組織レベルの運用概念（ConOps）も参照。 

4.1.15 

運用シナリオ（operational scenario） 

イベントの発生順序を推測して記述するもの。製品又はサービス要素間の相互作用はもちろん，製品又

はサービスと，その環境及び利用者との相互作用を含む。 

注記 運用シナリオは，システムの要求事項及び設計の評価，並びにシステムの妥当性確認及び検証

に用いる。 

4.1.16 

運用者（operator） 

システムの運用を行う実体（JIS X 0160:2012）。 

注記1 運用者及び利用者の役割は，同一の個人又は組織に対して，同時に又は順次的に，付与され

る（JIS X 0160:2012）。 

注記2 この用語定義の中で，実体という用語は個人又は組織を意味する（JIS X 0160:2012）。 

4.1.17 

要求事項（requirement） 

ニーズとそれに付随する制約・条件とを変換した又は表現する文。 

注記1 “requirement”は，通常“要求”又は“要件”と訳される。この規格では，JIS X 0160:2012

及びJIS X 0170:2013との整合性を維持するため，通常“要求事項”を用いる。ただし，“要

求エンジニアリング”，“要求仕様”など，成語として定着している用語はそのまま用いる。 

注記2 要求事項は様々な層に存在し，上位レベルのニーズを表現する（例えば，ソフトウェア要素

要求事項）。 

注記3 この規格の箇条5で説明するように，一般に要求プロセスはニーズを要求事項に変換するプ

ロセスと考えられる。要求事項には，利害関係者要求事項，システム要求事項，ソフトウェ

ア要求事項，ソフトウェア要素要求事項というレベルがある。したがって，あるレベルの要

求プロセスに注目したとき，そのプロセスの前段階で決定された要求事項は上位レベルのニ

ーズの一部になる。例えば，システム要求事項定義プロセスは，システムニーズをシステム

要求事項に変換する。このとき，システムニーズには，上位レベルの利害関係者要求事項が

含まれる。 

4.1.18 

要求事項引出し（requirements elicitation） 

システムの取得者及び供給者が，そのシステム及びライフサイクルプロセスに対する要求事項を発見・

レビュー・明確化・理解・文書化するプロセス。 

注記 ISO/IEC/IEEE 24765:2010から改変。 

4.1.19 

要求エンジニアリング（requirements engineering） 

多分野の協働を必要とする工学で，取得者の領域と供給者の領域とを仲介し，対象とするシステム，ソ

フトウェア，又はサービスが要求事項を満足するように要求事項を確立・保守するための工学。 

7 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記 要求エンジニアリングは，要求事項の発見・抽出・開発・分析・検証手法の決定・妥当性確認・

伝達・文書化・管理に関わる。 

4.1.20 

要求事項管理（requirements management） 

システム，製品，又はサービスのライフサイクルを通じて，要求事項を識別・文書化・保守・伝達・追

跡できるようにする活動。 

4.1.21 

要求事項追跡可能性マトリクス（requirements traceability matrix） 

要求事項及びその源をリンクさせ，プロジェクトライフサイクルを通して追跡する表。 

4.1.22 

要求事項妥当性確認（requirements validation） 

要求事項が（個別であれ集合であれ）利害関係者の意図する正しいシステムを定義していることを，試

験によって確認すること。 

注記 EIA 632:1999から改変。 

4.1.23 

要求事項検証（requirements verification） 

要求事項が（個別であれ集合であれ）整形式になっていることを，試験によって確認すること。 

注記1 EIA 632:1999から改変。 

注記2 これは，要求事項又は要求事項集合が，良好な要求事項としての特性を獲得するためにレビ

ューされていることを意味する。 

4.1.24 

ソフトウェア要求仕様（software requirements specification） 

ソフトウェア及びその外部インタフェースへの要求事項（機能・性能・設計制約・属性）の構造化され

た集合。 

注記 IEEE Std 1012:2004から改変。 

4.1.25 

利害関係者（stakeholder） 

システムに，権利，持分，請求権若しくは関心をもっている個人若しくは組織，又は，ニーズ及び期待

に合致する特性をシステムがもつことに，権利，持分，請求権若しくは関心をもっている個人若しくは組

織（JIS X 0170:2013及びJIS X 0160:2012）。 

注記 利害関係者には，エンドユーザ・エンドユーザ組織・支援者・開発者・製作者・教育訓練者・

保守者・廃棄者・取得者・顧客・運用者・供給者組織・認可者・規制機関が含まれるが，これ

らに限定するものではない。 

4.1.26 

状態（state） 

ある一時点での機能若しくは副機能，又は要素の振る舞いを特徴付ける条件（ISO/IEC 26702）。 

4.1.27 

供給者（supplier） 

製品又はサービスの供給に関して取得者と合意を結ぶ組織又は個人（JIS X 0170:2013及びJIS X 

0160:2012）。 

8 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記 供給者は利害関係者の部分集合である。 

4.1.28 

対象システム（system-of-interest） 

この規格の文脈においてライフサイクルが検討対象となるシステム（JIS X 0170:2013）。 

4.1.29 

システム要求仕様（system requirements specification） 

システム及びその運用環境並びに外部インタフェースに対する要求事項（機能・性能・設計制約・属性）

の構造化された集合。 

注記 IEEE Std 1233:1998及びIEEE Std 1012:2004から改変。 

4.1.30 

トレードオフ（trade-off） 

利害関係者にとっての実質利益に基づいて，様々な要求事項と代替解決策とから選定するという意思決

定行為（JIS X 0170:2013）。 

4.1.31 

利用者（user） 

システムを利用する間，システムからの恩恵を受ける個人又はグループ（JIS X 0170:2013）。 

注記1 利用者及び運用者の役割は，同一の個人又は組織の中で，同時に又は順次的に，付与される。 

注記2 利用者は利害関係者の部分集合である。 

4.1.32 

妥当性確認（validation） 

客観的証拠を提示することによって，特定の意図された用途又は適用に関する要求事項が満たされてい

ることを確認すること（JIS Q 9000:2006）。 

注記 システムライフサイクル文脈における妥当性確認とは，意図する用途・ゴール・目標をシステ

ムが達成できることを確実にし確信する一連の活動である。正しいシステムが構築されたかを

確認することである。 

4.1.33 

検証（verification） 

客観的証拠を提示することによって，規定要求事項が満たされていることを確認すること（JIS Q 

9000:2006）。 

注記 システムライフサイクル文脈における検証とは，システムライフサイクル上のある製品がその

製品に要求される特性に反してないかを比較する一連の活動である。その製品には，全てでは

ないが，定義された要求事項・設計記述・システムそのもの，が含まれる。システムが正しく

構築されたかを確認することである。 

4.2 

略語 

BRS 

ビジネス要求仕様（Business Requirements Specification） 

ConOps 

組織レベルの運用概念（Concept of Operations） 

FSM 

機能規模測定（Functional Size Measurement） 

HSI 

人間システム統合（Human Systems Integration） 

MOP 

性能評価測定量（Measures Of Performance） 

OpsCon 

システムレベルの運用概念（Operational Concept） 

9 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

RTM 

要求事項追跡可能性マトリクス（Requirements Traceability Matrix） 

SRS 

ソフトウェア要求仕様（Software Requirements Specification） 

StRS 

利害関係者要求仕様（Stakeholder Requirements Specification） 

SyRS 

システム要求仕様（System Requirements Specification） 

TBD 

決定予定（To Be Determined） 

TBR 

解決予定，改正予定（To Be Resolved, To Be Revised） 

TBS 

供給予定，定義予定（To Be Supplied, To Be Specified） 

TPM 

技術的性能評価測定量（Technical Performance Measure） 

5 

概念 

5.1 

序文 

ここでは，要求事項そのもの及び要求事項を文書化するプロセスを通じて作成される情報項目に当ては

まる概念を説明する。これらの概念は，対象システムのあらゆるレベルの要求事項の性質に当てはまる。

これらの概念は，また，要求事項の引出し・分析・割当て・文書化・管理に用いるプロセスに当てはまる。 

5.2 

要求事項の基本 

5.2.1 

一般 

要求エンジニアリングは多分野の協働を必要とする工学で，取得者の領域と供給者の領域とを仲介し，

対象とするシステム，ソフトウェア，又はサービスが要求事項を満足するように要求事項を確立・保守す

るための工学である。要求エンジニアリングは，要求事項の発見・引出し・開発・分析・検証手法の決定・

妥当性確認・伝達・文書化・管理に関わる。要求エンジニアリングによって得られる要求事項の階層構造

は次の性質をもつ。 

− 利害関係者（例えば，取得者・利用者・顧客・運用者・供給者）の間で合意が取れた解釈を可能にす

る。 

− 実世界ニーズに対して妥当性を確認でき，かつ，実装可能である。 

− 設計を検証し，かつ，ソリューションを受け入れる根拠になる。 

要求事項の階層構造を一つ以上の要求仕様で表現することがある（仕様のテンプレート及び内容に関し

ては，箇条8及び箇条9を参照）。 

5.2.2 

利害関係者 

要求エンジニアリングの文脈で考えると，利害関係者はプロジェクトによって様々である。利害関係者

集合には少なくとも利用者及び取得者（両者は同じでないことがある。）が含まれる。複雑なプロジェクト

では，それぞれが異なる関心をもつ多くの利用者及び取得者が影響を受ける。前記の最低限の利害関係者

に加えて，プロジェクトには二つのグループが必要となることがある。第一に，システム又はソフトウェ

アを開発，保守，又は運用する組織で，システムから便益を得る点で利害関係がある。第二は規制機関で，

法令，産業活動，などから来る，注意深い分析が必要な外的要求事項をもつ。 

5.2.3 

ニーズから要求事項への変換 

要求事項の定義は利害関係者の意図（ニーズ，ゴール，目標ともいう。）から始まる。それがより形式的

な記述に進化し，妥当な利害関係者要求事項に至る。初期の利害関係者の意図は利害関係者要求事項の役

をなさない。なぜならば，それはしばしば定義，分析，及び時に一貫性・実現性を欠くからである。組織

レベルの運用概念（ConOps）を用いて組織レベルで利害関係者の意図の理解を助けることによって，かつ，

システム視点からはシステムレベルの運用概念（OpsCon）を利用することによって，要求エンジニアリン

10 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

グは利害関係者を初期の意図から構造化されたより形式的な利害関係者要求事項記述へと導く。これらの

記述は，整形式で，かつ，5.2.4，5.2.5及び5.2.6の特性を満たす。 

次に，利害関係者要求事項は，5.2.4，5.2.5及び5.2.6に従って，対象システムに対するシステム要求事

項へと変換される。システム開発の実践によって一貫して示されているように，このプロセスは，システ

ム設計階層にわたる他のライフサイクルプロセスと同じく，反復的・再帰的なステップを必要とする。箇

条6にあるプロセスの再帰的適用は，下位レベルのシステム要素要求事項を生成することになる。 

箇条6では，利害関係者要求事項定義及び要求事項分析を実行するプロセスを詳述する。箇条7，箇条8，

及び箇条9では，要求事項の文書化に伴う情報項目に関するさらなる指針を提供する。附属書Aは，シス

テムレベルの運用概念（OpsCon）の内容に対する要求事項を提供し，附属書Bは，組織レベルの運用概念

（ConOps）の内容に対する指針を提供する。 

注記 要求事項の再利用を含めた要求開発技法に関するその他の指針としてISO/IEC 26551を参照。 

5.2.4 

要求事項の構成 

整形式の利害関係者要求事項・整形式のシステム要求事項・整形式のシステム要素要求事項を開発しな

ければならない。このことが，利害関係者による要求事項の妥当性確認に貢献し，要求事項が利害関係者

ニーズを正確に捉えることを確かなものにする。 

整形式の要求事項とは，次の事項を満たす記述である。 

− 検証できる。 

− 利害関係者の問題を解決する又は利害関係者の目標を達成するために，システムが満たす又はもち合

わせている必要がある。 

− 測定可能な条件によって限定されている，かつ，制約によって制限されている。 

− 特定の利害関係者が利用する場合のシステムの性能又はそれに相当するシステムの能力を，利用者，

運用者，などの利害関係者の能力に依存せずに，定義している。 

この記述は要求事項とその要求事項の属性（条件，前提条件，設計上の意思決定，及び制約）とを区別

する方法になる。 

整形式の要求事項を書くことに関する指針を次に示す。要求事項とは，ニーズ及びそれに付随する制約・

条件を，変換した又は表現する記述である。この記述は何らかの言語で書かれ，自然言語の形もあり得る。

要求事項は，要求事項の主体（例えば，システム，ソフトウェア）及び，何をなさなければならないか（例

えば，ある電力レベルで運転する，何かのフィールドを用意する。），を述べなければならない。図1に要

求事項の構成の例を示す。ほかにも要求事項を捉える方法に，条件アクション表及びユースケースがある。 

要求事項の存在を目立たせる特定のキーワード及び用語を事前に合意しておくことは重要である。次の

ように規定するのがよくある方法である。 

注記1 これらの表現を採用しない場合でも，要求事項の所在を識別し，任意選択・非拘束の条項と

の区別を識別できる仕組みを合意することが望ましい。 

− 要求事項は必須の拘束条項であり，“〇〇しなければならない”を用いる。 

− 事実の記述，未来の状態，又は目的の宣言は，任意選択・非拘束の条項であり，要求事項ではないこ

とが分かる表現を用いる。 

− 好ましい状態又はゴールは，望ましい・任意選択の・非拘束の条項であり，“〇〇することが望ましい”

を用いる。 

− 示唆又は許容は，任意選択の・非拘束の条項であり，“〇〇してもよい”を用いる。 

11 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− その他の非要求事項，例えば，説明文又は定義には，宣言的な表現を用いる。要求事項と誤解される

危険があるため，“〇〇すべきである”又は“〇〇する必要がある”は避けるのが最善である。 

− 肯定文を用い，できるだけ否定文の要求事項は用いない。 

注記2 “〇〇してはならない”という表現は，それが要求事項かどうかの判断を曖昧にする危険

がある。 

− 能動態を用い，“選択されなければならない”のような受動態を用いることは避ける。 

注記3 主体を明確にしない文は，それが要求事項かどうかの判断を曖昧にする危険がある。要求

エンジニアリングに特有な用語を全て正式に定義し，システムの要求事項全体で一貫して

適用することが望ましい。 

図1−要求事項文の構成の例 

条件は，要求事項に対して規定される測定可能な定性的又は定量的な属性である。さらに，条件は，必

要とされる要求事項に限定を設け，妥当性確認可能かつ検証可能な方法で要求事項を定式化・表明できる

ようにする属性でもある。条件は，設計者に任されている選択肢を限定することがある。利害関係者ニー

ズを利害関係者要求事項に変換するのに，ソリューション選択の可能性に不要な制限を求めないことが重

要である。 

一般に，制約とはシステムエンジニアリングプロセスの設計ソリューション又は実装を制限するもので

ある。制約は，全ての要求事項にまたがって課せられる場合，特定の要求事項若しくは要求事項集合との

関連で特定される場合，又は独立した要求事項として識別される（つまり，どのような特定の要求事項も

拘束しない）場合もある。 

制約の例には，次のものがある。 

− 既存システムとのインタフェース（例えば，様式，プロトコル，又は内容）で，変更できない場合 

− 物理的な大きさの限界（例えば，“コントローラは航空機翼の限定されたスペースに収まらなければな

らない”） 

− 特定の国の法律 

− 利用可能な期間又は予算 

[条件][主体][動作][対象][制約]（順不同） 

例 信号xを受信したら[条件]，システムは[主体]信号xの受領ビットを[対象] 2秒以内に[制約]設定しなけれ

ばならない[動作]。 

又は 

[条件][主体][対象][動作又は制約][値]（順不同） 

例 海況1では[条件]，レーダシステムは[主体] 標的を[対象] 100海里までの[値] 領域内で発見しなければな

らない[動作又は制約]。 

又は 

[主体][対象][動作][制約]（順不同） 

例 請求システムは[主体]未決の顧客請求を[対象] 請求が支払われる日付の昇順に[制約]表示しなければなら

ない[動作]。 

12 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 既存の技術プラットフォーム 

− 利用者又は運用者の能力及び限界 

優先度，タイミング，又は相対的な重要度を示すために，要求事項をランク付け又は重み付けしてもよ

い。シナリオ形式の要求事項は利用者の視点からシステムの動作を描く。 

注記4 6.2.3及び6.3.3に利害関係者要求事項及びシステム要求事項を定義するプロセスを詳述して

いる。 

5.2.5 

個々の要求事項の特性 

利害関係者要求事項・システム要求事項・システム要素要求事項は，それぞれ次の特性を備えていなけ

ればならない。 

− 必要である：要求事項は，本質的な能力，特性，制約，及び／又は品質要因を定義する。もしそれを

削除すると，その製品又はプロセスの他の能力で埋め合わせることができない欠陥が生じるようなも

のである。要求事項が現在有効であり，これまでに期限が切れていないことを確認する。失効日及び

有効日が予定されている要求事項は，明確に識別されることが望ましい。 

− 実装独立である：要求事項は，システムにとって何が必要かつ十分かを示すものであり，方式設計に

不要な制約を置くことを避ける。この目的は実装独立にある。要求事項は何が求められているかを示

すもので，いかにその要求事項が満足されるべきかを示すものではない。 

注記1 そのような情報がそれでも重要な場合，その情報を別の形で文書化又は伝達することが望

ましい。例えば，設計・実装を助けるための5.2.8にある要求事項の属性（例えば，根拠）

などの情報である。 

注記2 要求事項に設計ソリューションを含めると，潜在的な設計ソリューションを見逃す又はす

（棄）てるという危険を冒すことになりかねない。例えば，特定の商用システム一式又は

開発なしで購入可能なシステムを直接指定するような要求事項を記載すること，概念シス

テムレベルでは深すぎる事項に対して許容度要求事項を記載すること，必ずしも導出元の

要求事項を反映していない制約を作り上げること，などである。 

注記3 エラーメッセージのような下位レベルの要求事項は，概念レベルの要求事項には深すぎ

る。 

− 曖昧性がない：要求事項は，それがただ一通りに解釈されるように記載する。要求事項を単純かつ理

解しやすいように記載する。 

− 一貫性がある：他の要求事項と競合しない。 

− 完全である：要求事項を述べたら，それが測定可能で，かつ，利害関係者ニーズを満たす能力と特性

とを十分記述しているがゆえに，それ以上の詳述を必要としない。 

− 単独である：要求事項を表す文には一つの要求事項だけを含み，複数の文を接続詞でつながない。 

− 実現可能である：要求事項が技術的に到達可能で，かつ，大きな技術的進歩を必要とせず，かつ，シ

ステム制約（例えば，コスト，スケジュール，技術，法律，規制）内に，受入れ可能なリスクで収ま

る。 

− 追跡可能である：要求事項は，利害関係者ニーズを表す特定の文書，上位層の要求事項，又は他の資

料（例えば，商況調査又は設計検討），へ上方追跡可能である。また，下位層の要求仕様の特定要求事

項又は他のシステム定義資料，へ下方追跡可能である。つまり，要求事項の全ての親子関係が識別さ

れ，その要求事項からその源まで及びその要求事項から実装まで追跡できるようになっている。 

13 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 検証可能である：システムが特定の要求事項を満たすことを証明する方法がある。システムが特定の

要求事項を満たし得ることを証明する証拠を集めてもよい。要求事項が測定可能である場合，検証可

能性が高まる。 

5.2.6 

要求事項集合の特性 

利害関係者要求事項・システム要求事項・システム要素要求事項の，個々の要求事項ではなく，集合に

対して考えるべき特性がある。これによって，利害関係者の意図及び制約を満たす可能性のあるソリュー

ションを，要求事項の集合が全体として提供することが保証される。要求事項の集合は，それぞれ次の特

性をもたなければならない。 

− 完全である：仕様化しようとするシステム又はシステム要素の定義に関する全てを要求事項集合が含

んでいるがゆえに，その要求事項集合にそれ以上の詳述を必要としない。さらに，その集合に決定予

定（TBD），供給予定（TBS），又は解決予定（TBR）の箇条を含まない。“〇〇予定”の指定は，反復

的に解除されてもよい。また，“〇〇予定”項目に対して許容可能な時間枠があり，それはリスク及び

依存性で決まる。 

注記 完全性を改善するために推奨する実践方法がある。すなわち，全ての種類の要求事項を含め

ること，ライフサイクルの全ての段階で要求事項を説明すること，及び全ての利害関係者を

要求事項引出しアクティビティに参加させることである。 

− 一貫性がある：要求事項の集合に相矛盾するような複数の要求事項を含まない。要求事項に重複がな

い。全ての要求事項において，同じ項目に対して同じ用語が使用されている。 

− 満足可能である：要求事項の全集合が，ライフサイクル制約（例えば，コスト，スケジュール，技術，

法律，規制）の範囲内で獲得可能又は実現可能なソリューションによって満たされ得る。 

− 定義範囲がはっきりしている：要求事項集合が，意図するソリューションに対して識別された適用範

囲を維持し，利用者ニーズを満たすのに必要とされる以上に増加しない。 

これらの特性に対して要求事項集合及び追跡可能な方式設計を注意深くチェックすることが不可欠であ

る。これは，ライフサイクルを通して，システムのコスト，スケジュール，又は品質に影響するような要

求事項の変更及び“要求クリープ”（要求の漸増）を避けるためである。 

5.2.7 

要求事項の言語表現上の基準 

文章で要求事項を書く場合，次の考察は，良い要求事項特性が採用される助けとなる。 

要求事項は，“いかに”ではなく，“何”が必要かを記載することが望ましい。要求事項は，対象システ

ムにとって必要なことを述べ，対象システムのための設計上の意思決定を含めないことが望ましい。ただ

し，要求事項をシステムの各レベルにわたって割り当て，分割するとき，上位レベルで定義された設計上

の意思決定又はソリューション方式が意識される。これは，要求事項分析及び方式設計プロセスの反復的・

再帰的適用の一部である。 

曖昧な用語及び一般的な用語は，避けなければならない。これらは，検証が多分に難しいか若しくは不

可能ですらあるような要求事項，又は複数解釈を許すような要求事項をもたらす。定義範囲がはっきりし

ない又は曖昧な表現のタイプを次に示す。 

− 最上級（強調のための“最高の”，“最も”など） 

注記1 要求事項の定義に必要な最上級表現（例えば，“最高の金額提示者に落札する”）を禁止す

るものではない。 

− 主観的な語法（“ユーザフレンドリ”，“使いやすい”，“コスト効果的”など） 

14 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 曖昧な代名詞（指し示す対象が明確でない“それ”，“これ”，“あれ”など） 

− 曖昧な副詞及び形容詞（“ほとんどいつも”，“相当な”，“最小限の”など） 

− 無制限の検証不可能な用語（“支援する”，“〜に限らない”，“最低でも”など） 

− 比較級句（強調のための“〜より良い”，“より高い品質の”など） 

注記2 要求事項の定義に必要な比較級表現（例えば，“受注金額がより高いものから順に”）を禁

止するものではない。 

− 抜け穴（“可能ならば”，“必要に応じて”，“適宜”など） 

− 不完全な参照（参考文献に日付・版数を指定していない，検証作業を制限するため参考文献の当ては

まる箇所だけを指定すべきなのにしていない，など） 

− 否定的表現（具備されないシステム能力の記述，対象を“〇〇以外”と規定すること，など） 

注記3 例えば，“出荷済みデータ以外を集計する”という表現は，集計対象の全データの範囲が

明確でない場合，曖昧な表現となる。集計対象にどのデータを含めなければならないかを

表現するのがよい。 

ある要求事項に関する全ての前提条件を文書化し，かつ，その妥当性を，5.2.8に示す要求事項に付随す

る属性の一つ（例えば，根拠）又は別文書の形で確認しなければならない。定義は，要求事項としてでは

なく，宣言的な記述として含める。 

5.2.8 

要求事項の属性 

要求事項分析を支援するために，整形式の要求事項にはその要求事項を理解し管理する助けとなる説明

的な属性をもつことが望ましい。属性情報は，選択した要求事項リポジトリの中に，要求事項に付随させ

ることが望ましい。 

5.2.8.1 

要求事項属性の例 

要求事項属性の重要な例を次に示す。 

− 識別：個々の要求事項は一意に識別されることが望ましい［すなわち，番号，名前タグ，略名（ニモ

ニック）］。必要ならば識別子にリンク及び関連を反映させることができる，又はそれらを識別子と分

離することもできる。一意の識別子は要求事項の追跡に役立つ。一旦割り当てたら，識別子は一意で

なければならない。つまり決して変更しない（たとえ識別された要求事項が変わっても），かつ，再利

用もしない（たとえ識別された要求事項が削除されても）。 

注記1 同一の要求事項の内容変更に対しては変更管理を実施することが前提である。 

− 利害関係者にとっての優先度：個々の要求事項の優先度を識別することが望ましい。これは，潜在的

な利害関係者の間でのコンセンサスを通じて確立してもよい。例えば，1〜5の尺度，又は単純な高／

中／低のようなスキームを必要に応じて用い，個々の要求事項の優先度を識別することもできる。優

先度にはある要求事項が不要であると示唆する意図はなく，代替案を考慮した決定が必要なとき，ど

の要求事項がトレードオフを考慮する上での候補となるかが，優先度で分かることがある。優先度付

けには，要求事項を必要とする利害関係者を考慮する必要がある。これによって，要求事項のトレー

ドオフ及び利害関係者間での変更影響のバランスが促進される。 

− 依存性：要求事項の間の依存性が存在する場合，それを定義することが望ましい。要求事項によって

は，ある利害関係者から見ると低い優先度なのに，システムの成功に本質的なものがある。例えば，

外気温を測定するという要求事項はキャビン内温度の維持のような他の要求事項を支える上で不可欠，

ということがあり得る。このような関係を識別すれば，主たる要求事項が削除されたとき，副の要求

事項もまた削除できる。 

15 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− リスク：リスク分析技法を用いて，システム要求事項の重要さ又はリスク回避度合の形で等級を決定

する。主要なリスクは，潜在的な財政的損失，潜在的なビジネス機会損失，利害関係者からの信用失

墜，環境への影響，安全・健康問題，及び国内標準・法律に関係する。 

注記2 リスク分析に関するその他の指針がJIS X 0162にある。 

− 情報源：個々の要求事項には，その発生元を示す属性をもたせることが望ましい。一つの要求事項で

も，複数の情報源から来たと考えられることもある。個々の要求事項の情報源を識別すると，要求事

項の分類，競合解決，修正，又は削除に当たってどの組織に相談するとよいかを識別できる。所有権

という概念は情報源と関係する。所有権は要求事項の源に適用される。要求事項の源は要求事項がど

こから来たのかを示す。利害関係者要求事項についていえば，要求事項の元となった利害関係者が要

求事項の所有権を獲得する。要求事項が更に割当て及び導出によって発展したら，その要求事項を満

たす責任は適切な製品チームに渡る。 

− 根本的理由（rationale）：個々の要求事項を設定する際の根本的理由を把握することが望ましい。根本

的理由は，なぜ要求事項が必要とされているかを示し，かつ，あらゆる補助的な分析，トレードオフ

を考慮した比較検討，モデリング，シミュレーションなどの実質的・客観的証拠を指し示す。 

− 難易度：個々の要求事項に対して想定する難易度を記載することが望ましい（例えば，易／中／難）。

これは要求事項の幅及び入手可能性という形で別の利用状況を与える。また，コストモデリングの助

けになる。 

− 種類：要求事項が表現する性質は，その意図においても種別においても様々である。種類は，要求事

項を分析し，割り当てるためにグループ分けしながら収集する上で役立つ。 

5.2.8.2 

要求事項の種類を表す属性の例 

要求事項の種類を表す属性の重要な例を，次に示す。 

− 機能要求事項：機能要求事項は，システム又はシステム要素が実行すべき機能及びタスクを記述する。 

− 性能要求事項：ある機能又はタスクが，どの程度又はどのくらいうまく，かつ，いかなる条件下で実

行されるべきかを定義する要求事項である。これらは，システム性能の定量的な要求事項であり，個々

に検証可能である。単一の機能，機能要求事項，又はタスクに対して複数の性能要求事項が伴うこと

がある点に注意する。 

− 使用性又は利用時の品質要求事項（利用者の実施能力及び満足に対して）：これは，システムが利用

者ニーズを満たすようなシステムの設計及び評価の根拠になる。使用性又は利用時の品質要求事項

は，システムの要求仕様全体との関係を考慮しながら開発され，また，その一部になる。 

− インタフェース要求事項：インタフェース要求事項は，システムが外部システムといかに相互作用す

るよう求められるか（外部インタフェース），又は人間要素も含めてシステム内のシステム要素が互い

にいかに相互作用するか（内部インタフェース）を定義する。 

− 設計制約：動かせない境界及び限界（例えば，“システムは，レガシーシステム要素若しくは与えられ

たシステム要素を組み込まなければならない”，又は，“あるデータをオンラインリポジトリに維持し

なければならない”）を求めることによって，ソリューションを担当する設計者の自由な選択肢を制限

するような要求事項である。 

− プロセス要求事項：プロセス要求事項は利害関係者（通常，取得者又は利用者）の要求事項で，契約

及び特定の作業指示書を通じて求められる。プロセス要求事項には，国又は地方の法規（環境法を含

め）の遵守，管理要求事項，取得者又は供給者関係要求事項，及び特定の作業指示，が含まれる。プ

ロセス要求事項は，また，企業の方針及び慣行によって，計画に求められることもある。システム又

16 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

はシステム要素の実装プロセス要求事項（例えば，特定の設計手法を必須にすること）は，プロジェ

クト合意文書（例えば，契約・作業記述書・品質計画）の中で捉えられるのが普通である。 

− 非機能要求事項：非機能要求事項は，どのような条件下での運用若しくは存在がシステムに求められ

るか，又はどのようなシステム特性をもつことを求められるか，という要求事項である。システムが

“どうある”ことになっているかを定義する。品質要求事項及び人的要因要求事項は，この種類の例

である。 

− 品質要求事項：これは要求事項における多くの“〇〇性”，例えば，運搬性・生存性・柔軟性・移植

性・再利用性・信頼性・保守性・セキュリティを含む。非機能の品質要求事項の一覧を，要求事項

文書を手がける前に開発することが望ましい。これを，開発しようとするシステム用に修整するこ

とが望ましい。必要に応じて，品質要求事項の測定量も含めることが望ましい。 

注記1 ソフトウェア品質要求事項に関するその他の指針がISO/IEC SQuaRE標準規格，特にJIS 

X 25030:2012及びJIS X 25010:2013にある。 

− 人的要因要求事項：これは，人間利用者（及び利用に影響される他の利害関係者）との相互作用の成

果に対して求められる特性を，安全性・性能・有効性・効率性・信頼性・保守性・健康・福利・満足

の形で記載する。これには，使用性（有効性・効率性・満足度を含め），人的信頼性，及び健康への無

害性，の測定量が含まれる。 

注記2 人的要因に関するその他の指針が6.2.3.2にある。 

注記3 要求事項の種類を構成する他の方法もあり得る。 

5.3 

実践上の考慮 

5.3.1 

プロセスの反復・再帰 

プロセス適用の二つの形（反復及び再帰）はこの規格で定義するプロセスを適用する上で本質的かつ有

益である。 

5.3.1.1 

プロセスの反復的適用 

同じプロセス又はプロセス群をシステムの同じレベルに繰返し適用するとき，その適用を反復という。

反復は適切であるばかりか期待されてもいる。あるプロセス又はプロセス群の適用によって新しい情報が

作り出される。この情報は，典型的には要求事項に関する疑問，又は分析されたリスク若しくは機会の形

を取る。このような疑問は，プロセス又はプロセス群のアクティビティを完了する前に解決することが望

ましい。アクティビティ及びプロセスの再適用がその疑問を解決できる場合，そうするのが有益である。

次のプロセス又はアクティビティ群を対象システムに適用する前に，管理上許容される品質に関する情報

を利用できるようにするために，反復を要求することがあり得る。この場合，反復によって，プロセスを

利用しようとしているシステムに価値が加わる。プロセスの反復的な適用を図2に示す。 

注記 プロセス内の内部反復もあり得る。簡単のため図2にはこれを示していない。 

17 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

図2−プロセスの反復的適用 

5.3.1.2 

プロセスの再帰的適用 

プロセスの同じ組又はプロセスアクティビティの同じ組をシステム構造内の連続するレベルのシステム

要素に適用するとき，この適用形態を再帰的という。一つの適用の成果がシステム構造内の次の下位（又

は上位）システムへの入力となり，より詳細で成熟した成果になる。このような方法は，システム構造内

の連続するシステムに価値を加える。トップダウンでシステムにプロセスを再帰的に適用する様子を図3

に示す。利害関係者要求事項定義プロセスは，対象システムレベルだけに適用される。一方，要求事項分

析及び方式設計プロセスは，連続する再帰レベルのそれぞれに適用される。 

図3−プロセスの再帰的適用 

18 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記 再帰は双方向でもあり得る。つまり，対象システムレベルに対する要求事項が，更に分析を必

要とする（下位の）システムから出てくる場合がある。簡単のためこれは図3に示していない。 

5.3.2 

要求エンジニアリングにおける反復・再帰 

様々な利害関係者グループは，しばしばシステムを様々な抽象レベルから見るため，対象システム全体

だけではなく，より下位の詳細な抽象度で要求事項記述を定義・文書化することが必要である。これを達

成するには，システム要求事項をシステム要素に割り当てるか又は分散させる。要求事項をシステム要素

に割り当てるアクティビティは，方式設計プロセスの一部であり，システム方式の定義と並行に進む。要

求事項と方式とのトレードオフを解決するため，要求事項分析と方式設計プロセスとの間で複数回の反復

があってもよい（図2参照）。 

方式設計の主要な目標の一つは，システムをどのように分割するかを決定すること，つまり，どの要求

事項をどのシステム要素に割り当てるのが望ましいかをどのように識別するかを決定することである。シ

ステム要素が決定されると，新たな要求事項記述（導出要求事項と呼ぶ。）を作ることが望ましい。それに

よって，システムの方式要素間の関係を定義できるか，システム要素の下位の抽象度の文脈において必要

な明瞭性が得られるか，又はシステム要素に設計制約若しくは性能レベルを指定できる。これを達成する

には，要求事項分析プロセスを再帰的に適用する（図3参照）。 

加えて，要求事項によっては方式又は設計のある部分が進化しないと導出できないものもある。要求事

項によっては，幾つかのシステム要素がいかに相互運用するかに依存するものもある。例えば，システム

の情報スループットは，システムハードウェア・ソフトウェア・要員行動・環境の相互作用に依存する。

要求事項分析及び方式設計プロセスの再帰的・反復的適用は，このような要求事項を捉えるのに役立つ。 

要求エンジニアリングに十分な資源が与えられていても，分析のレベルを一様に適用することは，まれ

（稀）である。例えば，経験あるエンジニアならば，要求事項分析プロセスの早い時期に既存又は市販の

ソリューションがシステム要素の実装のどこに適用できるか識別できる。これらのシステム要素に割り当

てられた要求事項は，あまり分析の必要がないことがある。一方，ソリューションがそれほど自明でない

システム要素は，更に深いより詳細な分析が必要なことがある。重大な要求事項，つまり高いリスクをも

つ要求事項，又は公共安全，環境，若しくは健康に影響する要求事項は，常に厳密に分析することが望ま

しい。 

注記 6.2.3.2には，要求事項を定義するプロセスを詳述している。要求事項を十分に開発するため反

復・再帰をいかに適用するかを含めて，特に，分析・割当て・要求事項間のトレードオフ検討

における要求調整に関して詳しい。 

5.4 

要求事項の情報項目 

この細分箇条では，要求プロセスと要求情報項目との関係を，プロジェクトにおける典型的な適用スタ

イルを示すことによって記述する。 

19 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

図4−ビジネス文脈における要求事項の適用範囲の例 

要求プロセス及びその結果としての仕様は，要求事項を定義しようとするシステムの適用範囲に依存す

る。開発又は変更しようとするシステム又はシステム要素に対する要求事項は，事業又は組織運営に対す

る組織レベルの要求事項に支配される。システム又はシステム要素に対する要求事項は，下位のシステム

レベルに徐々に割り当てられる。システム及び対応する要求事項の適用範囲に対する典型的な視点を図4

に示す。 

注記1 “ビジネス”という用語は，たとえ公共分野などの非営利組織に適用されても使用する。こ

の規格の利用者は，利用者の環境によって，ビジネスという用語を全て“組織”又は“組織

的”という用語に置き換えてもよい。 

注記2 この規格では“business”を“事業”又は“業務”としている。両者を包含した意味をもつ場

合は“ビジネス”としている。 

利害関係者要求仕様（StRS），システム要求仕様（SyRS），及びソフトウェア要求仕様（SRS）は異なる

要求情報項目の組を表すことを意図している。これらの仕様は図4の要求事項に次のように対応する。 

・StRS−利害関係者要求事項（事業管理レベル及び業務運用レベル） 

・SyRS−システム要求事項 

・SRS−ソフトウェア要求事項 

これらの情報項目は複数の仕様（インスタンス）に反復的又は再帰的に適用できる。要求プロセス及び

要求仕様の順序の例を図5に示す。 

例1 SyRSは，システム又はシステム要素に適用できる。SyRSは，ソフトウェア要求事項を仕様化

するのにも利用できる。 

例2 SRSは，システム又はシステム要素内にあるソフトウェア固有の要素に対する下位レベルのソ

フトウェア要求事項に利用できる。 

20 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

図5−要求プロセス及び仕様の順序の例 

組織レベルの運用概念（ConOps）及びシステムレベルの運用概念（OpsCon）は，組織の様々な利害関

係者から要求事項を引き出すのに便利である。また，組織の意図を伝達・共有する実践的な方法として有

益である。組織レベルの運用概念（ConOps）は，組織レベルで，指導部が意図するその組織の運営方法に

位置付けられるものである。組織レベルの運用概念（ConOps）は一つ以上のシステムの利用をブラックボ

ックスとして参照することがある。システムレベルの運用概念（OpsCon）は特定の対象システムを利用者

の視点で位置付ける。 

StRS，SyRS，SRS，組織レベルの運用概念（ConOps），及びシステムレベルの運用概念（OpsCon）文書

に表現される情報項目は，相互依存する。これらの項目を開発するには，特に業務プロセス，組織の慣習，

及び技術ソリューションに対する選択肢に関して，相互作用と協力とが必要である。 

様々なタイプのシステム群が，含まれる様々な要求事項に対して並行に文書化を行うことがある。しか

し，一般に，それらはStRS及びSyRSからスタートし，ハードウェア及びインタフェースの仕様とともに

ソフトウェア仕様も含むようになる。 

6 

プロセス 

6.1 

要求プロセス 

プロジェクトは，JIS X 0170:2013及びJIS X 0160:2012のいずれかに又は両方に適合するかに応じて，

次の要求エンジニアリングプロセスを，JIS X 0170:2013及びJIS X 0160:2012で定義されているように，

実施しなければならない。 

− 利害関係者要求事項定義プロセス（JIS X 0170:2013の6.4.1又はJIS X 0160:2012の6.4.1）。 

− 要求事項分析プロセス（JIS X 0170:2013の6.4.2又はJIS X 0160:2012の6.4.2）。 

− ソフトウェア製品の取得又は供給に対するソフトウェア要求事項分析プロセス（JIS X 0160:2012の

7.1.2）。 

6.1.1 

プロセスに対する指針 

この規格では，計画・実施の付加的な指針を利用者に提供するために，要求関連プロセスを詳細化する。 

6.2以降では，JIS X 0170:2013オリジナルタスクでこの規格に関連するものを枠で強調し，詳細化しよ

21 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

うとする原文を読者に示す。関連のないタスクは省略したが，JIS X 0170オリジナルの番号は維持した。

オリジナルの出典参照は，右下端に含める。この規格に関連するJIS X 0170オリジナルの目的及び成果は，

要求エンジニアリングに関連するプロセスの部分集合に対して，一切変更せず，全体を用いる。 

主要なプロセスは，1)利害関係者要求事項定義プロセス及び2)要求事項分析プロセス（JIS X 0170）又

はシステム要求事項分析プロセス（JIS X 0160），である。これらの二つのプロセスの結果，ベースライン

となる要求事項の集合ができ，それが方式設計プロセスに流れ込み，そこで要求事項はシステム要素へと

割り当てられ，分割され，追跡される。方式設計プロセスには，要求プロセスの再帰的な適用・反復的な

適用の起点となる要求事項の割当ても含まれる。方式設計プロセスは，ISO/IEC TR 24748-1に記述されて

いるように，プロジェクトのシステムライフサイクルモデル定義に基づいて適用する。方式設計プロセス

には，システム要素要求事項の定義に対しては要求プロセスの再帰的な適用を，導出要求事項に対しては

要求事項分析プロセスの反復的な適用を，それぞれ開始させるような要求事項の割当て・分割が含まれる。

要求関連アクティビティ又はタスクをもつ他の技術プロセス及びプロジェクトプロセスもある。 

注記 JIS X 0170（JIS X 0160）の文には，本来“ベースライン”を用いるべきところを，以前の用語

“基準線”を用いているところがある。この規格ではこれを修正して引用する。 

システムアクティビティとソフトウェアアクティビティとには僅かな違いがある。この規格の目的のた

めに，箇条は基本的にJIS X 0170のシステムエンジニアリングプロセスに倣って命名する。 

二つの規格のプロセス間の関係を，この規格の関連する箇条へのマッピングとともに，附属書Cに示す。

表C.1及び表C.2では，二つの主技術プロセス及びその中で要求エンジニアリングに当てはまるアクティ

ビティを識別する。表C.3では，要求エンジニアリングに関連する他の技術アクティビティを識別する。 

6.2 

利害関係者要求事項定義プロセス 

6.2.1 

目的 

利害関係者要求事項定義プロセスは，定義された環境において，利用者及び他の利害関係者によって必

要とされるサービスを提供できるように，あるシステムに対して要求事項を定義することを目的とする。 

利害関係者要求事項定義プロセスでは，システムのライフサイクルを通じて，システムに関係している

利害関係者又は利害関係者のクラス並びに彼らのニーズ，期待及び要望を識別する。利害関係者要求事項

定義プロセスでは，これらを分析し，利害関係者要求事項の共通集合に変換する。利害関係者要求事項は，

システムがその運用環境との間にもつ意図された相互作用を表現する。利害関係者要求事項は，システム

がニーズを満たすことを確かめるために，結果として生まれた各運用サービスの妥当性を確認する場合に

参照する。 

6.2.2 

成果 

利害関係者要求定義事項プロセスの実施に成功すると次の状態になる。 

a) サービスで要求される特性及びサービスで要求される利用の文脈（内容，状況及び背景）が明示され

ている。 

b) システムソリューションにおける制約が定義されている。 

c) 利害関係者要求事項から，利害関係者及び利害関係者ニーズへの追跡可能性が達成されている。 

d) 利害関係者要求事項が定義されている。 

e) 妥当性確認のための利害関係者要求事項が識別されている。 

6.2.3 

アクティビティ及びタスク 

プロジェクトは，利害関係者要求事項定義プロセスの観点から，該当する組織の方針及び手順に従って，

次に示すアクティビティ及びタスクを実施する。 

22 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

6.2.3.1 

利害関係者要求事項引出し 

このアクティビティは，次のタスクからなる。 

1) システムのライフサイクルを通じて，システムに正当な関係をもつ個々の利害関係者又は利害関

係者のクラスを識別する。 

注記 これには，利用者，運用者，支援者，開発者，製作者，教育訓練者，保守者，廃棄者，

取得者及び供給者の組織，外部とインタフェースをもつ責任ある当事者，規制団体並び

に社会の構成員を含むが，それだけに限定はされない。直接のコミュニケーションが実

際的でない場合には，代表者又は指名された代理の利害関係者が選定される。例えば，

消費者向けの製品及びサービスでは，マーケティング部門が選定される。 

［JIS X 0170:2013，6.4.1.3 a) 1)］ 

システムライフサイクルの全ての段階を識別するのが最良である。その上で，ライフサイクルを通じて

システムに正当な関心をもつ個々の利害関係者又は利害関係者クラスを識別する。利害関係者から引き出

された要求事項は，その組織における利害関係者の役割・職責・立場に依存する。望まれる製品又はサー

ビスに関して役割又は関心をもつ利害関係者のクラスを全て識別する。その上で，ゴール・戦略・運用・

目標システムに強い影響のある利害関係者を識別する。利害関係者クラスの一覧は，製品又はサービスに

ついてより多くを学ぶにつれて時間とともにしばしば変更される。それぞれの利害関係者クラスの代表を

識別し，複数レベルの視点を含めることが望ましい。一人又は1レベルだけの利害関係者から集めた情報

は一つの視点からゆがめられがちである。“解決すべき問題”の真の像を与えるために，利害関係者の代表

者相関表が必要である。 

2) 識別された利害関係者から利害関係者要求事項を引き出す。 

注記 利害関係者要求事項は，識別された利害関係者のニーズ，欲しい物，望ましい物，期待

される物及び感知した制約といった形態で表現される。利害関係者要求事項は，文章又

は形式的なモデルで表現されてもよい。利害関係者要求事項は，システムの目的及び振

る舞いに焦点を当てたモデル並びに運用上の環境及び条件の文脈で記述されるモデルと

いった形態で表現される。例えば，JIS X 0129-1及びJIS X 25030にある製品の品質モデ

ルは，このアクティビティを助けるために役立つ。利害関係者要求事項は，社会によっ

て課されるニーズ及び要求，取得する組織によって課される制約並びに運用要員の能力

の限界特性を含む。要請文書又は合意を含む情報源を列挙することが役立つ。可能な場

合には，情報源の正当性及び理論的根拠を列挙し，利害関係者の前提及び要求事項が満

足されることで彼らが得る価値を列挙することが役立つ。重要な利害関係者のニーズに

ついては，有効性の尺度を定義して，運用上の性能を測定し，アセスメントを行えるよ

うにする。重大なリスクが，そのシステムのライフサイクルのいずれかの時点において，

人間（利用者及び他の利害関係者）に関する問題（すなわち，ニーズ，欲しい物，制約

条件，限界，懸案事項，障害，要因又は配慮）及びそれらのシステムの中への関与又は

システムとの相互反応から生じる可能性があるときは，人間対システム問題を識別し，

取り扱うための勧告はISO PAS 18152に見いだすことができる。 

［JIS X 0170:2013，6.4.1.3 a) 2)］ 

23 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記1 5.2.3は，要求事項を構築するのに必要な情報を引き出し，文書化し，記録するツールとして，

組織レベルの運用概念（ConOps）とシステムレベルの運用概念（OpsCon）とを利用するこ

とを述べている。附属書Aには，システムレベルの運用概念（OpsCon）に対する本質的な要

素を，附属書Bには，組織レベルの運用概念（ConOps）に対するこの情報を含む。 

注記2 利用者，運用者，保守者など，人間システム問題の何らかの原因に関する重要なリスクは必

ず存在する。 

ほとんどのシステムにおいて，要求事項の発生源はたくさんあろう。全ての潜在的な発生源を識別しシ

ステムへの影響を評価することは最も重要である。要求事項の発生源としてよくあるもの及び扱う必要の

ある問題を次に示す。 

− ゴール：“ゴール”という用語（時に“ビジネス関心事”又は“重大成功要因”と呼ばれる。）はシス

テムの全体的な高レベル目標をいう。ゴールは，システムの動機になるがしばしば曖昧な形を取る。

ゴールの（優先度に応じた）価値とコストとを評価することが重要である。 

− ミッションプロファイル：システムがその使命をいかに実行するか？システムが事業又は組織の運営

にいかに貢献するか？ 

− 運用シナリオ：説明する必要のある特別なシナリオがあるか？シナリオは，システムレベルの運用概

念（OpsCon）を定義すること，並びに，システム製品の想定利用の範囲，意図する運用環境，及び相

互接続するシステム，プラットフォーム，又は製品，を拘束することに利用できる。シナリオは，こ

れがないと見逃してしまうかもしれない要求事項を識別する助けになる。 

− 運用環境及び利用状況：要求事項には，システム又はソフトウェア製品を運用する環境から引き出さ

れるものもある。運用されるのは，高温条件下又は低温条件下なのか，野外なのか，その他の同程度

の制限条件下なのか？システム環境との相互作用の特性・タイミング・量（労働量）はどうなのか？

実時間システムにタイミング制約はあるのか，又は運用時間帯など業務環境における相互運用性に制

約はあるのか？環境の他の面（脅威及び相互運用しているシステム）もまた，システムへの要求事項

を導く。これらは，システムの実現性・コストに大きく影響し，かつ，設計選択を制限することがで

きる。 

− 運用配置：システムはいつ利用されるのか？必要とされる初期，中間，又は最終局面のどこで配置す

るのか？ 

− 性能：使命を果たすために重大なシステムパラメータは何か？ 

− 有効性：システムが使命を果たすのにシステムは，どのように効果的又は効率的であることが望まし

いか？有効性の適切な測定量は何か？使命を果たすためにシステムが利用可能な最短の時間は幾らか，

例えば，全時間の90 %か？ 

− 運用ライフサイクル：システムの寿命は，どのくらいの長さか？20年か？30年か？年間どのくらいの

時間システムを運用することが望ましいか？ 

− 組織環境：多くのシステムは，組織のプロセスを支援することが求められる。これはその組織の構造・

文化・内部方針に条件付けられることがある。一般に，新規システムは，業務プロセスに想定外の変

化を強要しないことが望ましい。 

− 利用者・運用者特性：誰がシステムを利用又は運用するのか？役割・スキルレベル・予想負荷はどの

くらい多様か？能力・可用性への予想又は制約は何か？アクセス可能性に対して配慮することが望ま

しいか？ 

注記3 アクセス可能性についてのその他の情報としてISO/IEC TR 29138-1:2009を参照。 

24 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

このタスクの一部として，以前から存在する要求事項の再利用のための機会を識別・評価することが重

要である。これには，同様の機能又は能力をもつ既存システムを識別すること，新しい対象システムに適

用可能な特定機能又は能力を識別すること，及び再利用可能な範囲についての情報を識別することが含ま

れる。 

注記4 要求事項の再利用についてのその他の指針として，ISO/IEC 26551を参照。 

要求事項引出しは，反復的なアクティビティである。要求事項引出しタスクの中で多様な組合せの要求

源をうまく適応させるために，要求事項を識別するための様々な技法を検討する。例えば，次のものであ

る。 

− ブレインストーミングを含む構造化ワークショップ 

− インタビュー，アンケート 

− 環境又は仕事の型の観察（例えば，時間・動作研究） 

− 技術文書レビュー 

− 市場分析又は競合システム評価 

− シミュレーション，プロトタイピング，モデリング 

− ベンチマークプロセス及びベンチマークシステム 

− 組織分析技法［例えば，SWOT（強み・弱み・機会・脅威）分析，製品ポートフォリオ］ 

システム利害関係者は，彼らの関心又は専門領域を代表するようなシステムの要求事項に対して，信頼

すべき情報源である。しかしながら，通常彼らは自身の専門を整形式の要求事項記述にどのように変換す

るかに不慣れである。このような人的な要求事項源に加えて，他システムから重要なシステム要求事項が

求められることがしばしばあり，それは他システムが当該システムの何らかのサービスを要求する若しく

は当該システムを制約するように振る舞う場合，又は応用分野の根元的な特性から来る場合がある。シス

テム要求事項を導く安全性などの規制制約も存在する可能性がある。 

利用者コミュニティの説明［典型的には組織レベルの運用概念（ConOps）に見られる。］は，労力に見

合う共通の理解をもたらすことがあり，シナリオの適切さを妥当性検証できる。利用者説明に含めること

があるのは，製品の販売対象となる人口統計的なグループ，又は，システムの採用を担当するかそうでな

ければシステムの運用から便益を得るような特定の要員カテゴリである。 

利害関係者要求事項引出しにおいて，利害関係者要求事項（例えば，整形式の要求事項）の検証に利害

関係者を参加させると，要求事項記述が彼らのニーズを正確に捉えていることをこれらの利害関係者が早

期に妥当性確認できる助けにもなる。5.2に提供する整形式の要求事項記述を作るための特性及び指針を適

用する。 

注記5 利害関係者要求事項を単に引き出すというよりも，要求事項を利害関係者が又は利害関係者

とともに作り上げる，開発する，又は形成していくという考え方が時に重要である。 

25 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

6.2.3.2 

利害関係者要求事項定義 

このアクティビティは，次のタスクからなる。 

1) システムソリューション上の制約事項，すなわち，既存の合意，管理上の決定及び技術上の決定

の結果がもたらす不可避な影響を定義する。 

注記 これらは，次に示すものから結果としてもたらされる場合がある。 

1.1) 

利害関係者が定義したソリューションの事例又は領域 

1.2) 

システム階層構造の上位レベルでなされた実装上の決定 

1.3) 

定義されたイネーブリングシステム，資源及び要員に対して要求された利用 

［JIS X 0170:2013，6.4.1.3 b) 1)］ 

制約は要求事項の一種である。次の事項があり得る。 

− 外部又は組織内の利害関係者から来る制約（例えば，エンジニアリング計画，技術的な性能測定量，

技術的な成熟度，規制，ライフサイクルコスト，又は利用者及び運用者人選上の制約） 

− 外部システム，相互作用するシステム，又はイネーブリングシステムから来る制約 

− 他のライフサイクルフェーズからのアクティビティ及び技術アクティビティ，例えば，移行・運用・

保守，から来る制約 

− 取得者又は利用者の全体的な満足を反映する有効性及び適合性の測定量（例えば，性能・安全性・信

頼性・可用性・保守性・作業負荷要求事項）から来る制約 

制約の例を次に示す。 

− 経営トップから要求される予算の制限は，これに続く要求プロセスに対する制約である。 

− システムに対して展開される保守戦略は，要求事項に条件及び制約を求めることがある（修理時間及

び／又は備品の保有レベルは，信頼性の価値を押し上げることがある。）。又は能力要求事項を直接定

義することがある（例えば，障害の切離し保守をサポートするための組込テスト機能）。 

2) 予想される運用及び支援のシナリオ並びにそれらの環境に合致して，要求される全てのサービス

を識別するために，そのアクティビティの順序の代表的な集合を定義する。 

注記 シナリオは，意図された環境におけるシステムの運用を分析するために，かつ，利害関

係者の誰からも公式に明示されていない要求事項，例えば，法規，規制及び社会的な義

務を識別するために利用される。システムの利用の文脈は，識別され，分析される。文

脈の分析の中に，システムの目標を達成するために利用者が行う活動，システムの最終

利用者の関連する特性（例えば，期待される訓練，疲労の程度），物理的な環境（例えば，

自然光，温度）及び利用されるいかなる機器（例えば，保護装置，通信機器）も含める。

システムの利用に影響を及ぼす又はその設計を制約する利用者への社会的及び組織的な

影響は，適用できる場合に，分析される。 

［JIS X 0170:2013，6.4.1.3 b) 2)］ 

シナリオは，コンセプト文書を定義し，システム製品の想定利用範囲，意図する運用環境，及び相互接

続するシステム，プラットフォーム，又は製品，を拘束するのに利用できる。シナリオは，これがないと

見逃してしまうかもしれない要求事項を識別する助けになる。シナリオは，システム性能の重大なしきい

26 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

（閾）値及び望ましいしきい（閾）値，並びにシステムの成功を左右するシステム性能パラメータの目標

値，を確立する助けになることがある。シナリオは，また，あると望ましいが重大なパラメータを満たす

ため妥協の対象となってもよいような要求事項を，確立することもある。ユースケース法もコンセプト文

書を定義するために利用できる。この方法では，一組のアクター（システム及びシステムと相互作用する

人間のクラス）を，システムに対する彼らのゴール・目的・ニーズに沿って識別する。ユースケースを分

析して，利害関係者要求事項を識別する。 

取得者・利用者・供給者を含む全方位の利害関係者を相手にするには，様々なレベルの抽象化又は表現

の仕掛けがしばしば必要になる。 

3) 利用者とシステムとの間の相互作用を識別する。 

注記 使用性に対する要求事項は，最小限で，最も効果的，効率的で確実な人間の能力及び人

間対システムの相互作用を確立する要求事項として決定される。可能な場合には，適用

可能な標準，例えばJIS Z 8512及び受け入れた専門的な実践が，次の定義のために用い

られる。 

3.1) 

身体的能力，精神的能力及び学習した能力 

3.2) 

利用の文脈の中の他の装置を含め，仕事場，環境及び施設 

3.3) 

正常条件，異常条件及び緊急な条件 

3.4) 

運用者及び利用者の採用，教育訓練及び文化 

使用性が重要である場合，使用性の要求事項を計画し，明示し，ライフサイクルプロセスを通

じて実施することが望ましく，次の規格又は技術報告書を適用することができる。 

− JIS Z 8521:1999 人間工学−視覚表示装置を用いるオフィス作業−使用性についての手引 

− JIS Z 8530:2000 人間工学−インタラクティブシステムの人間中心設計プロセス 

［JIS X 0170:2013，6.4.1.3 b) 3)］ 

人間システム統合（HSI）の考慮は，システムエンジニアリングにおける重要な概念である。HSIは，シ

ステムライフサイクル全体で人間に焦点を当てる。HSIは，人間，技術（ハードウェア及びソフトウェア），

運用状況，及びシステム要素間インタフェースを含み，これらが調和をもって動作するようにするトータ

ルなシステム方法を促進する。HSIは，人間中心の規律（例えば，労働力・要員・訓練・人的要因・環境・

健康・安全性・居住性・生存性）をシステムエンジニアリングプロセスにもたらし，システム全体の設計

と実施能力とを改善する。要求事項にHSIの考慮をもち込めるかどうかは，使命，機能，運用シナリオ・

タスク，利用者人口，及び品質特性考慮を明確に理解しているかどうかに左右される。利用者タスク・性

能，労働力，及び教育訓練の領域の要求事項は，システムのゴール又は使命をタスク分析のレベルまで分

割し，利用者インタフェースの特性又はフロントエンド分析を定義し，訓練の影響まで決定して初めて定

義できる。 

注記 JIS Z 8530の対応国際規格ISO 13407:1999は，ISO 9241-210に置き換わっている。 

27 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

4) 健康，安全性，セキュリティ，環境及び他の利害関係者要求事項及び重大な品質に関する機能を

明示する。 

注記 安全性に対するリスクを識別する。契約で保証されている場合は，安全性を提供するた

めの要求事項及び機能を明示する。このリスクには，運用及び支援の方法，健康及び安

全性並びに資産への脅威及び環境への影響に関するリスクを含む。適用可能な標準，例

えば，JIS C 0508規格群，及び受け入れた専門的な実践を利用する。セキュリティのリ

スクを識別する。契約で保証されている場合は，身体，手順，通信，コンピュータ，プ

ログラム，データ及び排出物質を含め，システムのセキュリティに関する全ての適用可

能な領域を明示する。保護される人員，資産及び情報に対するアクセス及び損傷，機密

情報を危うくすること並びに資産及び情報に対して認められたアクセスへの拒否を含

め，システムのセキュリティに影響を与える可能性がある機能を識別する。軽減及び抑

制を含め，必須又は適切な場合に，適用可能な標準及び受け入れた専門的な実践を参照

し，要求されたセキュリティの機能を明示する。 

［JIS X 0170:2013，6.4.1.3 b) 4)］ 

重大な品質とは，システムと運用環境との整合性を保証するために不可欠なシステムの側面である。 

6.2.3.3 

利害関係者要求事項の分析及び維持 

このアクティビティは，次のタスクからなる。 

1) 引き出された要求事項の完全な集合を分析する。 

注記 分析には，対立する，欠如している，不完全な，曖昧な，整合性のない，不合理な又は

検証できない要求事項の識別及び優先順位付けを含む。 

［JIS X 0170:2013，6.4.1.3 c) 1)］ 

5.2.5及び5.2.6に定義する特性に対して要求事項を分析することが望ましい。要求事項の優先度付けを

行うことが望ましく，5.2.8に記述するように分類してもよい。チェックリスト又は標準的なひな（雛）形

を用いるとレビュープロセスの助けになる。 

既存システム又はレガシーシステムからの利害関係者要求事項が再利用の候補として既に挙がっている

場合，適用可能性・実現性・品質・コスト有効性・価値・流通の要因に基づいて，それを利用できるか分

析することが望ましい。要求事項を再利用する一方で，再利用する要求事項と対象システム固有の要求事

項との一貫性チェックを注意深く行い，一貫性を確かめることが望ましい。 

2) 要求事項に関する問題を解決する。 

注記 これには，実現できない要求事項又は達成するのが実際には不可能な要求事項を含む。 

［JIS X 0170:2013，6.4.1.3 c) 2)］ 

要求事項の分析及び割当ての間中，要求調整を続けることが重要である。なぜならば，競合が将来発生

するからである。互いに相反する特徴を求める利害関係者間で調整が必要な場合がある。又は，望む性能

要求事項，制約，利用できる予算，及び納品スケジュールの間の競合によって調整が生じる場合もある。

ほとんどの場合，利害関係者と相談し適切なトレードオフ検討の上で合意に達する必要がある。多くの場

合，このような決定事項がその利害関係者へ追跡可能なことが，契約上の理由から重要になる。解決を促

す様々な分析手法及び競合解決技法が適用できることがあり，その特定の状況に依存する。 

28 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

組織によっては要求調整を要求事項妥当性確認の一部とすることがある。競合解決が要求事項分析タス

クの中でできるだけ早く発生する限り，特定のプロセス副カテゴリは重要ではない。 

3) ニーズ及び期待が適切に捉えられ，表現されていることを確実にするために，分析された要求事

項を該当する利害関係者へフィードバックする。 

注記 利害関係者の間で対立していたり，実施できなかったり，現実的でなかったりする要求

事項を解決するための提案を説明し，合意を得る。 

［JIS X 0170:2013，6.4.1.3 c) 3)］ 

4) 利害関係者要求事項が正確に表現されていることを，利害関係者とともに確立する。 

注記 これには，利害関係者要求事項が，各発案者からみて包括的なものになっていることを

確認し，かつ，要求事項同士の対立に対する解決が利害関係者の意図を改悪していない

し損なっていないことの確認を含む。 

［JIS X 0170:2013，6.4.1.3 c) 4)］ 

要求事項の妥当性確認をする要求エンジニアリングプロセスにおいては，一つ以上のチェックポイント

を正式に日時設定するのが普通である。その目標は，その要求事項に対するシステムソリューションを実

装するための資源を約束する前に，あらゆる問題を識別することである。要求事項妥当性確認は要求事項

集合を調査して正しいシステム（つまり，利害関係者が期待するシステム）を定義しているようにするプ

ロセスに関わる。要求事項妥当性確認の最も一般的な活動は，要求事項レビュー，シミュレーション，及

びプロトタイピングの実施である。 

要求事項レビューを実施するのが要求事項文書の検証及び妥当性確認の両方のおそらく最も普通の手段

である。レビュー者のグループを任命し，簡潔な説明をし，エラー，誤った前提条件，明瞭性の欠如，検

証可能性問題，及び実際上の常識からのズレ，を見つける。レビューを実施するグループの構成が重要で

あり（例えば，取得者主導プロジェクトにおいては少なくとも取得者の代表が一人含まれることが望まし

い。），何を見つけるかの指針をチェックリストの形で用意すると役立つことがある。 

要求事項集合のあらゆる抽象レベルでレビューを行ってもよい。様々なタイプのレビューが要求事項の

開発及び保守を通じて適用できることになる。例えば，技術レビュー，インスペクション，及びウォーク

スルーである。初期の要求事項レビュー及び妥当性確認には，システムの潜在的利用者からのフィードバ

ックを得ることを目的に本物から遠いプロトタイプを用いると効果がある。 

注記1 レビューに関するその他の指針がIEEE Std 1028-2008にある。 

注記2 プロトタイピング及びシミュレーションの議論は6.3.3.2にある。 

5) ライフサイクルを通して，及びその後も，要求事項の管理に適した形式で利害関係者要求事項を

記録する。 

注記 これらの記録は，利害関係者要求事項のベースラインを確立し，システムライフサイク

ルを通して，ニーズの変更及びその発生源を保持する。これらは，システム要求への追

跡可能性の基本事項となり，次に続くシステム実体に対する要求事項のための知識の源

を形成する。 

［JIS X 0170:2013，6.4.1.3 c) 5)］ 

 
 

29 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

特に，複雑なプロジェクトでは，要求事項管理ツールの利用を考慮することが望ましい。このツールは，

要求事項間の関連を示すリンクを追跡できる能力をもつことが望ましい。要求事項管理ツールは，ライフ

サイクルを通じて要求事項の体系的な管理を促進・支援するためのものである。ライフサイクルは，要求

事項引出し・要求事項分析・要求事項変更管理・要求事項再利用・要求事項品質評価を含むが，これに限

るものではない。 

注記 要求事項管理ツールについてのその他の情報がISO/IEC TR 24766:2009にある。 

要求事項リポジトリは最初，利害関係者ニーズ，プロジェクト制約（例えば，業務方針若しくはルール

からの制約，又は規制要求事項からの制約）など，設計を支配する全システム要求事項集合の根拠となる

条件の元となる文書で構築することが望ましい。それぞれの要求事項の発生源及び根拠を捉える必要があ

る。 

利害関係者要求事項定義プロセスの一部として出力される要求事項文書には次のものが含まれる。 

− 利害関係者要求仕様（StRS） 

− 組織レベルの運用概念（ConOps） 

− システムレベルの運用概念（OpsCon） 

これらの要求事項関連文書についてのその他の情報が箇条7〜箇条9，附属書A，及び附属書Bにある。 

要求事項リポジトリにはあらゆる要求事項属性，例えば，優先度及び要求事項の重大性，を含めること

が望ましい。要求事項属性についてのその他の情報が5.2.8にある。 

6) 利害関係者要求事項から利害関係者のニーズの源への追跡可能性を維持する。 

注記 利害関係者要求事項は，ニーズのいかなる変更も考慮されることを確実にするために，

ライフサイクル中の重要な決定時期において，レビューされる。 

［JIS X 0170:2013，6.4.1.3 c) 6)］ 

初期の要求事項追跡可能性を確立・維持し，正式の要求事項がいかに利害関係者目標を満足し，かつ，

利害関係者合意を達成するか，を文書化することが望ましい。利害関係者要求事項を，システムライフサ

イクルを通して更にそれを超えて把握・追跡・維持し，かつ，構成管理下に置く必要がある。要求事項管

理ツールを利用するとこのプロセスに役立つ。追跡可能性の応用についての議論は，この規格の6.3.3.2の

タスク3の下にある。 

注記1 情報を構成管理下に置くことについてのその他の指針がJIS X 0170の6.3.5及びこの規格の

6.5.2.1にある。 

注記2 5.2.5に要求事項追跡可能性を要求エンジニアリングに属するものとして記述している。 

6.3 

要求事項分析プロセス 

6.3.1 

目的 

要求事項分析プロセスは，望まれたサービスの利害関係者要求事項主導の視点を，これらのサービスを

提供できる要求された製品の技術的な視点へ変換することを目的とする。 

このプロセスは，利害関係者要求事項を満たす将来のシステムで，制約が許す限り，いかなる特定の実

装も示さない，将来のシステムの表現を作り上げる。それは，利害関係者要求事項を満たすために，供給

者の観点から，将来のシステムがもつべき特性及び規模を明示する測定可能なシステム要求事項を作成す

ることになる。 

30 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

6.3.2 

成果 

要求事項分析プロセスの実施に成功すると次の状態になる。 

a) 製品ソリューションに対して要求される特性，属性並びに機能及び性能への要求事項が明示されてい

る。 

b) システムの方式設計及びそれを実現する手段に影響を及ぼす制約が明示されている。 

c) システム要求事項から利害関係者要求事項への完整性（integrity）及び追跡可能性が備わっている。 

d) システム要求事項が満たされていることを検証する基礎が定義されている。 

6.3.3 

アクティビティ及びタスク 

プロジェクトは，要求事項分析プロセスの観点から，適用可能な組織の方針及び手順に従って，次に示

すアクティビティ及びタスクを実施する。 

6.3.3.1 

システム要求事項の定義 

このアクティビティは，次のタスクからなる。 

1) 提供される振る舞い及び性質の観点から，システムの機能的な境界を定義する。 

注記 これには，利用者及び環境の振る舞いに対するシステムへの刺激及びその反応を含む。

そして，機械的，電気的，質量，熱，データ及び手順的な流れのようなインタフェース

上の制約の観点からの，システムとその運用環境との間に要求される相互作用の分析及

び記述を含む。これは，システムの境界で，量的な用語で表現された，期待されるシス

テムの振る舞いを確立する。 

［JIS X 0170:2013，6.4.2.3 a) 1)］ 

システム要求事項を定義する前に，システム（又はサービス）に対する境界条件を利害関係者と確立す

ることによって適用範囲に関する問題を最小化できる。境界条件に影響する要因は，次の三つである。 

− 組織：利害関係者は目標システムを利用する組織及びその組織の真の使命又は目標について一つの理

解をもつことが望ましい。 

− 環境：利害関係者は，対象システムの領域の成熟度，運用環境における対象システムと他システムと

のインタフェースの確定度，及び運用環境における対象システムと他システムとの相対的な役割，に

関心をもつことが望ましい。 

− 制約：利害関係者は対象システムのライフサイクルに影響する制約を考えることが望ましい。例えば，

コスト，スケジュール，政治的制約，及び運用的制約である。 

2) システムが実行を要求されている各機能を定義する。 

注記1 この定義は，システムが運用者を含めてどのように良好に機能を実行することが要求

されているか，システムが機能を実行することができる条件，システムが機能の実行

を開始する条件及びシステムが機能の実行を停止する条件を含む。 

注記2 機能の性能に対する条件は，システムの運用の要求された状態及びモードへの参照を

組み入れてもよい。システム要求事項は，提案されたシステム特性の抽象的な表現に

大きく依存し，望まれるシステム要求事項の十分に完全な記述を与える，複数のモデ

ル化の手法及び見方を採用してもよい。 

［JIS X 0170:2013，6.4.2.3 a) 2)］ 

31 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

システムの様々な機能及び要素間の，相互作用及びインタフェースをより理解するにつれて，性能有効

性分析，トレードオフを考慮した比較検討，設計展開，インタフェース定義，及びコスト便益評価，の組

合せを通じて要求事項を作り出す。 

繰り返すが，システムに対して，既存の要求事項を再利用する機会を識別・評価することは重要である。

これには，同様の機能又は能力をもつ既存システム，新しい対象システムに適用可能な定義された機能又

は能力，及び再利用性の程度についての情報，を識別することが含まれる。 

注記 要求事項の再利用についてのその他の指針としてISO/IEC 26551を参照。 

3) 利害関係者要求事項によってもち込まれるか，又は回避できないソリューションの制限である，

必要な実装制約条件を定義する。 

注記 これには，システム構造の高いレベルの設計から割り当てられる実装上の決定を含む。 

［JIS X 0170:2013，6.4.2.3 a) 3)］ 

制約の妥当性確認を利害関係者と行い，システム要求事項集合及び方式設計を進展させる前に，その制

約を十分理解し，かつ，訂正することが重要である。運用シナリオ及び要求事項に加えて，実装制約も外

部要因から発生することがある。外部要因とは例えば，運用環境において相互接続するシステム，イネー

ブリングシステム，又は規制要求事項である。 

4) 技術的な達成度のアセスメントを可能にする，技術的な測定量及び利用時の品質についての測定

量を定義する。 

注記 これには，利害関係者要求事項の中で識別された効果の測定量に関連付けられた，重大

な性能パラメータを定義することを含む。重大な性能測定量は，利害関係者要求事項が

満たされることを確実にするために，プロジェクトのコスト，スケジュール又は何らか

の非遵守に関連する性能リスクの識別を確実にするために，分析され，レビューされる。

JIS X 0141は，適切な測定量を識別し，定義し，利用するためのプロセスを規定する。

JIS X 0129規格群は，関連する品質測定量を規定する。 

［JIS X 0170:2013，6.4.2.3 a) 4)］ 

技術的測定量は，要求事項の中に指定された技術パラメータを達成することに対して，システム又はシ

ステム要素の進捗度合に見通しを可能にするのに用いる。技術的測定量は例えば，性能評価測定量（MOP）

及び技術的性能評価測定量（TPM）である。MOPは，システム運用に関連する物理的属性又は機能的属性

を特徴付ける測定量である。TPMとは，設計の進捗，性能要求事項への合致度合，及び重大な性能パラメ

ータに対する技術的リスクを評価するのに用いる測定量である。これらのより多くの情報は，ISO/IEC 

26702及びISO/IEC TR 24748-2を参照。利用品質の測定量を用いるのは，製品が特定利用者のニーズを満

たしているかどうか，つまり，有効性・生産性・安全性・満足度に関する特定のゴールを達成し，しかも

現実的な環境の中の特定の利用状況でそれが満たされるかどうか，を決定するためである。 

32 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

5) システムのリスクの識別又は重大性によって正当化されるので，健康，安全性，セキュリティ，

信頼性，可用性及び支援可能性のような，重大な品質に関係のあるシステム要求事項及び機能を

明示する。 

注記 このタスクには，運用及び保守の方法，環境上の影響並びに人員の損傷に関係するもの

を含めた安全性への考慮事項の分析及びその定義を含む。また，必要なリスク軽減の観

点から表現された安全性に関する各機能及びそれに関連する安全性についての完整性

（integrity）が明示され，指定された安全性に関するシステムに割り当てられることを含

む。機能的な安全性に関して適用可能な規格，例えば，JIS C 0508，及び環境保護に関し

て適用可能な規格，例えば，JIS Q 14001，が利用される。機密の情報，データ及び原材

料を危険にさらすこと及び保護することに関連するものを含めたセキュリティの考慮事

項を分析する。該当する場合には，適用できるセキュリティ規格を利用して，管理，人

員，身体，コンピュータ，通信，ネットワーク，排出物質及び環境の要素を含めて，セ

キュリティに関連するリスクを定義する。ただし，これらに限定するものではない。 

［JIS X 0170:2013，6.4.2.3 a) 5)］ 

繰り返すが，個々の要求事項に対してその発生源及び根拠を捉える必要がある。追跡可能性を更新・保

守することが望ましい。それによって，正式なシステム要求事項（導出要求事項を含めて）がいかに利害

関係者要求事項及び目標を満足し，かつ，利害関係者合意を得られるよう意図されているか，を文書化す

ることができる。 

仕様は要求事項の集合である。仕様は，製品に対する本質的な技術要求事項，資料，及びその要求事項

が満たされるかどうかを決定する基準，を記述する。要求事項分析プロセスの一部として重要な要求仕様

には次のものが含まれることがある。 

− システム要求仕様 

− ソフトウェア要求仕様 

9.4及び9.5にシステム・ソフトウェア要求仕様に対する詳細な定義内容がある。 

システム要求事項及びソフトウェア要求事項の両方を文書化する便益を次に示す。 

− 製品が何をするものかについて取得者間又は供給者間で合意を得る根拠を確立する（市場主導のプロ

ジェクトでは，利用者情報がマーケティングによって得られることがある。）。 

− 設計が始められる前に厳密な要求事項の評価を強制し，後の再設計の危険を減少させる。 

− 製品コスト，リスク，及びスケジュールを見積もるための現実的な根拠になる。 

− 組織が仕様を利用して妥当性確認及び検証の計画を作成できる。 

− 新しい利用者又は新しい運用環境に製品を配置するための十分な情報に基づく根拠になる。 

− 製品の拡張の根拠になる。 

6.3.3.2 

システム要求事項の分析及び維持 

このアクティビティは，次のタスクからなる。 

33 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

1) 各要求事項，要求事項の対又は要求事項の集合が，全体的完整性（integrity）をもつことを確実に

するために，システム要求事項の完整性（integrity）を分析する。 

注記 各システム要求事項の記述文は，一意で，完全で，曖昧性がなく，他の全ての要求事項

と矛盾がなく，実装可能で，検証可能であることを確立するためにチェックされる。欠

陥，矛盾点及び弱点は，システム要求事項の完全な集合内で識別され，解決される。そ

の結果であるシステム要求事項は分析され，それらが完全で，一貫していて，（現在の技

法又は技術的進歩の知識を仮定すれば）達成可能で，適切な詳細度で表現されているこ

とを確認する。良い要求事項の属性及び品質に関する追加の詳細な指針については

ISO/IEC 26702:2007，IEEE Standard for Application and Management of the Systems 

Engineering Processを参照。 

［JIS X 0170:2013，6.4.2.3 b) 1)］ 

繰り返すが，システム要求事項に対して，要求事項が整形式であることを検証することが重要である。

5.2.5及び5.2.6に示したように，全ての要求事項をレビューし，良い要求事項の特性をもっているか，か

つ，良い要求事項集合の特性をもっているか，を確認する。 

既存又はレガシーシステムからシステム要求事項が再利用候補として識別されている場合，利用できる

かどうかを分析することが望ましい。適用性・実現性・可用性・品質・コスト有効性・価値・流通性のよ

うな要因に基づいて分析することが望ましい。要求事項を再利用する一方で，再利用する要求事項と対象

システム固有の要求事項との一貫性チェックを慎重に行い，一貫性を確保することが望ましい。 

注記 要求事項の再利用についてのその他の指針としてISO/IEC 26551を参照。 

5.2.8にある分類は，この仕事に役立つことがある。JIS X 0170の“検証の計画”プロセスを要求事項検

証の定義・計画・実行［JIS X 0170:2013の6.4.6.3 a)］に用いることが望ましい。 

要求事項の検証に加えて，次のアクティビティは，要求事項（個別であれ集合であれ）が利害関係者ニ

ーズを適切に表現していることの妥当性確認に位置付けられる。 

2) 指定されたシステム要求事項がニーズ及び期待に対応して利害関係者要求事項を適切に反映して

いることを保証するために，分析された要求事項を該当する利害関係者にフィードバックする。 

注記 それらが利害関係者要求事項への必要十分な応えであり，他のプロセス，特に方式設計

への必要十分な入力であることが確認される。 

［JIS X 0170:2013，6.4.2.3 b) 2)］ 

要求事項の妥当性確認とは，利害関係者要求事項が正しくシステム要求事項に変換されたことを確かな

ものにすることである。様々な技法を用いてもよい。例えば，利害関係者レビュー，プロトタイピング，

モデリング及びシミュレーション，概念モデリング，及び形式的モデリングである。適切な技法は利害関

係者の特性によって変わることがある。そのため，複数の技法を採用し全ての利害関係者に説明可能にす

ることが必要な場合がある。レビューについては，この規格の6.2.3.3のタスク4で議論している。 

利害関係者レビューが，要求事項の妥当性確認でよく用いる技法で，簡単に実施できる。利害関係者レ

ビューでは，キーとなる利害関係者を含むグループとともに要求事項分析を実施する。キーとなる利害関

係者とは，システム要求事項が完全に，正確に，一貫して利害関係者要求事項の意図を反映していること

を決定する利害関係者である。レビューを助けるためチェックリストを開発することがよくある。それに

よって，該当する要求事項カテゴリを全て考慮し，かつ，文書化したことが確かめられる。 

34 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

プロトタイピングは，要求事項を引き出し，システム要求事項の解釈の妥当性を確認し，要求事項の属

性を明確化又は検討し，かつ，どんな省略された要求事項があるのかを識別するためによく採用される。

プロトタイプの利点は，プロトタイプが利害関係者の評価・入力についてのより豊富な状況を与えること，

プロトタイプによって前提条件をより簡単に解釈できるようになること，なぜプロトタイプが誤っている

かという有益なフィードバックが得られること，にある。例えば，利用者インタフェースの動的な振る舞

いは，動画的な又は静的なプロトタイプによって文章及び図的なモデルで表現するよりずっと分かりやす

くなる。しかし同様に欠点もある。プロトタイプを開発するコスト，誤った前提条件及び保証のない期待

が隠れている危険，並びに本物から遠いプロトタイプを用いることによる品質問題，である。プロトタイ

プの目的が十分に理解されている場合は，本物からの近さを適切に設定することで効果的かつ早期に要求

事項レビュー及び妥当性確認が達成できる。本物との近さ及び構築品質のレベルはプロトタイプの目的に

基づくことが望ましい。 

モデリング及びシミュレーションは，利害関係者による要求事項の妥当性確認を助けるために用いるこ

とができる。モデリング及びシミュレーションの利点は，相互作用を実演できること及び結果が利害関係

者の期待するものでなかったときに感度分析を見込めること，にある。 

概念モデリングは，利用可能なもう一つの技法である。その目的はソリューションの設計を始めるより

むしろ問題を理解することを手助けすることにある。したがって，概念モデルは，問題領域から引き出し

た実体のモデルから成り，実世界における実体の関連性及び依存性を反映するように構成する。開発でき

るモデルには幾つかの種類がある。例えば，データ及び制御フロー，状態モデル，イベントトレース，ユ

ーザ相互作用，オブジェクトモデル，システムコンテキストモデルである。モデルの選択に影響を与える

要因には次のものがある。 

− 問題の本性：あるタイプのアプリケーション領域では，ある側面を特に厳密に分析することが求めら

れる。例えば，制御フロー及び状態モデルは情報システムよりも実時間システムでより重要になり得

る。 

− 専門性：供給者が経験をもっているモデリング表記法又は手法を採用すると生産性がより高いことが

しばしばある。しかし，ツールによるサポートがより厚い，プロセス要求事項として強制されている，

又は単に“より良い”，表記を採用することが適切又は必要なことがある。 

− 取得者のプロセス要求事項：取得者は特定の表記法・手法を強要することがある。これは上に述べた

要因と競合することがあり得る。 

− 手法・ツールの利用可能性：訓練・ツールによるサポートが不十分な表記法又は手法は，たとえそれ

が特定の問題タイプに他よりも適していたとしても，広く受け入れられないことがある。 

離散数学に基づく表記法を用い，論理的推論に遡ることができる形式的モデリングは，幾つかの特殊領

域に影響を与えてきた。形式的モデリングは，取得者又は標準によって強制されることがある。又は，あ

る重大な機能若しくは要素の分析には説得力のある利点をもたらすことがある。 

35 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

3) システム要求事項と利害関係者要求事項との間の追跡可能性を示す。 

注記 システム要求事項と利害関係者要求事項との間の双方向の追跡可能性を維持する。すな

わち，全ての達成可能な利害関係者要求事項は，一つ以上のシステム要求事項で満たさ

れる。全てのシステム要求事項は，少なくとも一つの利害関係者要求事項を満たすか又

は満たすことに寄与する。システム要求事項は，利害関係者のニーズ及び方式設計への

追跡可能性を可能にする適切なデータリポジトリに，保持される。 

［JIS X 0170:2013，6.4.2.3 b) 3)］ 

要求事項追跡は要求事項の発生源を発見し，要求事項の影響を予測することに関わる。追跡可能性にイ

ンタフェース要求事項を含めることが望ましい。追跡は，カバレージ解析（全ての利害関係者要求事項が

設計において満たされ，各々の下位レベル要求事項が正当であるようにすること），遵守解析（利害関係者

要求事項が満足されたことを文書化すること），及び要求事項が変化するときの影響分析，を実行するため

の根本である。要求事項は，次のものに追跡可能であることが望ましい。  

− より下位のレベルの要求事項へ（例えば，利害関係者要求事項からシステム要求事項へ，さらに，シ

ステム要素要求事項へ，最後はハードウェア及びソフトウェア要求事項へ） 

− 方式設計へ（例えば，論理又は物理設計へ） 

− システム要素へ（例えば，要求事項を実装するソフトウェア及びハードウェアへ） 

− その要求事項を満たす検証又はテスト実体へ，さらに，それを支持するモデル及び分析へ 

要求事項は，より上位の要求事項及び動機付けした利害関係者に対しても追跡可能であることが望まし

い（例えば，あるソフトウェア要求事項から，それのおかげで満たされるシステム要求事項へ遡る。）。ト

レードオフを考慮した比較検討又は設計検討から導出された要求事項の場合，これらの導出要求事項から，

それが導出された設計検討へ遡れることが望ましい。また，その検討から，その検討に情報を与えた上位

レベルの要求事項へ遡れることが望ましい。双方向の追跡可能性は次の全ての目的に利用できる手法であ

る。 

− システムレベルから最下位のシステム要素までの全ての要求事項の完整性（integrity）及び正確性を改

善する。 

− 要求事項の網羅性・法令遵守・複雑性などの関連する測定量とともに，要求事項開発及び割当ての追

跡を可能にする。 

− 設計のある側面を捕捉する要求事項層間の関連を文書化・レビューする方法になる。 

− 将来，システムの実装の保守・変更を容易にする助けになる。 

4) システムライフサイクルを通して付随する論理的根拠，決定及び前提とともに，システム要求事

項の集合を維持する。 

［JIS X 0170:2013，6.4.2.3 b) 4)］ 

要求事項は，その構成を制御しなければならない。要求事項とともに記録する補助情報には，個々の要

求事項・決定事項・前提条件・変更履歴に対する根拠の要約及び5.2.8にある要求事項カテゴリ分け，が

含まれる。繰り返すが，要求事項管理ツールの利用は，要求事項追跡可能性の維持及び構成管理という煩

雑で複雑なプロジェクトを手助けする。 

6.4 

他の技術プロセスにおける要求エンジニアリングアクティビティ 

6.4.1 

方式設計における要求事項 

36 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

方式設計プロセスは，システム要求事項を満たすソリューションをまとめあげることを目的とする。 

6.4.1.1 

方式の定義 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク1)は含まれない。要求エンジニアリングに関連する特定の指

針がないからである。 

2) 要求事項分析で識別されたシステム機能を分割し，システム方式の要素にそれらを割り当てる。

割当てのために必要となる派生要求事項を作り出す。 

［JIS X 0170:2013，6.4.3.3 a) 2)］ 

方式設計ソリューションは，システムを構成するシステム要素の集合に対する要求事項の形で定義され

る。要求事項と方式設計との間の追跡可能性を，システム要素及びインタフェースを含めて，確立・維持

することが重要である。導出要求事項が生まれたら，システム要素に対する検証及び妥当性確認の基準を

識別・記録することが望ましい。 

3) システム要素間のインタフェース及び外部システムとのシステム境界でのインタフェースを定義

し，文書化する。 

［JIS X 0170:2013，6.4.3.3 a) 3)］ 

インタフェースの要求事項は，インタフェース制御文書のような適切なインタフェース仕様を通じて確

認することが望ましい。インタフェース要求事項を方式設計ソリューションに組み込む。システム間の相

互作用を含むプログラムがこれらの文書を共有する。 

6.4.1.2 

方式の分析及び評価 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク1)，3)及び4)は含まれない。要求エンジニアリングに関連す

る特定の指針がないからである。 

2) どのシステム要求事項が運用者に割り当てられるかを決定する。 

注記 この決定は，利用要因の文脈を考慮し，最も有効で，効率的で，信頼できる人対機械の

相互作用のために，次に示す要因を最小限考慮する。 

2.1) 

人間の能力の限界 

2.2) 

安全性に対して重大な人間の行動及び誤りの結果への対応 

2.3) 

人間の仕事ぶりのシステム及び運用への結合 

［JIS X 0170:2013，6.4.3.3 b) 2)］ 

注記 方式設計のその他の指針がJIS X 0170:2013の6.4.3にある。 

6.4.2 

検証における要求事項 

検証プロセスは，指定された設計要求事項がシステムによって満足されていることを確認することを目

的とする。 

注記 検証についてのその他の指針がJIS X 0170:2013の6.4.6（検証プロセス）にある。 

6.4.2.1 

検証の計画 

このアクティビティは，次のタスクからなる。 

37 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記 このアクティビティ配下のタスク1)及び3)は含まれない。要求エンジニアリングに関連する特

定の指針がないからである。 

2) システム要求事項に基づく検証計画を定義する。 

注記 その計画は，結合戦略で定義された構成の順序の説明となる。必要に応じて，障害診断

のための分解戦略を考慮に入れる。スケジュールでは，一般的には，完全に構成された

製品に応じて信頼を次第に築いていく，リスクを管理した検証ステップを定義する。 

［JIS X 0170:2013，6.4.6.3 a) 2)］ 

要求事項を作成するとき最初に検証手法を関連付けておくとこのアクティビティは円滑に進む。検証手

法は文書化することが望ましい。文書化には，要求事項検証・要求事項追跡可能性マトリクス，又は検証

計画の中の検証記述が含まれる。検証手法は，購入者が受け入れられるように，各要求事項が遵守される

ことを，どのように（成功基準及び終了方法を含め），どこで及びいつ証明するか，を定義する。一つの検

証手法は，個々の要求事項に付随し，その要求事項が満たされたことを証明する客観的な情報を生み出す

活動を定義する。良い検証手法の定義には，次の考慮内容の幾つか又は全てが含まれている。 

− いかに：どの検証手法を適用するかを識別する（下の一覧を参照）。 

− 誰が：検証を実施するために主導的な責任を伴う組織又は個人（例えば，契約者，下請負契約者，ベ

ンダ，製品チーム，又は供給者）を識別する。 

− いつ：検証をいつ行うかのプログラム計画を指定する。 

− どこで：検証アクティビティに必要な特別な場所・環境を指定する。 

要求事項が満たされたという客観的な証拠を得るために用いられる四つの標準的な検証手法がある。そ

れらは，インスペクション，分析又はシミュレーション，デモンストレーション，及びテストである。 

インスペクション：要求事項への遵守度合を確認するために該当する文書に違反項目がないかを試験す

ること。インスペクションは，試験及び観察で最もよく決定できる特性（例えば，塗装色，重さ）を検証

するために用いる。インスペクションは，一般に非破壊的であり，典型的には，視覚・聴覚・嗅覚・触覚・

味覚の利用，単純な物理的操作，機械的・電気的なゲージング，及び測定，を含む。 

良い実践：何が要求されているかと何をインスペクションしようとしているかとの比較をするため

に用いる文書又は図を含める。 

分析（モデリング及びシミュレーションを含め）：理論的に適合していることを示すために，定義され

た条件下で解析データ及びシミュレーションを使用すること。現実的な条件でテストすることが達成でき

ない又はコスト効果的でないところで用いる。分析（シミュレーションを含め）は，適切な要求事項，仕

様又は導出要求事項が，提案されたソリューションで満たされていることを立証する方法として用いられ

ることがある。分析は，また，“類似性”に基づくこともある。つまり，類似する項目の以前の検証をレビ

ューし，検証状況が現在のシステム要素に正当に移行できるということを確認する。類似性は，次の場合

だけ利用できる。 

− その項目が設計・製造・用途において似ている場合 

− 同種のシステム要素に対して等価な又はより厳重な検証仕様が用いられた場合 

− 意図する運用環境が同じ又は同種のシステム要素よりも厳密でない場合 

良い実践：解析の汎用的な名前（故障モード影響解析のような），解析又はコンピュータツール，及

38 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

び／又は数値的手法，入力データの発生源，及び生データの分析方法，を識別する。分析手法及び

ツール（シミュレーションを含め）が，客観的証明又は要求事項適合の提示として受入れ可能であ

ることを，取得者と合意できているようにする。 

デモンストレーション：機能的なパフォーマンスを定性的に見せることであり，通常，あっても最小限

の計測機器又はテスト機器を用いて行う。デモンストレーションは，供給者が選択したシステム刺激を伴

う一連のテスト作業を用いて，システム若しくはシステム要素がその刺激に適切に反応するか，又はシス

テムを用いる時に運用者が彼らに用意された機能を実行できるか，を示す。観測を行い，あらかじめ定義

された反応と比較する。要求事項又は仕様が統計的な用語（例えば，平均修理時間，平均消費電力）で与

えられているとき，デモンストレーションが適切なことがある。 

良い実践：成功したという証拠を集めるために誰が証人になるか，後続する一般的なステップは何

か，どんな特別な資源（例えば，計測機器，特別なテスト装置若しくは設備，シミュレータ，特定

のデータ収集，又はデモンストレーション結果の厳格な分析）が必要か，を記載する。 

テスト：ある項目の運用性，支援可能性，又は性能を，現実の又はシミュレーション制御条件の支配下

で，定量的に検証する行為である。分析のために非常に正確な定量データを獲得するために特別なテスト

装置又は計測機器がしばしば用いられる。 

良い実践：成功したという証拠を集めるために誰が証人になるかを記載する。テスト設備，テスト

装置，特別な資源ニーズ及び環境条件，要求される資格及びテスト要員，後続する一般的なステッ

プ，収集すべき特定のデータ，収集データの再現性の基準，並びに結果を分析する手法，を識別す

る。 

注記 認証はしばしば検証の5番目の手法として含まれる。認証は書面による保証で，システム又は

システム要素が要求される標準に従って開発され，かつ，その要求事項に適合していることの

保証である。これは，システム又はシステム要素が，取り決めた標準に割り当てた機能を実行

できることを保証するものである。開発レビュー及びシステム検証・妥当性確認の結果は認証

の根拠を形成する。認証は，受け入れられた標準に反してないかどうか，第三者によって実行

されるのが一般的である。 

この情報を更新された要求事項追跡可能性マトリクス（RTM）の中に含め，かつ，文書化する。 

6.4.2.2 

検証の実施 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク1)，3)及び4)は含めない。要求エンジニアリングに関連する

特別な指針がないからである。 

2) 指定された設計要求事項に対する遵守を示すために検証を行う。 

注記 不適合は，無作為の障害及び／又は設計の誤りの存在を識別し，是正処置が必要に応じ

て開始される。検証は，組織の制約と整合性がとれており，検証作業，条件及び結果の

再現における不確定性を最小にするような方法で実行される。検証作業及び検証結果の

承認された記録が作られる。 

［JIS X 0170:2013，6.4.6.3 b) 2)］ 

要求事項の追跡可能性は，要求事項の足跡を説明するための単一点としてしばしば用いられ，ある要求

事項からその発生源へ遡れる，かつ，その要求事項が満たされたことをライフサイクルを通じて評価する

39 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

ためにその要求事項の先へたど（辿）れることを意味する。要求事項の追跡可能性において，検証手法・

検証情報を要求事項に付随させ，システム又はシステム要素がその要求事項を満たすことをいかに検証さ

れるかを示す。システムがライフサイクルフェーズを通じて動くにつれて，作業成果物への要求事項の追

跡可能性を加えることが望ましい。 

6.4.3 

妥当性確認における要求事項 

妥当性確認プロセスは，システムによって提供されるサービスが利用中に利害関係者要求事項を遵守し，

意図された運用環境で，意図された利用を達成していることを示す，客観的な証拠を提供することを目的

とする。 

6.4.3.1 

妥当性確認の計画 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク1)は含まれない。要求エンジニアリングに関連する特定の指

針がないからである。 

2) 妥当性確認計画を準備する。 

注記 妥当性確認は，利害関係者要求事項に基づいている。必要に応じて，導入したシステム

の適合性に確信を次第に築いていき，食い違いの診断を助けるような，例えば，様々な

運用状態，シナリオ及び任務といった，妥当性確認ステップを定義する。各妥当性確認

の目的，条件及び適合基準が指定されるに従って，妥当性確認戦略を実施するのに必要

な技法及び手法が指定される。利害関係者要求事項が，包括的に指定できないか，又は

しばしば変わる場合には，システム進化の（しばしば速く開発される）増分について繰

返し妥当性確認することによって，利害関係者要求事項を洗練化し，ニーズの正しい識

別におけるリスクを低減してもよい。例えば，JIS Z 8530では，利用者を関与させる反

復のライフサイクルを記述している。 

［JIS X 0170:2013，6.4.8.3 a) 2)］ 

システムレベルの運用概念（OpsCon）及びベースラインとした利害関係者要求事項は妥当性確認計画ア

クティビティへの入力である。 

6.4.3.2 

妥当性確認の実施 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク1)，3)，4)及び5)は含まれない。要求エンジニアリングに関

連する特定の指針がないからである。 

2) 利害関係者要求事項に対するサービスの適合性を示すために妥当性確認を実施する。 

注記 妥当性確認は，組織の制約と整合性がとれており，妥当性確認の作業，条件及び結果の

再現における不確定性を最小にするような方法で実行される。妥当性確認作業及び結果

を客観的に記録し承認する。妥当性確認は，全ての運用上の要求事項，機能的な要求事

項及び使用性の要求事項を満足することだけでなく，顧客の満足度を構成する，しばし

ば非公式的に表現されるが，時には最も重要である，態度，経験及び主観的テストをも

満足することを確認するために行われることがある。 

［JIS X 0170:2013，6.4.8.3 b) 2)］ 

40 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

要求事項の妥当性確認は，プロジェクト権限者及びキーとなる利害関係者による承認に支配される。こ

のプロセスは，利害関係者要求事項定義プロセスの間に呼び出され，要求事項が的確に利害関係者ニーズ

を反映していることを確認し，妥当性確認の基準を確立する。つまり正しい要求事項を我々がもっている

ことを確認する。システムの妥当性確認では，システムが，構築された暁に，利害関係者が表明したニー

ズ及び要求事項を満足していること，つまりそれが正しいシステムであること，を確認する。要求事項の

追跡可能性を保守することが望ましい。また，要求事項追跡可能性マトリクス（RTM）の形式で文書化し

てもよい。 

注記1 妥当性確認に関するその他の指針がJIS X 0170の6.4.8（妥当性確認プロセス）にある。 

注記2 使用性要求事項の妥当性確認に関するその他の指針が，ISO/IEC TR 25060及びISO/IEC 

25062にある。 

6.5 

要求事項管理 

6.5.1 

管理の概要 

要求事項管理は，進化する要求事項及び付随する状況，並びに要求エンジニアリング活動からの履歴情

報を記録し保守するタスクを包含している。要求事項管理は，また，対象システムの全てのレベルに対し

てベースラインとなる要求事項を定義・制御・周知するための手順を確立する。JIS X 0170:2013及びJIS X 

0160:2012で定義されているように，効果的な要求事項管理は組織のプロジェクト及び技術プロセスを実

施する中で発生する。 

要求事項が静的であることはまれ（稀）である。開発管理の観点からいえば，一連の要求事項を永久に

凍結することが望ましいが，それが可能であることはまずない。進化しそうな要求事項を識別し，取得者

及び技術陣の双方に対して伝達することが望ましい。要求事項のコアな部分集合を早い段階で凍結できる

ことはある。提案された新しい要求事項の影響を評価し，要求事項ベースラインとなる要求事項の最初の

意図が維持されるか又は意図の変化が取得者に理解・承認されるようにする。 

ほとんど全ての場合，要求事項の理解はライフサイクル活動が進むとともに進化し続ける。このことは

しばしばライフサイクルの後の段階で要求事項の改正を招く。おそらく要求エンジニアリングについて理

解する上で最も重要な点は，要求事項の相当な部分が間違いなく変化するということである。これは分析

における誤りによることもあるが，しばしば環境の変化による避けられない結果である。例えば，取得者

の運用環境若しくはビジネス環境の変化，又はシステムを販売するマーケットの変化である。 

しかしながら，ライフサイクルの間に要求事項を変化させることに注意力を働かせることが望ましい。

要求事項によっては回避できない場合はあるが，あまりに節操のない変更は，“要求クリープ”（要求の漸

増）を招き，費用超過，スケジュール遅延，設計エラー，買い手の不満，又はプロジェクトの中断すらも

たらし得る。 

6.5.2 

変更管理 

要求事項の変更原因が何であれ，変更の不可避性を認識し，変更の影響を軽減するための処置を講ずる

ことは重要である。提案された変更が定義された影響評価・レビュー・承認プロセスを経るようにし，か

つ，注意深い要求事項の追跡及び版管理を適用することによって，変更を管理しなければならない。それ

ゆえ，要求エンジニアリングプロセスは，単なるフロントエンドタスクではなくライフサイクルにわたる。

典型的なプロジェクトでは，要求事項管理のアクティビティは，要求事項引出しから変更管理にわたって

進化する。 

よく用いられるベースラインは機能的ベースライン・割当てベースライン・開発ベースライン・製品ベ

ースラインである。与えられたプロジェクトで用いるベースラインは，それに付随する変更承認に必要な

41 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

権限のレベルとともに，プロジェクトの構成管理計画の中で識別する。これらのベースラインを次に示す。 

− 機能的ベースラインは，外部インタフェース記述を含むレビューされたシステム要求事項に対応する。 

− 割当てベースラインは，インタフェース要求仕様を含むレビューされたシステム要素要求仕様に対応

する。 

− 開発ベースラインは，ライフサイクル内で選択した幾つかの時点で，進化するシステム及びシステム

要素の構成を表現する。このベースラインに対する変更権限は基本的に供給者組織にある，というの

が一般的である。 

− 製品ベースラインは，完成したシステムに対応する。 

6.5.2.1 

構成管理 

構成管理プロセスは，プロジェクト又はプロセスの全ての識別されたアウトプットの完整性（integrity）

を確立し，維持し，関係する当事者が利用できるようにすることを目的とする。 

6.5.2.1.1 

構成管理の計画 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク1)は含まれない。要求エンジニアリングに関連する特定の指

針がないからである。 

2) 構成制御の対象となる品目を識別する。 

注記 品目は，適切な場合に，一意で，永続性のある識別子又は印によって区別される。識別

子は，構成制御下でその品目がそれらの仕様書又は同等の記述物に，明白に追跡できる

ように，関連する標準及び製品分野の規則に従っている。 

［JIS X 0170:2013，6.3.5.3 a) 2)］ 

システムレベルの運用概念（OpsCon）及び利害関係者・システム・システム要素要求事項が，構成管理

計画における構成制御のための情報項目として識別する。 

6.5.2.1.2 

構成管理の実施 

このアクティビティは，次のタスクからなる。 

42 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

1) 完整性（integrity）及びセキュリティの適切なレベルで，構成に関する情報を維持する。 

注記 これは，構成制御下の品目の性格を考慮することを含む。構成記述は，可能な場合に，

製品又は技術標準に適合する。構成情報が，他のベースラインの構成の状態への前後の

追跡ができることを確認する。指示された時間又は定義された状況下で文書化されたベ

ースラインを作成するために，構成品目の進化している構成状態を統合する。ベースラ

インのための論理的根拠及び関連する認可を構成ベースラインのデータに記録する。合

意，関連する法令又は業界のベストプラクティスに従って，システムライフサイクルを

通して構成記録を維持し，保管する。 

2) 構成ベースラインへの変更が適切に識別され，記録され，評価され，承認され，取り入れられ，

かつ，検証されることを確実にする。 

注記 指定された時期又は定義された状況下で，構成品目の進化している構成状態を統合して，

文書化されたベースラインを形成する。構成ベースラインのデータに，構成のステップ，

ベースラインのための論理的根拠及び関連する認可を記録する。合意，関連する法令又

は業界のベストプラクティスに従って，システムライフサイクルを通して構成記録を維

持し，保管する。情報の正確さ，適時性，リスク抑制のための完整性（integrity）及びセ

キュリティを確認するため，現在の構成状況及び以前の全ての構成の状況が記録され，

検索され，かつ，統合されていることを管理する。監査をして，図面，インタフェース

制御資料及び他の合意された要求事項に対するベースラインとの適合性を検証する。 

［JIS X 0170:2013，6.3.5.3 b)］ 

変更がシステムレベルの運用概念（OpsCon）及び利害関係者・システム・システム要素要求事項に対し

て行われるとき，その変更を正式に捕捉し，特定の変更と関連する根拠を識別する構成情報に沿って要求

事項のベースラインを文書化する必要がある。要求事項の追跡可能性を維持し，要求事項追跡可能性マト

リクス（RTM）の形で文書化してもよい。 

要求事項は，プロジェクト及び組織の構成管理プロセスに従って構成管理されなければならない。 

注記 JIS X 0170:2013及びJIS X 0160:2012両方の6.3.5に，構成管理に関するその他の情報がある。 

6.5.2.2 

情報管理 

情報管理プロセスは，システムライフサイクルの期間中及び必要に応じてシステムライフサイクルの後

に，指定された当事者に，関連する，適時の，完全な，有効な，かつ，必要ならば，機密の，情報を与え

ることを目的とする。 

6.5.2.2.1 

情報管理の計画 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク2)〜5)は含まれない。要求エンジニアリングに関連する指針

が特にないからである。 

1) 組織の方針，合意又は法令に従って，システムライフサイクルの間に管理され，それ以降の定義

された期間で，維持される情報の項目を定義する。 

［JIS X 0170:2013，6.3.6.3 a) 1)］ 

システムレベルの運用概念（OpsCon）書及び利害関係者要求仕様・システム要求仕様・ソフトウェア要

求仕様・その他システム要素要求仕様をシステムライフサイクル中に管理すべき情報項目として識別する。 

43 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

6.5.2.2.2 

情報管理の実施 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク2)〜6)は含まれない。要求エンジニアリングに関連する指針

が特にないからである。 

1) 情報の識別された項目を得る。 

注記 これは，情報の生成又は適切な発生源からの収集を含んでもよい。 

［JIS X 0170:2013，6.3.6.3 b) 1)］ 

システムレベルの運用概念（OpsCon）書及び様々な要求仕様を，構成ベースラインを反映しながら作成

したら，指定した情報管理の権限者及び責任者に情報項目を渡す。要求事項が変更され新しいベースライ

ンができたら，変更後の情報項目を情報管理に渡す。 

要求事項情報は，組織の情報管理プロセスに従って管理されなければならない。 

注記 JIS X 0170:2013及びJIS X 0160:2012両方の6.3.6に，情報管理に関するその他の詳細情報があ

る。 

6.5.3 

要求事項の測定 

測定プロセスは，プロセスの効果的管理を支援し，製品の品質を客観的に示すために，組織内で開発さ

れる製品及び実施されるプロセスに関するデータの収集，分析及び報告を目的とする。 

6.5.3.1 

測定の計画 

このアクティビティは，次のタスクからなる。 

注記 このアクティビティ配下のタスク5)〜7)は含まれない。要求エンジニアリングに関連する特定

の指針がないからである。 

1) 測定と関連する組織の性格を記述する。 

2) 情報ニーズを識別し，優先順位付けする。 

3) 情報ニーズを満たす尺度を選択し，文書化する。 

4) データ収集，分析及び報告手順を定義する。 

［JIS X 0170:2013，6.3.7.3 a) 1)から4)］ 

一つの規律として，プロセス及び製品両方の側面から要求事項を測定すると，要求エンジニアリングは

効果的なものになる。要求事項に対する情報ニーズへの見通しを得るため，複数の測定量が必要な場合が

ある。様々な測定量が有益であると多くの実践が一貫して示している。この例を次に示す。 

− 要求事項の不安定度：プロセスの側面においては，要求事項が不安定であるということは，組織の要

求エンジニアリングプロセスが要求事項の集合を整形式の要求事項集合に収束させられないことを示

している。製品の側面においては，不安定度の値が高いということは，利害関係者がシステム要求事

項に関してコンセンサスに至ることができないリスクを早い段階で示し，ライフサイクルの後続活動

に相当なリスクを負わせることを示している。 

その他の有益な要求事項の測定量には次のものがある。 

− 要求事項の動向 

− 要求事項変更率及び積み残し 

44 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 要求事項検証 

− 要求事項妥当性確認 

− 計画に対するTBD及びTBRの解決進捗度 

ソフトウェアプロジェクト管理を多くの観点から支援するソフトウェア機能規模測定法（Functional Size 

Measurement methods：FSM法）では，ソフトウェア要求事項が用いられる。FSM法は，二つの部分から

構成される：一つはプロジェクト管理のための用途，もう一つは，予測及び実績の管理のための用途であ

る。もしFSM法で事実に近い結果を得るつもりならば，システム要求事項からシステムのソフトウェア要

求事項への正確で完全な割当て・導出を達成することが非常に重要である。 

注記1 JIS X 0135-1:2010にFSM概念及びその用途の詳細がある。 

注記2 JIS X 0170:2013及びJIS X 0160:2012両方の6.3.7に測定プロセスについてその他の情報があ

る。JIS X 0141:2009にもある。 

6.5.3.2 

測定の実施 

このアクティビティは，次のタスクからなる。 

1) データ発生，収集，分析及び関連するプロセスへの報告の手順を統合する。 

2) データを収集し，蓄積し，照合する。 

3) データを分析し，情報製品を開発する。 

4) 結果を分析し，測定の利用者に伝達する。 

［JIS X 0170:2013，6.3.7.3 b)］ 

ライフサイクルを通じてすぐにデータが利用可能な測定量を選ぶことは良い実践である。そうすると，

データ集合を要求関連プロセスに統合することができ，データ及びそれによる見通しを，要求エンジニア

リングが進行する中で定期的に得ることができる。分析した要求事項関連尺度を集めてレビューすること

は良い実践である。前兆となる傾向及び予測を調べてリスク管理を助けることができる。 

要求事項の測定は組織の測定プロセスに従って管理されなければならない。 

7 

情報項目 

プロジェクトは，要求エンジニアリングプロセスの一部として次の情報項目を作成しなければならない。 

− 利害関係者要求仕様（StRS）書 

− システム要求仕様（SyRS）書 

− ソフトウェア要求仕様（SRS）書。ただし，JIS X 0160に適合する場合，情報項目には，この規格の

箇条9に定義する内容を含めなければならない。 

注記1 5.4で議論したように，3種の文書タイプのそれぞれに対して複数の仕様書を作成することが

ある。例えば，SyRSをシステム及びシステム要素に対して作成することがある。 

注記2 三つの仕様書StRS・SyRS・SRSは，よく似た情報項目を含むことがある。これは同じ製品

に対する異なる視点と考えられる。利用しやすくするため，この規格では三つの仕様という

形で典型的な内容を別々に提示する。 

注記3 ISO/IEC/IEEE 15289:2011は，システム・ソフトウェアライフサイクルの中で作成する特定

の情報項目の識別及び計画についての指針を提供する。 

情報項目の管理は，JIS X 0160:2012及びJIS X 0170:2013の情報管理プロセス，JIS X 0160:2012の文書

45 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

管理プロセス，並びにJIS X 0170:2013の6.2.4の知識管理アクティビティを適用することによって実施し

なければならない。 

情報項目は，要求される内容が容易に入手可能で，かつ，論理的に構成されている限りにおいて，物理

的な文書化を要求していない。 

例 モデル駆動開発（MDD）法では，ほとんど全てのシステム情報をモデリングツールで保守する。

この場合，情報はモデリングツールのリポジトリに関連をもって蓄積される。要求される情報は，

モデルの形で見るか又はレポート若しくはテーブル様式で抽出する。 

8 

情報項目に対する指針 

8.1 

要求情報項目のアウトライン 

箇条8では，推奨する様式を，最終文書に対するアウトラインの形で提供する。 

8.2 

利害関係者要求仕様書 

8.2.1 

序文 

利害関係者要求仕様（StRS）は，なぜシステムを開発又は変更しようとするのかという組織の動機を記

述し，システムが利用されるプロセス及び方針・ルールを定義し，利害関係者の視点からトップレベルの

要求事項を，利用状況から導出される利用者，運用者，又は保守者のニーズを含めて，文書化する。ビジ

ネス分野においては，新しい事業環境に適応するために組織がいかに新しい事業を追求しようとしている

か又は現行事業を変更しようとしているか，かつ，その事業に貢献するための手段としてシステムをいか

に活用するか，をStRSは記述する。その記述には，組織レベルでは，組織環境，ゴール・目標，事業モ

デル，及び情報環境を含み，業務運用レベルでは，業務運用モデル，業務運用モード，業務運用品質，組

織体制，及び提案するシステムの概念を含む。 

StRSの情報項目は，利害関係者が定義することが望ましい。利害関係者は，仕様の内容に対して責任を

もつことが望ましい。StRSは，利害関係者の要求プロセスへの積極的な参画の根拠となる。StRSに含ま

れる利害関係者要求事項の典型的なタイプは，組織要求事項，ビジネス要求事項，及び利用者要求事項で

ある。 

注記1 ISO/IEC/IEEE 15289:2011には，ビジネス要求事項・組織要求事項・利用者（利害関係者）

要求事項をシステム要求事項に含めるよう指針を載せている。この規格ではこれらの要求事

項をStRSに含める。その内容を利害関係者の視点で定義するのが望ましいからである。これ

らの要求事項は，技術的な考察を加えることによってSyRSに継承される。 

注記2 StRSは，多くの産業においてしばしばビジネス要求仕様（BRS）と同一視される。この規格

の読者は，読者の環境に応じてStRSをBRSに置き換えてもよい。 

注記3 利害関係者要求事項及びビジネス要求事項はThe Guide to the Business Analysis Body of 

Knowledge (BABOK) Ver. 2では次のように区別されている。ビジネス要求事項は企業のゴー

ル，目標，又はニーズの高レベルの記述である。ビジネス要求事項は，なぜプロジェクトが

開始されるか，何をプロジェクトが達成しようとするのか，及びプロジェクトの成功を測定

するのにどのような測定法を用いるか，を記述する。利害関係者要求事項は，特定の利害関

係者又は利害関係者クラスのニーズの記述である。利害関係者要求事項は，所定の利害関係

者がもっているニーズ又はその利害関係者がいかにソリューションと相互作用するか，を記

述する。利害関係者要求事項はビジネス要求事項と様々なクラスのソリューション要求事項

との橋渡しの役割をする。 

46 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

8.2.2 

StRSアウトラインの例 

StRS固有の要求条項を構成するのに，利害関係者の総意としてその構成方法が要求事項の理解を助ける

と合意されるように構成することが望ましい。全てのプロジェクトに最適な単一の構成手法はない。組織

又はビジネスの文脈において作成するStRSのアウトライン例を図6に示す。 

1. Introduction 序文 

1.1 Business purpose 事業の目的 
1.2 Business scope 事業の適用範囲 
1.3 Business overview 事業の概要 
1.4 Definitions 定義 
1.5 Stakeholders 利害関係者 

2. References 参考文献 
3. Business management requirements 事業管理要求事項 

3.1 Business environment 事業環境 
3.2 Goal and objective ゴール及び目標 
3.3 Business model 事業モデル 
3.4 Information environment 情報環境 

4. Business operational requirements 業務運用要求事項 

4.1 Business processes 業務プロセス 
4.2 Business operational policies and rules 業務運用方針及びルール 
4.3 Business operational constraints 業務運用制約 
4.4 Business operational modes 業務運用モード 
4.5 Business operational quality 業務運用品質 
4.6 Business structure 業務の構造 

5. User requirements 利用者要求事項 
6. Concept of proposed system 提案システムの概念 

6.1 Operational concept システムレベルの運用概念 
6.2 Operational scenario 運用シナリオ 

7. Project Constraints プロジェクト制約 
8. Appendix 付録 

8.1 Acronyms and abbreviations 頭字語及び略語 

図6−StRSアウトラインの例 

8.3 

システム要求仕様書 

8.3.1 

序文 

システム要求仕様（SyRS）は，選ばれた対象システムに対する技術的な仕様及び想定される人間システ

ム相互作用に対する使用性を識別する。システム要求仕様は，応用分野の視点から高レベルのシステム要

求事項を定義し，システム全体の目標，目標とする環境，及び制約・前提条件・非機能要求事項の記述，

に関する背景情報とともに定義する。SyRSは，また，システムの状況・利用方法のシナリオ・主要な応

用領域の実体・データ・情報・ワークフローを描くために設計された概念モデルを含むことがある。 

SyRSの目的は，システムと外部環境との相互作用又はインタフェースの形で，システムが何をするこ

とが望ましいかを記述することである。SyRSは，入力・出力・入出力間に要求される関係，を全て記述

することが望ましい。SyRSは伝統的に，取得者の要求事項を，システムを仕様化・構築する技術陣に伝

える文書として見られてきた。仕様を構成する要求事項集合及びその表現は二つのグループ間の橋渡しと

しての役割を果たし，取得者及び技術陣の双方によって理解される必要がある。システム開発における最

も困難な作業の一つは，両方のグループ内の全てのサブグループ間で意思疎通することであり，特に一つ

47 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

の文書でこれを行うことはなおさら困難である。この種の意思疎通は一般にそれぞれ異なる形式と言語表

現とを必要とする。 

この規格では，ここで示す情報の構造化集合と様々な読者にそれを提示する方法とを区別することを提

案する。SyRSの提示法は，その意図する用途にふさわしい形を取ることが望ましい。その形は，紙の文

書，モデル，プロトタイプ，その他の紙でない文書表現，又はそれらの組合せ，があり得る。これらの表

現は全て，特定の読者のニーズを満たすように，この一つのSyRSから導出することができる。しかし，

これらの提示法のそれぞれが，システム要求情報に共通な一つの源へ追跡可能にするよう注意を払うこと

が望ましい。特定の提示法を選択したことによる曖昧さを解決するために，ここで示す構造化情報集が確

実に唯一の源であり続けるようにすることが望ましい。 

この規格は，また，SyRSに含まれるシステム要求事項（システムは何をしなければならないか）と，

作業記述書のような契約文書に含まれるべきプロセス要求事項（いかにシステムを構築するか）とを明確

に区別する。 

SyRSは，ニーズ定義・システムレベルの運用概念（OpsCon）・システム要求事項分析タスク，の結果を

提示している。SyRSがそれ自体記述するものは，システムの取得者が彼らのためにシステムが何をして

くれると期待するか，システムが期待する環境，システムの利用プロファイル，性能パラメータ，期待す

る品質・有効性，及び検証アクティビティ，である。 

8.3.2 

SyRSアウトラインの例 

SyRS固有の要求条項を構成するのに，利害関係者の総意としてその構成手法が要求事項の理解を助け

ると合意されるように構成することが望ましい。全てのプロジェクトに最適な単一の構成法はない。SyRS

のアウトライン例を図7に示す。 

48 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

1. Introduction 序文 

1.1 System purpose システムの目的 
1.2 System scope システムの適用範囲 
1.3 System overview システムの概要 

   1.3.1 System context システムの状況 
   1.3.2 System functions システムの機能 
   1.3.3 User characteristics 利用者特性 

1.4 Definitions 定義 

2. References 参考文献 
3. System requirements システム要求事項 

3.1 Functional requirements 機能要求事項 
3.2 Usability requirements 使用性要求事項 
3.3 Performance requirements 性能要求事項 
3.4 System interface システムインタフェース 
3.5 System operations システム運用 
3.6 System modes and states システムモード及び状態 
3.7 Physical characteristics 物理的特性 
3.8 Environmental conditions 環境条件 
3.9 System security システムセキュリティ 
3.10 Information management 情報管理 
3.11 Policies and regulations 方針及び規制 
3.12 System life cycle sustainment システムライフサイクル持続性 
3.13 Packaging, handling, shipping and transportation パッケージ化・取扱・出荷・配送 

4. Verification 検証 

(parallel to subsections in Section 3) （第3章と並行） 

5. Appendices 付録 

Assumptions and dependencies 前提条件及び依存性 
Acronyms and abbreviations 頭字語及び略語 

図7−SyRSアウトラインの例 

注記 SyRSアウトラインは，ソフトウェアを含むものでも，システム要素に対する下位の仕様に修整

して用いることができる。 

8.4 

ソフトウェア要求仕様書 

8.4.1 

序文 

ソフトウェア要求仕様（SRS）は，特定の環境である機能を実行する特別なソフトウェア製品，プログ

ラム，又はプログラム集合に対する仕様である。SRSは，供給者の一人以上の代表者，取得者の一人以上

の代表者，又はその両方が書いてもよい。 

SRSがプロジェクト計画全体において果たす部分を考えることは重要である。ソフトウェアは，本質的

にプロジェクトの全ての機能を含むこともあれば，より大規模なシステムの一部のこともある。後者の場

合，システムとそのソフトウェア部分とのインタフェースを記述する要求仕様があるのが典型的であり，

そのソフトウェア部分に外部からの性能要求事項及び機能要求事項を求める。もちろん，そのようなとき，

SRSは，これらのシステム要求事項に一致し，かつ，これらのシステム要求事項を含むように拡張するこ

とが望ましい。SRSは，要求事項の優先度及び重大性を示す。SRSは，それを適用する特定のソフトウェ

ア製品に要求される能力を全て定義する。さらに，ソフトウェアが動作する時の条件・制約及びその要求

事項に対して意図している検証方法を文書化する。 

49 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

8.4.2 

SRSのアウトライン例 

SRS固有の要求条項を構成するのに，利害関係者の総意としてその構成手法が要求事項の理解を助ける

と合意されるように構成することが望ましい。全てのプロジェクトに最適な単一の構成法はない。SRSの

アウトライン例を図8に示す。 

1. Introduction 序文 

1.1 Purpose 目的 

1.2 Scope 適用範囲 

1.3 Product overview 製品の概要 

  1.3.1 Product perspective 製品の概要 

  1.3.2 Product functions 製品の機能 

  1.3.3 User characteristics 利用者特性 

  1.3.4 Limitations 制限 

1.4 Definitions 定義 

2. References 参考文献 

3. Specific requirements 詳細要求事項 

3.1 External interfaces 外部インタフェース 

3.2 Functions 機能 

3.3 Usability Requirements 使用性要求事項 

3.4 Performance requirements 性能要求事項 

3.5 Logical database requirements 論理データベース要求事項 

3.6 Design constraints 設計制約 

3.7 Software system attributes ソフトウェアシステム属性 

3.8 Supporting information 支援情報 

4. Verification 検証 

(parallel to subsections in Section 3) （第3章と並行） 

5. Appendices 付録 

5.1 Assumptions and dependencies 前提条件及び依存性 

5.2 Acronyms and abbreviations 頭字語及び略語 

図8−SRSアウトラインの例 

注記1 検証，つまり図8の第4章，はオリジナルのIEEE Std. 830には含まれない。 

SRS内の要求事項に対する構成方法には，例えば，次のようなものがある: 

システムモード：システムによっては，運用モードに依存して極めて異なる振る舞いをするものがある。

例えば，制御システムは訓練モード，通常モード，又は非常モードに応じて異なる一連の機能をもつこと

がある。 

利用者クラス：システムによっては，異なる利用者クラスに異なる機能の組を用意することがある。例

えば，エレベータ制御システムは，乗客・保守作業者・消防士にとって異なる能力を示す。 

オブジェクト：オブジェクトは，システム内に対応物をもつ実世界の実体である。例えば，患者モニタ

ーシステムにおいて，オブジェクトには，患者・センサー・看護士・病室・医師・薬品などがある。それ

ぞれのオブジェクトに（そのオブジェクトの）一組の属性と（そのオブジェクトが実行する）一組の機能

とが付随する。これらの機能はサービス，メソッド，又はプロセスとも呼ばれる。 

50 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

機能（feature）：機能（feature）とは，一連の入力を要求して望む結果を出力する，システムの外部から

望まれるサービスである。例えば，電話システムには，地域内通話，転送，及び会議通話という機能（features）

を含む。各機能（feature）は，通常，刺激応答対の列で記述される。 

刺激：システムによっては，刺激の形で機能を記述すると最もよく構成できるものがある。例えば，自

動航空機着陸システムの機能は，出力ロス・風切り・ロールの急変・垂直速度超過などの章に構成するこ

とがある。 

応答：システムによっては，応答の生成という形を用いて全ての機能を記述すると最もうまく構成がで

きるものがある。例えば，人事システムの機能は，給与明細の発行に伴う全機能，現状従業員一覧を生成

することに伴う全機能，などに対応して構成することがある。 

機能階層：前記のどの構成法も役立たないとき，全機能性を共通の入力，共通の出力，又は共通の内部

データアクセスに従って組織した機能階層に構成することができる。データフロー図及びデータ辞書が機

能間，データ間，及び機能・データ相互の関連を示すのに利用できる。 

注記2 SRS要求事項の文書化を助ける利用可能な表記法・手法・自動化ツールが多くある。ほとん

どの部分に対してそれらが有益なのは構成の機能である。例えば，モードで構成するとき有

限状態機械又は状態チャートが役立つことがある。オブジェクトで構成するときオブジェク

ト指向分析が役立つことがある。機能（feature）で構成するとき刺激反応列が役立つことが

ある。機能階層で構成するときデータフロー図及びデータ辞書が役立つことがある。 

9 

情報項目の内容 

9.1 

序文 

箇条9では，要求される情報項目の規定事項を記載する。ソフトウェア要求仕様書の内容は，9.5に示す

ように，JIS X 0160:2012のシステム要求事項分析プロセスに適合する場合だけ当てはまる。 

注記 9.2の情報内容は，文書形式で維持される情報項目に一般に適用可能である。 

9.2 

一般的内容 

9.2.1 

識別子 

次の識別情報を含める。 

a) タイトル 

b) 改正表示 

タイトル及び改正表示は文書を一意に識別する。改正情報には，プロジェクト名，文書の版数，発行日，

承認サイン，現版内で変更があった箇条の一覧，及び以前の版全ての番号・発行日の一覧，を含めてもよ

い。 

9.2.2 

前付け 

次の前付けを含める。 

a) 目次 

b) 図一覧 

c) 表一覧 

9.2.3 

定義 

通常の辞書定義以外の特別な意味をもつあらゆる単語又は句に対して定義を与える。 

9.2.4 

参考文献 

参考文献に関する次の情報を含める。 

51 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

a) 仕様書で参照する全ての文書の完全な一覧を記載する。 

b) それぞれの文書を，タイトル，報告書番号（当てはまる場合），日付，及び発行している組織で識別す

る。 

c) 参考文献の入手源を指定する。 

附属書などの文書を参照することでこの情報を与えてもよい。参照情報を“適合性”章と“指針”章と

に分けることが望ましい。前者には，引用することによって要求事項が取り込まれるような引用文書への

参照を含める。後者には，要求事項を含まない，情報だけをもつ引用文書への参照を含める。 

9.2.5 

頭字語及び略語 

文書で用いる全ての頭字語及び略語のつづ（綴）りの完全な表記を示すか又は意味を定義する。 

注記 この情報を文書内の一つ以上の附属書への参照，又は他の文書への参照で与えてもよい。 

9.3 

利害関係者要求仕様（StRS）書 

9.3では，利害関係者要求仕様（StRS）書の規定事項を定義する。プロジェクトは，利害関係者要求仕

様書に対するプロジェクトの方針に従って，次の情報項目を作成しなければならない。文書の情報項目の

構成法，例えば，順序及び章構成，はプロジェクトの文書化方針に従って選択してもよい。 

9.3.1 

事業の目的 

経営環境に適合するために組織が新しい事業を追求する又は現行事業を変更することに対する目的及び

背景を，組織レベルで記述する。この文脈において，提案システムがどのように事業目標を満たすことに

貢献するかを記載することが望ましい。 

9.3.2 

事業の適用範囲 

考えている事業領域を次の項目によって定義する。 

a) 事業領域を名称で識別する。 

b) 考えている事業領域に含まれる事業活動の範囲を定義する。適用範囲は，事業活動に直接関与する組

織の事業部門及び外部実体，又は事業活動によって実施される機能の面から定義できる。適用範囲外

の環境的な実体を示すことも有用である。 

c) 開発又は変更するシステムの適用範囲を記述する。その記述にはどの事業活動がシステムに支援され

るかという前提条件を含む。 

9.3.3 

事業の概要 

考えている事業領域の主要な内部部門及び外部実体，並びにそれらがいかに関連しているか，を定義す

る。図形記述が望ましい。 

9.3.4 

利害関係者 

利害関係者又は利害関係者クラスを一覧化するとともに，各利害関係者が組織及びビジネスにどのよう

に影響するか，又はシステムの開発及び運用にどのように関係するようになるか，を記述する。 

9.3.5 

事業環境 

新規事業又は既存事業を理解し，かつ，開発又は変更するシステムの利害関係者要求事項を引き出すた

めに考慮すべき外部環境要因及び内部環境要因を定義する。環境要因には，市場動向，法律・規制，社会

的責任，及び技術的な基盤のような外部条件から，事業への，したがってシステムへの，考えられる影響

を含めることが望ましい。 

9.3.6 

ゴール及び目標 

提案するシステムを通じて又はそれによって得られる事業結果を記述する。 

52 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

9.3.7 

事業モデル 

事業のゴールを達成することが期待できる手法を記述する。その記述は，開発又は変更するシステムに

よって支援される手法を中心にし，製品・サービス，地域・場所，流通チャネル，事業連携・パートナシ

ップ，財政・収入のモデル，などの項目をもって記述することが望ましい。 

注記 事業モデル要素の詳細な記述及び定義はOMGのBusiness Motivation Model (BMM)にある。 

9.3.8 

情報環境 

複数の情報システムに対する共通の基盤について，組織レベルの意思決定のための全体的な戦略を記述

する。次の項目を含んでいることが望ましい。 

a) プロジェクトポートフォリオ：同じ事業のゴールを追求する複数のシステムプロジェクトが動いてい

る又は計画されている場合の，ポートフォリオ経営戦略から来る優先度・相対的な位置付け・考えら

れる制約である。 

b) 長期システム計画：共通のシステム基盤又は方式が既に決定又は計画されている場合，考えられる設

計上の意思決定に求められる制約として記述することが望ましい。 

c) データベース構成：組織レベルのデータベース構成計画，並びに組織共通データの可用性及びアクセ

ス可能性に関して考えられる制約を明らかにすることが望ましい。 

9.3.9 

業務プロセス 

業務活動の手順及びそのプロセス内でのシステムとのインタフェースを記述する。この情報項目の目的

は，業務活動をシステムがどのような利用状況でどのように支援するかを表現することである。一般に，

業務プロセスは分解及び分類による階層構造を形作る。プロセスの一つ一つは階層の中で一意に命名・番

号付けすることが望ましい。個々のプロセスの説明を，アクティビティの順序を表現する流れ図で記述す

ることが望ましい。 

9.3.10 業務運用方針及びルール 

業務プロセスを実施する上で適用される命題を記述する。この命題は，一連の業務活動を開始・分岐・

終了する条件，業務プロセスにおける判断の基準，又は量を評価する式，である。これらはSyRS及びSRS

の機能要求事項の中で取り上げられる可能性が高い。方針及びルールに一意な名称・番号を付け，業務プ

ロセスの記述の中で参照しなければならない。 

9.3.11 業務運用制約  

業務プロセスを実施する中で求められる条件を記述する。条件は性能制約に関するもの（例えば，“プロ

セスは，トリガーイベントが発生した後1日で終了しなければならない”），又は管理面での要請から来る

ものもある（例えば，“発生したプロセスは全てモニターし記録しなければならない”）。 

9.3.12 業務運用モード 

例えば，イベントの発生が集中して業務運用が極端に忙しくなることがあるような非定常状態で業務運

用を実施する手法を記述する。業務運用の非定常状態には，事故又は災害のような予期せぬ事態で提案シ

ステムが利用できない場合の手作業モードを含む。 

9.3.13 業務運用品質 

業務運用に要求される品質レベルを定義する。例えば，ある業務プロセスでは，業務プロセスの信頼性

よりも緊急性がより高い優先度で要求されることがある。 

9.3.14 業務の構造 

システムに関連する業務上の構造を識別・記述する。例えば，組織構造（部門及び部署），役割及び責任

の構造，地理的な構造，並びに資源共有の構造である。これらの構造にシステム機能を合わせ，将来の構

53 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

造変化を支援することが必要な場合がある。 

9.3.15 利用者要求事項 

利用者要求事項には（StRSの文脈において），次の全てを含める。 

a) 利用者，運用者又は保守者が，システム利用を通じて実行する必要がある入力，選択又は情報観察 

b) これらのタスクを実行するために利用者，運用者又は保守者がシステムから要求する出力 

c) 利用者，運用者又は保守者とシステムとの相互作用を決める適用可能な条件及び制約（つまりシステ

ムの使用性） 

これらの要求事項は，次に運用シナリオを記述するのに用いられ，それによってシステムと相互作用す

るときこれらの要求事項がいかに満たされるかが特定される。 

設計のために識別される利用状況（つまり，システムが利用される状況）は，利用者要求仕様の一部と

するのが望ましい。その要求事項に当てはまる条件を明確に識別するためである。システムに対する使用

性要求事項及び目標には，特定の利用場面において測定可能な有効性・効率性・満足の基準が含まれる。 

注記1 利用状況及び実例レポートについてのより多くの情報にはJIS Z 8521を参照。日常製品の利

用状況についてのより多くの情報はISO 20282-1を参照。 

注記2 利用者ニーズ・利用状況・利用者要求事項に関するその他の情報がISO/IEC TR 25060及び

ISO 9241-210にある。 

9.3.16 システムレベルの運用概念 

提案システムを高レベルで記述する。つまり設計の詳細を指定することなく，実現されることになって

いる運用操作面での特徴を示す。次の情報を含めることが望ましい。 

a) 運用方針及び制約 

b) 提案システムの説明 

c) システム運用のモード 

d) 利用者クラス及び他の関係者 

e) 支援環境 

注記 システムレベルの運用概念（OpsCon）書の情報項目内容の詳細な議論は，附属書A，特にA.2.5，

を参照。 

9.3.17 運用シナリオ 

利用者，運用者又は保守者が，いかにシステム（の利用状況）と相互作用するかの例を記述する。シナ

リオは，システムに支援される業務プロセスの活動又は一連の活動に対して記述する。シナリオは，一意

に命名・番号付けをすることが望ましい。また，9.3.9の業務プロセスの記述から参照することが望ましい。 

注記 利用状況及び使用性に対するより多くの情報がISO/IEC TR 25060及びISO 9241-210にある。 

9.3.18 プロジェクト制約 

プロジェクトをコスト・スケジュール内で実行する制約を記述する。 

9.4 

システム要求仕様（SyRS）書 

9.4では，システム要求仕様（SyRS）の規定事項を定義する。プロジェクトは，システム要求仕様書に

関するプロジェクトの方針に従って次の情報項目内容を作成しなければならない。内容の文書としての構

成，例えば，順序及び章構造をプロジェクトの文書化方針に従って選択してもよい。 

9.4.1 

システムの目的 

システムを開発又は変更する（一つ以上の）理由を定義する。 

54 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

9.4.2 

システムの適用範囲 

考えているシステムの適用範囲を，次の事項によって定義する。 

a) 開発するシステムを名前で識別する。 

b) 初期に終了したニーズ分析の結果を基に，利用者の問題を簡潔だが明確な表現で参照し明記する。こ

れらのニーズを満たすためにシステムが何を行い，かつ，何を行わないかを表現する。 

c) 定義するシステムの適用を記述する。この一部に，全ての関連するトップレベルの便益・目標・ゴー

ルをできるだけ正確に記述することが望ましい。 

9.4.3 

システムの概要 

9.4.3.1 

システムの状況 

システムの主要な要素を，人的要素を含めて記述し，それらのシステム要素がどのように相互作用する

かを概要レベルで記述する。システムの概要には，システムの状況を表す適切な図表現及び説明文を含め，

システム境界を横切る全ての主要インタフェースを定義する。 

9.4.3.2 

システムの機能 

システムの主要な能力・条件・制約を記述する。 

9.4.3.3 

利用者特性 

システムの利用者，運用者，又は保守者のそれぞれの（機能・場所・デバイスの種類による）タイプ，

各グループの人数，及びそれぞれのシステム利用の性質を定義する。 

注記 仕様書中の適切な箇所では，SyRS及びSRSの利用者特性を一貫させることが望ましい。 

9.4.4 

機能要求事項 

システム運用に適用可能な機能要求事項を定義する。 

9.4.5 

使用性要求事項 

使用性（利用時の品質）要求事項を定義する。使用性要求事項及びシステムに対する目標には，特定の

利用状況における測定可能な有効性・効率性・満足度の基準が含まれる。 

9.4.6 

性能要求事項 

重大な性能条件及びそれに付随する能力を，次の考慮を含めることによって定義する。 

a) 発生する動的なアクション又は変化（例えば，率・速度・運動・騒音レベル） 

b) 規定された環境及び他の条件下で利用者ニーズを満足するよう求められる装置の耐久能力を，耐久寿

命の最短時間の見込みを含めて網羅する定量的な基準。要求される連続運用期間及び利用率の計画値

を示す 

c) 運用フェーズ及びモードに対する性能要求事項 

9.4.7 

システムインタフェース 

システム要素間のインタフェース及び外部実体とのインタフェースに対する要求事項を仕様化する。人

間もシステム要素であるので，システム要素間のインタフェースには人間とのインタフェースを含めるこ

とが望ましい。外部実体とのインタフェースには，他システムを含めることが望ましい。 

インタフェースに付随するあらゆる相互依存性又は制約を定義する（例えば，通信プロトコル・特別な

デバイス・標準・固定様式）。各々のインタフェースは情報の双方向フローを表現してもよい。明確化のた

めに必要ならばインタフェースの図表現を用いることができる。 

9.4.8 

システム運用 

9.4.8.1 

人間システム統合要求事項 

適用可能な文書を参照し，特殊な又は特有の要求事項はどのようなものも仕様化する。例えば，要員と

55 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

要員との間のコミュニケーションへの機能割当てに求める制約及び要員と装置との相互作用に求める制約

である。 

特定の領域又は場所又は装置で，運用の敏感さ又は仕事の重大さゆえに人間工学上の留意事項に集中し

なければならないようなものを定義する（例えば，人的エラーの影響が特別に深刻になるかもしれない分

野）。 

注記 ISO/TR 18529には，システム開発及び運用において人間中心プロセスの定義・評価・改善に利

用できる形式化されたモデルを含む。 

9.4.8.2 

保守性 

計画している保守・支援環境での保守に当てはまる定量的な保守要求事項を仕様化する。例を次に示す。 

a) 時間（例えば，平均・最長ダウン時間，復旧時間，ターンアラウンド時間，平均・最長修理時間，保

守作業間の平均時間） 

b) 率（例えば，特定の保守活動当たりの保守要員時間，運用準備率，運用時間当たりの保守時間，予防

保守の頻度） 

c) 保守複雑性（例えば，要員数及びスキルレベル，サポートする装置の多様性，取り外すか交換するか

又は修理する部品） 

d) 保守活動指数（例えば，運用時間当たりの保守コスト，分解修理当たりの要員時間） 

e) システム内のコンポーネント及びコンポーネント内の部品へのアクセス可能性 

9.4.8.3 

信頼性 

システム信頼性要求事項を定量的に定義する。信頼性要求事項がその下で満たされるはずの条件を含め

て仕様化する。また，信頼性担当モデルも含めてもよい。これは望まれるシステム信頼性を達成する上で

信頼性の値をシステム機能に割り当て分担させるものである。 

9.4.9 

システムモード及び状態 

システムに様々なモード又は状態があり得る場合，それを定義するとともに，必要に応じて図形を利用

する。 

注記 システムのモードとは状態の集合をいう。 

9.4.10 物理的特性 

9.4.10.1 物理的要求事項 

質量・体積・寸法に関する制約を含める。システムが配置される場所の建築構造上の特性，この仕様で

網羅される項目，サービスで用いる資材の要求事項，名札及びシステムマーク・装置の交換可能性・出来

栄え，を網羅する要求事項を含める。 

9.4.10.2 適応性要求事項 

成長・拡張・能力・縮小（contraction）に対する要求事項を定義する。例えば，システムが将来のネット

ワーク帯域を必要とする場合，需要が増えたとき新ネットワークカードを収める予備のカードスロットを

もつ適用可能なハードウェアを仕様化することが望ましい。 

9.4.11 環境条件 

システムが出会う環境条件を含める。次の領域を位置付けることが望ましい。 

− 自然環境［例えば，風・雨・温度・植物相・動物相・菌・かび・砂・海水煙・ちり（塵）・放射線・化

学物質・浸水］ 

− 誘導環境（例えば，運動・衝撃・騒音・電磁・熱） 

− 電磁信号環境 

56 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 自己誘導環境（例えば，運動・衝撃・騒音・電磁・熱） 

− 脅威 

− 協調環境 

また，法律又は規制上の環境・政治的環境・経済的環境・社会的環境・ビジネス環境も考慮することが

望ましい。 

注記1 誘導環境（induced environment）：人又は装置が作り出す環境で，人又は物質に直接又は間接

に影響する環境（Dictionary Military and Associated Terms, US Department of Defence 2005）。 

注記2 自己誘導環境（self-induced environment）：そのシステム自身がないと仮定した場合に存在し

ないような，対象システム自身によって影響を受ける環境（J. O. Grady: System requirements 

analysis, Academic Press, 2006）。 

注記3 協調環境（cooperative environment）：対象システムに含まれない，対象システムと相互作用を

もつ任意のシステム（J. O. Grady: System requirements analysis, Academic Press, 2006）。 

9.4.12 システムセキュリティ 

システムセキュリティ要求事項を定義する。これはシステムを納める設備とシステム自身の運用上のセ

キュリティ要求事項との両方に関連する。セキュリティ要求事項の一例は，セキュリティ及びプライバシ

ー要求事項で，システムへのアクセス制限，例えば，ログオン手順及びパスワードの存在，データ保護及

び復帰手法の存在，を含む。さらに，偶然の又は悪意による，アクセス，使用，改変，破壊，又は暴露か

らシステムを保護するような要因を含めてもよい。特に，安全重視の埋込システムでは，データセットの

分散ログ若しくは履歴，一定機能の様々な単一システム群への割当て，又はシステムの幾つかのエリア間

の通信，を組み入れてもよい。 

9.4.13 情報管理 

システムが受け取る，生成する，又は出力する情報のシステム管理に対する要求事項を定義する。例え

ば，システムが受け取り蓄積することを要求される情報の型及び量，システムが扱う情報に求める占有的

（proprietary）保護又はその他の保護，並びにその情報に対してどのようなバックアップ及びアーカイブ要

求事項が存在するか，である。 

9.4.14 方針及び規制 

外部の規制から来る要求事項だけでなく，システムの運用若しくは性能に影響する組織の方針，又は業

務の日常慣行から来る制約を詳細化する。例えば，多国語支援・労働方針・個人情報保護・規制機関への

報告，である。 

健康・安全基準を仕様化する。装置の特性，運用手法，及び有毒システム・電磁放射のような環境への

影響，に関してシステム設計の根拠となるものを含む。 

9.4.15 システムライフサイクル持続性 

高品質システムを実現する助けとなるような品質アクティビティ，例えば，レビュー，測定量の収集及

び分析の概要を示す。ライフサイクル持続性には，また，運用レベル及び貯蔵レベルの支援，交換部品，

ソーシング及び供給，プロビジョニング，技術文書・技術データ，支援要員の訓練，初期の幹部訓練，及

び契約補給の初期支援，を用意するのに必要な設備の条項が含まれる。 

9.4.16 パッケージ化・取扱・出荷・配送 

意図する運用操作の状況に合わせてシステムをパッケージ化・取扱・出荷・配送できるようにするため

に求められる要求事項を定義する。 

57 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

9.4.17 検証 

システム又はシステム要素を評価するために計画されている検証方法及び手法を記載する。検証に対す

る情報項目を，9.4.4〜9.4.16の情報項目と並列に与えることを推奨する。 

9.4.18 前提条件及び依存性 

下位レベルのシステム要求事項への割当て及び導出において，考慮すべきシステム要求事項に当てはま

る前提条件及び依存性を挙げる。 

9.5 

ソフトウェア要求仕様（SRS）書 

9.5では，ソフトウェア要求仕様（SRS）の規定事項を定義する。プロジェクトは，ソフトウェア要求仕

様書に関するプロジェクトの方針に従って，次の情報項目内容を作成しなければならない。情報項目の文

書としての構成，例えば，記載順序及び章構成は，プロジェクトの文書化方針に従って選択してもよい。 

9.5.1 

目的 

定義するソフトウェアの目的を定義する。 

9.5.2 

適用範囲 

考えているソフトウェアの適用範囲を次の項目によって定義する。 

a) 作成するソフトウェア製品（群）を名前で識別する（例えば，ホストDBMS，レポートジェネレータ）。 

b) ソフトウェア製品（群）が何を行うかを説明する。 

c) 仕様化するソフトウェアの適用について，関連する便益・目標・ゴールを含めて，記述する。 

d) 上位レベルの仕様（例えば，システム要求仕様）に同様の記述がもしあれば，それと矛盾しないよう

にする。 

9.5.3 

製品の概要 

システムと他の関連製品との関係を定義する。 

製品がより大きなシステムの一要素である場合，そのより大きなシステムの要求事項を，このSRSで取

り扱う製品の機能性と関連付ける。 

製品がより大きなシステムの要素である場合，このSRSで取り扱う製品とより大きなシステムとの間の

インタフェースを識別する。 

より大きいシステムの主要要素を示すブロック図・相互接続・外部インタフェースが役立つ。 

ソフトウェアが，次の制約内でいかに動作するかを記述する。 

a) システムインタフェース 

b) 利用者インタフェース 

c) ハードウェアインタフェース 

d) ソフトウェアインタフェース 

e) 通信インタフェース 

f) 

メモリ 

g) 運用 

h) サイト適応要求事項 

9.5.3.1 

システムインタフェース 

各々のシステムインタフェースを列挙し，かつ，システム要求事項を達成するためのソフトウェアの機

能性及びシステムに合致するインタフェース記述を識別する。 

9.5.3.2 

利用者インタフェース 

次を仕様化する。 

58 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

a) ソフトウェア製品と利用者間との個々のインタフェースの論理的特性。これには，ソフトウェア要求

事項を達成するために必要な構成の特性（例えば，要求される画面様式，ページ若しくはウィンドゥ

レイアウト，あらゆるレポート若しくはメニューの内容，又はプログラミング可能なファンクション

キーの可用性）が含まれる。 

b) システムを利用する人，保守する人，又はシステムにその他のサポートを行う人とのインタフェース

を最適化するあらゆる局面。これは単純に，利用者にシステムがどのように見えるかについての実施

項目及び禁止項目一覧（“べし・べからず”集）であってもよい。一例として，エラーメッセージを長

くするか短くするかの選択に対する要求事項がある。これは例えば，“使いやすさ”章にある“ソフト

ウェアシステム属性”で仕様化することもある。 

注記 利用者インタフェースに対するスタイルガイドは，構成，コーディング，及び利用者とシス

テムとの相互作用に対して一貫性のあるルールになる。 

9.5.3.3 

ハードウェアインタフェース 

ソフトウェア製品及びハードウェア要素間のインタフェースの論理的特性を仕様化する。これには，構

成の特性（ポート数，命令セットなど）が含まれる。また，どのデバイスがサポート対象か，いかにサポ

ートするか，及びプロトコルのような事柄も含む。例えば，端末サポートに，行単位サポートではなくフ

ルスクリーンサポートが求められることがある。 

9.5.3.4 

ソフトウェアインタフェース 

併用が要求される他のソフトウェア製品（例えば，データ管理システム，オペレーティングシステム，

又は数学パッケージ），及び他のアプリケーションシステムとのインタフェース（例えば，売掛金システム

と一般会計システムとのリンク）を仕様化する。 

要求されるソフトウェア製品各々に対して，次を指定する。 

a) 名称 

b) 略名（ニモニック） 

c) 仕様番号 

d) 版数 

e) 要求事項の情報源 

各々のインタフェースに対して次を仕様化する。 

1) 相互接続するソフトウェアの目的を，このソフトウェア製品との関連の観点から考察したもの  

2) 情報交換の内容及び形式によるインタフェースの定義。インタフェースを詳細に文書化する必要は

なく，インタフェースを定義する文書への参照が求められる。 

9.5.3.5 

通信インタフェース 

通信との様々なインタフェースを仕様化する。例えば，ローカルネットワークプロトコル。 

9.5.3.6 

メモリ制約 

一次・二次メモリに対して適用可能な特性及び制限を仕様化する。 

9.5.3.7 

運用 

利用者が要求する通常運用・特別運用を仕様化する。例えば，次のような事項である。 

a) 利用者組織における様々な運用モード（例えば，利用者が起動する運用） 

b) 会話人が対話型で運用操作する期間及び無人で運用する期間 

c) データ処理支援機能 

d) バックアップ運用・リカバリ運用 

59 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記 これは時に，利用者インタフェース章の一部として定義される。 

9.5.3.8 

サイト適応要求事項 

サイト適応要求事項には次が含まれる。 

a) あるサイト固有，任務固有，又は運用モード固有の，データ又は初期化順序に対する要求事項の定義

（例えば，座標値，安全限界） 

b) ソフトウェアを特定の実装に合わせるために，修正することが望ましいサイト依存又は任務依存の機

能（features）の仕様 

9.5.4 

製品の機能 

ソフトウェアが実行する主要な機能を要約する。例えば，会計プログラムのSRSには，このパートを用

いて，顧客勘定保守機能・顧客明細書機能・請求書準備機能を，これらの機能が要求する膨大な詳細に触

れずに，説明してもよい。 

この記述部分で必要な機能の要約は，このソフトウェア製品に特別な機能を割り当てている上位レベル

の仕様（もしあれば）の章からそのまま転記することができるときがある。 

明瞭性のために次の事項に注意する。 

a) 機能の一覧が取得者又はこの文書を初めて読む人が理解できるように，製品機能を構成することが望

ましい。 

b) 他の機能及びその関係を示すために文章又は図的手法を用いることができる。図は，製品の設計を示

す意図ではなく，変数間の論理的な関連を単純に示す意図で用いる。 

9.5.5 

利用者特性 

想定する製品利用者の一般的な特性を記述する。その特性は，使用性に影響し得る特性，例えば，教育

レベル・経験・身体障害・技能的専門性，を含む。この項目には，詳細要求事項を記載しないほうがよい。

むしろ，ある詳細要求事項が後に9.5.9の詳細要求事項で定義される理由を記載することが望ましい。 

注記 仕様書中の適切な箇所では，SyRS及びSRSの利用者特性を一貫したものにすることが望まし

い。 

9.5.6 

制限 

供給者の選択肢を制限する項目があれば，それら全ての項目を一般的に記述する。例えば，次の項目で

ある。 

a) 規制方針 

b) ハードウェア制限（例えば，信号タイミング要求事項） 

c) 他アプリケーションとのインタフェース 

d) 並行運用 

e) 監査機能 

f) 

制御機能 

g) 高次言語要求事項 

h) 信号ハンドシェークプロトコル（例えば，XON-XOFF，ACK-NACK） 

i) 

品質要求事項（例えば，信頼性） 

j) 

アプリケーションの重大性 

k) 安全性及びセキュリティの配慮 

l) 

身体的又は精神的配慮 

60 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

9.5.7 

前提条件及び依存性 

SRSで記載する要求事項に影響する要因を一つ一つ一覧化する。これらの要因はソフトウェアの設計制

約ではなく，これらの要因の何らかの変化がSRSの要求事項に影響し得るようなものである。例えば，あ

る特定のオペレーティングシステムが，ソフトウェア製品が指定するハードウェアの上で利用できる，と

いうような前提条件である。もし，実際，そのオペレーティングシステムが利用できないならば，SRSも

それに従って変更しなければならないことになる。 

9.5.8 

要求事項の配分 

ソフトウェア要求事項をソフトウェア要素に配分する。複数のソフトウェア要素に渡る実装を必要とす

るような要求事項がある場合，又は，あるソフトウェア要素への割当てが最初は未定義の場合には，その

ように記述することが望ましい。機能とソフトウェア要素との間の相互参照表を用いて，配分を要約する

ことが望ましい。 

システムの将来の版（例えば，ブロック及び／又は増分）まで遅れる可能性のある要求事項を識別する。 

9.5.9 

詳細要求事項 

全てのソフトウェア要求事項を，設計者がソフトウェアシステムをその要求事項を満たすように設計で

きるまで十分な詳細レベルで，仕様化する。 

全てのソフトウェア要求事項を，そのソフトウェアシステムがその要求事項を満たすことをテスト者が

テストできるまで十分な詳細レベルで，仕様化する。 

最小限，ソフトウェアシステムへの全ての入力（刺激），ソフトウェアシステムからの全ての出力（反応），

及び，入力に反応して又は出力を得るためにソフトウェアシステムが実行する全ての機能，を記述する。 

詳細要求事項は次のようであることが望ましい。 

a) この規格の5.2に記述した特性の全てに適合していること。 

b) 関連する以前の文書とクロスリファレンスされること。 

c) 一意に識別できること。 

9.5.10 外部インタフェース 

ソフトウェアシステムの入出力を全て定義する。この記述は9.5.3.1〜9.5.3.5のインタフェース記述を繰

り返さず，補足することが望ましい。 

定義する各々のインタフェースには次の内容を含むことが望ましい。 

a) 項目名 

b) 目的の記述 

c) 入力の発生源又は出力の行き先 

d) 正当な値の範囲，精度，及び／又は許容度 

e) 測定量の単位 

f) 

タイミング 

g) 他の入出力との関連 

h) 画面様式又は画面構成 

i) 

ウィンドゥ様式又はウィンドゥ構成 

j) 

データ様式 

k) コマンド様式 

l) 

終了メッセージ 

61 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

9.5.11 機能 

そのソフトウェア内で，入力を受け取って処理するとき及び出力を処理して生成するときに，実施する

必要のある基本的な動作を定義する。次の項目を含める。 

a) 入力に対する正当性チェック 

b) 運用の正確な順序 

c) 異常状況への反応，次を含む。 

1) オーバフロー 

2) 通信故障 

3) エラーハンドリング及びリカバリ 

d) パラメータの影響 

e) 出力の入力との関連，次を含む。 

1) 入出力の順序 

2) 入力から出力への変換式 

機能要求事項をサブ機能又はサブプロセスに分割するのが適切なことがある。このことは，ソフトウェ

ア設計もそのように分割されることを意味しない。 

9.5.12 使用性要求事項 

使用性（利用時の品質）要求事項を定義する。ソフトウェアシステムの使用性要求事項及び目標には，

特定の利用状況における測定可能な有効性・効率性・満足性の基準が含まれる。 

9.5.13 性能要求事項 

そのソフトウェアそのもの，又はそのソフトウェアと人間との間の全般の相互作用，に関する静的数値

要求事項及び動的数値要求事項の両方を仕様化する。 

静的な数値要求事項には，次が含まれることがある。 

a) 支援する端末の数 

b) 支援する同時利用者の数 

c) 扱う情報の量及び型 

静的な数値要求事項は別の“キャパシティ”章で定義されるときもある。 

動的な数値要求事項には，例えば，通常及びピーク負荷条件の両方に対して，ある時間間隔内で処理す

るトランザクション数，タスク数，及びデータ量が含まれることがある。 

性能要求事項は測定可能な言葉で記載することが望ましい。 

 例えば， 

トランザクションの95 %は，1秒未満で処理されなければならない。 

 望ましくないのは， 

運用者にトランザクションが終了するのを待たせてはならない。 

注記 ある特定の機能に適用する数値的な限界は，通常その機能の下位の段落の記述内容の一部とし

て仕様化される。 

9.5.14 論理データベース要求事項 

データベースに置くことになるあらゆる情報に対する論理的な要求事項を仕様化する。次が含まれる。 

a) 様々な機能で用いる情報の型 

b) 利用頻度 

62 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

c) アクセス能力 

d) データエンティティ及びその関連 

e) 完整性（integrity）制約 

f) 

データ保持要求事項 

9.5.15 設計制約 

外部標準，規制要求事項，又はプロジェクト制限によって求められるシステム設計への制約を仕様化す

る。 

9.5.16 標準への適合 

既存の標準又は規制から導出される要求事項を仕様化する。次を含む。 

a) レポートの形式 

b) データ命名 

c) 責任追跡手順 

d) 監査追跡 

例えば，この要求事項にはソフトウェアが処理活動を追跡する要求事項があり得る。このような追跡を

必要とするのは，規制基準又は財務的な標準を最低限満たすアプリケーションである。監査追跡要求事項

には，例えば，給与データベースへの全ての変更を変更前後の値とともに追跡ファイルに記録しなければ

ならない，というような要求事項がある。 

9.5.17 ソフトウェアシステム属性 

ソフトウェア製品に要求される属性を仕様化する。次は例の一部である。 

a) 信頼性：ソフトウェアシステムを出荷するときに要求される信頼性を確立するために必要な要因を仕

様化する。 

b) 可用性：システム全体の定義された可用性レベルを保証するために要求される要因を仕様化する。例

えば，チェックポイント・リカバリ・リスタートである。 

c) セキュリティ：偶然の又は悪意による，アクセス，使用，改変，破壊，又は暴露からソフトウェアを

保護する要求事項を仕様化する。この分野特有の要求事項には，次のようなニーズが含まれることに

なる。 

1) 何らかの暗号技法を活用する。 

2) 特定のログ又は履歴データ一式を保持する。 

3) 様々なモジュールに一定の機能を割り当てる。 

4) プログラムのある領域間の通信を制限する。 

5) 重大な変数に対してデータ完整性（integrity）をチェックする。 

6) データプライバシーを保証する。 

d) 保守性：そのソフトウェア自身の保守性に関連するソフトウェアの属性を仕様化する。これには，一

定のモジュール性，インタフェース，又は複雑さの制限が含まれることがある。良い設計実践と考え

られるという理由だけでここに要求事項を置かないことが望ましい。 

e) 移植性：ソフトウェアを他のホスト機及び／又はオペレーティングシステムに移植しやすいことに関

連するソフトウェアの属性を仕様化する。例えば，次の属性である。 

1) ホスト依存コードをもつ要素の割合 

2) ホスト依存であるコードの割合 

3) 移植性が証明された言語の使用 

63 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

4) コンパイラ又は言語仕様の特定のサブセットの使用 

5) 特定のオペレーティングシステムの使用 

9.5.18 検証 

当該ソフトウェアを評価するために計画している検証方法及び手法を記載する。検証に対する情報項目

は，9.5.10〜9.5.17の情報項目と並行に与えることを推奨する。 

9.5.19 支援情報 

SRSに次のような支援情報を加えることが望ましい。 

a) 入出力様式の例，コスト分析検討の記述，又は利用者調査の結果 

b) SRSの読者を助け得る支援情報又は背景情報 

c) ソフトウェアによって解決しようとする問題の記述 

d) コード及び媒体が，セキュリティ，移植，初期ロード，などの要求事項を満足するための特別なパッ

ケージ化の指定 

SRSでは，これらの情報項目が要求事項の一部と考えられるかどうか，明確に記載することが望ましい。 

64 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

附属書A 

（規定） 

システムレベルの運用概念 

A.1 概要 

システムレベルの運用概念（OpsCon）書は，システムが何をするか（いかにするかではなく）及びなぜ

必要か（根拠）を記述する。システムレベルの運用概念（OpsCon）は利用者指向の文書で，開発しようと

するシステムの特性を利用者の視点から記述する。システムレベルの運用概念（OpsCon）文書は，システ

ムの包括的な定量的・定性的特性を，取得者・利用者・供給者などの組織を構成する要素に伝達するため

に用いる。 

この規格の利用者は，システムレベルの運用概念（OpsCon）及びSyRSを別に作成するよう配慮するこ

とが望ましい。そうすることでシステムレベルの運用概念（OpsCon）文書の内容は，必要な全ての要求エ

ンジニアリングタスクに，特に利用者視点に焦点を絞ることができる。また，利用者の経験及び知識基盤

にとってな（馴）染みのある語彙及び描画ツールを利用することができる。ほかにも便益がある。例えば，

人とシステムとの関わりに関する問題・制約・機会を定義できること，何が仕様化されていないかの見通

しが得られること，システムに要求される制約・機会・柔軟性の度合が明確になること，及び要求事項に

対する優先順位が設定できること，である。 

プロジェクトは，システムレベルの運用概念書に関するプロジェクトの方針に従って，次の情報項目を

作成しなければならない。A.2.5の情報項目は，9.3.16及び9.3.17で述べたように利害関係者要求仕様書の

作成と並行して作成しなければならない。 

注記1 システムレベルの運用概念（OpsCon）文書を別に作成することで，エンジニアリングチーム

は，SyRSを作成する間，技術コミュニティ及びシステム供給者・利用者の語彙と知識ベース

とに，より集中することができる。 

注記2 組織レベルの運用概念（ConOps）とシステムレベルの運用概念（OpsCon）との間には類似

性がある。組織レベルの運用概念（ConOps）は，運用に対する意図・前提条件についての組

織の視点を記述する。組織レベルの目的の大局観を捉えるものである。附属書Bを参照。 

A.2 システムレベルの運用概念（OpsCon）書 

システムレベルの運用概念（OpsCon）文書の本質的要素を一つ一つ記述する。このガイドに基づくシス

テムレベルの運用概念（OpsCon）文書のそれぞれの版に，文書を一意に識別するタイトル及び改正情報を

含めることが望ましい。改正情報には，プロジェクト名，文書の版番号，リリース日付，承認サイン，現

版で変更された箇条の一覧，及び全ての前版の版番号・リリース日付，を含めてもよい。承認されたシス

テムレベルの運用概念（OpsCon）文書は，構成管理下に置くことが望ましい。 

注記 IEEE 1362-1998の箇条4から抽出した。この規格では，IEEE 1362-1998の組織レベルの運用概

念（ConOps）をシステムレベルの運用概念（OpsCon）に置き換えている。 

システムレベルの運用概念（OpsCon）文書のまえがきには，読者がこの文書を読む前に，著者が読者に

知っておいてほしい情報を記載する。まえがきには，文書の目的，文書の作成に至ったアクティビティの

範囲，文書の著者及び作成の理由，文書の対象読者，並びに改正の予定，を含めることが望ましい。 

目次・図一覧・表一覧を全てのシステムレベルの運用概念（OpsCon）文書に含めることが望ましい。 

65 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

A.2.1 適用範囲 

システムレベルの運用概念（OpsCon）文書及びそれが対象とするシステムの概要を記載する。 

A.2.1.1 識別情報 

このシステムレベルの運用概念（OpsCon）を適用するシステム又はサブシステムの識別番号，タイトル，

及び（必要ならば）略語を含める。全体システムに対する関連システムレベルの運用概念（OpsCon）文書

が既に階層又はネットワーク構造で作成されている場合，この文書と他のシステムレベルの運用概念

（OpsCon）文書との相対的な位置付けを記述することが望ましい。 

A.2.1.2 文書の概要 

システムレベルの運用概念（OpsCon）文書に対する目的又は動機を要約し展開する。文書の対象読者に

言及することが望ましい。システムレベルの運用概念（OpsCon）の利用に付随するセキュリティ又はプラ

イバシーの考慮を記述する。このガイドの他の部分を概説する。システムレベルの運用概念（OpsCon）文

書の目的は，多くの場合，次のいずれかになる。 

− 提案するシステムに対する利用者のニーズ及び期待を，取得者及び／又は供給者に伝達する。 

− 利用者のニーズに対する取得者又は供給者の理解及びこのニーズを満たすためにシステムがいかに運

用されなければならないか，を伝える。 

しかし，システムレベルの運用概念（OpsCon）文書を他の目的に役立ててもよい。例えば，利用者グル

ープ間，取得者内の組織間，及び／又は供給者間でコンセンサスを築く目的である。 

システムレベルの運用概念（OpsCon）文書の読者には次のように様々な人があり得る。 

− 利用者はこれを読んで，自分のニーズ及び要望が自分達の代表者によって正しく記述されたかどうか

を確認する，又は，自分のニーズを供給者が理解しているかを検証することがある。 

− 取得者はこれを読んで，利用者ニーズ及び／又はそのニーズに対する供給者の理解について，知識を

得ようとすることがある。 

− 供給者は，典型的にはシステムレベルの運用概念（OpsCon）文書をシステムライフサイクル活動の根

拠として利用し，かつ，新しいチームメンバを問題領域及びシステムレベルの運用概念（OpsCon）が

対象とするシステムにな（馴）染ませるために利用する。 

A.2.1.3 システムの概要 

システムレベルの運用概念（OpsCon）が対象とする提案システム又はサブシステムの目的を簡潔に記載

する。システムの一般的な性質を記述し，かつ，プロジェクトのスポンサー，利用者組織，供給者の組織，

支援者の組織，認証者又は認証機関，及びシステムを稼動させる運用センター又は運用サイト，を識別す

る。さらに，現行システム又は提案システムに関連する他の文書を識別する。システムの概要を図表現す

ることを強く勧める。コンテキスト図，トップレベルのオブジェクト図など，システム及びその環境を描

く図の形があり得る。引用しそうな文書は，プロジェクト承認書，関連技術文書，重要な書状，関連プロ

ジェクトに関する文書，リスク分析報告書，及び実現性検討書であるが，これらに限るものではない。 

A.2.2 参考文献 

システムレベルの運用概念（OpsCon）文書で参照する全ての文書の文書番号・タイトル・改正・日付を

一覧化する。また，通常の経路で手に入らない文書は全てその入手先を識別する。 

A.2.3 現行システム又は状況 

システム又は状況（自動化されていようが手作業であろうが）を現状あるがままに記述する。変更の対

象となる現行システムが存在しない場合，提案システムの動機となっている状況を記述する。この場合，

66 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

動機となる状況を記述するよう，必要に応じて次の章を修整することになろう。問題領域を紹介する。そ

うすることで読者は，要望されている変更及び改善の理由をよりよく理解できるようになる。 

A.2.3.1 背景・目標・適用範囲 

現行システム又は状況の概要を，必要ならば，背景・使命・目標・適用範囲を含めて，記載する。現行

システムの背景に加えて，この章に現行システムの動機を簡潔に要約することが望ましい。システムの動

機とは例えば，何かのタスクを自動化すること，又はある脅威的状況に対抗すること，が考えられる。現

行システムのゴールも，それを達成するために用いる戦略・解法・戦術・手法・技法とともに，定義する

ことが望ましい。運用モード・利用者クラス・運用環境とのインタフェースは，提案システムの適用範囲

を定義する。これらをこの章で要約し，後続の章でより詳細に定義する。 

A.2.3.2 運用方針及び運用制約 

現行システム又は状況に当てはまるあらゆる運用方針及び運用制約を記述する。運用方針とは，現行シ

ステムの運用に関わるあらかじめ定めた管理上の決定事項で，意思決定活動をガイドする一般的な記述又

は了解の形を取るのが普通である。方針は意思決定の自由度を制限するが，一定の裁量も許す。運用制約

は現行システムの運用に求める制限である。運用制約には次の例がある。 

a) システムの運用時間に求める制約。おそらく安全な端末へのアクセスによって制限される。 

b) システム運用に利用できる要員の数に求める制約 

c) コンピュータハードウェアに求める制約（例えば，“〇〇はコンピュータX上で動作しなければなら

ない”） 

d) 運用施設に求める制約，例えば，オフィススペース 

A.2.3.3 現行システム又は状況の記述 

現行システム又は状況の説明には，必要に応じて次の項目を含める。 

a) 運用環境及びその特性 

b) 主要なシステム要素及びそれら要素間の相互接続関係 

c) 外部システム又は外部手順とのインタフェース 

d) 現行システムの能力，機能又はサービス，及び特徴 

e) 現行システム又は状況を利用者の視点から理解するのに十分な入力・出力・データフロー・制御フロ

ー・手作業プロセス・自動化プロセス，を描く図及び付随する説明文 

f) 

システム運用のコスト 

g) 運用リスク要因 

h) 性能特性，例えば，スピード・スループット・量・頻度・作業負荷 

i) 

品質属性，例えば，可用性・正確性・効率性・拡張性・柔軟性・相互運用性・保守性・移植性・信頼

性・再利用性・支援可能性・生存性・使用性 

j) 

安全性・セキュリティ・プライバシー・完整性（integrity）・緊急時における運用の継続性に関する対

策 

k) システムを支援する手配要求事項 

この章の目的が，現行システムを記述し，それがどのように動作するかを記述することであるため，こ

の目的にかな（叶）うならどんなツール及び／又は技法を利用してもよい。重要なのは，文書の対象読者

が十分理解できるように，システムの記述を十分単純・明瞭にすることである。システムレベルの運用概

念（OpsCon）文書は利用者の言葉で書くよう留意することも重要である。 

利用できるならばどこでも図的ツールを利用することが望ましい。特に，システムレベルの運用概念

67 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

（OpsCon）文書は，様々なタイプの読者に理解可能であることが望ましいからである。有用な図的ツール

には，ワークブレイクダウンストラクチャ（WBS），N2図，シーケンス図又はアクティビティ図，機能フ

ローブロック図，構造図，割当図，データフロー図（DFD），オブジェクト図，コンテキスト図，ストーリ

ボード，及びエンティティリレーションシップ図が含まれるが，これらに限るものではない。 

運用環境の記述は，現行システムの運用に用いている施設・装置・コンピュータハードウェア・ソフト

ウェア・要員・運用手順，をできる限り識別することが望ましい。この記述は，使用する運用装置の数・

版・容量などの理解を読者に与えるために，必要なだけ詳細であることが望ましい。例えば，現行システ

ムにデータベースがある場合，もしその情報が利用者の運用能力に影響を及ぼすならば，ストレージユニ

ット（群）の容量を定義することが望ましい。同様に，システムがコミュニケーションリンクを使用する

場合，それらのリンクの容量が，利用者の能力，応答時間，又はスループットといった要因に影響を及ぼ

すかどうかを定義するのが望ましい。 

現行システムの運用又は運用環境に影響を及ぼす安全性・セキュリティ・プライバシーの側面を記述す

ることが望ましい。 

既存システムを明確に記述できる場合，この章の情報を，システム又は状況にふさわしいように構造化

することが望ましい。記述部分が大量になる場合，付録に含めるか又は参考文献に組み入れることができ

る。付録に含められそうな情報は，例えば，データ辞書である。参考文献に含められそうな情報は，例え

ば，現行システムの運用方針及び手順の詳細マニュアルである。 

A.2.3.4 現行システム又は状況に対する運用モード 

現行システム又は状況の様々な運用モード［例えば，正常・縮退（degraded）・保守・訓練・緊急時・代

替サイト・平時・有事・地上・飛行中・活性・アイドルモード・バックアップ］を記述する。全ての利用

者クラスに当てはまるモードは全て含めることが望ましい。含めるべき重要モードは，もしあれば，縮退・

バックアップ・緊急時モードである。もしこれらのモードが様々な地理上のサイト及び装置を含み，それ

がシステムの運用側面に重大な影響を及ぼすならば，特に重要である。 

この章を更に下位の章に分割し，それぞれの章が一つのモードについて記述するように構成できる。シ

ステムプロセス，手順，及び能力又は機能を，それぞれのモードと関連付けることが望ましく，必要なら

ば相互参照マトリクスを利用することが望ましい。 

A.2.3.5 利用者クラス及び他の関係者 

利用者クラスは，利用者とシステムとの相互作用の仕方で区別する。利用者クラスを区別する要因には，

共通の責任，共通のスキルレベル，共通の業務活動，及びシステムとの相互作用モードの共通性，がある。

様々な利用者クラスは，システムとの相互作用においてはっきり区別できる運用シナリオをもつことがあ

る。この文脈において，既存システムと相互作用する人ならば誰でも利用者であり，操作する利用者・デ

ータ入力要員・システム運用者・運用支援要員・ソフトウェア保守者・トレーナを含む。 

この章は，もし内容の伝達に役立つならば，次のように更に細かく構成することができる。 

A.2.3.5.1 組織構造 

現行システムに関与する様々な利用者グループ及び利用者クラスの現在の組織構造を記述する。組織図

がこの目的のために有用な図的ツールである。 

A.2.3.5.2 利用者クラスのプロフィール 

現行システムに対する利用者クラスそれぞれのプロフィールを記載する。ある利用者に幾つかの役割が

ある場合，役割それぞれを別々の利用者クラスとして識別することが望ましい。 

現行システムに対する利用者クラスを，運用者及び保守者を含めて，それぞれ別の章に記述することが

68 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

望ましい。それぞれに，利用者クラスの責任，教育，経歴，スキルレベル，活動，及び現行システムとの

相互作用モード，を記述することが望ましい。 

A.2.3.5.3 利用者クラス間の相互作用 

現行システムに関与する様々な利用者クラス間の相互作用を記述する。特に，利用者グループ・運用者・

保守者間の相互作用を記述する。一つの組織内の相互作用でも組織の境界をまたがる相互作用でも，シス

テムの利用者間で発生する相互作用及び利用者と非利用者との間の相互作用を，もしそれが既存システム

の運用に関連するならば，記述することが望ましい。公式だけでなく，非公式の相互作用を含めることが

望ましい。 

A.2.3.5.4 その他の関係者 

システムと直接相互作用しないが，現行システムに影響する又は現行システムから影響を受けるその他

の要員を記述する。例えば，幹部マネージャ，方針決定者，及び利用者の顧客，である。彼ら自身が実際

にシステムと相互作用することはないが，彼らが新システム又は変更システムに相当な影響を与え，かつ，

影響を受けることがある。 

A.2.3.6 支援環境 

現行システムに対する支援概念及び支援環境を，一つ以上の支援組織，設備，装置，支援ソフトウェア，

修理又は交換の基準，保守レベル及びサイクル，ストレージ，流通，並びに供給手法，を含めて記述する。 

A.2.4 変更の性質及び変更の正当性 

新システム開発又は既存システム変更の動機となっている現行システム又は状況の欠点を記述する。現

行システム又は状況の議論の内容が提案システムの記述にどのように移行したかを記載する。変更の対象

となる現行システムがない場合，この章ではそのように記述し，新システムの特徴に対する正当性を与え

ることが望ましい。 

A.2.4.1 変更に対する正当性 

この章では，次の事項を記載することが望ましい。 

a) 利用者ニーズ，使命，目標，環境，インタフェース，要員など，新規又は変更システムを必要とする

要因について，どの側面を新しくするか又は変更するかを簡潔に要約する。 

b) 新規要因又は変更要因に応えることを妨げるような，現行システム又は状況の欠陥又は限界を要約す

る。 

c) 新規又は変更システムに対する正当性を記載する。 

1) 提案システムがある新しい機会に対応する場合，この機会に対応するためになぜ新システムを開発

することが望ましいか，という理由を記述する。 

2) 提案システムが現行の運用を改善する場合，現行システムの変更を意思決定した背後にある根拠を

記述する（例えば，“ライフサイクルコストを低減するため”又は“要員の効率性を改善するため”）。 

3) 提案システムが新しい機能的能力を実装する場合，なぜこの機能が必要なのかを説明する。 

A.2.4.2 変更要望の記述 

新しい又は修正される能力，機能，プロセス，インタフェースなど，A.2.4.1で識別した要因に応えるの

に必要な変更，を要約する。変更は現行システムに基づくことが望ましい。変更の対象となる既存システ

ムがない場合，新規システムが具備する能力を要約する。この記述には，必要に応じて次の事項を含める

ことが望ましい。 

− 能力の変更：新規又は変更システムがその目標及び要求事項を満足するために追加・削除・修正する

機能及び特徴の記述 

69 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− システム処理の変更：データ変換プロセス又はプロセス群の変更の記述で，例えば，現状データから

の新規出力，新規データからの現状出力，又はその両方 

− インタフェースの変更：インタフェースの変更を引き起こすシステムの変更，及びシステムの変更を

引き起こすインタフェースの変更の記述 

− 要員の変更：新しい要求事項，利用者クラスの変更，又はその両方，によって起こる要員の変更の記

述 

− 環境の変更：システム機能，プロセス，インタフェース，若しくは要員の変更をもたらす運用環境の

変更の記述，及び／又は，システム機能，プロセス，インタフェース，若しくは要員の変更によって

環境に生じる変更の記述 

− 運用の変更：前記の変更によって起こる利用者の運用方針，手順，手法，又は日常作業ルーチンの変

更の記述 

− 支援の変更：システム機能，プロセス，インタフェース，若しくは要員の変更がもたらす支援要求事

項の変更の記述，及び／又は，支援環境の変更がもたらすシステム機能，プロセス，インタフェース，

若しくは要員の変更の記述 

− その他の変更：利用者に影響する変更で，前記のカテゴリのどれにも当てはまらない他の変更の記述 

A.2.4.3 変更間の優先度 

変更要望及び新しい特徴の間の優先度を識別する。それぞれの変更を，必須・望ましい・任意，のよう

に分類することが望ましい。“望ましい”及び“任意”の場合は，そのクラス内で更に優先度付けすること

が望ましい。変更の対象となる既存システムがない場合，この章では提案システムの特徴を分類し優先度

付けすることが望ましい。 

− 必須の特徴：新システム又は変更システムが具備しなければならない特徴である。その特徴が実装さ

れないとき生じる影響を，必須の特徴それぞれに対して説明することが望ましい。 

− 望ましい特徴：新システム又は変更システムが具備することが望ましい特徴である。望ましい特徴を

更に優先度付けすることが望ましい。その特徴がなぜ望ましいかの理由を，望ましい特徴それぞれに

対して説明することが望ましい。 

− 任意の特徴：新システム又は変更システムにあってもよい特徴。任意の特徴を更に優先度付けするこ

とが望ましい。その特徴がなぜ任意かの理由を，任意の特徴それぞれに対して説明することが望まし

い。 

変更要求事項及び新しい特徴を，必須・望ましい・任意というカテゴリに分類することは，提案システ

ムのライフサイクルの間，意思決定プロセスをガイドするために重要である。この情報は，また，予算又

はスケジュールのカット又はオーバの場合に役立つ。なぜならば，どの機能を完成させるべきか，かつ，

どの特徴を遅らせる又は省略することが可能か，を決定することができるからである。 

A.2.4.4 検討したが含めない変更 

変更及び新特徴で，検討はしたがA.2.4.2に含めていないもの及びそれを含めない根拠を識別する。提案

システムにおいて，検討したが提案システムに含めない変更及び特徴を記述することによって，著者は彼

らの分析活動の結果を文書化したことになる。この情報はシステムに関与する他の要員にも役立ち得る。

利用者であれ取得者であれ供給者であれ，彼らは一定の変更又は機能（feature）が考慮されたのか，もし

考慮されたならば，なぜそれが含まれなかったかを知りたいはずである。特にソフトウェアの場合，何が

変更されたか，何が改善されたか，又は（例えば，あるシナリオ若しくは回避策において）何が依然とし

て不安全又は危険なのか，という外へのサインは，あったとしてもほとんどない。 

70 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

A.2.4.5 前提条件及び制約 

識別した変更及び新特徴に当てはまる，あらゆる前提条件又は制約を記述する。新規又は変更システム

のライフサイクルを通じて利用者に影響するような前提条件及び制約を全て含めることが望ましい。前提

条件とは，真であるとした条件である。前提条件の例は，“システム負荷は今後2年で2倍になることにな

る。したがって，より性能の高い新システムが必要である”というようなものである。制約とは，新規若

しくは変更システム，又は採用するプロセスに求められる外部からの制限である。制約の例には，外部イ

ンタフェース要求事項及びスケジュール・予算の制限がある。 

A.2.5 提案システムの概念 

A.2.4で定義した望まれる変更から導かれる提案システムを記述する。提案システムを高レベルな方法で，

設計の詳細を指定することなく，提供されることになっている運用操作面での特徴を示しながら，記述す

る。利用する記述手法及び記述の詳細レベルは状況によって決まる。提案システムが，利用者ニーズ及び

買い手の要求事項を満たすため，どのように動作するように見えるかが十分説明できるよう，それに足る

詳細レベルにすることが望ましい。場合によっては，システムレベルの運用概念（OpsCon）にあるレベル

の設計詳細を記載する必要がある。システムレベルの運用概念（OpsCon）に設計仕様を含めないことが望

ましいが，提案システムの運用上の詳細を明確にする目的の場合，典型的な設計戦略の例を幾つか含むこ

とはあってもよい。実際の設計制約を提案システムの説明に含める必要がある場合，誤解の可能性を避け

るために，その制約が要求事項であると明示的に識別しなければならない。 

注記 提案システムの幾つかの特徴が元のシステムの特徴と同じ場合，“変更なし”というコメントを

章番号及び名称の後に置くことが望ましい。 

A.2.5.1 背景・目標・適用範囲 

新規又は変更システムの概要を，必要ならば，背景・使命・目標・適用範囲を含めて，記載する。提案

システムの背景の記述に加えて，この章にシステムの動機を簡潔に要約することが望ましい。システムの

動機とは例えば，何かのタスクを自動化すること，又は新しい機会で優位に立つこと，が考えられる。新

規又は変更システムのゴールも，それを達成するために提案されている戦略・解法・戦術・手法・技法と

ともに，定義することが望ましい。運用モード・利用者クラス・運用環境とのインタフェースは，提案シ

ステムの適用範囲を定義する。これらをこの章で要約し，後続の章でより詳細に定義する。 

A.2.5.2 運用方針及び制約 

提案システムに当てはまる運用方針及び運用制約を記述する。運用方針とは，新規又は変更システムの

運用に関わるあらかじめ定めた管理上の決定事項で，意思決定活動をガイドする一般的な記述又は了解の

形を取るのが普通である。方針は意思決定の自由度を制限するが，一定の裁量も許す。運用制約は提案シ

ステムの運用に求める制限である。運用制約には次の例がある。 

− システムの運用時間に求める制約。おそらく安全な端末へのアクセスによって制限される。 

− システム運用に利用できる要員の数を制限する制約 

− コンピュータハードウェアを制限する制約（例えば，“〜はコンピュータX上で動作しなければなら

ない”） 

− 運用施設を制限する制約，例えば，オフィススペース 

A.2.5.3 提案システムの記述 

この章は，提案システムの記述の主要部分を含むことになる。提案システムの記述には，必要に応じて

次の項目を含める。 

a) 運用環境及びその特性 

71 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

b) 主要なシステム要素及びこれらの要素の間の相互接続関係 

c) 外部システム又は外部手順とのインタフェース 

d) 提案システムの能力又は機能 

e) 提案システム又は状況を利用者の視点から理解するのに十分な入力・出力・データフロー・手作業プ

ロセス・自動化プロセス，を描く図及び付随する説明文 

f) 

システム運用のコスト 

g) 運用リスク要因 

h) 性能特性，例えば，スピード，スループット，量，頻度 

i) 

品質属性，例えば，信頼性・可用性・正確性・効率性・拡張性・柔軟性・相互運用性・保守性・移植

性・再利用性・支援可能性・生存性・使用性 

j) 

安全性・セキュリティ・プライバシー・完整性（integrity）・緊急時における運用の継続性，に対する

対策 

k) システムを支援する手配要求事項 

この章の目的が，提案システムを記述し，それがどのように動作することが望ましいかを記述すること

であるため，この目的に役立つツール及び／又は技法を用いるのがよい。さらなる議論はA.2.3.3を参照。 

A.2.5.4 運用モード 

提案システムの様々な運用モード［例えば，日常的運用・縮退（degraded）・保守・訓練・緊急時・代替

サイト・平時・有事・地上・飛行中・活性・アイドルモード］を記述する。全ての利用者クラスに当ては

まるモードを全て含める。含めるべき重要モードは，もしあれば，縮退・バックアップ・緊急モードであ

る。もしこれらのモードが異なる地理上のサイト及び装置を含み，それがシステムの運用側面に重大な影

響を及ぼすならば，特に重要である。 

この章を更に下位の章に分割し，それぞれの章が一つのモードについて記述するように構成できる。シ

ステムプロセス，手順，及び能力又は機能を，それぞれのモードと関連させることが望ましい。 

A.2.5.5 利用者クラス及び他の関係者 

利用者クラスは，利用者とシステムとの相互作用の仕方で区別する。利用者クラスを区別する要因には，

責任・スキルレベル・業務活動・システムとの相互作用モード，がある。様々な利用者クラスは，システ

ムとの相互作用においてはっきり区別できる運用シナリオをもつことがある。この文脈において，既存シ

ステムと相互作用する人なら誰でも利用者であり，操作する利用者・データ入力要員・システム運用者・

運用支援要員・ソフトウェア保守者・トレーナを含む。この章は，もし内容の伝達に役立つならば，更に

下位の章に分割することができる。 

A.2.5.5.1 組織構造 

提案システムに関与する様々な利用者グループ及び利用者クラスの組織構造を記述する。組織図がこの

目的のために有用な図的ツールである。 

A.2.5.5.2 利用者クラスのプロフィール 

提案システムに対する利用者クラスそれぞれのプロフィールを記載する。ある利用者に幾つかの役割が

ある場合，役割それぞれを別の利用者クラスとして識別することが望ましい。 

提案システムに対する利用者クラスを，運用者・保守者・トレーナを含めて，それぞれ別の章に記述す

ることが望ましい。それぞれの章に，利用者クラスの責任・教育・経歴・スキルレベル・活動・提案シス

テムとの相互作用について想定されるモード，を記述することが望ましい。 

72 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

A.2.5.5.3 利用者クラス間の相互作用 

提案システムに関与する様々な利用者クラス間の相互作用を記述する。特に，利用者グループ・運用者・

保守者間の相互作用を記述することが望ましい。一つの組織内の相互作用でも相互接続する組織の境界を

またがる相互作用でも，提案システムの利用者間で発生する相互作用及び利用者と非利用者との間で起こ

る相互作用を，もしそれらが提案システムの運用に関連するならば，記述することが望ましい。公式だけ

でなく，非公式の相互作用を含めることが望ましい。 

A.2.5.5.4 その他の関係者 

システムと直接相互作用しないが，提案システムに影響する又は提案システムから影響を受けるその他

の要員を記述する。例えば，幹部マネージャ，方針決定者，及び利用者の顧客，である。彼ら自身が積極

的にシステムと相互作用することはないが，彼らが新システム又は変更システムに相当な影響を与え，か

つ，影響を受けることがある。 

A.2.5.6 支援環境 

提案システムに対する支援概念及び支援環境を，一つ以上の支援組織，設備，装置，支援ソフトウェア，

修理又は交換の基準，保守レベル及びサイクル，並びに部品の保管・流通・供給手法，を含めて記述する。 

A.2.6 運用シナリオ 

シナリオとは，提案システムが，与えられた一連の状況の下で，どのように動作するか，かつ，その利

用者及び外部インタフェースとどのように相互作用するかを，ステップごとに記述するものである。読者

がシナリオ上をウォークスルーして，提案システムの様々な部分の全てがどのように機能し相互作用する

かを理解できるように記述することが望ましい。シナリオは，システムの全ての部分，利用者，及びその

他の実体がどのように相互作用するかを記述することによって，それらを結び付ける。シナリオを利用し

て，システムが何をしないことが望ましいかを記述することもできる。 

シナリオは章及び節に構成し，システムの役割，利用者との相互作用，及び他システムとの相互作用が

見えるように，運用操作手順を，それぞれの章・節に記述することが望ましい。運用シナリオは，提案シ

ステムに対して識別した全ての運用モード及び全ての利用者クラスに対して記述することが望ましい。シ

ナリオそれぞれに，必要に応じてイベント・アクション・刺激・情報・相互作用を含め，提案システムの

運用側面を包括的に理解できるようにすることが望ましい。プロトタイプ・ストーリボード・その他のメ

ディア（例えば，ビデオ又はハイパーメディア表現）をシナリオ情報の一部に利用してもよい。 

ほとんどの場合，それぞれのシナリオごとに場合分けを幾つか設定する必要がある。例えば，通常運用

で一つ，負荷ロード処理で一つ，例外処理で一つ，縮退（degraded）モード運用で一つ，である。 

シナリオには幾つかの重要な役割がある。第一は，システムの個々の部分全てを分かりやすい全体像に

つなぎ合わせる役割である。全ての部分がいかに相互作用して運用能力を実現するかを理解する手助けに

なる。第二は，提案システムの運用上の詳細を説明する役割である。これによって，利用者の役割，シス

テムがどのように動作することが望ましいか，及び具備される様々な運用操作面での特徴，をよりよく理

解できる。 

シナリオは，また，シミュレーションモデルを開発するのに利用できる。シミュレーションモデルは，

導出要求事項の定義・割当て及びプロトタイプの識別・準備において，中心となる問題を確認するのに役

立つ。また，シナリオ利用者マニュアルの第一版の根拠になり，かつ，受入テスト計画を作成する根拠に

もなり得る。さらに，システム設計が利害関係者ニーズ及び期待を満たすことを取得者・供給者が検証す

るのにも役立つ。 

シナリオを様々な方法で提示することができる。一つの方法は，提案システムの主要な処理機能それぞ

73 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

れに対してシナリオを書き起こすことである。この方法を用いると，この章の中に，それぞれの処理機能

ごとに一つの章を充てることになる。その場合，章に更に下位の章を幾つか設け，その章ごとにその処理

機能が支援する一つのシナリオをもたせる。それに代わる方法として，スレッドベースでシナリオを作成

するものがある。つまり，提案システムの中で，最初から最後まで一通り実行されるトランザクションタ

イプに対して一つのシナリオを記述する。この場合，それぞれの章は，相互作用のタイプごとに一つのシ

ナリオを記述し，加えて縮退（degraded）・負荷ロード・バックアップの各運用モードに対するシナリオ群

を記述する。その他の代替案として，それぞれの利用者の能力に対してシステムを渡る情報フローに従う

方法，制御フローに従う方法，又はシステム内のオブジェクト及びイベントに焦点を当てる方法，がある。 

シナリオは，システムレベルの運用概念（OpsCon）の重要な要素であり，十分に強調することが望まし

い。定義されたシナリオの数と詳細度は，プロジェクトで認知されているリスク及び重大度に比例するこ

とになる。 

A.2.7 影響の要約 

提案システムが利用者・供給者・運用保守組織に与える運用上の影響を記述する。また，新システムの

開発・配置・教育訓練の期間中，利用者・取得者・供給者・運用保守組織に与える一時的な影響も記述す

る。 

この情報を記載するのは，システムの開発中及び新システムへの移行中に影響を受ける全ての組織が，

新システムによってもたらされる変化に対して準備し，かつ，取得者・利用者グループ・運用保守組織へ

の影響に対する計画を立てられるようにするためである。 

A.2.7.1 運用上の影響 

この章を更に下位の章に分割して，提案システムの運用中に，利用者組織・支援組織・運用保守組織に

与えると想定される運用上の影響を記述する。これらの影響には次の項目が含まれることがある。 

− 主コンピュータ運用センター又は代替センターとのインタフェース 

− 手順の変更 

− 新しいデータ源の利用 

− システムに入力するデータの量・型・タイミングの変更 

− データ保持要求事項の変更 

− 緊急事態，災害，又は事故状況に基づく新しい運用モード 

− 要求されるデータが直ちに利用可能でない場合に入力データを用意する新しい手法 

− 運用予算の変更 

− 運用リスクの変化 

A.2.7.2 組織上の影響 

この章を更に分割して，提案システムの運用中に，利用者組織・開発組織・支援組織・保守組織に与え

ると想定される運用上の影響を記述する。これらの影響には次の項目が含まれることがある。 

− 職責の変更 

− 職位の追加又は消滅 

− 訓練又は再訓練する利用者 

− 要員の数，スキルレベル，地位の呼称，又は職場，の変更 

− 緊急事態，災害，又は事故に伴う一つ以上の代替サイトで，不測事態対応（contingency）運用として

求められる要員の数及びスキルレベル 

A.2.7.3 開発中の影響 

74 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

この章を更に分割して，提案システムの開発中に利用者組織，開発者組織，及び支援又は保守組織に与

えると想定される影響を記述する。これらの影響には次の項目を含むことがある。 

− 契約約定前の検討・会議・議論における参画 

− レビュー及びデモンストレーション，初期の運用能力及びシステムのバージョンアップに対する評価，

データベースの開発又は変更，及び必要な教育訓練，に対する利用者・支援者の参画度 

− 新システムと既存システムとの並行運用 

− 提案システムのシステムテスト期間中の運用上の影響 

A.2.8 提案システムの分析 

提案システムに対して考えられている便益・制限・欠点・代替案の分析を記載する。 

A.2.8.1 便益 

提案システムがもたらす定性的（及び可能な範囲で定量的）な便益を要約する。この要約は必要に応じ

て下の項目を含むことが望ましい。どの場合も，便益と識別されている不備とを関連付けることが望まし

い。 

− 新能力。加わる新しい特徴又は機能性 

− 拡張される能力。既存の能力からのアップグレード 

− 削除される能力。利用されない，時代遅れの，混乱させる，又は危険な能力 

− 改善される性能。より良い応答時間，ストレージ容量要求事項の縮小，品質の改善，システム負荷又

は利用者負荷の減少，など 

A.2.8.2 不利及び制限 

提案システムの定性的（及び可能な範囲で定量的）な不利及び／又は制限を要約する。不利には，要員

の再教育ニーズ，仕事場の再調整ニーズ，又は利用者インタフェースの新スタイルへの変更ニーズ，が含

まれよう。制限には，利用者が望むにもかかわらず含まれない特徴，新しい能力を獲得するために起こる

既存システムの能力の劣化，又はある複雑な運用に対する望ましいレベル以下の応答時間，がある。 

A.2.8.3 考えられる代替案 

考えられる主要な代替案，トレードオフ分析結果，及び決定に至った根拠，を記述する。システムレベ

ルの運用概念（OpsCon）文書の文脈においては，代替案とは運用の代替案であって，設計の代替案ではな

い。ただし，設計の代替案が新システムで求められる運用能力に限った程度ならば別である。この情報は，

現在及び以降に，与えられた方法が分析され評価されたものかどうかを，又はなぜある特定の方法若しく

はソリューションが排除されたのかを，究明する上で役立つ可能性がある。この情報は記録しないとおそ

らく失われることになる。 

A.2.9 付録 

システムレベルの運用概念（OpsCon）文書の使いやすさと保守しやすさをもたせるために，文書の附属

書に何らかの情報を置いてもよい。図及び分類データが典型例である。附属書それぞれを，文書本体の中

で通常ならば記載することになる箇所から参照することが望ましい。附属書を利用しやすくするため，別

の文書として製本してもよい。 

A.2.10 用語集 

概念分析及びシステムレベルの運用概念（OpsCon）文書の作成中に，用語集を保守・更新することが望

ましい。頭字語及び略語を，この文書で用いる意味とともに，アルファベット順に一覧化する。また，文

書を理解するために必要なあらゆる用語及び定義を一覧化する。誤解による不要な仕事を避けるため，全

ての定義を全ての関係者がレビューし合意することが望ましい。 

75 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

附属書B 

（参考） 

組織レベルの運用概念 

B.1 

概要 

この附属書では，組織レベルの運用概念（ConOps）文書に対する指針を，情報項目の形で提供する。こ

の文書はこの規格で規定する要求仕様書ではなく，この規格の利用者が，要求事項引出しタスクにおいて，

プロジェクトの背景を理解し，かつ，全体的なビジネス及びシステム特性を伝達するための実践的文書と

して役立つことを意図している。 

組織レベルの運用概念（ConOps）は，組織レベルで，指導部が意図する組織の運営方法を表す。この文

書は，（複数の）システムをブラックボックスと見て，組織のゴール及び目標へ向かうためにシステムをい

かに利用するかに焦点を当てる。組織レベルの運用概念（ConOps）文書は，開発するシステム，既存シス

テム，及び将来可能性のあるシステム利用を含めて，事業の全体的運用又は一連の運用に関して，組織の

前提条件又は意図を記述する。この文書はしばしば長期の戦略的計画及び年間運用計画の形で具体化され

る。組織レベルの運用概念（ConOps）文書は，組織にとっては将来のビジネス及びシステムの全体的な特

性を指し示すための根拠となり，プロジェクトにとってはその背景を理解する根拠となり，かつ，この規

格の読者には，利害関係者要求事項引出しを実施する根拠ともなる。組織レベルの運用概念（ConOps）文

書は，次の情報項目を含むことが望ましい。 

B.2 

組織レベルの運用概念（ConOps）書 

B.2.1 

目的 

この文書の目的を，組織の現況，長期戦略的計画のゴール，及びそれらの間のギャップを記述すること

で説明する。 

B.2.2 

適用範囲 

文書の適用範囲を，それが当てはまる組織の事業領域を指定することによって記述する。 

B.2.3 

戦略的計画 

組織のビジネス及び結果として得られるシステムに対して，長期の戦略的計画を記述する。これには，

組織の現在のビジネスをいつ変えることが望ましいか，かつ，どのシステムを実装・運用するのが望まし

いかを含む。この計画は優先度をもつ選択肢が含まれていてもよい。 

B.2.4 

有効性 

計画を実行することで期待できる有効性を見積もる。 

B.2.5 

全体運用 

B.2.5.1 状況 

組織のビジネスの全体像を記述する。かつ，どのビジネス機能又は組織単位が，どの既存システムで扱

われるか及びどれが計画システムで扱われるかを記述する。より詳細な記述のため，主要なデータの源及

び流れをその上にマップしてもよい。 

B.2.5.2 システム 

既存システム及び将来開発されるシステムを一覧化し，かつ，概要を記述する。 

B.2.5.3 組織単位 

76 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

業務運用，システム運用，及びその管理，の役割を果たす組織単位を一覧化し，かつ，互いに関連付け

る。 

B.2.6 

統治（governance） 

B.2.6.1 統治（governance）の方針 

計画を実施する上で重要な業務的決定事項・技術的決定事項に影響する方針又は原則を記述する。 

B.2.6.2 組織 

統治に責任ある組織単位を記述し，かつ，システム開発における組織構造及び人的資源に対する方針を

記述する。 

B.2.6.3 投資計画 

システム開発に対する可能な投資計画を記述する。さらに，いかにその方針が管理されるのが望ましい

かを描く。 

B.2.6.4 情報資産管理 

情報資産をどのように管理するかという方針を記述し，どの組織単位がその管理に責任をもつかを定義

する。 

B.2.6.5 セキュリティ 

セキュリティに関する方針を記述する。 

B.2.6.6 事業継続計画 

事業継続計画に関する方針を記述する。 

B.2.6.7 法令遵守（compliance） 

法令遵守（compliance）に関する方針を記述する。 

77 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

附属書C 
（参考） 

JIS X 0170及びJIS X 0160からのプロセスマッピング 

C.1 利害関係者要求事項定義プロセス 

表C.1に，利害関係者要求事項定義プロセスに含まれるアクティビティと，対応する箇条6のアクティ

ビティとを，追加した適用指針を含めて示している。JIS X 0170:2013及びJIS X 0160:2012のプロセス詳

細には異なるタイトルと言語表現とがあるが，同等のプロセスがマッチするように調整した。 

表C.1−利害関係者要求事項定義プロセスにおけるJIS X 0170，JIS X 0160，及びJIS X 0166の箇条対応 

JIS X 0170箇条 

JIS X 0160箇条 

JIS X 0166 

6.4.1 利害関係者要求事項定義プロセス 

6.4.1 利害関係者要求事項定義プロセス 

6.2 

a) 利害関係者要求事項引出し 

このアクティビティは，次のタスクから

なる。 

6.4.1.3.1 利害関係者の識別 
このアクティビティは，次のタスクからなる。 

6.2.3.1 

1) システムのライフサイクルを通じて，シス

テムに正当な関係をもつ個々の利害関係
者又は利害関係者のクラスを識別する。 

6.4.1.3.1.1 プロジェクトは，システムのライフサ
イクルの全期間を通して，システムに正当な利害
関係をもつ個々の利害関係者又は利害関係者の
種類を識別する。 

6.2.3.1 

2) 識別された利害関係者から利害関係者要

求事項を引き出す。 

6.4.1.3.2 要求事項の識別 
このアクティビティは，次のタスクからなる。 
6.4.1.3.2.1 プロジェクトは，利害関係者要求事項
を引き出す。 

6.2.3.1 

b) 利害関係者要求事項定義 

このアクティビティは，次のタスクから

なる。 

6.2.3.2 

1) システムソリューション上の制約事項，す

なわち，既存の合意，管理上の決定及び技
術上の決定の結果がもたらす不可避な影
響を定義する。 

6.4.1.3.2.2 プロジェクトは，既存の合意，管理上
の決定及び技術上の決定の避けられない影響か
らもたらされるシステムソリューション上の制
約条件を定義する。 

6.2.3.2 

2) 予想される運用及び支援のシナリオ並び

にそれらの環境に合致して，要求される全
てのサービスを識別するために，そのアク
ティビティの順序の代表的な集合を定義
する。 

6.4.1.3.2.3 プロジェクトは，予想される運用シナ
リオ及び支援シナリオ，並びに環境に対応する全
ての要求されるサービスを識別するために，代表
的な活動順序を定義する。 

6.2.3.2 

3) 利用者とシステムとの間の相互作用を識

別する。 

6.4.1.3.2.4 プロジェクトは，人間の能力及びスキ
ルの限界を考慮して，利用者とシステムとの間の
相互作用を識別する。 

6.2.3.2 

4) 健康，安全性，セキュリティ，環境及び他

の利害関係者要求事項及び重大な品質に
関する機能を明示する。 

6.4.1.3.2.5 プロジェクトは，健康，安全，セキュ
リティ，環境及び他の利害関係者要求事項並びに
重大な品質に関係する機能を指定し，人間の健康
及び安全に対する，システムの使用が及ぼす悪影
響の可能性に対処する。 

6.2.3.2 

c) 利害関係者要求事項の分析及び維持 

このアクティビティは，次のタスクから

なる。 

6.4.1.3.3 要求事項の評価 
このアクティビティは，次のタスクからなる。 

6.2.3.3 

1) 引き出された要求事項の完全な集合を分

析する。 

6.4.1.3.3.1 プロジェクトは，導出された要求事項
の全集合を分析する。 

6.2.3.3 

78 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.1−利害関係者要求事項定義プロセスにおけるJIS X 0170，JIS X 0160，及びJIS X 0166の箇条対応

（続き） 

JIS X 0170箇条 

JIS X 0160箇条 

JIS X 0166 

2) 要求事項に関する問題を解決する。 

6.4.1.3.4 要求事項の合意 
このアクティビティは，次のタスクからなる。 
6.4.1.3.4.1 プロジェクトは，要求事項に関する問
題を解決する。 

6.2.3.3 

3) ニーズ及び期待が適切に捉えられ，表現さ

れていることを確実にするために，分析さ
れた要求事項を該当する利害関係者へフ
ィードバックする。 

6.4.1.3.4.2 ニーズ及び期待が適切に把握され，表
現されていることを確実にするために，分析され
た要求事項を該当する利害関係者へフィードバ
ックする。 

6.2.3.3 

4) 利害関係者要求事項が正確に表現されて

いることを，利害関係者とともに確立す
る。 

6.4.1.3.4.3 プロジェクトは，利害関係者要求事項
が正確に表現されていることを，利害関係者とと
もに確立する。 

6.2.3.3 

5) ライフサイクルを通して，及びその後も，

要求事項の管理に適した形式で利害関係
者要求事項を記録する。 

6.4.1.3.5 要求事項の記録 
このアクティビティは，次のタスクからなる。 
6.4.1.3.5.1 プロジェクトは，ライフサイクルを通
して及びその後も，要求事項管理に適した形式
で，利害関係者要求事項を記録する。 

6.2.3.3 

6) 利害関係者要求事項から利害関係者のニ

ーズの源への追跡可能性を維持する。 

6.4.1.3.5.2 プロジェクトは，利害関係者のニーズ
の源への利害関係者要求事項の追跡可能性を維
持する。 

6.2.3.3 

C.2 要求事項分析プロセス 

表C.2に，要求事項分析プロセスに含まれるアクティビティと，対応する箇条6のアクティビティとを，

追加の適用指針を付けて示している。 

表C.2−要求事項分析プロセスにおけるJIS X 0170，JIS X 0160，及びJIS X 0166の箇条対応 

JIS X 0170箇条 

JIS X 0160箇条 

JIS X 0166 

6.4.2 要求事項分析プロセス 

6.4.2 システム要求事項分析プロセス 

6.3 

a) システム要求事項の定義 

このアクティビティは，次のタスクから

なる。 

1) 提供される振る舞い及び性質の観点から，

システムの機能的な境界を定義する。 

2) システムが実行を要求されている各機能

を定義する。 

3) 利害関係者要求事項によってもち込まれ

るか，又は回避できないソリューションの
制限である，必要な実装制約条件を定義す
る。 

4) 技術的な達成度のアセスメントを可能に

する，技術的な測定量及び利用時の品質に
ついての測定量を定義する。 

5) システムのリスクの識別又は重大性によ

って正当化されるので，健康，安全性，セ
キュリティ，信頼性，可用性及び支援可能
性のような，重大な品質に関係のあるシス
テム要求事項及び機能を明示する。 

6.4.2.3.1 要求事項の仕様化 
このアクティビティは，次のタスクからなる。 
6.4.2.3.1.1 開発すべきシステムの意図された具体
的用途を分析し，システム要求事項を明記する。
システム要求事項仕様は，次のことを文書化す
る。 
− システムの機能及び能力 
− 事業，組織及び利用者の要求事項 
− 安全，セキュリティ，人間工学，インタフェ

ース，運用及び保守の要求事項 

− 設計制約及び適格性確認の要求事項 
システム要求事項仕様を文書化する。 

6.3.3.1  

79 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−要求事項分析プロセスにおけるJIS X 0170，JIS X 0160，及びJIS X 0166の箇条対応（続き） 

JIS X 0170箇条 

JIS X 0160箇条 

JIS X 0166 

b) システム要求事項の分析及び維持 

このアクティビティは，次のタスクから

なる。 

1) 各要求事項，要求事項の対又は要求事項の

集合が，全体的完整性（integrity）をもつ
ことを確実にするために，システム要求事
項の完整性（integrity）を分析する。 

6.4.2.3.2 要求事項評価 
このアクティビティは，次のタスクからなる。 
6.4.2.3.2.1 システム要求事項は，次の基準を考慮
して評価する。評価の結果を文書化する。 
a) 取得ニーズの追跡可能性 
b) 取得ニーズとの一貫性 
c) テスト可能性 
d) システム方式設計の実現可能性 
e) 運用及び保守の実現可能性 

6.3.3.2 

2) 指定されたシステム要求事項がニーズ及

び期待に対応して利害関係者要求事項を
適切に反映していることを保証するため
に，分析された要求事項を該当する利害関
係者にフィードバックする。 

6.3.3.2 

3) システム要求事項と利害関係者要求事項

との間の追跡可能性を示す。 

注記 上記の6.4.2.3.2.1 a)参照 

6.3.3.2 

4) システムライフサイクルを通して付随す

る論理的根拠，決定及び前提とともに，シ
ステム要求事項の集合を維持する。 

6.3.3.2 

C.3 他の要求関連の技術プロセス 

表C.3に，その他の技術プロセスに含まれる要求事項アクティビティと，対応する箇条6のアクティビ

ティとを，追加の適用指針を付けて示している。 

表C.3−他の技術プロセスにおけるJIS X 0170，JIS X 0160，及びJIS X 0166の箇条対応 

JIS X 0170箇条 

JIS X 0160箇条 

JIS X 0166 

6.4.3 方式設計プロセス 
a) 方式の定義 

このアクティビティは，次のタスクから

なる。 

2) 要求事項分析で識別されたシステム機能

を分割し，システム方式の要素にそれらを
割り当てる。割当てのために必要となる派
生要求事項を作り出す。 

3) システム要素間のインタフェース及び外

部システムとのシステム境界でのインタ
フェースを定義し，文書化する。 

6.4.3 システム方式設計プロセス 
6.4.3.3.1 システム方式の確立 
このアクティビティは，次のタスクからなる。 
6.4.3.3.1.1 システムの最上位の方式を確立する。
方式は，ハードウェア，ソフトウェア及び手作業
の品目を識別する。全てのシステム要求事項が品
目に割り当てられていることを確実にする。それ
に続いて，ハードウェア構成品目，ソフトウェア
構成品目及び手作業を，これらの品目から識別す
る。システム方式及び品目に割り当てたシステム
要求事項を文書化する。 

6.4.1.1 

b) 方式の分析及び評価 

このアクティビティは，次のタスクから

なる。 

2) どのシステム要求事項が運用者に割り当

てられるかを決定する。 

6.4.3.3.2 システム方式の評価 
このアクティビティは，次のタスクからなる。 
6.4.3.3.2.1 システム方式及び品目に対する要求事
項は，次の基準に基づいて評価する。評価の結果
を文書化する。 
a) システム要求事項への追跡可能性 
b) システム要求事項との一貫性 
d) 割り当てられた要求事項を満たすソフトウェ

ア品目の実現可能性 

6.4.1.2 

80 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.3−他の技術プロセスにおけるJIS X 0170，JIS X 0160，及びJIS X 0166の箇条対応（続き） 

JIS X 0170箇条 

JIS X 0160箇条 

JIS X 0166 

6.4.6 検証プロセス 
a) 検証の計画 

このアクティビティは，次のタスクから

なる。 

2) システム要求事項に基づく検証計画を定

義する。 

6.4.6 システム適格性確認テストプロセス 
6.4.6.3.1 適格性確認テスト 
このアクティビティは，次のタスクからなる。 
6.4.6.3.1.1 システムに対して指定された適格性確
認要求事項に従って，システム適格性確認テスト
を行う。各システム要求事項について実装の適合
性をテストし，システムの納入準備ができている
ことを確実にする。適格性確認テストの結果を文
書化する。 

6.4.2.1 

b) 検証の実施 

このアクティビティは，次のタスクから

なる。 

2) 指定された設計要求事項に対する遵守を

示すために検証を行う。 

6.4.6.3.1.2 システムは，次の基準を考慮して評価
する。評価の結果を文書化する。 
a) システム要求事項のテスト網羅性 
b) 期待した結果への適合性 
c) 運用及び保守の実現可能性 

6.4.2.2 

6.4.8 妥当性確認プロセス 
a) 妥当性確認の計画 

このアクティビティは，次のタスクから

なる。 

2) 妥当性確認計画を準備する。 

6.4.3.1 

6.4.8 妥当性確認プロセス 
b) 妥当性確認の実施 

このアクティビティは，次のタスクから

なる。 

2) 利害関係者要求事項に対するサービスの

適合性を示すために妥当性確認を実施す
る。 

6.4.3.2 

81 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

附属書D 
（規定） 

修整の方針 

D.1 序文 

この附属書では，この規格の情報項目内容の修整に対する要求事項を提供する。修整はこの規格への適

合性にとって要求事項ではない。実際，“完全適合性”の主張を行う場合，修整は許されない。“修整適合

性”の主張をする場合，次のプロセスを適用して修整を実施しなければならない。 

D.2 情報項目修整プロセス 

D.2.1 修整プロセスの目的 

修整プロセスは，次のような特定の状況又は要因を満足させるために，この規格の情報項目内容を適合

させることを目的とする。 

a) 合意の中でこの規格を採用している組織を取り巻く要因 

b) この規格を参照するという合意を満たすことが要求されるプロジェクトの要因 

c) 製品又はサービスを提供するために組織のニーズを反映する要因 

D.2.2 修整プロセスの成果 

修整プロセスの実施に成功すると，この規格で規定する要求仕様書の目的を達成するために，変更又は

追加の情報項目内容が定義される。 

D.2.3 アクティビティ及びタスク 

この規格を修整する場合，組織又はプロジェクトは次のアクティビティを実施しなければならない。 

a) 修整に影響を与える状況を識別し，文書化する。これらの影響は，次を含むが，限定するものではな

い。 

1) 運用環境の安定性及び多様性 

2) 新規性，規模，及び複雑さ 

3) 利用開始日及び利用期間 

4) 出現しつつある技術の機会 

5) 利用可能な予算及び組織の資源のプロファイル 

6) イネーブリングシステムのサービスの可用性 

7) 他の規格への適合性ニーズ 

b) 修整決定によって影響を受ける全ての関係者から入力を得る。これは，次を含むが，限定するもので

はない。 

1) 利害関係者 

2) 組織によって結ばれた合意に対する関係者 

3) 貢献する組織機能 

c) 修整を必要とする情報項目内容を選択し，削除する。 

注記1 修整とは関係なく，組織及びプロジェクトは，この規定に適合するために要求される内容

以外に，情報項目内容を追加することは常に許されている。 

82 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記2 組織又はプロジェクトでは，情報項目内容を修正したいという要望が発生することがあ

る。修正するには，その情報項目内容を削除し（適切な修整適合性の主張をしながら），

かつ，結果を注意深く検討した上で，今修整した規定に情報を追加するような情報項目内

容を新たに作成する。 

83 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

参考文献 

[1] 

JIS X 0129-1:2003 ソフトウェア製品の品質−第1部：品質モデル 

注記 対応国際規格：ISO/IEC 9126-1:2001，Software engineering−Product quality−Part 1: Quality 

model（IDT）（ISO/IEC 9126-1:2001は取り消され，ISO/IEC 25010:2011に置き換えられた。） 

[2] 

ISO 9241-210:2010，Ergonomics of human-system interaction−Part 210: Human-centred design for 

interactive systems 

[3] 

JIS X 0160:2012 ソフトウェアライフサイクルプロセス 

注記 対応国際規格：ISO/IEC 12207:2008 (IEEE Std 12207-2008)，Systems and software engineering

−Software life cycle processes（IDT） 

[4] 

JIS X 0135-1:2010 ソフトウェア測定−機能規模測定−第1部：概念の定義 

注記 対応国際規格：ISO/IEC 14143-1:2007，Information technology−Software measurement−

Functional size measurement−Part 1: Definition of concepts（IDT） 

[5] 

JIS X 0170:2013 システムライフサイクルプロセス 

注記 対応国際規格：ISO/IEC 15288:2008 (IEEE Std 15288-2008)，Systems and software engineering

−System life cycle processes（IDT） 

[6] 

ISO/IEC/IEEE 15289:2011，Systems and software engineering−Content of life-cycle information products 

(documentation) 

注記 対応する日本工業規格が制定される予定である。 

[7] 

JIS X 0162:2008 システム及びソフトウェア技術−ライフサイクルプロセス−リスク管理 

注記 対応国際規格：ISO/IEC 16085:2006，Systems and software engineering−Life cycle processes

−Risk management（IDT） 

[8] 

ISO/TR 18529:2000，Ergonomics−Ergonomics of human-system interaction−Human-centred lifecycle 

process descriptions 

[9] 

ISO/IEC TR 19759:2005，Software Engineering−Guide to the Software Engineering Body of Knowledge 

(SWEBOK) 

[10] ISO 20282-1，Ease of operation of everyday products−Part 1: Design requirements for context of use and 

user characteristics 

[11] ISO/IEC TR 24748-1:2010，Systems and software engineering−Life cycle management−Part 1: Guide for 

life cycle management 

[12] ISO/IEC TR 24748-2，Systems and software engineering−Life cycle management−Part 2: Guide to the 

application of ISO/IEC 15288 (System life cycle processes) 

[13] ISO/IEC/IEEE 24765:2010，Systems and software engineering−Vocabulary 

[14] ISO/IEC TR 24766:2009，Information technology−Systems and software engineering−Guide for 

requirements engineering tool capabilities 

[15] JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及び

ソフトウェア品質モデル 

注記 対応国際規格：ISO/IEC 25010:2011，Systems and software engineering−Systems and software 

Quality Requirements and Evaluation (SQuaRE)−System and software quality models（IDT） 

84 

X 0166：2014 (ISO/IEC/IEEE 29148：2011) 

  

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

[16] JIS X 25030:2012 ソフトウェア製品の品質要求及び評価（SQuaRE）−品質要求事項 

注記 対応国際規格：ISO/IEC 25030:2007，Software engineering−Software product Quality 

Requirements and Evaluation (SQuaRE)−Quality requirements（IDT） 

[17] ISO/IEC TR 25060，Systems and software engineering−Systems and software product Quality 

Requirements and Evaluation (SQuaRE)−Common Industry Format (CIF) for usability: General framework 

for usability-related information 

[18] ISO/IEC 25062，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)

−Common Industry Format (CIF) for usability test reports 

[19] ISO/IEC 26551，Software and systems engineering−Tools and methods for product line requirements 

engineering 

[20] ISO/IEC 26702:2007，Systems engineering−Application and management of the systems engineering 

process 

[21] ISO/IEC TR 29138-1:2009，Information technology−Accessibility considerations for people with 

disabilities−Part 1: User needs summary 

[22] JIS Q 9000:2006 品質マネジメントシステム−基本及び用語 

注記 対応国際規格：ISO 9000:2005，Quality management systems−Fundamentals and vocabulary

（IDT） 

[23] ANSI/AIAA G-043-1992，Guide for the Preparation of Operational Concept Documents, American Institute 

of Aeronautics and Astronautics, January 1993 

[24] EIA 632:1999，Processes for Engineering a System, Electronics and Information Technology Association, 

January 1999 

[25] IEEE Std 830，IEEE Recommended Practice for Software Requirements Specifications 

[26] IEEE Std 1012，IEEE Standard for Software Verification and Validation 

[27] IEEE Std 1233，IEEE Guide for Developing System Requirements Specifications 

[28] IEEE Std 1362，IEEE Guide for Information Technology−System Definition−Concept of Operations 

(ConOps) Document 

[29] Systems Engineering Handbook, Version 3.2, International Council on Systems Engineering, August 2010 

[30] The Guide to the Business Analysis Body of Knowledge (BABOK), Version 2.0, International Institute of 

Business Analysis, March 2009 

[31] JIS Z 8521 人間工学−視覚表示装置を用いるオフィス作業−使用性についての手引 

[32] JIS X 0141:2009 システム及びソフトウェア技術−測定プロセス 

[33] JIS X 25000:2010 ソフトウェア製品の品質要求及び評価（SQuaRE）−SQuaREの指針 

[34] IEEE Std 1028-2008，IEEE Standard for Software Reviews and Audits