USDM 要件の抽出・仕様化・整理 の方法

「要求」を抽出するにはどうしたらよいか？

ボトムアップから「要求」を作り出す

一般的な「要求抽出」のやり方としては、利害関係者へのインタビューや自社製品や競合他社の製品調査などが挙げられます。このようなやり方は"要求の源泉"からたどっていくという意味でトップダウンと呼ばれます。しかし、この方法では"あるべき姿"を一からあぶり出すことができる反面、今ある仕様を網羅することに対しては不安が残ります。

詳細な仕様がすでにある場合には、ボトムアップからスタートする方法も有効です。詳細な仕様からマインドマップなどの情報を整理する手法を使って仕様の背景にある「要求」を抽出していきます。

もし、仕様が書かれていない場合は既存資産から仕様を起こす作業を行います。詳しくは「XDDPによる派生開発」をご参照ください。

抽出した「要求」を基に既存システムや先行開発の担当者にヒアリングし、抽出した「要求」が正しいか、他に隠れた「要求」が無いかを確認します。

｢品質要求｣の重要性

制御仕様や機能仕様には、システムの機能的な動作に関することや設計制約などは記載されていますが、品質に関する要求は記載されていません。しかし、品質要求はその製品に対して人が持つ印象に大きな影響を与えるため、品質要求を把握することはよい製品を開発する上でとても重要なことです。

品質要求には使いやすさなどの製品のユーザに関係する品質と保守性などの開発者に関係する品質があります。

ユーザに関係する品質はセールスからの要望やユーザクレームの情報等があるため重視されやすいのですが、開発者に関係する品質は見落とされがちです。しかし、開発者に関係する品質要求は、開発の効率や工数に大きな影響を与えるので、良い製品を作ることができる組織を維持するためにはこれらの要求も定義しなければなりません。

「要求」を仕様化するにはどうしたらよいか？

「仕様」は開発者への作業指示

「仕様」とは前述の通り「要求」を実現するためのシステムの具体的な動きや制限を表したものです。

これは開発者への「どのように作るか」という作業指示と言い換えることもできるので、開発者が設計・実装するのに十分な詳細度で記載する必要があります。

下図はクルーズコントロールシステムの「要求」と「仕様」の例を表したものです。システムの「目標スロットル開度を算出」という要求の具体的な実現方法として、「目標加減速度と実スロットル開度を用いて2次元テーブルから目標スロットル開度を決定する」という「仕様」を導出しています。

仕様のヌケモレを防ぐには

「要求」を基にして「仕様」を作成しても、ただ思いついた「仕様」を書いていくというやり方では「仕様」のヌケモレを防ぐことはできません。

作成した「仕様」をレビューすることでヌケモレを検出する方法も有効ですが、レビューは多くの工数を必要とする手法であり、レビューだけでヌケモレを防止するのでは効率的とはいえません。

仕様を作成する段階でヌケモレを防止する仕組みを導入すれば、最初から品質の高い「仕様」を作成することができ、レビュー工数も削減することができます。

ヌケモレを防止する仕組みとしては、時系列分割、構成分割、状態分割、共通分割という思考のフレームワークを用いることが有効です。これは、「要求」から「仕様」を導出する過程で、例えば「構成の視点で要求を分割するとどのような仕様が導出できるか？」と考えることで、適切な「仕様」を導出する手法です。

これらのフレームワークは「仕様」を導出する場合だけではなく、上位要求から下位要求を導出する場合にも用いることができます。

さらに、このように導出した仕様からテストシナリオを抽出してテスト仕様書を作成することで、テストの段階でもヌケモレを防止できるというメリットもあります。詳細は「要求仕様書とモデルからテスト仕様書を作成」をご覧ください。

要求と仕様をUSDMで階層化して表現する

「要求」を抽出したり「要求」から「仕様」を導出したりしても、それらを適切にまとめることができなければ、開発に有効な成果物にはなりません。

適切に「要求」と「仕様」をまとめ上げる方法のひとつに『USDM』という方法があります。『USDM』は主に自然言語を用いて「要求」と「仕様」を階層化して整理するのが特徴です。派生開発プロセスの『XDDP』でも変更要求仕様の記述方法として採用されています。

「要求」と「仕様」を対応付けることで、その「仕様」がどの「要求」を実現するためのものなのか、全ての「要求」がヌケモレなく「仕様」まで具現化されているかを確認することができます。

また、『USDM』では機能仕様や制御仕様では扱わない保守性などの品質要求も記述することができるため、開発者への「設計方法に関する作業指示」も要求仕様書に含めることができます。

コンサルタントが教える成功の秘訣

シニアコンサルタント 高橋久憲

私が関与した開発現場では、開発のインプットとして具体的な制御方法について細かく記載したものしかありませんでした。そのため、仕様の妥当性が分からず、今の設計構造にも問題があるのではないかという不安を抱えていました。

そこで、細かい制御仕様を抽象化して｢要求｣を出し、その｢要求｣をブレークダウンする形で仕様を定義しました。『USDM』を使うことで、｢要求｣を満足するのに十分な仕様であることが確認でき、更に、設計構造を見直すこともできるようになりました。

良い｢要求仕様｣を作るためには、｢要求｣と｢仕様｣を切り離す必要があります。そのためには、制御仕様を抽象化して｢要求｣を得ることが必要です。しかし、長年細かな制御仕様に慣れている開発者の方には抽象化が難しいようです。その分野こそエクスモーションの強みです。ぜひ、お任せください。

USDM関連コラム

要件定義・要求仕様（USDM）開発支援に関する記事を見る

他のソリューションを見る

最新コラム