2.8 ソフトウェア要求

概要と動機

ソフトウェア要求とは、システムがステークホルダーにとって受け入れ可能であるために、提供し、満たし、あるいは備えなければならない能力や条件の記述です。要求工学、つまりそれらの記述を引き出し、分析し、規定し、検証し、管理する規律ある仕事は、価値の連鎖のまさに最初に位置します。アーキテクチャからコード、受け入れテストまで、下流のすべては、要求を満たそうとする試みです。だから要求が間違っていたり、不完全だったり、曖昧だったりすると、間違ったものを正しく作るために費やされた労力はすべて純粋な無駄になり、それは最も遅く発見されるため、存在する中で最も高価な無駄です。ソフトウェアエンジニアリング知識体系(SWEBOK)のソフトウェア要求の知識領域は、これを、本当の仕事への事務的な前置きではなく、本物のエンジニアリングの規律として扱っています。

大きなチームにとって、要求は、多くの人が一つの一貫したシステムを作れるようにする、共有された理解です。一人の開発者なら意図を頭の中に持てますが、多くのチームにわたる何百人もの人々にはできません。要求は、能力を必要とする人々とそれを作る人々の間の契約となり、仕事をチーム間で分割する基礎となり、何かが「完了」したと判断する物差しになります。それらは直接、問題と機会が表面化するディスカバリー(11.1章)、ユーザーのニーズを理解するUXの基礎(5.1章)、インターフェースの義務が固まるAPIとインターフェース設計(2.3章)、非機能要求が構造を駆動するアーキテクチャと品質特性(3.1章)、そしてそれらを中心にスコープ、コスト、スケジュールが計画されるプロジェクト管理(10.6章)につながります。

企業や政府の設定では、要求は法的、契約的、安全上の重みを持ちます。規制されたシステムは、義務づけられたあらゆる義務(アクセシビリティ、プライバシー、セキュリティ、記録の保持、財務統制)が要求として捉えられ、実装され、証拠とともに検証されていることを示さなければなりません。政府の調達はしばしば要求仕様書を中心に組まれ、支払い、監査、認証はすべて、各要求がそれを満たしたという証拠までたどれることに依存します。ここでは、要求は良い実践以上のものです。説明責任の背骨です。

主要原則

要求は、解決策ではなくニーズや制約を表現します。何を、なぜを述べるのであって、どうやってではありません。
すべての要求は、必要で、曖昧さがなく、検証可能で、実現可能で、追跡可能でなければなりません。
要求は、孤立して発明されるのではなく、ステークホルダーとともに発見され、交渉されます。
非機能要求と制約は、機能と同じくらいアーキテクチャを形づくります。
要求は進化します。凍結したり無視したりせず、変更を意図して管理します。
ニーズから要求、設計、テスト、証拠までのトレーサビリティは、説明責任の結合組織です。
適切な形式性の水準は、習慣ではなく、リスク、規模、規制の文脈に依存します。

推奨事項

要求を明確に定義し、分類する

カテゴリを意図して名指しします。機能要求は、システムが何をしなければならないかを述べます。提供する振る舞い、変換、サービス。非機能要求(品質特性)は、それらをどれだけうまく行わなければならないかを述べます。性能、可用性、セキュリティ、ユーザビリティ、アクセシビリティ、保守性など。これらはアーキテクチャ(3.1章)と密に結びつきます。制約は、解決策に対する交渉不可能な境界です。義務づけられた技術、標準、予算、法的ルール、既存システムとのインターフェース。そして、ビジネス要求(組織がなぜシステムを望むか)、ユーザー要求(ユーザーが何を達成する必要があるか)、システム要求(したがってソフトウェアが何をしなければならないか)を分けます。これらの水準を混ぜ合わせると、すぐにスコープの混乱が続きます。

仮定ではなく本物の情報源から引き出す

引き出し(エリシテーション)は能動的な発見です。インタビュー、ワークショップ、観察、プロトタイプ、既存のシステムや文書の分析を通じて、ステークホルダーから要求を引き出します。見落としやすいものを含め、関連するすべてのステークホルダーを探し出してください。オペレーター、監査人、サポート担当者、システムの影響を受けるが直接は使わない人々。引き出しをディスカバリーのパイプライン(11.1章)とUXリサーチ(5.1章)に結びつけ、述べられた望みが根底にあるニーズまでたどれるようにします。各要求の出所と根拠を記録します。なぜ要求が存在するかを知ることこそが、後でそれを安全に変更できるようにするからです。

分析し、交渉し、優先順位を付ける

引き出された生のニーズは、衝突し、重複し、実現可能な量を上回ります。分析は、それらを調整する方法です。要求を分類し、衝突を見つけ、実現可能性とリスクを量り、ステークホルダーと優先順位を交渉します。優先順位は、must/should/couldの区別や、価値対コストのランキングなどで、公然と付けて、時間が足りなくなったときに、適切なスコープを切れるようにします。そしてモデルが明確さを加える所では、要求をモデル化します。プロセスフロー、状態図、データモデル、インターフェース定義は、散文が隠すギャップを表面化します。

適切な形式性の水準で規定する

要求を、リスクと読み手に合う形で書き留めます。高保証の政府のシステムは、IEEE 29148のような標準に沿って構造化された正式な仕様を正当化するかもしれず、動きの速い製品チームは、バックログの受け入れ基準付きのユーザーストーリーとして要求を捉えるかもしれません。どちらにせよ、各要求は原子的で、検証可能で、「速い」「使いやすい」「など」のようなつかみどころのない言葉を含まないものでなければなりません。受け入れ基準を付け、要求を書く同じ瞬間に、その検証方法を定義します。そして、要求がメール、チケット、スライドに散らばるのを許さず、権威ある情報源を一つ保ちます。

作る前に検証する

検証は、規定した要求が正しく、一貫していることを確認します。ステークホルダーとレビューし、シナリオをたどり、できる所ではプロトタイプを使って抽象的な記述を具体的にします。検証は、後のどんな修正よりも安上がりです。要求のレビューで捉えられた欠陥は、同じ欠陥が本番で捉えられるコストのほんの一部です。

要求を管理し、トレーサビリティを維持する

要求は変わります。あなたの仕事は、その変更に抵抗することではなく、管理することです。変更のプロセスを設けます。変更を受け入れる前に、提案された各変更の影響、コスト、下流への効果を量ります。要求を合意された時点でベースライン化し、バージョン管理します。各要求を設計、コード、テストへ前方に、そしてそれが生まれたニーズへ後方にリンクする双方向のトレーサビリティを保ちます。トレーサビリティは、大きなチームが頼りにする二つの問いに答えます。このニーズが変わったら何に影響するか。この納品された機能を正当化したのはどのニーズか。規制された文脈では、単に主張するのではなくコンプライアンスを示せるよう、トレースを受け入れの証拠(テスト結果、監査記録、承認)まで広げます。

アジャイルと計画駆動の文脈に適応する

計画駆動で規制されたプログラムでは、正式な変更管理のもと、要求をかなり早くに規定し、ベースライン化します。アジャイルの文脈では、要求は優先順位付けされ進化するバックログとして存在し、実装の直前に詳細化され、動くソフトウェアを通じて継続的に検証されます。基礎にある活動はどちらでも同じで、異なるのはタイミング、形式性、成果物だけです。大きな組織はしばしば両者を混ぜます。安定した高保証の義務は正式に規定しトレースし、製品の振る舞いは反復的に詳細化します。バランスは、イデオロギーではなくリスクで選んでください。

トレードオフ: 長所と短所

アプローチ	最適な用途	長所	短所
正式な前もっての仕様	高保証、規制、固定スコープの契約	強いトレーサビリティ。明確な受け入れの基礎。監査可能	変更が遅い。学ぶ前に過剰に規定するリスク
アジャイルのバックログ	関与するステークホルダーがいる進化する製品	速いフィードバック。学びに適応。作られないスコープでの無駄が少ない	長期的なトレーサビリティが弱い。監査と契約が難しい
ハイブリッド(正式な制約 + アジャイルな振る舞い)	義務が混在する企業	重要な所には厳密さ、他には柔軟性	どの部分がどちらかの判断が必要

中心的な緊張は、安定性と学びの間にあります。要求を早く固定すると、確固たる受け入れの基礎と監査可能性を得ますが、作りながら学ぶことに適応する能力を失います。先送りすると、適応性を得ますが、長期的なトレーサビリティと契約上の明確さを失います。要求工学により多く投資することは、目先の速度を、後の手戻りの減少と取引することでもあります。それは、システムの規模、寿命、失敗の結果が増すにつれて元が取れる取引です。最大のプロジェクトと最も規制されたものは、しっかりと高投資の側にいます。低リスクの社内ツールはそうではありません。

チームで議論すべき問い

最もリスクの高いシステムでステークホルダーに数えられるのは誰で、受け入れまで繰り返し除外してしまうのは誰ですか。 大きなプログラムで飛ばされる人々は、めったに明らかなユーザーではありません。午前3時にそれを動かすオペレーター、認証しなければならない監査人、障害に対応するサポート担当者、ログインしないがそのデータをあなたが保持している影響を受ける非ユーザー。彼らを見逃すと、最も高価な瞬間、受け入れの最中や規制当局が尋ねた後に、彼らの要求を発見します。具体的なステークホルダーのマップを会議に持ち込み、ストレステストしてください。義務づけられたそれぞれの義務(アクセシビリティ、プライバシー、記録の保持、セキュリティ)について、それを所有する人と、それを捉える要求の名前を挙げます。所有者の名前を挙げられなければ、ギャップを見つけたことになり、直し方は、固定されたアーキテクチャに彼らのニーズを後付けするのではなく、今そのステークホルダーを引き出しに加えることです。
要求が変わるとき、変更を承認する前に、それが何に影響するかに答えられますか。 これは、双方向のトレーサビリティが本物か、飾りかの実践的なテストです。大きな、あるいは規制されたシステムでは、一つのルールの変更が、設計、コード、テスト、受け入れの証拠に波及しえて、それを盲目的に承認することが、以前は満たしていたルールを静かに違反する、準拠しているように見えるシステムを出荷する方法です。最近の変更要求を持ち込み、会議でそれを前方にたどってみてください。午後いっぱいの考古学が必要なら、トレーサビリティは役目を果たしていません。答えは変更のプロセスを作り直すべきです。影響評価が手作業の探索ではなく、生きたトレースへの素早い問い合わせになり、ベースラインとバージョニングが、変更の対象となる安定した点を与えるようにします。
私たちの要求の唯一の権威ある情報源はどこにあり、その外にどれだけの真実が散らばっていますか。 要求の乱立(本当の仕様がメール、チケット、スライド、誰かの記憶に散らばっていること)は、大きなチームで最も一般的な失敗の一つであり、合意されたことを示さなければならない監査されるシステムでは致命的です。どのシステムが正本であるかを声に出して決め、他の場所で述べられたものは、出所と根拠を添えてそこに着地するまで、草案として扱ってください。証拠を持ち込んでください。最近のスコープの争いのうち、二人が異なる「最終」版を引用したことに行き着いたものがいくつあったか数えます。数がゼロより大きいなら、行動は一つの情報源に統合し、各要求の根拠を書き留めることです。なぜ要求が存在するかを知ることこそが、後でそれを安全に変更したり落としたりできるようにするからです。
非機能要求は、アーキテクチャを駆動するのに十分早く捉えられていますか。それとも、構造が固まった後に発見し続けていますか。 性能、可用性、セキュリティ、アクセシビリティの義務は、ほとんどの機能よりアーキテクチャを形づくりますが、大きなプログラムでは、それを満たすべき構造がすでにコンクリートに固められた後になって、最も頻繁に遅れて表面化する要求です。相反する引力は本物です。機能的な振る舞いは、ステークホルダーが声に出して求め、デモ映えするものですが、「ピーク負荷で1秒未満の応答」や「WCAGアクセシビリティ適合」という要求は、違反されるまで見えません。最もリスクの高いシステムの非機能要求の現在のリスト、それぞれが書かれたタイムライン上の時点、そしてアーキテクチャ(3.1章)がそれらを明示的なドライバーとして受け取ったか、推測したかを持ち込んでください。企業や政府の設定では、義務づけられた品質の義務(暗号化、記録の保持、アクセシビリティ法)を加え、それぞれが仮定ではなく、設計に渡された書面の測定可能な要求であることを確認してください。受け入れの後に品質特性を後付けすることが、予算とスケジュールが静かに死ぬ所だからです。
所有する各システムにとって適切な形式性の水準は何で、それを習慣ではなくリスクで選んでいますか。 一つの大きな組織は通常、使い捨ての社内ツールから、生命や安全に関わる規制されたプラットフォームまで、幅広いシステムを運用しており、すべてに一つの儀式を適用すれば、低リスクの仕事を書類に埋もれさせるか、高リスクの仕事を規定不足のままにします。緊張は、正式な前もっての仕様の監査可能性と確固たる受け入れの基礎と、進化するバックログの速いフィードバックと減った無駄の間にあり、ほとんどの企業にとっての正直な答えは、意図した混合です。安定した高保証の義務は形式化しトレースし、製品の振る舞いは反復的に詳細化します。失敗の結果、規制上のリスク、変化の速さでランク付けしたシステムの短い一覧を持ち込み、それぞれについて、実際に使っている形式性と、リスクが正当化する形式性を名指ししてください。公募とIEEE 29148のような標準に固定された政府のプログラムでは、形式性は一部が契約によって決まるので、議論は、監査が依存するトレーサビリティを壊さずに、どこにアジャイルの詳細化を重ねられるかです。
最もリスクの高いシステムのすべての要求は検証可能で、それぞれ、要求が書かれた瞬間に書かれた受け入れ基準を持っていますか。 検証できない要求は要求ではなく、願望です。そして「速い」「安全」「使いやすい」のようなつかみどころのない言葉は、まさに誰もそれを不合格にできないからレビューを通ります。大きなチームにとって、これは二重の意味で重要です。検証できない要求は受け入れでスコープの争いを生み、機能が本当に完了したと言えなくします。相反する考慮は速度です。各要求に測定可能な基準と検証方法を付けることは、散文を書くより前もっては遅いですが、最も高価な後の手戻りに対する最も安い防御です。最近の要求のサンプルを持ち込み、それぞれを単純な基準でテストしてください。原子的か、測定可能か、どう確認されるかを名指ししているか。規制された文脈や政府の文脈では、テストを証拠まで広げてください。追跡された合格する受け入れの証拠のない要求は、ソフトウェアが何をしているように見えようと、納品されたとは見なされないので、受け入れ基準は、いずれ作成しなければならないコンプライアンス記録の種なのです。

セクター別の視点

スタートアップ。 小さなチームと短いランウェイでは、要求をできる限り軽く保ってください。仕様書ではなく、一つの共有バックログの受け入れ基準付きのユーザーストーリー。ここでも見返りのある規律は、作る前に本物のユーザーと話し、各ストーリーの出所と根拠を記録することです。間違った機能を作って無駄にしたであろう一週間が、節約される一週間になります。正式なトレーサビリティは省いても構いませんが、本当のニーズを教えてくれる会話は決して省かないでください。

小規模事業者。 おそらくビジネスアナリストも要求の専門家もいないので、仕事は顧客に最も近い人に落ち、買うか作るかの問いが支配的になります。要求を、必要とする成果の短い優先順位付きのリストとして枠づけ、特注の構築を規定するためではなく、既製のツールを評価するために使います。根底にあるニーズと、ベンダーの機能のリストを厳密に分けてください。「製品Xが必要だ」と書かれた要求は、本当のニーズを満たしたであろう、より安い選択肢を静かに閉ざしてしまうからです。

大企業。 規模は、要求を、多くのチームが一つの一貫したシステムを作れるようにする契約に変えるので、優先事項は一貫して適用される標準のプロセスです。定義されたカテゴリ、ニーズからテストへの双方向のトレーサビリティ、権威ある唯一の情報源、ベースラインを伴う管理された変更。ビジネス、ユーザー、システムの要求を明示的に分け、非機能要求をドライバーとしてアーキテクチャに渡して、スコープと品質の義務がチーム間に散らばらないようにします。安定した高保証の義務には正式な仕様を、製品の振る舞いにはアジャイルの詳細化を混ぜ、バランスを、特定のチームの好みではなく、リスクで統治します。

政府。 調達規則は、しばしば契約全体を要求仕様書の周りに組み、しばしばIEEE 29148のような標準に沿って構造化されるので、正確さと網羅性は任意ではなく契約上のものです。各要求を設計、テストケース、受け入れの証拠にリンクする要求トレーサビリティマトリクスを保守してください。ベンダーへの支払い、監査、運用認可はすべて、実証されたカバレッジに依存するからです。透明性と公的な説明責任はハードルをさらに上げます。アクセシビリティ、プライバシー、記録の保持の義務づけられた義務はそれぞれ、明示的で検証可能な要求として現れなければならず、追跡された合格する証拠のない要求は、単に納品されていません。

事例

スタートアップ。 スケジューリングアプリを作る4人のスタートアップは、正式な仕様ではなく、共有バックログの受け入れ基準付きのユーザーストーリーとして要求を捉えます。カレンダー同期機能を書く前に、創業者は午後を5人の見込み顧客との会話に費やし、本当のニーズは、彼らが想定していた同期ではなく、二つのツールにまたがるダブルブッキングを避けることだと知ります。その一つの会話がストーリーを組み直し、間違ったものを作る一週間を節約します。この規模でも、各ストーリーの出所と根拠を書き留めるので、優先順位が変わったとき、なぜそれが存在したかを蒸し返さずに、スコープを落としたり作り直したりできます。

大企業。 多国籍銀行が、融資の受付プラットフォームを置き換えます。要求チームは、ビジネス要求(承認時間の短縮、融資規制の遵守)、ユーザー要求(融資担当者が一つの画面でオファーを比較する必要がある)、システム要求(プラットフォームは三つの基幹システムと統合しなければならない)を分けます。非機能要求(一般的なクエリの1秒未満の応答、99.95%の可用性、個人データの暗号化)は明示的に捉えられ、ドライバーとしてアーキテクチャ(3.1章)に渡されます。すべての要求は、バックログを通じて自動の受け入れテストまでトレースされます。そのため、規制当局が特定の融資ルールがどう徹底されているかを尋ねたとき、チームはルールからそれを検証するテストまでのトレースをたどるだけです。

政府。 国の機関が、正式な公募を通じて給付の適格性判定システムを調達します。契約は、IEEE 29148に沿って構造化された要求仕様書に固定され、機能的な適格性ルール、義務づけられたアクセシビリティ適合、プライバシーと記録保持の制約、セキュリティ統制を含みます。要求トレーサビリティマトリクスが、各要求を設計要素、テストケース、受け入れの証拠にリンクします。ベンダーへの支払いと運用認可(本番でシステムを動かす正式な承認)の両方が、実証されたカバレッジに依存します。追跡された合格する受け入れの証拠のない要求は、ソフトウェアが何をしているように見えようと、単に納品されたとは見なされません。

ビジネスケース: 動機、ROI、TCO

要求工学の経済的な論拠は、欠陥を後から直すコストにあります。業界の調査は一貫して、要求の欠陥がプロジェクト失敗の最も一般的で最も高価な原因の一つであり、欠陥を直すコストが要求の段階から本番にかけて桁違いに上がることを見出しています。だから、要求の明確化と検証に費やされるお金は、実のところてこです。早い段階でのささやかな投資が、間違ったものを作り、テストし、運用することを省きます。

要求の総所有コストには、システムの全寿命にわたる引き出し、規定、ツール、変更管理の継続的な労力が含まれ、一度きりのコストではありません。それに対するのが、貧しい要求のコストです。手戻り、スコープの争い、スケジュールの超過、失敗した受け入れ、契約上のペナルティ、そして規制された環境では、罰金や認可の喪失。リーダーシップには、要求の成熟度をリスクの低減と予測可能性として枠づけてください。要求の変動性、欠陥の発生源、検証されたニーズまでたどれる納品された仕事の割合を追跡し、これらをプロジェクト管理の予測(10.6章)に結びつけます。見返りは機能としては現れません。起こらなかった失敗と手戻りとして現れます。

アンチパターンと落とし穴

要求を装った解決策: 根底にあるニーズではなく、選ばれた技術や画面のレイアウトを規定し、より良い選択肢を閉ざすこと。
曖昧な言葉: 測定可能な基準のない「速い」「安全」「直感的」が、要求を検証不能にすること。
ゴールドプレーティング: どのステークホルダーも実際には必要としない要求を捉え、スコープとコストを膨らませること。
欠けた非機能要求: アーキテクチャが固まった後になって初めて、性能、セキュリティ、アクセシビリティの義務を発見すること。
要求の乱立: 権威ある情報源のないまま、真実がメール、チケット、スライドに散らばること。
凍結された、あるいは管理されない変更: すべての変更を拒むか、影響評価なしにすべての変更を受け入れるか。
トレーサビリティの欠如: 変更が何に影響するか、機能がなぜ存在するかに答えられないこと。監査されるシステムでは致命的です。
分析麻痺: 動くソフトウェアから学ぶことを遅らせる、終わりのない規定。
無視されたステークホルダー: 受け入れまで除外されるオペレーター、監査人、影響を受ける非ユーザー。

成熟度モデル

レベル1、開始。 要求は暗黙的か口頭で、一貫せず反応的に捉えられます。スコープの争いと手戻りが一般的で、トレーサビリティも受け入れ基準も定義されたプロセスもありません。
レベル2、発展。 一部のチームは要求を書き留め、プロジェクトごとに追跡し、基本的な優先順位付けと場当たり的な変更の扱いがあります。実践はありますがチームや人によって異なり、カテゴリ、形式性、質は組織全体で一貫しません。
レベル3、標準化。 標準の要求プロセスが文書化され、組織全体で徹底されています。定義されたカテゴリ、引き出しと検証の実践、書く時点で付けられる受け入れ基準、権威ある唯一の情報源、ニーズからテストへの双方向のトレーサビリティが、アジャイルまたは計画駆動の文脈に一貫して適応されます。
レベル4、管理。 プロセスがデータで測定され、制御されています。要求の変動性、欠陥の発生源、トレーサビリティのカバレッジ、検証されたニーズまでたどれる納品された仕事の割合がベースラインに対して追跡され、トレーサビリティは受け入れの証拠とコンプライアンスまで広がり、要求の指標がプロジェクトの予測(10.6章)に反映されるので、変更と品質の決定は意見ではなく証拠に基づきます。
レベル5、オーケストレーション。 要求の実践は継続的に改善され、組織全体に統合されています。形式性はリスクと成果によって適応的に調整され、引き出しとトレーサビリティのツールはディスカバリー、アーキテクチャ、デリバリーに接続し、組織は自らの測定の履歴を使って、繰り返される要求の欠陥がコードに届く前に防ぎます。

議論のためのアイデア

上級のステークホルダーが解決策として述べたとき、本物の要求と早すぎる解決策をどう見分けますか。
最もリスクの高いシステムと最もリスクの低いシステムで、適切な要求の形式性の水準は何で、誰が決めますか。
動きの速いアジャイルのバックログで、官僚的なオーバーヘッドにならずに、双方向のトレーサビリティを最新に保つにはどうしますか。
あなたの組織で、最も遅れて発見されがちな非機能要求はどれで、それはなぜですか。
規制されたプログラムで、要求が満たされた十分な受け入れの証拠とは何ですか。
AI支援の引き出しと規定のツールは、要求の実践をどう変えるべきで、どんな新しいリスクを持ち込みますか。

要点

要求は解決策ではなくニーズと制約を述べます。必要で、曖昧さがなく、検証可能で、追跡可能でなければなりません。
機能要求、非機能要求、制約を分け、ビジネス、ユーザー、システムの水準を分けます。
本物のステークホルダーから引き出し、分析し優先順位を付け、適切な形式性で規定し、作る前に検証し、変更を管理します。
ニーズから受け入れの証拠までの双方向のトレーサビリティは、特に規制された環境で、説明責任の背骨です。
アジャイルと計画駆動の文脈は同じ活動を共有し、タイミング、形式性、成果物が異なるので、リスクで選びます。
貧しい要求のコストは遅れて支払われ、増幅されます。早い投資は、手戻りと失敗した受け入れに対するてこです。

参考文献とさらなる読み物

IEEE and ISO/IEC, Guide to the Software Engineering Body of Knowledge (SWEBOK), Software Requirements knowledge area
Karl Wiegers and Joy Beatty, Software Requirements
ISO/IEC/IEEE 29148, Systems and software engineering: Life cycle processes: Requirements engineering
Suzanne Robertson and James Robertson, Mastering the Requirements Process
Dean Leffingwell, Agile Software Requirements
Mike Cohn, User Stories Applied
Ian Sommerville, Software Engineering (requirements engineering chapters)