勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

Software Requirements Essentials（2023）をざっと読む

Requirement Developments book

「ソフトウェア要求　第3版」の著者であるKarl Wiegersの新著が出ていたので、ざっと読んでみる記事（あるいは読んだ記録）。

「私はかつて、過去10年間でベストセラーになった要件エンジニアリングの本を10 冊を読んだことがあります。この1冊には、それらの10冊を合わせたものよりも有益な情報が簡潔に記載されています」-- Mike Cohn

ここまで言われたら読むしかない。

Software Requirements Essentials: Core Practices for Successful Business Analysis

Software Requirements Essentials: Core Practices for Successful Business Analysis

Amazon

もくじ

全体的な感想

序文にも書かれているが、本書のポイントは「忙しい人のためのコンパクトな要件定義のアドバイス」となっていることだ。実際、「ソフトウェア要求　第3版」は良い教科書なのだが読み切るのが難しい。それがここまでコンパクトになっているのには驚きを感じる（あとでもう少し分析する）。一方で、ソフトウェア要求について近年大きな進歩がないということも本書を通じて確認できる。実際に真新しい手法が出てくることはなかった。

とはいえ、最新かつコンパクトということで非常に有用な書籍である。誰か翻訳しないんですかね。

ソフトウェア要求　第3版から何が省略されたのか

上記の通り本書の魅力はコンパクトであることなのだけれども、それでは「ソフトウェア要求　第3版」から何が省略されたのかについて、ざっくりと確認しておく。ただしあまり時間をかけていないので正確ではない点に注意。以下の章タイトルはすべて「ソフトウェア要求　第3版」のものである

  • 第2章 顧客の観点から見た要求　はざっくり省略された
    • 「ソフトウェア顧客の要求に関する権利宣言」「～責任宣言」は好きな話だったのでちょっと残念
  • 第4章 ビジネスアナリスト がない
    • 役割やスキル、育成の話が消滅
  • 第18章 要求の再利用 が削除された
  • 第19章 要求開発に続くもの もない
    • 工数見積もり、プロジェクト計画、実装（設計～コーディング）との連携に関する話がなくなった
  • 第3部 特定の種類のプロジェクト向けの要求（第20章～26章）はない
    • アジャイル型プロジェクト、更改、パッケージなど様々なタイプ別のアドバイスは本書では取り上げられていない
    • なお、アジャイル型プロジェクトについてはむしろメインストリームになっているので全編でフォローされている
  • 第29章 要求連鎖のつながり は省略
    • トレーサビリティに関する話がなくなっている
  • 第30章 要求工学のためのツール
    • 文中でツールに関する言及はされているが、深い掘り下げはなくなった。実際現代でスタンダードとなるようなツールは存在しないということじゃないかと思う
  • 第5部 要求工学の実行（第31章～32章）もない
    • 要求プロセスの改善とリスクマネジメントであるが、これもなくなっている

こうやって振返ってみると、よい圧縮がされているという印象。逆に上記が気になるなら「ソフトウェア要求　第3版」またはそれ以降に出版された参考文献などをチェックすればよいのだろう。

20のコアプラクティス

ここからは、本書で紹介されている20のコアプラクティスに関する覚書である。ざっくり何が書かれているかをメモっている。

冒頭にこう書いてあるのがとても良い。

  • プラクティスに関する2つのアドバイス
    • これらすべてのアクティビティをまだ実行しなくても心配する必要はない
    • 一度にすべてをやろうとしないこと

#1: 解決策を検討する前に問題を理解する

解決すべき問題を理解しなければ、プロジェクトが失敗する場合がある。これを回避するために問題分析を漏らすべきではないという話（手法としては、根本原因分析やなぜなぜ分析が紹介されている）。利害関係者が「製品Xまたは機能Yを構築してください」と提案してきても、それが正しいとは限らないということを理解する。

#2: ビジネス目標を定義する

ビジネス目標、またはビジネス要求を定義する話。複雑であればモデル化する必要もある。本章ではフォーマルなものからライトウェイトなものまでさまざまな文書化のテンプレートなども示されている。

なお、ビジネス目標ヒアリングのための質問リストがサポートサイトでダウンロード可能である。

#3: ソリューションの境界を定義する

「何が入っていて、何が入っていないのか」の境界を確立する話。「どのビジネスプロセス、機能、イベントがソリューションの一部になりますか？どれがその外に残るでしょうか？」そしてコンテキストダイアグラムを描く。より抽象度の高いものとしてのエコシステムマップの作製を検討する。ソリューションの境界を定義できれば、ロードマップ等の計画立案にも役に立つ。なるほどー。

ソリューション境界定義のための質問リストもサポートサイトでダウンロード可能である。

#4: 利害関係者を特定し、特徴づける

ステークホルダーと、その代表者の特定、特徴づけは重要だという話。

利害関係者特定のための質問リストもサポートサイトでダウンロード可能である。

#5: 権限を与えられた意思決定者を特定する

意思決定者の特定、もしくは決定方法について。また、単一の意思決定者がいない場合の対応方法（投票など）について。

#6: ユーザーが必要な解決策は何かを理解する

問うべきなのは「システムに何をさせたいか」ではなく「解決策として何が必要か」という話。これをユーザーから直接引き出すのは難しく、相互作業の要求開発によって求めていく必要がある。ユーザーの目標と、その達成につながるインタラクションによって要件は構成される。ユーザーストーリー、もしくはユースケースを使用する。

#7: イベントと応答を特定する

ユースケースは対話型システムには適しているため、分析対象によっては不足がある。これを補完するためにイベントの分析をする。ユーザーとシステムの対話が中心ではないリアルタイムシステムやミドルウェアシステムなどに適応すると良い。イベント応答表を作成することになるが、必要に応じて状態遷移図で補完する必要がある。

この項は、ちょっと歯切れが悪い印象。しかし実際にここで書かれたケースで困ることがあったので覚えておきたい。普通の要件定義で抜けがち。

#8: データの概念と関係を評価する

データ要件を実施する話。かなり細かく、踏み込んだ内容となっている。

  • データオブジェクトの完全な一覧を作成する
  • 概念データモデルを整理する
  • データの理解を洗練するためにCRUD表を作る（CRUDだけでなく、コピー、リスト、使用、移動、変換される方法も調べる、つまりCRUDCLUMT表を作るべきと提言している）
  • プロセスフロー、またはユースケースとの整合性を確認する
  • データ出力要件を確認する
  • データに関するビジネスルール、品質属性、その他の制約について確認する
  • システム内のデータ移動を確認する必要があればDFDを作る
  • データディクショナリを作る

データ要件確認のための質問リストもサポートサイトでダウンロード可能である。

本項については、「ソフトウェア要求　第3版」と対比しても内容が深くなっている印象。特にデータモデルでは抜けてしまうデータ要件という話は重要だし、かなり参考になるという感想だ。

#9: 品質特性を引き出し評価する

非機能要件の話。非機能要件の重要性は高いが、引き出し方法についての良い方法は存在しない。様々な関連書籍などが示されている。

なんとなく、歯切れの悪い章という印象だ。非機能要件ヒアリングのための2000の質問が「The Quest for Software Requirements: Probing Questions to Bring Nonfunctional Requirements into Focus; Proven Techniques to Get the Right Stakeholder Involvement」という本にあるとのことで興味深いが、電子書籍化されてないようだ。残念

#10: 要件と要件セットを分析する

収集した要件の分析に関して。熟練したビジネスアナリストが個々の要求、および要求全体に関して分析を行うことで大きな価値がつけ加えられるとしている。検討すべき事項のチェックリストがサポートサイトからダウンロード可能だが、本書ではそれぞれの観点についてのアドバイスが充実している。

このプラクティスは「ソフトウェア要求　第3版」では軽く触れているだけ（3.3 良い プラクティス： 要求分析）で、大きく発展されているように感じた。結局のところ、ユーザーから引き出した要求は不完全であるため、様々な観点で検討発展させなければ完全な要求セットにならないという話が展開される。

#11: 要件モデルを作成する

要件はテキストだけでなくモデルとして表現すべきという話。様々なモデルの特徴などが紹介される。

要求モデリング言語RMLや要求マッピングマトリックス(RMM)などは知らなかった。深掘りしたい。

#12: プロトタイプを作成して評価する

ユーザーの「何が必要なのかは言えないが、見ればわかる（これをIKIWISIという）」の対策としてのプロトタイプについて。目的にあわせて「インタラクションデザインのプロトタイプ」または「技術設計プロトタイプ」を使って検証を行うことが説明されている。

#13: 要件に優先順位を付ける

要件の優先順位付けに関する意義、及び効果的な質問や分析手法について説明されている。

#14: 要件を一貫した方法で記述する

要件の文章化について。最も重要な目標は効果的なコミュニケーションをすることであって、スタイルや標準、慣例に準拠することではない。なお本項では「要件ステートメント」のスタイルについての注記となっている（つまりモデルの利用などについての言及はない）。

非機能要件の定義について以下の書籍と「Planguage」という表記法が少しだけ紹介されている。ただ細かい内容は示されておらず、ネットで調べてもよくわからないので、読むしかないか……

#15: 要件を構造化した方法で整理する

要件の文書化について。組織が効果的であると考える標準テンプレートをベースに、プロジェクトに最適な文書化を行うという話。

基本的には「ソフトウェア要求　第3版」で示されているものと大きな変化はない。オープンソースの要求管理ツールについての言及があるが、おそらくは以下だろうか。ちょっと見てみたい。

#16: ビジネス ルールを特定して文書化する

ビジネスルール（ビジネスロジック）の扱いについて。

#17: 用語集を作成する

用語集の作成について。

#18: 要件を確認してテストする

要件の検証に関して。それはレビューとテストで構成される。様々なレビューの手法の紹介。要件のテストについてはチェックリストをチェックするといったものではなくて、ソフトウェアテストそのものをこの段階で実施することについて説明される。

要求のテストについては「ソフトウェア要求　第3版」でも語られていた（要求の妥当性検証）が、さらに拡張されている印象を持った。シナリオテストだけではなく、境界値分析などのソフトウェアテスト手法ですら要件段階で実施することを提案している。

#19: 要件のベースラインを確立して管理する

文字通りの要件のベースライン化について。ベースラインの承認忌避など発生しやすい問題への対策など。

#20: 要件への変更を効果的に管理する

こちらも文字通り、要件変更管理について。

おまけ

本書についての著者のインタビュー

X(Twitter)で本書を読んでいる話を書いたら、以下のポッドキャストが面白いというコメントをいただいたので聞いてみた。かなり興味深い。本書を書いた理由なども語られている。

Karl WiegersのYouTubeチャンネル

上記のポッドキャストで紹介されていたのだが、なんとKarl Wiegersが本書の解説ビデオをYouTubeに上げている。まだ全部見ていないけど本書を手に取る前にチェックしても良さそう。
www.youtube.com

ソフトウェア要求　第3版

ソフトウェア要求　第3版

Amazon