「すし屋の注文」とは訳が違う、要求仕様書の書き方：上を目指すエンジニアのための要求エンジニアリング入門（4）（2/3 ページ）

仕様化すべき要求を受け取る

　要求者あるいは要求アナリストは、これから開発あるいは調達する何かを「要求仕様」として明示しなければならない。このため、前工程から「仕様化すべき要求」を受け取っていなければならない。しかし、「すしを食べたい」という「仕様化すべき要求」を仕様化することは、行きつけのすし屋で「中トロ」と注文するほど簡単ではない。1つの注文にも要求者がたくさんいるのである。要求データベースに要求を登録したステークホルダーのことを思い出そう。要求はさまざま。要求源もさまざま。個々の要求を1つだけ取り上げても要求仕様にはならないのである。だから、仕様化するには多数の要求を整理することが欠かせない。これは、前工程「要求分析」の仕事であった。

第2回 すべての始まり＝「要求」を抽出する - ＠IT自分戦略研究所

　しかし、整理してもまだ問題がある。要求は、いまだ誰も実現したことのない不確かな技術を必要とする場合がある。あるいは、要求自体が大量にあり、しかも相互に関連していて、その中に矛盾を抱えたまま仕様化しなければならない、といった難題を含んでいることもある。

　手慣れた読者は要求分析プロセスを通じて、少なくとも要求を階層別に、すなわち「ビジネス要求 ⊃ システム要求 ⊃ ハードウェア要求／ソフトウェア要求」に分類していることであろう。さらに、ソフトウェア要求を「機能要求」「非機能要求」「制約条件」に詳細に分類していることであろう（図2）。

図2　ソフトウェア要求の分類

要求仕様の標準

　ここで、要求仕様の標準について触れておこう。「ソフトウェアエンジニアリング基礎知識体系（SWEBOK）」の要求仕様の項には、

• システム要求定義文書（ユーザー要求文書または操作概念）（ユーザー要求文書または操作概念）
• ソフトウェア要求仕様（SRS：Software Requirements Specification）（SRS：Software Requirements Specification）

について記載があるが、内容は極めて簡素である。「システム要求 ⊃ ソフトウェア要求」に見合ったシステム要求定義文書とSRSを作成しなければならない。

　SWEBOKはSRSを書く目的として、

• ソフトウェアプロダクトがすること／しないことをはっきりさせる
• 設計に入る前に、要求を査定し、要求定義フェイズへの手戻り回数を軽減する
• コスト、スケジュール、リスクを見積もるためのベースとする

ことなどを挙げている。

　このように、SWEBOKは、「SRSとはいったいどのようなものか」にはまったく触れていない。仕方がないので、IEEEの標準（IEEE Standard 830-1998）に登場を願うこととしよう。

　図3は、IEEE発行の『Software Requirements Engineering』（第2版）p.207〜244に記載されている「IEEE Recommended Practice for Software Requirements Specifications」（IEEE Standard 830-1998）のSRSテンプレートの目次部分のみを和訳し、転記したものである。

　これはSRSを理解するうえで最も標準となるものである。参考にすることをお勧めする。

　これを標準的な書き方とすれば、SRSはテンプレートの目次構成に沿って書き表すことが望ましい。SRSの表し方について、例えばカール E. ウィーガーズの著書『ソフトウェア要求』（第2版の訳書）の第10章には、このテンプレートに沿った詳細な説明が記載されている。また、図解を用いた表記を勧めている。今日、図による表記はおおむねUML（Unified Modeling Language）によっている。