優れたソフトウェア開発に役立つ有益なソフトウェア要件仕様書の作成

2011 年に、長く使用されてきた IEEE 29148:1998 規格とテンプレートが更新および強化され、現在は ISO/IEC/IEEE 29148 となっています。この教育的ガイドでは 5 つのモジュールでベスト プラクティスが規定され、強力な SRS 文書を作成するための情報が記載されています。最初の 3 つの部分には、範囲、適切な参照資料の仕様、設定の定義を定めるためのプロセスを中心とした要素が記述されています。 
4 つ目のモジュールは最長で、ここでは優れた SRS 文書と計画を作成するための性質、優勢な環境、一般的特性を特定する方法を説明しています。 これらの特性を正確に記述できるようになれば、質の高い有益な SRS を作成できるようになります。 
文書は次のようなものである必要があります。

• 正確: ソフトウェアが特定された要件を満たしていることを保証するための分析方法。
• 明確: ソフトウェアの使用目的が一意に解釈でき、共通の言語で伝えられること。
• 完全: 機能、パフォーマンス、設計の制約、属性、または外部インターフェイスのすべての要件が表現されていること。
• 整合性がある: システム要件仕様書など、ほかの文書との整合性が取れていること。 
• 重要性や安定性がランク付けされている: すべての要件が等しく重みづけされているわけではないため、要件を適切にランク付けする方法が採用されている必要がある。
• 検証可能: 曖昧さを防止するために、測定可能な要素と定義された用語を使用すること。
• 修正可能: SRS 文書の組織的構造が適切に定義されており、冗長性が排除され、適応が容易であること。
• 追跡可能: 開発の最初から SRS に基づいてから作成された文書までたどって追跡できること。

Cisco (シスコ) のシニア プロダクト マネージャーのゼーン・ボンド (Zane Bond) 氏によると、「要件は新しい開発プロジェクトの中心となります。実際に必要とされている要件を理解することは、科学でもあり、アートでもあります。開発方法、文化、提供方法に関係なく、明確で理解しやすい要件を記述することは、プロジェクトの成功にとても重要な要素となります。文書が非常にシンプルであれば、それが正しく作成されていることがわかり、要件の記述に今までこれほど多くの顧客とのやりとり、市場分析、設計会議などが必要とされていたことを不思議に思うでしょう。」
ボンド (Bond) 氏は SRS を構成するための次のようなヒントを示しています。 

• 要件がシンプルであるほど、チームに特定の作業方法を強いることが少なくなります。チームが適切に業務を遂行するための十分な環境を確保しながらも、過度に具体的な要件を用いて要求を指示することがないよう、常にバランスを取る必要があります。要件については、次のアントワーヌ・ド・サン＝テグジュペリ (Antoine de Saint-Exupéry) の言葉からの引用が思い浮かびます。「完璧さが達成されるのは、付け加えるものがないときではなく、取り除くものがないときだと思います。」完璧さとは本当は目標ではなく、求めるものを起点とし、不可欠な要素まで絞り込んでいく精神のことです。
• 要件には、誰がなぜこれを必要としているかなど、解決する問題を明確に記述する必要もあります。要件の背景を知ることは、チームがプロセスに関してより良い決定をする上で役立ちます。
• SMART の基準は、主要な要素が欠落していないことや、構築する内容の規模に応じた進行状況を確認するのに役立ちます。ごく小さな要素は最小限の要件によって達成できますが、戦略的な中規模から大規模の要素にはより詳細な要件が必要となります。