源流フェーズを例とした概要件定義例

　ここでは、前章で述べた、より大きな課題認識から概要件定義としてブレークダウンする方法を例示する。なお、スペースの都合上、源流フェーズのみを例として記述する。

　源流フェーズは、商品／製番に供する汎用的で堅牢なベース（マスター）製品を開発・試作・検証・確立するための、高度で創造的な業務プロセスで構成される。一般的には「企画部門が主管する企画仕様について、機構、エレキ、制御など要素の源流部門がその基本仕様案を作成。それら仕様を擦り合せてアーキテクチャを体系化し、要素ごとに具体的な設計／試作・検証を行い、総合的な評価・検証（機能検証、原価検証、生産検証）などを数回繰り返して収斂・確立させるプロセス」と表現できる。

　しかし実際には、新しい技術の確立や、そのための新しい知識の収集・習得、また過去のノウハウ・知見などの参照・理解・反映など、非構造的な業務の集まりといった方が当たっている。このように複雑で構造化しにくいプロセスも、図のように情報の生成・管理・参照に関する行為として捉えると、業務要件定義が整理しやすくなる。

［1］「源流の情報生成層」としての概要件定義
（a）業務情報（仕様書、設計仕様書、計算資料、通知書、推進日程など）の生成・編集ができること
（b）業務手順情報（構想手順、設計手順、シミュレーション手順、考え方手順、ノウハウ集など）の生成・編集ができること
（c）それらに関連した資料（各種ドキュメント、通知など）の生成・編集ができること（QMS規格に準じた幾つかの仕組みの管理も、この要件となる）
（d）製品情報（設計モデル、図面、属性情報、シミュレーションモデル・解析情報など）の生成・編集ができること（CAD、CAEなど設計ツールの要件となる）
（e）製品定義情報の生成・編集ができること（部品表、部品属性など）

［2］「源流の情報管理層」としての概要件定義
（f）上記（a）（b）（c）を統合的に管理できること
　例えば、企画の仕様から要素ごとに展開される多数の仕様の定義、版管理と、それら仕様間の整合性の確保、成果物管理、変更管理など（中日程レベルでの進捗管理、課題管理、プロセス管理）
（g）上記（d）の管理ができること
　例えば、設計データ（モデル、図面、部品表）の版管理
（h）上記（e）の管理ができること 　例えば、製品定義情報のBOM管理、構成管理、変更管理など（大日程レベルの進捗管理、課題管理、プロセス管理）

［3］「源流の情報参照層」としての概要件定義
　代表例としては、品質や信頼性をつかさどる要件として下記が可能なこと。
（i）商品の稼働現場からの稼働状況の収集・蓄積・分析ができること（M2M）
（j）修理センター、コールセンターからの品質情報、VOC（Voice of Customer）などのフィードバック機能があること
（k）市場からの自社製品機種の品質情報（トラブルの兆候、クレームなど）、VOCの収集・蓄積・分析ができること
（l）市場における競合他社の評判情報収集・分析ができること
（m）社内の文書、実験資料、過去トラブル集、ノウハウ集、設計手順書などから、必要な情報（知識、ノウハウ、知見など）が検索可能なこと

　上記［1］［2］［3］を、商品化フェーズについても同様に定義する（ここでは省略する）。