generated at
ソフトウェア要求

高位のシステム要求を、ドメインという見方から定義
さらにそこから、ソフトウェア要求の仕様化へ

要求の正確な定義はまだ論争中
筆者の気に入っている定義
> 要求とは、何を実装しなければならないかという仕様である。 また、システムがどう振る舞わなければならないかという記述であり、システム特性や属性の記述でもある。 システムの開発プロセスに対する制約条件のこともある。
要求は、ユーザーの視点 (システムの外から見た振る舞い) と、開発者の視点 (システム内部の特性) の両方を含む
要求情報の種類
用語定義
ビジネス要求プロダクトを構築する組織または購入する顧客のビジネス目標 (概要レベル)
ビジネスルールビジネスの特定の側面を定義、または制約する方針やガイドラインなど
制約条件設計や構築のために開発者が利用できる選択肢に制限を課すもの
外部インターフェイス要求ソフトウェアシステムと、利用者や他のソフトウェアシステム、ハードウェア装置とのつながり
フィーチャーユーザーに価値を提供するシステム能力 (一連の機能要求で表される)
機能要求特定の条件下でシステムが示す振る舞いを記述したもの
非機能要求システムが示すべき特性や特質、またはシステムが順守すべき制約条件の記述
品質属性プロダクトのサービスやパフォーマンスの特性を記述したもの (非機能要求の一種)
システム要求複数のサブシステムを含むプロダクトの最も概要レベルの要求
ユーザー要求特定のクラスのユーザーが、システムや望むプロダクト属性を用いて実行する目標・仕事
>
この図では一方向の流れだが、実際にはビジネス要求とユーザー要求と機能要求の間で循環や繰り返しがある
社内部門の場合と商用プロダクトの会社の場合で、ビジネス要求から機能要求までどう流れるか
社内部門 : ビジネスニーズ → (マネジャー) → ビジネス要求 → (ビジネスアナリスト・ユーザー代表者) → ユーザー要求 → (ビジネスアナリスト) → 機能要求 → (開発者・テスト担当者)
商用プロダクトの会社 : 市場ニーズ・プロダクトコンセプト → (マーケティング部門) → ビジネス要求 → (プロダクトマネジャー) → ユーザー要求 → (ビジネスアナリスト / プロダクトマネジャー) → 機能要求 → (開発者・テスト担当者)
ビジョン / スコープ記述書ユーザー要求文書ソフトウェア要求仕様書という 3 種類のドキュメントを統合してもよいが、それぞれ異なる目的と対象読者に向けられていることは忘れないように