この規格ページの目次
38
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
び/又は数値的手法,入力データの発生源,及び生データの分析方法,を識別する。分析手法及び
ツール(シミュレーションを含め)が,客観的証明又は要求事項適合の提示として受入れ可能であ
ることを,取得者と合意できているようにする。
デモンストレーション : 機能的なパフォーマンスを定性的に見せることであり,通常,あっても最小限
の計測機器又はテスト機器を用いて行う。デモンストレーションは,供給者が選択したシステム刺激を伴
う一連のテスト作業を用いて,システム若しくはシステム要素がその刺激に適切に反応するか,又はシス
テムを用いる時に運用者が彼らに用意された機能を実行できるか,を示す。観測を行い,あらかじめ定義
された反応と比較する。要求事項又は仕様が統計的な用語(例えば,平均修理時間,平均消費電力)で与
えられているとき,デモンストレーションが適切なことがある。
良い実践 : 成功したという証拠を集めるために誰が証人になるか,後続する一般的なステップは何
か,どんな特別な資源(例えば,計測機器,特別なテスト装置若しくは設備,シミュレータ,特定
のデータ収集,又はデモンストレーション結果の厳格な分析)が必要か,を記載する。
テスト : ある項目の運用性,支援可能性,又は性能を,現実の又はシミュレーション制御条件の支配下
で,定量的に検証する行為である。分析のために非常に正確な定量データを獲得するために特別なテスト
装置又は計測機器がしばしば用いられる。
良い実践 : 成功したという証拠を集めるために誰が証人になるかを記載する。テスト設備,テスト
装置,特別な資源ニーズ及び環境条件,要求される資格及びテスト要員,後続する一般的なステッ
プ,収集すべき特定のデータ,収集データの再現性の基準,並びに結果を分析する手法,を識別す
る。
注記 認証はしばしば検証の5番目の手法として含まれる。認証は書面による保証で,システム又は
システム要素が要求される標準に従って開発され,かつ,その要求事項に適合していることの
保証である。これは,システム又はシステム要素が,取り決めた標準に割り当てた機能を実行
できることを保証するものである。開発レビュー及びシステム検証・妥当性確認の結果は認証
の根拠を形成する。認証は,受け入れられた標準に反してないかどうか,第三者によって実行
されるのが一般的である。
この情報を更新された要求事項追跡可能性マトリクス(RTM)の中に含め,かつ,文書化する。
6.4.2.2 検証の実施
このアクティビティは,次のタスクからなる。
注記 このアクティビティ配下のタスク1),3)及び4)は含めない。要求エンジニアリングに関連する
特別な指針がないからである。
2) 指定された設計要求事項に対する遵守を示すために検証を行う。
注記 不適合は,無作為の障害及び/又は設計の誤りの存在を識別し,是正処置が必要に応じ
て開始される。検証は,組織の制約と整合性がとれており,検証作業,条件及び結果の
再現における不確定性を最小にするような方法で実行される。検証作業及び検証結果の
承認された記録が作られる。
[JIS X 0170:2013,6.4.6.3 b) 2)]
要求事項の追跡可能性は,要求事項の足跡を説明するための単一点としてしばしば用いられ,ある要求
事項からその発生源へ遡れる,かつ,その要求事項が満たされたことをライフサイクルを通じて評価する
――――― [JIS X 0166 pdf 41] ―――――
39
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
ためにその要求事項の先へたど(辿)れることを意味する。要求事項の追跡可能性において,検証手法・
検証情報を要求事項に付随させ,システム又はシステム要素がその要求事項を満たすことをいかに検証さ
れるかを示す。システムがライフサイクルフェーズを通じて動くにつれて,作業成果物への要求事項の追
跡可能性を加えることが望ましい。
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)]
――――― [JIS X 0166 pdf 42] ―――――
40
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
要求事項の妥当性確認は,プロジェクト権限者及びキーとなる利害関係者による承認に支配される。こ
のプロセスは,利害関係者要求事項定義プロセスの間に呼び出され,要求事項が的確に利害関係者ニーズ
を反映していることを確認し,妥当性確認の基準を確立する。つまり正しい要求事項を我々がもっている
ことを確認する。システムの妥当性確認では,システムが,構築された暁に,利害関係者が表明したニー
ズ及び要求事項を満足していること,つまりそれが正しいシステムであること,を確認する。要求事項の
追跡可能性を保守することが望ましい。また,要求事項追跡可能性マトリクス(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 変更管理
要求事項の変更原因が何であれ,変更の不可避性を認識し,変更の影響を軽減するための処置を講ずる
ことは重要である。提案された変更が定義された影響評価・レビュー・承認プロセスを経るようにし,か
つ,注意深い要求事項の追跡及び版管理を適用することによって,変更を管理しなければならない。それ
ゆえ,要求エンジニアリングプロセスは,単なるフロントエンドタスクではなくライフサイクルにわたる。
典型的なプロジェクトでは,要求事項管理のアクティビティは,要求事項引出しから変更管理にわたって
進化する。
よく用いられるベースラインは機能的ベースライン・割当てベースライン・開発ベースライン・製品ベ
ースラインである。与えられたプロジェクトで用いるベースラインは,それに付随する変更承認に必要な
――――― [JIS X 0166 pdf 43] ―――――
41
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
権限のレベルとともに,プロジェクトの構成管理計画の中で識別する。これらのベースラインを次に示す。
− 機能的ベースラインは,外部インタフェース記述を含むレビューされたシステム要求事項に対応する。
− 割当てベースラインは,インタフェース要求仕様を含むレビューされたシステム要素要求仕様に対応
する。
− 開発ベースラインは,ライフサイクル内で選択した幾つかの時点で,進化するシステム及びシステム
要素の構成を表現する。このベースラインに対する変更権限は基本的に供給者組織にある,というの
が一般的である。
− 製品ベースラインは,完成したシステムに対応する。
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 構成管理の実施
このアクティビティは,次のタスクからなる。
――――― [JIS X 0166 pdf 44] ―――――
42
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
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)書及び利害関係者要求仕様・システム要求仕様・ソフトウェア要
求仕様・その他システム要素要求仕様をシステムライフサイクル中に管理すべき情報項目として識別する。
――――― [JIS X 0166 pdf 45] ―――――
次のページ PDF 46
JIS X 0166:2014の引用国際規格 ISO 一覧
- ISO/IEC/IEEE 29148:2011(IDT)
JIS X 0166:2014の国際規格 ICS 分類一覧
JIS X 0166:2014の関連規格と引用規格一覧
- 規格番号
- 規格名称