en : software requirements specification

略 : SRS

プロダクト要求を入れる

ソフトウェアシステムが提供しなければならない機能と能力、その特性、および尊重しなければならない制約条件

様々な条件下におけるシステムの振る舞いを必要十分に表現

性能、セキュリティ、ユーザビリティなどの望ましい品質特性についても

それ以降のプロジェクト計画や設計、コーディングの基盤となるし、システムテストとユーザー文書の基礎でもある

設計や実装の詳細 (既知の制約条件は除く)、プロジェクト計画、テスト計画といった類のものは入れるべきではない

組織によってさまざまな言葉で呼ばれる

ビジネス要求記述書、機能仕様書、プロダクト仕様書、システム仕様書、単に要求文書など

ソフトウェア要求仕様書が業界標準用語 (ISO/IEC/IEEE 29148:2011)

UI 設計を含めるかどうか

メリデメがある

メリット : 要求が具体的になる

デメリット : それはソリューションの表現であり、本当の要求ではない

本当に UI 設計を含めたいなら、設計の制約条件としてソフトウェア要求仕様書に入れるべき

多くの場合、要求の引き出しに、ユーザーストーリーを利用する

各イテレーションで、プロダクトオーナーやビジネスアナリストの役割の人、開発者、テスト担当者、そしてユーザーとの話し合いの結果をそのイテレーション内のユーザーストーリーの詳細として具体化していく

この詳細が、SRS における機能要求に相当する

詳細は、ユーザー受け入れテストの形で表現されることが多い

ストーリーのテストは、そのストーリーを実装するイテレーションで実施され、将来のイテレーションではリグレッションテストを行う

テストは自動化して、リグレッションテストを迅速かつ完全に実施できるようにしなければならない

ソフトウェア要求の仕様作成に最も適した形式はプロジェクトごとに選択すること

要求開発の全体的な目標を思い出そう : リスクの許容範囲内で、プロダクトの次の一部の構築に進める程度に要求の共通理解を深めること