この規格ページの目次
43
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
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)]
一つの規律として,プロセス及び製品両方の側面から要求事項を測定すると,要求エンジニアリングは
効果的なものになる。要求事項に対する情報ニーズへの見通しを得るため,複数の測定量が必要な場合が
ある。様々な測定量が有益であると多くの実践が一貫して示している。この例を次に示す。
− 要求事項の不安定度 : プロセスの側面においては,要求事項が不安定であるということは,組織の要
求エンジニアリングプロセスが要求事項の集合を整形式の要求事項集合に収束させられないことを示
している。製品の側面においては,不安定度の値が高いということは,利害関係者がシステム要求事
項に関してコンセンサスに至ることができないリスクを早い段階で示し,ライフサイクルの後続活動
に相当なリスクを負わせることを示している。
その他の有益な要求事項の測定量には次のものがある。
− 要求事項の動向
− 要求事項変更率及び積み残し
――――― [JIS X 0166 pdf 46] ―――――
44
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
− 要求事項検証
− 要求事項妥当性確認
− 計画に対する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の文書
――――― [JIS X 0166 pdf 47] ―――――
45
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
管理プロセス,並びに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) er. 2では次のように区別されている。ビジネス要求事項は企業のゴー
ル,目標,又はニーズの高レベルの記述である。ビジネス要求事項は,なぜプロジェクトが
開始されるか,何をプロジェクトが達成しようとするのか,及びプロジェクトの成功を測定
するのにどのような測定法を用いるか,を記述する。利害関係者要求事項は,特定の利害関
係者又は利害関係者クラスのニーズの記述である。利害関係者要求事項は,所定の利害関係
者がもっているニーズ又はその利害関係者がいかにソリューションと相互作用するか,を記
述する。利害関係者要求事項はビジネス要求事項と様々なクラスのソリューション要求事項
との橋渡しの役割をする。
――――― [JIS X 0166 pdf 48] ―――――
46
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
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は伝統的に,取得者の要求事項を,システムを仕様化・構築する技術陣に伝
える文書として見られてきた。仕様を構成する要求事項集合及びその表現は二つのグループ間の橋渡しと
しての役割を果たし,取得者及び技術陣の双方によって理解される必要がある。システム開発における最
も困難な作業の一つは,両方のグループ内の全てのサブグループ間で意思疎通することであり,特に一つ
――――― [JIS X 0166 pdf 49] ―――――
47
X 0166 : 2014 (ISO/IEC/IEEE 29148 : 2011)
の文書でこれを行うことはなおさら困難である。この種の意思疎通は一般にそれぞれ異なる形式と言語表
現とを必要とする。
この規格では,ここで示す情報の構造化集合と様々な読者にそれを提示する方法とを区別することを提
案する。SyRSの提示法は,その意図する用途にふさわしい形を取ることが望ましい。その形は,紙の文
書,モデル,プロトタイプ,その他の紙でない文書表現,又はそれらの組合せ,があり得る。これらの表
現は全て,特定の読者のニーズを満たすように,この一つのSyRSから導出することができる。しかし,
これらの提示法のそれぞれが,システム要求情報に共通な一つの源へ追跡可能にするよう注意を払うこと
が望ましい。特定の提示法を選択したことによる曖昧さを解決するために,ここで示す構造化情報集が確
実に唯一の源であり続けるようにすることが望ましい。
この規格は,また,SyRSに含まれるシステム要求事項(システムは何をしなければならないか)と,
作業記述書のような契約文書に含まれるべきプロセス要求事項(いかにシステムを構築するか)とを明確
に区別する。
SyRSは,ニーズ定義・システムレベルの運用概念(OpsCon)・システム要求事項分析タスク,の結果を
提示している。SyRSがそれ自体記述するものは,システムの取得者が彼らのためにシステムが何をして
くれると期待するか,システムが期待する環境,システムの利用プロファイル,性能パラメータ,期待す
る品質・有効性,及び検証アクティビティ,である。
8.3.2 SyRSアウトラインの例
SyRS固有の要求条項を構成するのに,利害関係者の総意としてその構成手法が要求事項の理解を助け
ると合意されるように構成することが望ましい。全てのプロジェクトに最適な単一の構成法はない。SyRS
のアウトライン例を図7に示す。
――――― [JIS X 0166 pdf 50] ―――――
次のページ PDF 51
JIS X 0166:2014の引用国際規格 ISO 一覧
- ISO/IEC/IEEE 29148:2011(IDT)
JIS X 0166:2014の国際規格 ICS 分類一覧
JIS X 0166:2014の関連規格と引用規格一覧
- 規格番号
- 規格名称