4章 要求の定義
・要求は、簡潔だがミッション機能に影響するものは明確に定義されていて
また、不必要な制約や設計要求は含まれないものであるべき
・
4.1 システム開発における要求の役割
・システム開発に当たり、目的（objective）に沿って行おうとすると、ユーザーやシステム開発者、部品開発者にいたるまで、
全員が一緒に仕事をする必要が出てくる。要求はそれらの人々の間を受け持つもので、互いによく話し合って決める
・開発者は詳細決定を焦りがちだが、主要求を中軸に置いたしっかりした開発によってはじめて詳細が決まる
・ユーザー側があまり細かい数値的要求を出してもあまりよくない
・そうして決まった要求には「最大化」とか「十分な」といったあいまいな語句は使われるべきではない。
・ゴール（設計目標）には、要求に加えて開発余裕が設けられている。これによって、開発者はある程度自由度を持った開発が可能となる。
・多くの場合、宇宙機には複数のミッションをするため、できるだけ早くすべてのミッション要求が決まってほしい
・ミッションコンセプトの評価の段階では、あまり型式ばっていない形で、メインとなる要求を文書化しておく必要がある
・新技術の開発による問題の解決を求める場合には、リスク分散のため補プランを立てる
・開発費明細書を使ってコストで開発限界を示さないと、コストが大幅に膨れ上がってしまうことがある
4.2 要求分析と性能割り当て
・システムとは衛星自体よりも多くのものを含み、エラーの発生源は非常に多い
・要求は階層構造になっていて、段階が高いところの要求ミスはその下の階層のすべてに響いてしまう
・
・
4.2.1 機能的分析
・Fig4.2のような、機能のブロックダイアグラムを作ることにより全体がわかりやすくなる。
・他にも、機能の相互関係を示した情報も役立つ。
・図や情報を作るだけで満足してはならない。作ること自体は分析ではない。
・
4.2.2 性能割り当て
・分析やシミュレ－ションにより作られた性能割り当て表によりミッションを行う上での課題と向き合えるようになる
・上手にトレードして、それぞれの要素のコストと効果を考慮した、よい配分で機能を各要素に割り当てる
・時間割り当てはシステムドライバーになりやすい。…細かい推算をする必要はない
・初期機能割り当ては反復的性質を持っていて、多くの話し合いの中でコストとリスクを最小化する
・
・timelineの中の責務は4.2.1の機能表に沿って決められる。
・多くの機能-コストトレードオフの点がある。
・目標は性能リスクとコストを均等に分配して要求を満たすことである。
4.2.3 性能割り当ての精錬と決定
・ここで間違うと、後々システム上大きな問題となる
・基本的に反復プロセスである（FIg4-5）
・プロセスを始める前に性能要素と関連した要求事項を、明らかにかつ、ミッションneedまで追跡できるようになっていなければならない
・焦って作られた、あいまいあるいは一貫性のない要求や不正確な情報は誤解や無駄を生みプロジェクトを圧迫する
・設計余裕はコストアップだけでなく、それ自体が問題となることもあるため、その使用には慎重になるべきである
・割り当てサイクルが終わったら試作機を作ってみる。コストや開発中であることを考慮してためらいがちだが、
これによって、設計段階に入ることの合意を得ることができるという大きな意味を持つ
・
4.3 要求明細書
・要求明細書は、開発段階ではただの一定の要求基準だが、システム開発段階になると絶対従わなくてはならないものとなる
・すべての要求を文書化すべき
・要求明細書には一貫性と完全性(すべてのエラー源について取り決めていること)が求められる。
また意味や位置づけがわかりやすいもの(変更があったときそれによって何が変わるのかわかりやすい)がよい。
・機能的ミッション要求 …ユーザーと開発者の分析や話し合いの中でよいものを決める
・システム明細 …システムが何を、どのようにするか
・システム規格 …すべての部品に共通の定義や制約(重さなど)
・システムプラン …
・部分明細 …要求の各要素への配分
・設備明細 …
・インターフェースコントロール …各システム間の同意が示される
・外部インターフェース
・脅威 …システムが完成していない中で予想されうる失敗など
・システム基準を一般化すると、コスト削減につながるが、開発自由度減や部分開発者の目的取り違え等のリスクが生じる。
例外はNASAのstandard busで設計余裕が広く取ってある(いろいろなパターンが用意されている)
4.4 まとめ
・Table4-4
・要求と要求明細書の内容が一致しているとは限らない→途中変更の可能性
刻々と更新し常に最新で正確なものであるようにする必要がある
最後に要求とは
・機能(functiuon) …何をするか
・程度(perdormance requirement) …どれだけするか
・根拠 …誰もが要求の出所が確かめられる
採用されるに十分な合意が得られた理由
からなる
最終更新：2007年04月17日 09:52
