原題：Software Requirements, 3rd edition, Microsoft Press.
著者：Karl E. Wiegers(1953-) ソフトウェア開発。有機化学。
著者：Joy Beatty "ビジネスアナリシス"。数学。計算機科学。
訳者：渡部 洋子［わたなべ・ようこ］ ITコーディネータ。ITコンサルティング。翻訳。
監修：宗 雅彦［そう・まさひこ］ ビジネスアナリシス。
【目次】
目次 [4-16]
はじめに [17-22]
監修者より（宗 雅彦） [23-26]
謝辞 [27-28]
第1部 ソフトウェア要求：だれが、何を、何のためにするのか
第１章 ソフトウェア要求の基礎
1.1 ソフトウェア要求の定義 003
1.1.1 「要求」のいろいろな解釈
1.1.2 要求のレベルと種類
1.1.3 3つのレベルの取り扱い
1.1.4 プロダクト要求 対 プロジェクト要求
1.2 要求開発と要求管理 016
1.2.1 要求開発
1.2.2 要求管理
1.3 あらゆるプロジェクトに要求がある 020
1.4 できの悪い要求が、善良な人々に降りかかるとき 020
1.4.1 ユーザーの参加が不十分
1.4.2 不正確な計画
1.4.3 ユーザー要求のクリープ
1.4.4 あいまいな要求
1.4.5 金メッキ
1.4.6 ステークホルダーの見落とし
1.5 高品質の要求プロセスの利益 024
第２章 顧客の観点から見た要求
2.1 期待のギャップ 029
2.2 顧客はだれ？ 030
2.3 顧客と開発者のパートナーシップ 032
2.3.1 ソフトウェア顧客の要求に関する権利宣言
2.3.2 ソフトウェア顧客の要求に関する責任宣言
2.4 要求を尊重する文化の確立 040
2.5 意思決定者の特定 042
2.6 要求に関する合意の獲得
2.6.1 要求ベースライン
2.6.2 合意が得られないとき、どうするか？
2.6.3 アジャイル型プロジェクトにおける合意の獲得
第３章 要求工学の良いプラクティス
3.1 要求開発プロセスのフレームワーク
3.2 良いプラクティス：要求引き出し
3.3 良いプラクティス：要求分析
3.4 良いプラクティス：要求仕様作成
3.5 良いプラクティス：要求の妥当性確認
3.6 良いプラクティス：要求管理
3.7 良いプラクティス：知識
3.8 良いプラクティス：プロジェクトマネジメント
3.9 新しいプラクティスの開始
第４章 ビジネスアナリスト
4.1 ビジネスアナリストの役割
4.2 ビジネスアナリストの仕事
4.3 アナリストに不可欠なスキル
4.4 アナリストに不可欠な知識
4.5 ビジネスアナリストの育成
4.5.1 元ユーザー
4.5.2 元開発者またはテスト担当者
4.5.3 元（あるいは兼任）プロジェクトマネジャー
4.5.4 対象分野専門家
4.5.5 新人
4.6 アジャイル型プロジェクトにおけるアナリストの役割 084
4.7 協働チームの構築 085
第2部 要求開発
第５章 ビジネス要求の確立
5.1 ビジネス要求の定義
5.1.1 ビジネスに望む利益の特定
5.1.2 プロダクトビジョンとプロジェクトスコープ
5.1.3 ビジネス要求の衝突
5.2 ビジョン／スコープ記述書
5.2.1 (1). ビジネス要求
5.2.2 (2). スコープと制限
5.2.3 (3). ビジネス環境
5.3 スコープ表現技法
5.3.1 コンテキスト図
5.3.2 エコシステムマップ
5.3.3 フィーチャーツリー
5.3.4 イベントリスト
5.4 スコープを明確にしておく
5.4.1 ビジネス目標を使用したスコープの決定
5.4.2 スコープ変更の影響の評価
5.5 アジャイル型プロジェクトにおけるビジョンとスコープ
5.6 ビジネス目標を使用した完了の判断
第６章 ユーザーの意見の掘り出し
6.1 ユーザークラス
6.1.1 ユーザーの分類
6.1.2 ユーザークラスの特定
6.2 ユーザーペルソナ
6.3 ユーザーの代表者とのつながり
6.4 プロダクトチャンピオン
6.4.1 外部のプロダクトチャンピオン
6.4.2 プロダクトチャンピオンの期待
6.4.3 複数のプロダクトチャンピオン
6.4.4 プロダクトチャンピオンのアイデアの提案
6.4.5 プロダクトチャンピオンが陥りやすい落とし穴
6.5 アジャイル型プロジェクトにおけるユーザーの代表者
6.6 要求の衝突の解決
第７章 要求の引き出し
7.1 要求の引き出し技法 139
7.1.1 インタビュー
7.1.2 ワークショップ
7.1.3 フォーカスグループ
7.1.4 観察
7.1.5 アンケート
7.1.6 システムインターフェイス分析
7.1.7 ユーザーインターフェイス分析
7.1.8 文書分析
7.2 プロジェクトの引き出しの計画 149
7.3 引き出しの準備 151
7.4 引き出しアクティビティの実行 153
7.5 引き出し後のフォローアップ 155
7.5.1 注意点の整理と共有
7.5.2 未解決の課題の文書化
7.6 顧客の情報の分類 157
7.7 どうやって終わりを知るのか？ 161
7.8 引き出しに関する注意点 162
7.9 前提とする要求と暗黙の要求 163
7.10 抜けている要求の発見 164
第８章 ユーザー要求の理解
8.1 ユースケースとユーザーストーリー
8.2 ユースケースアプローチ
8.2.1 ユースケースと使用シナリオ
8.2.2 ユースケースの識別
8.2.3 ユースケースの調査
8.2.4 ユースケースの妥当性確認
8.2.5 ユースケースと機能要求
8.2.6 ユースケースの罠の回避
8.3 使用状況中心の要求の利益
第９章 ルールに従った行動
9.1 ビジネスルールの分類
9.1.1 ファクト
9.1.2 制約
9.1.3 アクションイネーブラ
9.1.4 推論
9.1.5 計算
9.1.6 アトミックなビジネスルール
9.2 ビジネスルールの文書化
9.3 ビジネスルールの発見
9.4 ビジネスルールと要求
9.5 すべてのとりまとめ
第10章 要求の文書化
10.1 ソフトウェア要求仕様書
10.1.1 要求のラベル付け
10.1.2 不完全さの取扱い
10.1.3 ユーザーインターフェイスとSRS
10.2 ソフトウェア要求仕様書のテンプレート
10.2.1 (1). はじめに
10.2.2 (2). 概説
10.2.3 (3). システムフィーチャー
10.2.4 (4). データ要求
10.2.5 (5). 外部インターフェイス要求
10.2.6 (6). 品質属性
10.2.7 (7). 国際化要求と現地化要求
10.2.8 (8). その他の要求
10.2.9 付録A：用語集
10.2.10 付録B：分析モデル
10.3 アジャイル型プロジェクトにおける要求仕様書
第11章 優れた要求の記述
11.1 優れた要求の特性
11.1.1 要求記述の特性
11.1.2 要求全体の特性
11.2 要求を書くためのガイドライン
11.2.1 システムまたはユーザーの観点
11.2.2 記述スタイル
11.2.3 詳細度
11.2.4 表現テクニック
11.2.5 あいまいさの回避
11.2.6 不完全さの回避
11.3 要求の例、改善前と改善後
第12章 1枚の絵は1024の語に値する
12.1 要求のモデリング
12.2 顧客の声から要求モデルへ
12.3 適切な表現の選択
12.4 データフローダイアグラム
12.5 スイムレーンダイアグラム
12.6 状態遷移図と状態遷移表
12.7 ダイアログマップ
12.8 デシジョンテーブルとデシジョンツリー
12.9 イベント応答表
12.10 UMLダイアグラムに関して一言
12.11 アジャイル型プロジェクトにおけるモデリング
12.12 最後に一言
第13章 データ要求の仕様作成
13.1 データ間の関係のモデリング
13.2 データディクショナリ
13.3 データ分析
13.4 レポート仕様作成
13.4.1 レポート要求の引き出し
13.4.2 レポート仕様の考慮点
13.4.3 レポート仕様のテンプレート
13.5 ダッシュボードのレポート
第14章 機能の先にあるもの
14.1 ソフトウェア品質属性
14.2 品質属性の調査
14.3 品質属性の定義
14.3.1 外部品質属性
14.3.2 内部品質属性
14.4 Planguageを用いた品質要求の指定
14.5 品質属性のトレードオフ
14.6 品質属性要求の実装
14.7 制約条件
14.8 アジャイル型プロジェクトにおける品質属性への対応
第15章 プロトタイプを使ったリスク低減
15.1 プロトタイプ作成：何を、なぜ作るのか
15.2 モックアップとコンセプトの実証
15.3 使い捨て型プロトタイプと進化型プロトタイプ
15.4 ペーパープロトタイプと電子的プロトタイプ
15.5 プロトタイプの作業
15.6 プロトタイプの評価
15.7 プロトタイプ作成のリスク
15.7.1 プロトタイプのリリースの圧力
15.7.2 細部に気を取られる
15.7.3 非現実的な性能への期待
15.7.4 プロトタイプへの過大な工数の投資
15.8 プロトタイプの成功要因
第16章 まずは重要なことから：要求の優先順位付け
16.1 要求に優先順位を付ける理由
16.2 優先順位付けの現実
16.3 優先順位付けをめぐって人々が演じるゲーム
16.4 優先順位付けの技法
16.4.1 入れるか入れないか
16.4.2 ぺア比較とランク付け
16.4.3 3段階の尺度
16.4.4 MoSCoW
16.4.5 100ドル
16.5 価値とコストとリスクに基づく優先順位付け
第17章 要求の妥当性確認
17.1 妥当性確認と検証
17.2 要求のレビュー
17.2.1 インスペクションプロセス
17.2.2 欠陥チェックリスト
17.2.3 要求レビューのヒント
17.2.4 要求レビューの課題
17.3 要求プロトタイプの作成
17.4 要求のテスト
17.5 受け入れ基準を用いた要求の妥当性確認
17.5.1 受け入れ基準
17.5.2 受け入れテスト
第18章 要求の再利用
18.1 要求を再利用する理由
18.2 要求の再利用のさまざまな側面
18.2.1 再利用の範囲
18.2.2 修正の範囲
18.2.3 再利用の仕組み
18.3 再利用する要求情報の種類
18.4 一般的な再利用のシナリオ
18.4.1 ソフトウェアのプロダクトライン
18.4.2 リエンジニアリングシステムとリプレースシステム
18.4.3 その他再利用の可能性のある機会
18.5 要求パターン
18.6 再利用促進のためのツール
18.7 要求を再利用可能にする
18.8 要求の再利用の障壁と成功要因
18.8.1 再利用の障壁
18.8.2 再利用の成功要因
第19章 要求開発に続くもの
19.1 要求の工数見積もり
19.2 要求からプロジェクト計画へ
19.2.1 要求からのプロジェクト規模と工数の見積もり
19.2.2 要求とスケジュール作成
19.3 要求から設計とコードへ
19.3.1 アーキテクチャと割り振り
19.3.2 ソフトウェア設計
19.3.3 ユーザーインターフェイス設計
19.4 要求からテストへ
19.5 要求から成功へ
第3部 特定の種類のプロジェクト向けの要求
第20章 アジャイル型プロジェクト
20.1 ウォーターフォール型の限界
20.2 アジャイル開発アプローチ
20.3 要求に対するアジャイル型アプローチの基本的な観点
20.3.1 顧客の参加
20.3.2 詳細の文書化
20.3.3 バックログと優先順位付け
20.3.4 タイミング
20.3.5 エピックとユーザーストーリーとフィーチャー、やれやれ！
20.3.6 変更を予期する
20.4 アジャイル型プロジェクトに合わせて要求プラクティスを調整する
20.5 アジャイル型への移行：今度は何？
第21章 機能拡張およびリプレース型プロジェクト
21.1 予想される困難
21.2 既存システムが存在する場合の要求技法
21.3 ビジネス目標による優先順位付け
21.3.1 ギャップに注意する
21.3.2 性能レベルの維持
21.4 古い要求が存在しない場合
21.4.1 どの要求の仕様を作成するべきか？
21.4.2 既存システムの要求を見つける方法
21.5 新システムの採用の推進
21.6 イテレーションにできるか？
第22章 パッケージソリューション型プロジェクト
22.1 パッケージソリューションを選定するための要求
22.1.1 ユーザー要求の作成
22.1.2 ビジネスルールの検討
22.1.3 データのニーズの特定
22.1.4 品質要求の定義
22.1.5 ソリューションの評価
22.2 パッケージソリューションを導入するための要求
22.2.1 設定要求
22.2.2 統合要求
22.2.3 拡張要求
22.2.4 データ要求
22.2.5 ビジネスプロセスの変更
22.3 パッケージソリューションに関する一般的な問題
第23章 アウトソース型プロジェクト
23.1 要求の適切なレベルの詳細度
23.2 発注者とサプライヤの相互関係
23.3 変更管理
23.4 受け入れ基準
第24章 ビジネスプロセス自動化プロジェクト
24.1 ビジネスプロセスのモデリング
24.1.1 現行プロセスを使用した要求の引き出し
24.1.2 最初にあるべきプロセスの設計
24.2 ビジネスパフォーマンスメトリクスのモデリング
24.3 ビジネスプロセス自動化プロジェクトに適したプラクティス
第25章 ビジネスアナリティクスプロジェクト
25.1 ビジネスアナリティクスプロジェクトの概要
25.2 ビジネスアナリティクスプロジェクトのための要求開発
25.2.1 決定による作業の優先順位付け
25.2.2 情報の利用方法の定義
25.2.3 データのニーズの指定
25.2.4 データ変換分析の定義
25.3 分析の進化的な性質
第26章 組込みおよびその他のリアルタイムシステムのプロジェクト
26.1 システム要求とアーキテクチャと割り振り
26.2 リアルタイムシステムのモデリング
26.2.1 コンテキスト図
26.2.2 状態遷移図
26.2.3 イベント応答表
26.2.4 アーキテクチャ図
26.2.5 プロトタイプ作成
26.3 インターフェイス
26.4 タイミング要求
26.5 組込みシステムの品質属性
26.6 組込みシステムの問題
第4部 要求管理
第27章 要求管理のプラクティス
27.1 要求管理プロセス
27.2 要求のベースライン
27.3 要求のバージョン管理
27.4 要求の属性
27.5 要求のステータスの追跡
27.6 要求に関する課題の解決
27.7 要求に必要な作業工数の測定
27.8 アジャイル型プロジェクトにおけるにおける要求管理
27.9 要求管理が必要な理由
第28章 変更発生
28.1 変更管理が必要な理由
28.2 スコープクリープの管理
28.3 変更管理のポリシー
28.4 変更管理プロセスの基本コンセプト
28.5 変更管理プロセスの詳細
28.5.1 (1). 目的とスコープ
28.5.2 (2). 役割と責任
28.5.3 (3). 変更依頼のステータス
28.5.4 (4). 開始基準
28.5.5 (5). タスク
28.5.6 (6). 終了基準
28.5.7 (7). 変更管理の状況に関するレポート
28.5.8 付録A. それぞれの変更依頼で保管する属性
28.6 変更管理委員会
28.6.1 CCBの構成
28.6.2 CCB憲章
28.6.3 再検討の約束
28.7 変更管理ツール
28.8 変更アクティビティの測定
28.9 変更の影響分析
28.9.1 影響分析の手順
28.9.2 影響分析のテンプレート
28.10 アジャイル型プロジェクトにおける変更管理
第29章 要求連鎖のつながり
29.1 要求の追跡
29.2 要求追跡の動機
29.3 要求のトレーサビリティマトリクス
29.4 要求追跡ツール
29.5 要求追跡の手順
29.6 要求追跡は可能か、そして必要か？
第30章 要求工学のためのツール
30.1 要求開発ツール
30.1.1 引き出しツール
30.1.2 プロトタイプ作成ツール
30.1.3 モデリングツール
30.2 要求管理ツール
30.2.1 要求管理ツールを使用する利点
30.2.2 要求管理ツールの能力
30.3 要求ツールの選定と導入
30.3.1 ツールの選定
30.3.2 ツールの設定とプロセス
30.3.3 ユーザーの適応の促進
第5部 要求工学の実行
第31章 要求プロセスの改善
31.1 要求と他のプロジェクトプロセスとの関係
31.2 要求とさまざまなステークホルダーグループ
31.3 変革に対するコミットメントの取得
31.4 ソフトウェアプロセス改善の基本原則
31.5 根本原因分析
31.6 プロセス改善のサイクル
31.6.1 現在のプラクティスを評価する
31.6.2 改善行動を計画する
31.6.3 プロセスを構築し、試行し、展開する
31.6.4 結果を評価する
31.7 要求工学プロセス資産
31.7.1 要求開発のプロセス資産
31.7.2 要求管理のプロセス資産
31.8 まだここにいるのか？
31.9 要求プロセス改善のロードマップの作成
第32章 ソフトウェア要求とリスクマネジメント
32.1 ソフトウェアリスクマネジメントの基礎
32.1.1 リスクマネジメントの要素
32.1.2 プロジェクトリスクの記録
32.1.3 リスクマネジメント計画の立案
32.2 要求に関連するリスク
32.2.1 要求の引き出し
32.2.2 要求の分析
32.2.3 要求の仕様作成
32.2.4 要求の妥当性確認
32.2.5 要求の管理
32.3 リスクマネジメントは友である
あとがき [631-632]
付録Ａ 現在の要求プラクティスのセルフアセスメント
付録Ｂ 要求のトラブルシューティングのガイド
B.1 要求の問題の一般的な兆候
B.2 ソリューションの実行に対する一般的な障壁
B.3 要求のトラブルシューティングのガイド
B.3.1 プロセスに関する課題
B.3.2 プロダクトに関する課題
B.3.3 計画に関する課題
B.3.4 コミュニケーションに関する課題
B.3.5 引き出しに関する課題
B.3.6 分析に関する課題
B.3.7 仕様作成に関する課題
B.3.8 妥当性確認に関する課題
B.3.9 要求管理に関する課題
B.3.10 変更管理に関する課題
付録Ｃ サンプル要求文書
C.1 ビジョン／スコープ記述書
C.2 ユースケース
C.3 ソフトウェア要求仕様書
C.4 ビジネスルール
用語集 [681-692]
参考文献 [693-708]
著者について [709]
【メモランダム】
ここでは、目次の見やすさを優先して、表記をごく一部変更している。
本書（日本語版）では欧米式の構成表記がなされている。原書ではこの類の数字は付されていないので、翻訳者・編集部によるものだろう。ただしそのままでは視認性が悪いので、多少の工夫はできたと思う。
［変更前］
28.5 変更管理プロセスの詳細
28.5.1 1. 目的とスコープ
28.5.2 2. 役割と責任
28.5.3 3. 変更依頼のステータス
28.5.4 4. 開始基準
28.5.5 5. タスク
28.5.6 6. 終了基準
28.5.7 7. 変更管理の状況に関するレポート
［変更後］
28.5 変更管理プロセスの詳細
28.5.1 (1). 目的とスコープ
28.5.2 (2). 役割と責任
28.5.3 (3). 変更依頼のステータス
28.5.4 (4). 開始基準
28.5.5 (5). タスク
28.5.6 (6). 終了基準
28.5.7 (7). 変更管理の状況に関するレポート
【抜き書き】
・「はじめに」から、想定読者と構成。黒字強調は引用者による。
対象とする読者
ソフトウェアを含むシステムの要求を定義したり、理解したりすることに関与する人ならだれでも、本書から有益な情報を見つけることができる。まず対象とする読者は、〔……〕開発プロジェクトで、ビジネスアナリストあるいは要求エンジニアとして働く人たちである。2番目に対象とする読者は、アーキテクト、設計者、開発者、テスト担当者、その他の技術チームのメンバーで、ユーザーが期待するものを理解して満たさなければならない人たち、そして有効な要求の作成とレビューに参加しなければならない人たちである。マーケティング担当者やプロダクトマネジャーも、〔……〕こういったプラクティスに価値を見出すだろう。またプロジェクトマネジャーは、プロジェクトの要求アクティビティを計画し追跡して、要求の変更を取り扱う方法を学ぶことができる。そして、自分たちのビジネスと機能と品質のニーズを満たすプロダクトの定義に参加するステークホルダーが、もう1つの読者グループを形成する。エンドユーザーや顧客がソフトウェアプロダクトを購入または契約するとき、そして他の多数のステークホルダーが要求プロセスと自分たちがそこで果たす役割の重要性を理解するとき、本書がきっと役に立つ。本書の構成
本書は5部構成になっている。「第1部 ソフトウェア要求：だれが、何を、何のためにするのか」は、いくつかの定義から始まる。あなたが会社で技術の側にいるなら、「第2章 顧客の観点から見た要求」の顧客と開発者のパートナーシップに関する部分を、主要顧客と一緒に読んでみてほしい。「第3章 要求工学の良いプラクティス」では、要求開発と要求管理に関する「良いプラクティス」を何十個か紹介し、さらに要求開発プロセスの全体像を示す。「第4章 ビジネスアナリスト」では、ビジネスアナリストの役割（多くの別名を持つ役割）をテーマにしている。
「第2部 要求開発」は、プロジェクトのビジネス要求を定義する技法から始まる。第2部の各章では、適切な顧客代表者を見つけて、彼らから要求を引き出し、ユーザー要求、ビジネスルール、機能要求、データ要求、そして非機能要求を文書化する方法を扱う。「第12章 1枚の絵は1024の語に値する」では、要求をさまざまな観点から表現することにより、自然言語の文章を補足するビジュアルモデルを多数紹介し、「第15章 プロトタイプを使ったリスク低減」では、プロトタイプを使ってリスクを減らす方法について説明する。第2部の他の章では、要求に優先順位を付け、妥当性を確認し、再利用する方法を紹介している。そして第2部の最後で、要求が他の観点のプロジェクト作業にどのような影響を及ぼすかを検討する。
この版で追加した「第3部 特定の種類のプロジェクト向けの要求」では、さまざまな種類のプロジェクトに最も効果的な要求アプローチを推奨する。ここでは、あらゆる種類のプロダクトを開発するアジャイル型プロジェクト、機能拡張およびリプレース型プロジェクト、パッケージソリューションを組み込むプロジェクト、アウトソース型プロジェクト、ビジネスプロセス自動化プロジェクト、ビジネスアナリティクスプロジェクト、そして組込みおよびその他のリアルタイムシステムのプロジェクトを取り上げる。
「第4部 要求管理」は、要求の変更を取り扱う技法に重点を置いて、要求管理の原則とプラクティスをテーマとして取り上げている。「第29章 要求連鎖のつながり」では、要求の追跡により、個々の要求を、その発生源と下流の開発成果物の両方につながりを持たせる方法について説明する。第4部は、チームが要求開発と要求管理の両方を実施するやり方を改善できる市販のツールについて触れて終わる。
本書の最後である「第5部 要求工学の実行」は、あなたが学んだ考えを実践に移すのを助けるものである。「第31章 要求プロセスの改善」は、要求に関する新しい技法を、あなたのグループの開発プロセスに組み込む際に役立つ。そして「第32章 ソフトウェア要求とリスクマネジメント」では、要求に関連する一般的なプロジェクトリスクについて説明する。さらに「付録A 現在の要求プラクティスのセルフアセスメント」を使用すると、改善の対象にふさわしい領域の選択に役立つ。他の2つの付録で、要求のトラブルシューティングのガイドと、サンプル要求文書をいくつか示しているので、学んだことすべてをつなぎ合わせて見ることができる。
・「第1章 ソフトウェア要求の基礎」の冒頭から。
1.1.1 「要求」のいろいろな解釈
コンピュータープログラミングというものが発明されて以来何十年も経つというのに、ソフトウェア実務家はいまだ「要求」の正確な定義をめぐって論争を続けている。本書では、この論争には踏み込まずに、実務に役立つと思う定義を示すにとどめたい。
コンサルタントのBrian Lawrenceは、要求とは「設計の選択肢を規定するもの」と提案している（Lawrence, Brian. 1997. "Requirements Happens..." American Programmer 10(4): 3-9 ）。多くの種類の情報がこの分類にあてはまるので、一般的な定義としてこれは悪くない。結局のところ、何のために要求を作成するかというと、最終的に顧客のニーズを満たせるような適切な設計を選択するためなのだ。別の定義として「ステークホルダーに価値を提供するためにプロダクトが持たなければならない特性」がある。これも悪くないがあまり正確ではない。今気に入っている定義は、Ian SommervilleとPete Sawyerの次の定義である（Sommerville, Ian and Pete Sawyer. 1997. Requirements Engineering: A Good Practice Guide. John Wiley & Sons Ltd. 邦訳『要求定義工学プラクティスガイド』2000年、富野壽 監訳、共立出版）。
「要求とは、何を実装しなければならないかという仕様である。また、システムがどう振る舞わなければならないかという記述であり、システム特性や属性の記述でもある。システムの開発プロセスに対する制約条件のこともある。」 この定義は、まとめて「要求」と呼ばれるさまざまな種類の情報に当てはまる。要求は、ユーザーの視点（システムの外から見た振る舞い）と、開発者の視点（システム内部の特性）の両方を含む。特定の条件下におけるシステムの振る舞いも含むし、意図した使用者がシステムを適切に、場合によっては楽しく使用できるようにする特性も含むのである。
