麻豆原创 コーポレートブログ
要求定义における要求分析と要求仕様化
皆さん、こんにちは。技术开発グループの苍-辞锄补飞补苍です。
10月に入り、気温がぐっと下がりましたね。気温差からくる体调不良にご注意ください。
本题です。
とある部署からの要望通りに开発してリリースしたけど、别の部署から「思っていたのと违う」とクレームを受けた経験はありますか？よくある原因としては、本当に欲しい机能とは何かの検讨が不足していた、ステークホルダ间で要求の认识が共有できていなかったなどが考えられます。今回は要求获得の后工程である、要求分析と要求仕様化についてのお话です。要求を分析、整理して、ステークホルダ间で合意を得て、きちんと文书化します。后のトラブルを回避するにも重要な工程です。
目次
要求定义
要求分析の流れ
要求获得で得た要求は、まだ十分に整理されていない状态です。まだ要求の抜け漏れも多く、この状态の要求を仕様化するのは难しいので、この要求分析にて整理してあげる必要があります。また整理した要求に対して优先顺位をつけ、ステークホルダと合意を形成する工程でもあります。
- 要求の分类
要求获得で得た要求を、何かしらの基準に従って分类します。要求は、ソフトウェアの动作に関する要求から、システム全体に関わる要求、保守运用や移行の要求などスコープも様々です。それら要求の性质を明らかにして整理します。 - 要求の构造化
个々の要求の依存関係や一贯性を明らかにします。図表などを用いて、要求の漏れや矛盾、曖昧さを検出します。 - 要求の割り当て
要求をアーキテクチャの要素であるコンポーネントに割り当てます。要求を割り当て、分析することにより、実现可能性などのより详细な要求を分析します。 - 要求の优先顺位付け
构造化された、あるいは、割り当てられた要求に対して、优先顺位を付けます。开発は限られたリソースで开発する必要がありますので、すべての要求を一度に开発することは困难な场合もあります。 - 要求交渉
要求のスコープや优先顺位の妥当性などについて、ステークホルダと合意形成するための交渉を行います。ステークホルダ间で要求が対立するケースもありますので、対立の解消を図ることも必要となります。
要求仕様化の流れ
要求が整理されましたので、要求を仕様化して文书を作成します。「要求」とは、ステークホルダが抱えている课题を解决し、彼らが望んでいる状况を作るために実现すべき事柄です。そして「仕様」とは、要求を実现するためにシステムが満たすべき事柄（性能や特性、动作など）です。この工程では要求から仕様を策定して文书化します。
- ビジネス／プロダクト要求の文书化
ビジネス要求もしくはプロダクト要求を文书化します。ビジネス要求はビジネスに関する要求で、公司や组织のミッション、ゴール、戦略に基づき、ビジネスの持つべき能力を规定します。プロダクト要求は製品として顾客へ提供されるプロダクトに関する要求です。 - システム要求の仕様化
情报システムに関する要求を仕様化して文书化します。情报システムの仕様とは、契约や企画、规制などを満たすために、システムやコンポーネントが満たすべき仕様になります。 - ソフトウェア要求の仕様化
ソフトウェアに関する要求を仕様化して文书化します。
要件定义へ
要求定义により、ステークホルダから要求を獲得もしくは抽出し、仕様化することが出来ました。しかし、これだけではまだ開発することは難しいかと思います。画面構成はどうするのか？帳票のデザインは？バッチ処理などはどう動くのか？などの仕様を詰めていく必要があります。これらの仕様は次工程である要件定義にて明らかにしていくことになります。
おわりに
前回から続き、要求定义の工程をざっくりとお話ししました。言うは易く行うは難し、という言葉がある通り、プロセスを知っただけでは実践は難しいですね。
要求定义では、現状の業務が抱える課題を見抜く観察眼、ステークホルダから要求を聞き出し、時として調整が必要なコミュニケーション能力、膨大な要求を分析し整理するロジカル思考に、開発者を含むステークホルダが読んでも認識齟齬が起きない文書を作成する言語化能力など、幅広いスキルが必要になります。
个人の経験やスキルに依存しないように、色々な手法が提唱されています。个々の手法については、また别の投稿でお话しできればと思います。
ではまた。
