USDMにおける表現の作法

USDMには文章としての表現方法に関する作法も含まれる

USDMは要求や仕様の表現に重点を罹き、書き手自身に気付きをもたらし、関係者間の共通理解を育むことで、要求仕様のヌケモレを防ぐことを目的とした手法です。そのため、ただ「階層構造で要求と仕様を記述する」、「要求には理由と説明を記載する欄を設ける」といった要求仕様書のフォーマットに関する決まりだけではなく、要求や仕様を読みやすくするにはどのような点に気を付けるべきか、どのような言葉を使って記述すれば気付きが得られやすい要求が書けるかといった、文章に関する作法も多く示されています。

USDMで示されている作法に従うことで、ヌケモレが少なくなったという実感が持て、他人に理解してもらいやすい要求仕様を書くことができるようになります。

USDMにおける表現の作法

ここではUSDMで示されている要求および仕様を表現する作法を4つご紹介します。これらの点を注意して記述するだけでも、ヌケモレに気付きやすく、他人にも理解しやすい要求仕様を書くことができるようになると思いますが、USDMにはこれら以外にも様々な作法がありますので、要求仕様がうまく書けないとお悩みの方は一度書籍等を参考にしてみてはいかがでしょうか。

作法1 : 要求は動詞を意識して書く

USDMの基本的な考え方の一つに『仕様は要求の中の「動詞」および「目的語」に存在する』というものがあります。仕様というのは動詞として要求の中で表現されたシステムの振る舞いをプログラムコ ードに変換するための記述だからです。

もし要求を記述した文章にシステムの振る舞いを動詞によって十分に表現できていないと、その動詞に対応する仕様を導出することができず仕様のヌケモレにつながったり、書かれている仕様に過不足がないかを確認しにくくなってしまいます。

図に示した悪い例では「スヌーズ機能」という単語だけでシステムに求められることを表現しようとしていますが、これだけでは具体的にシステムがどのように振る舞うのかイメージできません。そのため、この記述から仕様を導出しようと思っても何から決めていけば良いのか分かりませんし、もし仕様を決められたとしても求められていることを全て満足できているのかも分かりません。

良い例では図中に青字で示したように動詞を使ってシステムの振る舞いが表現されていますので、「ユーザによるアラーム音の停止判定」、「ユーザの覚醒判定」、「アラーム音の再鳴動」を実現する方法を仕様として決定していけば良いことが分かりますし、もし仕様としてこれらの動詞に結びつかないものが書かれていたら、要求が不足していることに気付くことができます。

作法2: 要求には必ず「本質的な理由」を書く

要求の文章だけでは、その要求が必要である意図が読み手に伝わらない可能性があります。そうすると、要求の書き手と読み手の間に要求に対する認識のずれが生じてしまいます。

要求が必要な理由を記載することでこの認識のずれを解消することができるため、USDMでは要求―つ一つに理由欄を設け、必ず理由を記載することを義務付けています。しかし、理由欄に文章を記載していても、理由として妥当な内容になっていないと認識のずれは解消できません。

図の悪い例では、「自動で追従してほしいため」と、一見すると理由のような内容が記載されています。しかし、この内容は要求に記載されている内容をただ言い換えただけで、要求がなぜ必要かを説明できていません。そのため、もしかしたらこの要求を実現する仕様として「ドライバがアクセルペダルを軽く踏み続けている間は、ドライバに追従の意思 があると判定する」というものを採用してしまうかもしれません。一方良い例では、「ドライバがペダルを操作する負荷を無くす」という本質的な理由が示されているため、その要求によって達成したいことを満たせる仕様を決定することができます。

作法3: 時系列に従って書く

認知科学の研究によると、人間は手続き的な行動や出来事を一連の流れとして構造化し知識として記憶していると言われています。要求仕様も時系列の流れを意識して書くことで、システムの振る舞いがイメージしやすくなりますし、もしシステムの振る舞いにヌケモレがあったとしても気付きやすくなります。USDMでは要求仕様を基本的に時系列の順番で記載するようにします。

図の悪い例では、時系列の順番を無視して書かれているため、2つの要求の間に何か振る舞いをする必要があるのかイメージしにくくなっています。

良い例は、時系列を意識して書かれた要求の例です。時系列を意識することで「アラーム時刻の設定」から「アラームの鳴動」までの間に、システムが「アラーム時刻まで待機」する必要があることに気付きやすくなりますし、さらに「待機中にユーザーによって操作された時に何をすべきか？」というように、関連する要求を連想しやすくなります。

作法4: 仕様は誰もが同じものをイメージできる詳細さで書く

プログラムコ ードの作成、変更方法に関して関係者が同じ認識を共有するには、要求がきちんと書かれているだけでは不十分で、皆が「Specify」できる粒度で仕様が記述されていなければなりません。

下の図は作法3の例の要求ALM.01.03に対する仕様を記載した例になりますが、悪い例ではフレームワークを使うことしか分からず、具体的にどのようなアラーム音を嗚らすのかイメー ジできません。一方、良い例では誰もがアラーム音に対して同じイメージを持てる詳細さで書かれています。

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

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

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

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

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

USDM関連コラム

USDM要求の定義と仕様化に関する記事を見る

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

最新コラム