要求管理
要求管理（ようきゅうかんり、英: Requirements management）は、プロジェクトの要求を管理し、それら要求とプロジェクトの計画および成果物との不整合を特定することを目的とする。要求管理には変更管理と要求トレーサビリティが含まれる[1]。
概要 編集
要求管理では、バランス、コミュニケーション、調整が重要である。ある種の要求が他の要求を無効化してしまうのを防ぐには、開発メンバー間の一定のコミュニケーションが必須である。例えば、内部アプリケーションのソフトウェア開発において、ユーザーの要求を無視させるような強い内部的ニーズがあったり、ユースケース作成時にそのような要求がユーザーの要求であるかのように思い込むことがある。
トレーサビリティ 編集
要求トレーサビリティとは、要求のライフサイクルの文書化に関わる。それぞれの要求の起点にさかのぼることは可能なはずであり、従ってトレーザビリティを達成するために、それぞれの要求になされた変更が文書化される必要がある。実装された機能が配備されて使われるようになった後でも、要求の使用状況はトレース可能であるべきである[2]。
要求は、その製品を注文した実業家、マーケティングの管理職、実際のユーザーなど、様々なソースからもたらされる。これらの人々は製品に対してそれぞれ異なる要求を持っている。要求トレーサビリティを使えば、実装された機能が元々どの個人またはグループの要求に由来するものかを辿ることができる。例えばこれは、個々の要求が特定のユーザーにとってどれだけ価値があるのかの判断に使われ、開発中の要求の優先順位付けに使うことができる。また、実際に配備してみてユーザーに使われない機能があることが判ったとき、それがそもそも何故要求されたのかを調べるのにも使われる。
工程 編集
開発工程の各段階で、鍵となる要求管理活動と手法が存在する。ここでは、工程を「調査、実現可能性検討、設計、構築と試験、リリース」の5つに分ける。
調査 編集
調査においては、ユーザー、注文主、開発チームの三者から要求を集める。それぞれに対して、似たような質問をする。目標は何か、制約条件は何か、現在のツールやプロセスはどうなっているか、などである。このようにして集めた要求をよく理解しないと、うまく機能する要求仕様を作成できない。
ただし、チームがどんなに努力しても、この段階で要求仕様を完全に定義することはできない。当初引き出せなかった要求があったり、内外の要因によってプロジェクトが影響され、要求の一部は変更を余儀なくされる。従って、チームの各員は柔軟性が成功の秘訣であることを肝に銘じなければならない。
調査工程での成果物は、チーム全員が合意した要求仕様書である。後の工程で、プロジェクトの方向性がぶれたり不必要に変更されるのを防ぐために、この文書が重要となる。開発が進むと、新たな機能によって新たな可能性が見えてくる。そこで要求仕様書が本来のビジョンにチームを固定し、制御された範囲内での議論を可能にする。
多くの組織は要求管理に文書しか使っていないが、中にはソフトウェアツールで管理している組織もある。その種のツールはデータベース上で要求を管理し、一般にトレーサビリティ機能（例えば、要求を親子関係のリンクで連結したり、テストケースと要求をリンクする）、ベースライン生成、バージョン制御、変更管理を自動化する。通常、このようなツールにはエクスポート機能があり、データベース上の要求を要求仕様書の形式で出力し、一般的な文書アプリケーションで使える形にできる。
実現可能性検討 編集
実現可能性検討の工程では、費用の見積もりが行われる。まず、現状のコストと新システム導入後の予測コストを比較する。この際に次のような質問がなされる。「データ入力ミスの現在のコストは何か?」あるいは「現状のインタフェースでオペレータがミスをしたことで無駄になるコストは?」実際、これらの問題が組織の財務部門に注目されたときに、新しいツールの必要性が認められることが多い。
コストには「どの部門がこの予算を引き受けるのか?」、「この新製品の市場で予測される収益率は?」、「より使いやすいシステムを作る場合、トレーニングとサポートのコスト低減によって内部収益率はどう変化するか?」といった問題も含まれる。
技術的コストにはソフトウェア開発コストとハードウェアのコストが関連する。「そのツールの作成に適した人々がいるか?」「新たなソフトウェアを動作させるのに新たなハードウェアは必要か?」この後者の質問は重要である。一般に新たなソフトウェアはユーザーが負担していた処理を実行することでプロセスを効率化する。従って、現状のハードウェアがその新たな負荷を処理できるだけの性能を持っているかどうかを調査する必要がある。
これらの質問は要求管理の基本的な点を明らかにする。システムは人間とツールから成るが、そのツールがコンピュータまたはコンピュータ上の新たなアプリケーションの場合、このような質問で要求を理解することは特に重要である。人間の精神は不十分なデータから傾向を解釈して並列処理することを得意とする。コンピュータは逐次的かつ正確な処理を得意とする。要求管理は、人間とコンピュータにそれぞれ得意とする作業が割り当てられることを保証する役割も持っている。例えば、「人間に同じデータを2カ所以上で入力させない。システムが必要に応じて同じデータを入力すべきところを自動的に埋める」などである。
この工程の成果物は、プロジェクトの予算と日程である。
設計 編集
コストの見積もりが正確で、得られる効果が大きければ、プロジェクトは設計工程へと進む。設計では、設計の成果物と要求仕様書の内容との整合を管理することが要求管理の主な仕事となる。
ここでも柔軟性が重要である。設計段階での柔軟な対応で成功を収めた逸話がある。フォードの自動車設計者らは1980年代初期に今後10年の間にガソリン価格がガロン当たり3.18ドルになると予測していた。しかし、トーラスの設計段階でのガソリン価格はガロン当たり1.5ドル前後で推移していた。そこで設計チームは、ガソリンが当初の予測ほど高騰しないと判断し、トーラスをより大型で高出力の自動車に設計しなおすことにした。結果としてトラースが発売されると居住性や快適性が評価され、爆発的な売り上げを記録した。
しかし多くの場合、このような当初の要求仕様からの大幅な逸脱はうまくいかない。従って要求仕様書は設計変更の判断を行う際の重要な情報源となる。
構築と試験 編集
構築と試験では、要求管理の主な活動は、日程遅延と予算超過がないかを監視し、実際に作成されたツールが要求された仕様を満たしているかを確認することである。そのため、プロトタイピングや反復的試験が行われる。ソフトウェアの場合、インタフェース部分だけを先にプロトタイピングして、想定されるユーザーに使ってもらい確認するといった手法が使われる。試験の結果の記録は設計チームに渡され、実際の開発に利用される。これによって時間が節約され、その後の作業がやりやすくなる。
リリース 編集
リリースしたからといって、要求管理の仕事が終わるわけではない。リリース後は製品の利用状況データを集め、次の版や新製品の調査工程の入力とする。
ツール 編集
要求管理ツールにはデスクトップ型とウェブベース型がある。
INCOSEは、要求管理ツールも含めたプロジェクトツールのデータベースを管理している[3]。
モデリング言語 編集
関連項目 編集
脚注 編集
- ^ Pressman, Scott. Software Engineering: A Practitioner's Approach. Sixth Edition, International, p 180. McGraw-Hill Education 2005
- ^ Gotel, O., Finkelstein, A. An Analysis of the Requirements Traceability Problem Proc. of First International Conference on Requirements Engineering, 1994, pages 94-101
- ^ Requirements management tools
参考文献 編集
- CMMI Product Team (2006年8月) (PDF). CMMI for Development, Version 1.2. Technical Report CMU/SEI-2006-TR-008. Software Engineering Institute 2008年1月22日閲覧。.
- Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007, ISBN 354047689X