要件定義と仕様化が大事な場面／うまく書けない原因

要求の定義と仕様化が特に必要なケース

「要求仕様」の定義は、ソフトウェア開発を行う場合はどのようなケースでも重要な工程ですが、特に必要性の高いケースを３つご紹介します。

まず、開発対象の製品が『派生開発』である場合です。『派生開発』では変更管理のプロセスをうまく回すことが大切ですが、「USDM」を用いて変更要求仕様書を作成することで、変更の実施前に変更内容を明確にでき、間違った方法で変更してしまうことを防げます。

次に、既存ソフトウェアの『リファクタリング』を行う場合です。実施前と後でソフトウェアの振る舞いが変わっていないことを確認するために元の仕様を明文化する際、「USDM」を使用できます。

最後に、『機能安全』に対応する場合です。｢要求仕様｣とシステム要素との対応付けが必要なので、｢要求仕様｣を明確にする必要があります。そこで、「USDM」のフォーマットを拡張し、「要求仕様」とシステム要素の関係を下図のような【トレーサビリティマトリクス】 （要求仕様システム要素トレーサビリティマトリクス：RSSETM）で示すことで、｢要求仕様｣をヌケモレなくシステム要素に割り当てられます。

要求と仕様を要求管理ツールで管理する

『USDM』で整理した要求仕様とその階層関係を要求管理ツールによって管理することもできます。

例えば、「要求仕様書」で定義した要求と仕様に多対多の関係があるなど『USDM』では確認することの難しい複雑な関連が存在する場合には、ツールを利用することによって目的の要求や仕様の関連のみを抽出して関連性を確認することができます。これは、機能安全で要求されるトレーサビリティの確保にも繋がります。

もちろん、使い慣れたExcelで記述された『USDM』の方が閲覧・編集ともに扱いやすく、要求仕様の可読性も高いと思われます。目的に応じて、これらを使い分けることが重要です。

要求仕様がうまく書けない原因

要求や仕様のヌケモレを防ぐためには、トップダウンやボトムアップの手法で抽出し、要求と仕様を 対応付けてまとめあげることが大切であるということは理解できても、実際に要求仕様を書いてみるとヌケモレが少なくなったという実感が持てなかったり、他人に理解してもらえなかったりして困った経験をお持ちの方も多いのではないでしょうか？

多くの開発現場では、要求や仕様は自然言語のみ、もしくは自然言語と図、表、数式の組み合わせで表 現されていると思いますが、筆者は、先ほど挙げたような問題は自然言語によって適切に表現できていないことに原因があるのではないかと考えています。

文章を書くことのメリットの一つに、 自分が書いたものを読み返すことで、自分の考えや理解を検証したり、さらに深く検討したりできるようになることがあります。 しかし、書いた文章を後で読み返し た時に、自分でも内容をなかなか思い出せないような表現で書かれていたら、考えや理解を検証したり、さらに深く検討したりすることは困難です。 また、そのような文章では、他人に理解してもらい、間違いや不足を指摘してもらうことも難しいでしょう。

つまり、自分で書いた要求仕様から関連する別の要求仕様を連想できるようになったり、 自分が把握 した要求や決定した仕様、その意図を他人に伝えたりするには、自然言語で適切に要求や仕様を表現する方法を身に着ける必要があります。

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

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

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

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

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

USDM関連コラム

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

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

最新コラム