アイオス コーポレートブログ
要求定義における要求分析と要求仕様化
皆さん、こんにちは。技術開発グループのn-ozawanです。
10月に入り、気温がぐっと下がりましたね。気温差からくる体調不良にご注意ください。
本題です。
とある部署からの要望通りに開発してリリースしたけど、別の部署から「思っていたのと違う」とクレームを受けた経験はありますか？よくある原因としては、本当に欲しい機能とは何かの検討が不足していた、ステークホルダ間で要求の認識が共有できていなかったなどが考えられます。今回は要求獲得の後工程である、要求分析と要求仕様化についてのお話です。要求を分析、整理して、ステークホルダ間で合意を得て、きちんと文書化します。後のトラブルを回避するにも重要な工程です。
目次
要求定義
要求分析の流れ
要求獲得で得た要求は、まだ十分に整理されていない状態です。まだ要求の抜け漏れも多く、この状態の要求を仕様化するのは難しいので、この要求分析にて整理してあげる必要があります。また整理した要求に対して優先順位をつけ、ステークホルダと合意を形成する工程でもあります。
- 要求の分類
要求獲得で得た要求を、何かしらの基準に従って分類します。要求は、ソフトウェアの動作に関する要求から、システム全体に関わる要求、保守運用や移行の要求などスコープも様々です。それら要求の性質を明らかにして整理します。 - 要求の構造化
個々の要求の依存関係や一貫性を明らかにします。図表などを用いて、要求の漏れや矛盾、曖昧さを検出します。 - 要求の割り当て
要求をアーキテクチャの要素であるコンポーネントに割り当てます。要求を割り当て、分析することにより、実現可能性などのより詳細な要求を分析します。 - 要求の優先順位付け
構造化された、あるいは、割り当てられた要求に対して、優先順位を付けます。開発は限られたリソースで開発する必要がありますので、すべての要求を一度に開発することは困難な場合もあります。 - 要求交渉
要求のスコープや優先順位の妥当性などについて、ステークホルダと合意形成するための交渉を行います。ステークホルダ間で要求が対立するケースもありますので、対立の解消を図ることも必要となります。
要求仕様化の流れ
要求が整理されましたので、要求を仕様化して文書を作成します。「要求」とは、ステークホルダが抱えている課題を解決し、彼らが望んでいる状況を作るために実現すべき事柄です。そして「仕様」とは、要求を実現するためにシステムが満たすべき事柄（性能や特性、動作など）です。この工程では要求から仕様を策定して文書化します。
- ビジネス／プロダクト要求の文書化
ビジネス要求もしくはプロダクト要求を文書化します。ビジネス要求はビジネスに関する要求で、企業や組織のミッション、ゴール、戦略に基づき、ビジネスの持つべき能力を規定します。プロダクト要求は製品として顧客へ提供されるプロダクトに関する要求です。 - システム要求の仕様化
情報システムに関する要求を仕様化して文書化します。情報システムの仕様とは、契約や企画、規制などを満たすために、システムやコンポーネントが満たすべき仕様になります。 - ソフトウェア要求の仕様化
ソフトウェアに関する要求を仕様化して文書化します。
要件定義へ
要求定義により、ステークホルダから要求を獲得もしくは抽出し、仕様化することが出来ました。しかし、これだけではまだ開発することは難しいかと思います。画面構成はどうするのか？帳票のデザインは？バッチ処理などはどう動くのか？などの仕様を詰めていく必要があります。これらの仕様は次工程である要件定義にて明らかにしていくことになります。
おわりに
前回から続き、要求定義の工程をざっくりとお話ししました。言うは易く行うは難し、という言葉がある通り、プロセスを知っただけでは実践は難しいですね。
要求定義では、現状の業務が抱える課題を見抜く観察眼、ステークホルダから要求を聞き出し、時として調整が必要なコミュニケーション能力、膨大な要求を分析し整理するロジカル思考に、開発者を含むステークホルダが読んでも認識齟齬が起きない文書を作成する言語化能力など、幅広いスキルが必要になります。
個人の経験やスキルに依存しないように、色々な手法が提唱されています。個々の手法については、また別の投稿でお話しできればと思います。
ではまた。
