63
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
ている。
3) 利害関係者のニーズ及び期待が適切に把握されて表現されていることを妥当性確認するために,分
析された要求事項を適用可能な利害関係者へフィードバックする。
4) 利害関係者要求事項の課題を解決する。
注記 この課題には,JIS X 0166で定義されている特性のような,個々の要求事項の特性又は要
求事項の集合の特性から逸脱するような要求事項を含む。
f) 利害関係者ニーズ及び利害関係者要求事項の定義を管理する。このアクティビティは,次のタスクか
らなる。
1) 利害関係者要求事項についての明示的な合意を獲得する。
注記 これには,利害関係者要求事項が正しく表現されているか,要求事項の提供元の利害関係
者にも理解できるか,及び矛盾のある要求事項の解決策が利害関係者の意図を損なってし
まう又は失ったものになっていないか,を確認することを含む。
2) 利害関係者ニーズ及び利害関係者要求事項のトレーサビリティを維持する。
注記 ライフサイクルを通じて,利害関係者ニーズ及び利害関係者要求事項と,それらの提供元
及び利害関係者,組織の戦略,並びにビジネス及びミッションの問題及び機会との間で,
双方向のトレーサビリティを維持する。さらに,システムのソリューションを作り上げつ
つあるシステムへのトレーサビリティによって,システム要求事項定義プロセスへ移行す
ることを容易にする。適切なデータリポジトリによって,これが容易になることがよくあ
る。
3) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが,構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス(利害関係者ニーズ及び利害関係者要求事項定義)で,ベースラインのための
候補となる情報項目を識別し,CMへ情報項目を提供する。このプロセスにおいてベース
ライン化される典型的な情報項目は,利害関係者ニーズ,利害関係者要求事項及びシステ
ムレベルの運用概念である。
6.4.3 システム要求事項定義プロセス(System Requirements Definition process)
6.4.3.1 目的
システム要求事項定義プロセスは,要望されている能力についての利害関係者から見た利用者主体のビ
ューを,利用者にとっての運用時のニーズに合致するソリューションについての技術面のビューへ変換す
ることを目的とする。
このプロセスは,供給者の観点から,利害関係者要求事項を満足させるためには,どのような特性,属
性,並びに機能及び遂行能力・性能・運用時の実績への要求事項をシステムが備えることになるのかを仕
様化した,測定可能なシステム要求事項の集合を作り出す。
制約が許す限り,特定の実現方法については何ら示さない要求事項とすることが望ましい。
6.4.3.2 成果
システム要求事項定義プロセスの実施に成功すると次の状態になる。
a) システムソリューションのためのシステム記述が定義されている。記述にはシステムのインタフェー
ス,機能及び境界が含まれている。
b) システム要求事項(機能,遂行能力・性能・運用時の実績,プロセス,非機能,及びインタフェース
への要求事項)及び設計上の制約が定義されている。
――――― [JIS X 0170 pdf 66] ―――――
64
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
c) 重大なシステムの遂行能力・性能・運用時の実績の測定量が定義されている。
d) システム要求事項が分析されている。
e) システム要求事項定義プロセスの実施を可能にするために必要な全てのイネーブリングシステム又は
サービスが利用可能になっている。
f) システム要求事項と利害関係者要求事項との間のトレーサビリティが確立されている。
6.4.3.3 アクティビティ及びタスク
プロジェクトは,システム要求事項定義プロセスに関する,適用可能な組織の方針及び手順に従って,
次に示すアクティビティ及びタスクを実施しなければならない。
a) システム要求事項定義の準備を行う。このアクティビティは,次のタスクからなる。
1) 提供される振る舞い及び性質の観点から,システムの機能的な境界を定義する。
注記 機能的な境界の定義の一部は,利害関係者ニーズ及び利害関係者要求事項定義プロセスの
枠組みで定義された,利用の状況及び運用シナリオに基づいている。これには,次を含む。
利用者及び環境の振る舞いに対してシステムが受ける刺激及びそれらへのシステムの反応,
並びにシステムとその環境との間に要求される相互作用の分析及び記述。これらには,機
械的,電気的,質量,熱,データ及び手順的な流れのようなインタフェース上の性質及び
制約の観点を用いる。これによって,システムの境界となるところで期待されるシステム
の振る舞いを,定量的な用語で表現して確立する。
2) システム要求事項定義の戦略を定義する。
注記 これには,システム要求事項を識別及び定義し,ライフサイクルを通じて要求事項を管理
するために用いる取組方法を含む。
3) システム要求事項定義の支援に必要なイネーブリングシステム又はサービスを識別し計画する。
注記 これには,要求事項の識別及びイネーブリングシステムとのインタフェースを含む。シス
テム要求事項定義のためのイネーブリングシステムには,要求事項定義の促進及び要求事
項管理のためのツールを含む。
4) 利用されるイネーブリングシステム若しくはサービスを獲得する,又はそれらへのアクセスを取得
する。
注記 システム要求事項定義の実現を支援するイネーブリングシステムの支援機能が,意図され
たように利用できるかを客観的に確認するために,妥当性確認プロセスが用いられる。
b) システム要求事項を定義する。このアクティビティは,次のタスクからなる。
1) システムが遂行するよう要求されている各機能を定義する。
注記1 これは次を含む。システムが運用操作者を含めて,どのように良好に機能を遂行するこ
とが要求されているか,並びにシステムが機能を遂行することができる条件,システム
が機能の遂行を開始する条件,及びシステムが機能の遂行を停止する条件がどのような
条件であるか。機能は,重大な品質特性の分析から導出される場合もある(例えば,信
頼性のためのシステム診断機能,高頻度データバックアップ機能)。
注記2 機能の遂行能力・性能・運用時の実績に対する条件には,システム運用中に要求される
運用状態及び運用モードへの参照を組み入れることもできる。システム要求事項は,提
案されたシステム特性の抽象的な表現に大きく依存し,要望されるシステム要求事項全
体を抜け漏れなく完全に十分に記述するために,複数種類のモデル化の手法及び観点を
採用することもある。
――――― [JIS X 0170 pdf 67] ―――――
65
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
注記3 対象システムの機能性の達成を支援するために要求されるイネーブリングシステムの支
援機能を,対象システムの機能と同時に識別し定義する。これは,対象システムが機能
性を達成することを支援するように,イネーブリングシステムの支援機能を識別し,か
つ,構成することを確実なものにするよう助けるために必要である。
2) 必要な実装制約条件を定義する。
注記 これには,システム構造のより高いレベルのアーキテクチャ定義から割り当てられた実装
上の決定,及び利害関係者要求事項によってもち込まれたか,又はソリューションの制限
となっている,実装上の決定を含む。
3) リスク,システムの重大性又は重大な品質特性に関連するシステム要求事項を識別する。
注記 重大な品質特性は,一般に,健康,安全性,セキュリティのアシュアランス,信頼性,ア
ベイラビリティ,及び運用の支援性に関連するものを含む。このタスクには,運用及び保
守の方法,環境上の影響並びに人員の負傷に関係するものを含めた安全性への考慮事項の
分析及びその定義を含む。
また,安全性に関する各機能及びそれに関連する安全性についての完整性が,必要なリ
スク軽減の観点から表現され,明示され,かつ,指定された安全性に関するシステムに割
り当てられることを確実にするよう支援することを含む。機能安全性に関して適用可能な
規格,例えば,JIS C 0508規格群,及び環境保護に関して適用可能な規格,例えば,JIS Q
14001が利用される。
機密の情報,データ及び資材を,危険にさらすこと及び保護することに関連するものを
含めたセキュリティの考慮事項を分析する。該当する場合には,適用できるセキュリティ
規格を利用して,管理,人員,身体,コンピュータ,通信,ネットワーク,排出物質及び
環境の要素を含めて,セキュリティに関連するリスクを定義する。ただし,リスクはこれ
らに限定されるものではない。システム及びソフトウェアのアシュアランスの手引は
ISO/IEC 15026-4を参照。ISO/IEC 27036シリーズは,製品及びサービスのアウトソーシン
グのための情報セキュリティに関する要求事項の手引を提供する。
品質要求事項に関するJIS X 25030は,外部システムの品質要因及び品質特性に関する
手引を提供する。人間との対話操作・相互作用をもつシステムでは,人的要因に対するエ
ンジニアリング(人間工学)面の仕様が検討される。使用性についての要求事項があるシ
ステムでは,使用性について要望されるレベルを得るための推奨事項を,人間中心のライ
フサイクルプロセスについて記載がある人間工学に関する標準報告書ISO/TR 18529で見
つけることもできる。
4) システム要求事項及び根拠を定義する。
注記1 これには,利害関係者要求事項,機能的な境界,機能,制約,コスト目標,識別された
インタフェース,及び重大な品質特性と一致したシステム要求事項の定義を含む。シス
テム開発の実践によって一貫して示されているように,このプロセスは,他のライフサ
イクルプロセスとともに,システムの各階層にわたって反復的・再帰的に適用する段階
的な手順を要求するものである。システム要求事項に関する追加情報はJIS X 0166の箇
条5及び箇条6を,システム要求仕様書の記述及び注釈付きの目次概要は箇条8及び箇
条9を参照。
注記2 システム要求事項は,ライフサイクルを通して,要求事項の管理に適した形式で記録さ
――――― [JIS X 0170 pdf 68] ―――――
66
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
れる。これらの記録は,システム要求事項のベースラインを確立し,関連する論理的根
拠,決定及び前提を含む。これらは,情報項目及び次に続くシステム要素へのトレーサ
ビリティの基礎となる。システム要求事項の変更依頼は,利害関係者要求事項との一貫
性を含めて,提案された変更を受容するかを決定するために役立つ根拠も提供する。
注記3 システム分析プロセスは,システムのコスト見積り,スケジュール,及び技術面での遂
行能力・性能・運用時の実績を考慮して,要求事項のパラメータの適切な値を決定する
ために使用される。妥当性確認プロセスは,要求事項が利害関係者のニーズを満たして
いるかどうかを判定するために使用される。検証プロセスは,良い要求事項の属性及び
性質(JIS X 0166を参照)に関して,要求事項の品質を判定する。
c) システム要求事項を分析する。このアクティビティは,次のタスクからなる。
1) システム要求事項を抜け漏れなく集め,完全な全体集合にして分析する。
注記1 システム要求事項は,要求事項の集合としての特性に対して分析されるとともに,個々
の要求事項の特性に対しても分析される。個々の要求事項に関して,潜在的な可能性に
ついて分析される特性には次が含まれる。要求事項が必要なものであること,実装方法
に依存しないものであること,曖昧性がないこと,矛盾なく一貫性があること,抜け漏
れがなく完全にそろ(揃)っていること,単独性があり他の要求事項との重複がないこ
と,実現可能であること,トレース可能であること,検証可能であること,費用面で可
能であること,及び定義範囲を示す境界が明確にされていること。JIS X 0166は,要求
事項の特性についての追加情報を提供する。欠陥,矛盾点及び弱点は,システム要求事
項の完全な全体集合内で識別され,解決される。
注記2 システム分析プロセスが,システムの実現可能性,費用面での可能性及びこれらのバラ
ンスをアセスメントするために使用される。
2) 技術面での達成度のアセスメントを可能にする,重大な遂行能力・性能・運用時の実績の測定量を
定義する。
注記 これには,システム要求事項の中で識別された有効性の測定量に関連付けられた,技術面
の測定量及び品質測定量,並びに重大な遂行能力・性能・運用時の実績を表すパラメータ
を定義することを含む。重大な遂行能力・性能・運用時の実績についての測定量(例えば,
システムの遂行能力を表す運用時の実績の測定量及び技術面での性能の測定量)を,分析
及びレビューし,次のことに役立てる。システム要求事項が満たされることを確実なもの
にすること,及びプロジェクトのコスト,スケジュール又はシステムの遂行能力・性能・
運用時の実績に関する,何らかの不適合に関連したリスクの識別を確実なものにすること。
JIS X 0141は,適切な測定量を識別し,定義し,利用するためのプロセスを規定する。
INCOSE TP-2003-020-01は,重大な遂行能力・性能・運用時の実績についての測定量の選
択,定義,及び実装に関する技術面の測定について情報を提供する。JIS X 25000シリーズ
は,関連する品質測定量を提供する。
3) レビューのため,分析された要求事項を該当する利害関係者にフィードバックする。
注記 フィードバックは,指定されたシステム要求事項が適切に捉えられ,表現されていること
を確実なものにするよう助ける。システム要求事項が利害関係者要求事項への必要十分な
対応をもって応えていることの確認,並びに他のプロセス,特にアーキテクチャ及び設計
への必要十分な入力であることの確認がされる。これは,特定の要求事項に対して用いら
――――― [JIS X 0170 pdf 69] ―――――
67
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
れる妥当性確認プロセスの適用の一つである。
4) システム要求事項の課題を解決する。
注記 これには,JIS X 0166に定義されているように,個々の要求事項又は要求事項の集合がも
つ特性を損なってしまう要求事項を課題として解決することを含む。
d) システム要求事項を管理する。このアクティビティは,次のタスクからなる。
注記 システム要求事項の維持は,例えば,アーキテクチャ,設計など他のライフサイクルプロセ
スの適用に起因する全ての変更を管理することに連動して,一般に正式の構成管理下で,ベ
ースラインを定義し,記録し,かつ,制御することを含む。
1) システム要求事項についての明示的な合意を獲得する。
注記 これには,システム要求事項が正しく表現され,要求事項を発案した各利害関係者から見
て理解できるものになっていることを確認し,かつ,要求事項間の対立した矛盾に対する
解決が,利害関係者の意図を改悪又は損なっていないことの確認を含む。
2) システム要求事項のトレーサビリティを維持する。
注記 ライフサイクルを通じて,システム要求事項と,利害関係者要求事項,アーキテクチャ要
素,インタフェース定義,分析結果,検証手法又は技法,及び割り当てられ,分割され,
導出された要求事項との間で,双方向のトレーサビリティが維持される。これは,全ての
達成可能な利害関係者要求事項が,一つ以上のシステム要求事項で満たされ,かつ,全て
のシステム要求事項が,少なくとも一つの利害関係者要求事項を満たすか又は満たすこと
に寄与することを確実なものにするよう助ける。適切なデータリポジトリによって,これ
が容易になることがよくある。
3) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが,構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス(システム要求事項定義)で,ベースラインのための候補となる情報項目を識
別し,CMへ情報項目を提供する。このプロセスにおいて,ベースライン化される典型的
な情報項目は,システム要求事項である。
6.4.4 アーキテクチャ定義プロセス(Architecture Definition process)
6.4.4.1 目的
アーキテクチャ定義プロセスは,システムアーキテクチャの代替案を作成し,利害関係者の関心事を捉
え,システム要求事項を満たす一つ以上の代替案を選定し,一貫した一連の複数のビューの中でアーキテ
クチャを表現することを目的とする。
解決するべき問題を協議によって理解し,満足するソリューションを識別するように,アーキテクチャ
定義プロセス,ビジネス又はミッション分析プロセス,システム要求事項プロセス,設計定義プロセス,
並びに利害関係者ニーズ及び利害関係者要求事項定義プロセスを反復して用いることがよくある。アーキ
テクチャ定義プロセスの結果はライフサイクルプロセスにわたって広く用いられる。アーキテクチャ定義
は多くの抽象的なレベルに適用することができ,そのレベルでの決定に必要な関連する詳細を強調する。
注記1 システムアーキテクチャは,基本となる原則,概念,性質及び特性,並びにそれらの対象シ
ステムへの組込みを扱う。アーキテクチャ定義は単に設計を駆動するもの(又は設計の一部)
というだけではなく,それ以上の用途がある。アーキテクチャ記述,並びにアーキテクチャ
の用途及び性質についての詳細はISO/IEC/IEEE 42010:2011を参照。
注記2 アーキテクチャ定義プロセスは,複数の利害関係者の識別及びそれら利害関係者の関心事の
――――― [JIS X 0170 pdf 70] ―――――
次のページ PDF 71
JIS X 0170:2020の引用国際規格 ISO 一覧
- ISO/IEC/IEEE 15288:2015(IDT)