ソフトウェア要件仕様

ソフトウェア要件仕様書（SRS ）とは、開発予定の ソフトウェアシステムの記述です。これは、ビジネス要件仕様書（CONOPS）をモデルとしています。ソフトウェア要件仕様書には、機能要件と非機能要件が明記されており、完璧なユーザーインタラクションを実現するためにソフトウェアがユーザーに提供しなければならない一連のユースケースが含まれる場合もあります。

ソフトウェア要件仕様書は、顧客と請負業者またはサプライヤーの間で、ソフトウェア製品がどのように機能すべきかについての合意の基礎を確立します（市場主導型プロジェクトでは、これらの役割はマーケティング部門と開発部門が担う場合があります）。ソフトウェア要件仕様書は、より具体的なシステム設計段階の前に要件を厳密に評価するものであり、その目的は後々の再設計を減らすことです。また、製品のコスト、リスク、スケジュールを見積もるための現実的な基礎を提供する必要があります。^{[ 1 ]}適切に使用すれば、ソフトウェア要件仕様書はソフトウェアプロジェクトの失敗を防ぐのに役立ちます。ソフトウェア要件仕様書には、プロジェクト開発に必要な十分要件と必要要件が記載されています。^{[ 2 ]}要件を導き出すには、開発者は開発中の製品を明確かつ徹底的に理解する必要があります。これは、ソフトウェア開発プロセス全体を通してプロジェクトチームと顧客との詳細かつ継続的なコミュニケーションを通じて達成されます。

SRSは契約の成果物データ項目記述^{[ 3 ]}の1つである場合もあれば、組織が義務付けた他の形式のコンテンツを含む場合もある。

通常、SRSはテクニカルライター、システムアーキテクト、またはソフトウェアプログラマーによって作成されます。^{[ 4 ]}

ソフトウェア要件仕様は、1975年には既にソフトウェア開発プロセスで使用されていました。^{[ 5 ]}

ソフトウェア要求仕様の目的と内容は、1983 年にIEEEによって正式に定められました。この規格は 1984 年に IEEE-830-1984 として発行され、ANSIによって承認されました。^{[ 6 ]} 1993 年と 1998 年に改訂され、国際規格に置き換えられました。^{[ 7 ] [ 8 ]} この規格は、優れた SRS の基準と内容に関する推奨事項を提供することを目的としていました。要求エンジニアリングにおけるプロトタイピングの利点を認識し、構造の例といくつかのバリアントを提案しました。

ISO /IEC/IEEE 29148規格「システムおよびソフトウェアエンジニアリング - ライフサイクルプロセス - 要求エンジニアリング」は、2011年にIEEE 830に取って代わりました。[ ^{8 ]現在} の改訂版は2018年のものです。この規格は、要求品質基準、要求管理プロセス、ビジネス要求仕様（BRS）、およびステークホルダー要求仕様（StRS）も対象としているため、より広範です。^{[ 9 ]} 若干変更された例の構造を提案しています。

SRSの構成例は次のとおりです。^{[ 10 ]}

1. 目的
   1. 定義
   2. 背景
   3. システム概要
   4. 参考文献
2. 全体的な説明
   1. 製品の観点から
      1. システムインターフェース
      2. ユーザーインターフェース
      3. ハードウェアインターフェース
      4. ソフトウェアインターフェース
      5. 通信インターフェース
      6. メモリ制約
   2. 設計上の制約
      1. 業務
      2. 敷地改修要件
   3. 製品機能
   4. ユーザーの特性
   5. 制約、前提条件、および依存関係
3. 具体的な要件
   1. 外部インターフェースの要件
   2. 性能要件
   3. 論理データベースの要件
   4. ソフトウェアシステムの属性
      1. 信頼性
      2. 可用性
      3. 安全
      4. 保守性
      5. 携帯性
   5. 機能要件
      1. 機能的分割
      2. 機能説明
      3. 制御の説明
   6. 環境特性
      1. ハードウェア
      2. 周辺機器
      3. ユーザー
   7. 他の

ソフトウェアを要件に適合させるために計画されている検証アプローチについても、例えば特定の要件に関するセクションを反映した構造を持つ特定のセクションで取り上げることをお勧めします。^{[ 9 ]}

要求事項は、システム設計とは無関係に、何が必要かということのみを厳密に規定するべきであり、ソフトウェアがどのようにそれを行うべきかを規定するべきではない。^{[ 9 ]}したがって、個々の要求事項は、必要かつ適切で、曖昧さのないものでなければならない。さらに、要求事項のセットは、完全かつ一貫性があり、実現可能で、理解しやすいものでなければならない。

コードの臭いという概念に続いて、要求仕様における問題を説明するために要求の臭いという概念が提案されました。要求仕様では、要求が必ずしも間違っているわけではありませんが、問題となる可能性があります。^{[ 11 ]}要求の臭いの例としては、主観的な表現、曖昧な副詞や形容詞、最上級、否定的な表現などがあります。^{[ 11 ]}比較表現、検証不可能な用語、全体性を意味する用語も避けるべきです。^{[ 9 ]}

• システム要件仕様
• 作戦構想
• 要求工学
• ソフトウェアエンジニアリング知識体系（SWEBOK）
• 設計仕様
• 仕様（技術規格）
• 形式仕様
• 抽象型

• IEEEソフトウェア要件仕様ガイド。1984年。doi : 10.1109 / IEEESTD.1984.119205。ISBN 978-0-7381-4418-4。
• IEEEソフトウェア要件仕様に関する推奨実施基準。 1994年。doi : 10.1109 /IEEESTD.1994.121431。ISBN 978-0-7381-4723-9。
• IEEEソフトウェア要件仕様に関する推奨実施基準。1998年。doi : 10.1109 /IEEESTD.1998.88286。ISBN 978-0-7381-0332-7. S2CID 8674647 . 
• システムおよびソフトウェアエンジニアリング -- ライフサイクルプロセス -- 要求工学。ISO/ IEC /IEEE 29148:2018(E)。2018年。pp. 1–94。doi : 10.1109 /IEEESTD.2011.6146379。ISBN  978-0-7381-6591-2。(「この規格は、IEEE 830-1998、IEEE 1233-1998、IEEE 1362-1998 を置き換えるものです -")
• レフィングウェル、ディーン；ウィドリグ、ドン（2003）。ソフトウェア要件の管理：ユースケースアプローチ（第2 版）。アディソン・ウェスリー。ISBN 978-0321122476。
• ゴッテスディナー、エレン（2009）。『ソフトウェア要件の記憶を呼び起こす手引き：ビジネスチームと技術チームが要件を開発・管理するのに役立つデスクトップガイド』アディソン・ウェスリー。ISBN 978-1576811146。
• ウィーガース、カール；ビーティ、ジョイ（2013）。ソフトウェア要件、第3版。マイクロソフトプレス。ISBN 9780735679665。
• 「IEEE SRS テンプレート - rick4470/IEEE-SRS-Tempate」 . GitHub . 2017年12月27日取得.
• コスト削減につながるソフトウェア要件仕様書の書き方とは？

^{[ 1 ]}