ソフトウェア要求仕様書
ソフトウェアシステムが提供しなければならない機能と能力、その特性、および尊重しなければならない制約条件
様々な条件下におけるシステムの振る舞いを必要十分に表現
性能、セキュリティ、ユーザビリティなどの望ましい品質特性についても
それ以降のプロジェクト計画や設計、コーディングの基盤となるし、システムテストとユーザー文書の基礎でもある
設計や実装の詳細 (既知の制約条件は除く)、プロジェクト計画、テスト計画といった類のものは入れるべきではない
組織によってさまざまな言葉で呼ばれる
UI 設計を含めるかどうか
メリデメがある
メリット : 要求が具体的になる
デメリット : それはソリューションの表現であり、本当の要求ではない
本当に UI 設計を含めたいなら、設計の制約条件としてソフトウェア要求仕様書に入れるべき
アジャイル型プロジェクトにおける要求仕様書
各イテレーションで、プロダクトオーナーやビジネスアナリストの役割の人、開発者、テスト担当者、そしてユーザーとの話し合いの結果をそのイテレーション内のユーザーストーリーの詳細として具体化していく
ストーリーのテストは、そのストーリーを実装するイテレーションで実施され、将来のイテレーションではリグレッションテストを行う ソフトウェア要求の仕様作成に最も適した形式はプロジェクトごとに選択すること
要求開発の全体的な目標を思い出そう : リスクの許容範囲内で、プロダクトの次の一部の構築に進める程度に要求の共通理解を深めること