ソフトウェア要求 第 3 版
著者 : Karl Wiegers
Amazon : https://amzn.to/39XXLYE
関連 : 要求エンジニアリング
内容メモ・感想
感想 
要求開発のバイブルらしい (監訳者より)
めちゃくちゃ学びがあって良い
アジャイル開発についても言及されていてよい
日本語だと 「要求」 と 「要件」 を使い分けたりするが、英語だと全部 requirements らしい
本書の訳も 「要求」 で統一されている
『ユースケース駆動開発実践ガイド』 を読んでおくとユースケース周りの理解がはかどりそう
ユースケース駆動開発だと、まずは機能要求があって、それを満たすようなユースケースを書くことでシステムの振る舞いを顧客と合意する、というような逆の流れっぽい？
ソフトウェア要求 (1 部)
ソフトウェア要求の基礎 (1 章)
ソフトウェア世界の問題の多くは、人がプロダクトの要求を知って、文書化して合意に至り、修正する、という方法に欠陥があることに起因
要求アクティビティの段階で入り込む誤り : ソフトウェアプロダクトの欠陥のうち 40 ～ 50 % を占める (『成功する要求仕様 失敗する要求仕様』 より)
ソフトウェア要求の定義
プロジェクトのステークホルダーが要求とは何かという共通認識を持っているという仮定をしてはならない (前もって定義を明確にしておくこと)
「要求」 には様々な定義があるので、統一した形容で要求を修飾すべし
本書ではプロジェクト要求については詳細は取り扱わないが、プロジェクト要求が重要でないというわけではない
ソフトウェアシステムを作るうえで最も難しいのは、何を作るべきかを正確に決めること
設計や実装を始める前に、全ての機能要求を明確化できない or しなくてよい場合 → イテレーティブ or インクリメンタル型のアプローチで要求の一部を実装してから顧客のフィードバックを受けて次のサイクルへ
これこそがアジャイル型開発の本質
要求にかける時間を惜しむのではなく、要求に十分に注意を払わない場合に発生する浪費を惜しむべき
手戻りには、開発費の 30 ～ 50 % かかることが多い
要求の誤りが手戻りコストの 70 ～ 80 % を占める
一般的な要求リスク (一部のみ)
不正確な計画 : 要求に基づいてプロジェクトの工数を所要時間を見積もるために、要求の規模と開発チームの生産性を知る必要
要求に基づく見積りの詳細 : 『要求開発と要求管理』 を参照
ユーザー要求のクリープ : 開発中に要求が膨らむ
まずはベースラインを明確に記述すること
プロジェクトマネジャーはスケジュールにコンティンジェンシーバッファを組み込む
金メッキ : 開発者が、要求仕様にない機能を 「ユーザーが喜ぶだろう」 と思って追加する場合に発生
ステークホルダーの見落とし : プロジェクトの存在を知りもしないステークホルダーも存在する (システムに関連する標準を義務付ける政府機関など)
顧客の観点から見た要求 (2 章)
顧客と開発者の関係という、重大なテーマ
ビジネス目標を話せる人がシステムのユーザーとは限らない (ユーザー要求を話せない) し、ユーザーは機能要求を全て明確にできるわけでもない
顧客、特にユーザーが要求開発に参加する重要性
プロジェクト初期に、要求に関する意思決定者が誰で、どのように意思決定するのかを判断すること
グループで意思決定する場合は、意思決定リーダーを決め、決定に至る方法を決める決定ルールを選定する必要
要求について顧客と開発者が合意に達することが両者のパートナーシップの中核
要求合意時のベースライン (その時点でのスナップショット) を確立するという考え方が重要
アジャイル型環境でも、サインオフの考え方は有効に働く (変化という考え方が存在するのは、何か基準がある場合だけ)
要求工学の良いプラクティス (3 章)
50 を超える要求工学の良いプラクティスを 7 つのカテゴリ (引き出し、分析、仕様作成、妥当性確認、要求管理、知識、プロジェクトマネジメント) に分類した表が書かれている
要求開発はイテレーティブに行われる (段階的詳細化)
>
プロジェクトも組織文化も多様なので要求開発プロセスに決まったアプローチはないが、次のフレームワークをベースにすると良い
>
要求工学の良いプラクティスについての詳細
ビジネスアナリスト (4 章)
ビジネスアナリストについて
要求開発 (2 部)
ビジネス要求の確立 (5 章)
ビジネス要求の定義
ビジョン / スコープ記述書について
スコープ表現技法として、使えるツールがいくつか紹介されている
スコープが変更された場合、計画を変更する必要がある
最初のスケジュールとリソースにコンティンジェンシーバッファが組み込まれているなら良いが……
アジャイル型プロジェクトでは、正式なビジョン / スコープ記述書は作成されないが、その内容は必要ではある
多くのアジャイル型プロジェクトでは、計画イテレーション (イテレーションゼロ) にて包括的なプロダクトビジョンとプロジェクトの他のビジネス要求を定義する
あらゆるプロジェクトでビジネス目標を明確にすることに集中しよう
ユーザーの意見の掘り出し (6 章)
顧客が期待するものと開発者が開発するものの不一致を避ける最善の方法は、顧客が参加すること
一種類のユーザーだけを想定するのではなく、複数のユーザークラスを想定すること
プロジェクト初期に、ユーザークラスを特定して、それぞれの特徴を明らかにすること
特定には、さまざまな分析モデル (例 : コンテキスト図の外部エンティティはユーザークラスの候補) や会社の組織図などが役立つ
それにより、重要なユーザークラスのそれぞれの代表者から要求を引き出せる (拡張集約法が役立つ)
例 : 開発チームのメンバーは構築中のシステムのエンドユーザーではないが、内部品質に関して要求を持つ
ユーザークラスの特徴や責任、物理的所在地は、ソフトウェア要求仕様書かプロジェクトの要求計画書に文書化する
ペルソナを通して考えると、要求についての思考プロセスが具体的になる
プロダクトチャンピオンにプロジェクトに参加してもらうアプローチ
アジャイル型プロジェクトにおけるユーザーの代表者
アジャイル型プロジェクトの 「顧客と開発者の密接な連携」 は健全な思想ではあるが、1 人の人が全てのユーザークラスのニーズを理解して説明できるようになるというのは (小規模プロジェクトでなければ) 現実的ではない
プロダクトチャンピオンのような代表者構造を使用して、ユーザーの適切な参加を保証する方法が良いのではないか
要求の引き出し (7 章)
要求の引き出し技法
ファシリテーション付きのアクティビティ : ステークホルダーとやり取りしながら要求を引き出す
インタビュー、ワークショップ、フォーカスグループ、観察、アンケート
独立型のアクティビティ : 自分だけで作業して情報を見つける
ユーザーが表した要求を補足するもので、ユーザー自身では気づかない可能性がある機能を明らかにする
システムインターフェイス分析、ユーザーインターフェイス分析、文書分析
引き出しプロセス全体 (引き出しアクティビティの計画からセッションのアウトプットの整理まで)
アナリストであるからには、顧客が示す要求の表面だけでなく裏側を探って、真のニーズを理解せねばならない
「何が欲しいのですか」 ではなく 「何をする必要がありますか」 の方がはるかに良い質問
「なぜ」 を何回か聞くことで、ソリューションの提示ではなく解決すべき問題をしっかり理解できる
「他に聞かれるだろうと思っていたことはありますか」 と聞いて、考えていなかった問題を明らかにする努力をする
顧客から聞いた要求情報をカテゴリ分類して適切に文書化して使用できるように
引き出しの参加者が 「これがビジネス要求です」 などと教えてくれることはないので、アナリストが判断する
9 つに分類 : ビジネス要求、ユーザー要求、ビジネスルール、機能要求、品質属性、外部インターフェイス要求、制約条件、データ要求、ソリューションのアイデア
要求の引き出しの完了を示すわかりやすい指標はない
引き出しに関する注意
要求の引き出しでは what に集中すべきだが、分析と設計の間はグレーゾーン
how を仮定するとユーザーが必要としているものを理解しやすい (ただし、それはあくまで仮のものだということをユーザーに理解してもらう必要がある)
非明示的な要求
ステークホルダーの期待と異なるものを生み出してしまう原因になる
前提とする要求 : 明示的に表現されないが、人が期待する要求
暗黙の要求 : 他の要求のために必要だが、明示されていない要求
「何を前提にしていますか？」 と聞いて、隠れている考えを明らかにする
抜けている要求の発見
概要レベルの要求を詳細レベルに分解する : 概要レベルのあいまいな要求は読み手の解釈次第なので、期待と作るものの間にギャップがでる
境界値をチェック
一般的な機能のチェックリストを作る (例 : エラーロギング、バックアップとリストア、アクセス制御セキュリティ、報告書作成、印刷、プレビュー機能、ユーザーの好みの構成、など)
ユーザー要求の理解 (8 章)
ユーザー要求を調べる際によく使われる技法
ユースケース : システムと外部のアクターとの間の、アクターにとって価値のある結果をもたらすことのできる、一連の相互作用を記述するもの
ユーザーストーリー : 新しい能力を望む人 (通常はシステムのユーザーや顧客) の観点からフィーチャーを簡潔に記述したもの
簡潔な記述でユーザーニーズを伝え、詳細を具体化するための話し合いの出発点となる
ユーザーストーリーのユーザークラス (人間でなくてもよい) はユースケースの主アクターに相当
ユースケースやユーザーストーリーは、プロダクト中心の観点ではなくユーザーニーズを捉えるのに役立つ
一方で、ユーザーとシステムの相互作用以外の部分に複雑性がある場合にはあまり有効ではない
多くの組み込みシステムやほかのリアルタイムシステムの仕様作成にも向いていない
ユーザーの目的は 1 つでも、システムの方が複雑な場合がある (多くのボタン操作やセンサーによる制御など)
→ 外部イベントとシステムの応答を一覧する技法が使える
ユースケースとユーザーストーリーの出発点は似ているが、向かう先は違う
>
ユーザーストーリーアプローチでは、一般的に機能要求仕様は作成せず、受け入れテストの集合を作る
開発者は、受け入れテストに通るように実装を行う
ユースケースアプローチでは、ユーザーストーリーでは提供できない構造と背景を提供する
アジャイルの世界ではユースケース全体が網羅するスコープと同じものをユーザーストーリーが網羅することはある
が、それ以外の場合は、ユーザーストーリーは単一のユースケースシナリオか代替フローを表すだけ
ユースケースからソフトウェア機能要求を導き出したプロセスの例
>
実装やユーザーインターフェイスの詳細とは独立した概念テストを早期に作成すると、チームが共通理解を得るのに役立つ
要求を複数の方法 (機能要求の一覧や対応するテスト、分析モデルなど) で表現するのは良い考え
要求が一つの方法でしか表現されてないと、比較して誤りを見つけたりができない
機能要求 : システムの振る舞いの具体的な一部
多くの機能要求はユースケースシナリオからそのまま導出できる
ユースケースに含まれない機能要求もある → ビジネスアナリストが導き出して開発者に伝える必要
また、複数のユースケースに含まれる同じ機能要求もある
ユースケースだけを記述する方法もあれば、ユースケースと機能要求をそれぞれ文書化する方法などもある
ユースケースの罠
ユースケースが多すぎる : 適切な抽象度になっていないのでは？
複雑なユースケース : 代替フローにすべきものを通常フローに入れるなどしているのでは？
設計を含んでいる : ユースケースは、ユーザーがシステムの支援で何を達成するかを表現するもの
データ定義を含んでいる : データ定義はプロジェクト単位のドキュメント等に入れる
ユーザーが理解できないユースケース : ユースケースはユーザーの観点のもの
ユースケースの技術的な利益
そのドメインで重要なオブジェクトとその相互の責務を明らかにする
時間経過によるビジネスプロセスの変化を、機能要求や設計、コードに伝えやすい
ルールに従った行動 (9 章)
ビジネスルール自体はビジネスに属するものでソフトウェア要求ではないが、要求の発生源になりえる
政府の法規制がビジネス目標につながることもある (ビジネス要求) し、プライバシーポリシーがユーザー要求につながることもあるし、その他ビジネスルールが機能要求や品質属性に関係しうる
ビジネスアナリストは、プロジェクトに影響をおよぼすルールについて、誰に聞けばいいか知っている必要がある
ビジネスルールを文書化したら、ソフトウェアに実装すべきルールはどれかを決める
要求の文書化 (10 章)
優れた要求の記述 (11 章)
要求開発に続くもの (19 章)
特定の種類のプロジェクト向けの要求 (3 部)
アジャイル型プロジェクト (20 章)
組込みおよびその他のリアルタイムシステムのxxx (26 章)
要求管理 (4 部)
要求管理のプラクティス (28 章)
要求連鎖のつながり (29 章)
要求の追跡
一例
>
追跡する動機は？
要求の抜けの発見や不要な要求の発見などに繋がる
変更の影響を把握しやすくする
保守しやすくする
など
要求プロセスの改善 (31 章)
プロセス改善を成功させるためには計画が必要
ロードマップの作成など
一例
>
右側の箱が望むビジネス目標で、丸がマイルストーン、他の箱が大きな改善アクティビティ