学習の内容と経緯

読書感想文：「ソフトウェア要求」6, 7, 8, 9 章の続き。

面白かったポイントと考察

段階的な要求の詳細化

ざっくりした要求からトレーサビリティを保ちつつ少しずつブレークダウンして行くのが要求開発のコツだと感じた。 いきなり要求の詳細はかけないので、段階的に詳細化していくことが重要であると思う。

万能な資料はないこと

今のところ、万人にわかりやすい完璧な一意な資料を作成するのは難しい。なので、様々な角度から要求を文書化し仮説を肉付けしていくことが大事だと思う。
また、プロジェクトにあった方法を選択することが重要であることから、様々な要求開発方法を学習してタイミングで選択できるように知識をつけておくことが重要であると感じた。

優れた要求を作成するために目指したい特徴

優れた要求と呼ばれるものには以下の特徴がある。

• 完全である
  要求を実現するために必要な情報がすべて含まれている。機能要求ならば開発者が実装するために必要な情報がすべて含まれていなければならない。
• 正確である
  ステークホルダーのニーズを満たすための全ての情報が客観的に記述されていること。誰が要求しどのようなプロセスで実現されるのかが明確である必要がある。
• 実現可能である
  実現可能な要求であること。技術、予算、スケジュール的に実現可能でなければならない。
• 必要である
  作成した要求文書がステークホルダーの期待値を満たすことが可能であるか、この文書で確認できなければいけない。
• 優先順位がついている
  要求の達成に現実的な範囲で応えるために、優先順位をつけなければいけない。
• あいまいさがない
  個人の解釈に結果が左右されないような記述方法がされていなければならない。例えば「<事前条件>のとき<行動>した場合、<アクター>は<期待する結果>しなければならない」というような行動を示す同士と、観察可能な結果をつけるとあいまいさがなくなる。
• 検証可能である
  テスト担当者が要求に対して正しく実現されているかどうか判断可能な状態にしなければならない。判断不可能な場合は、それはまだ要求としては不完全であり、よりブレークダウンする余地がある。

自身が作成した要求文書について、振り返る際はこの特徴を踏まえておきたいと感じた。

要求をできるだけ図で表現する

長い文章で表現された要求は誰しもが理解しやすい訳では無い（人間の短期記憶の特性上でも全て理解するのはほとんど不可能である）。ポジションによっては詳細よりも概要だけほしいステークホルダーもいるはずで、その人達にも理解しやすいように図で表現することが必要（ステークホルダーに理解してもらえなければ文書化の意味が薄れる）。 時間が無いからと言ってモデルを省略するのは愚策で、そもそもモデリングができない時点で要求の理解が不十分である可能性が高く、今後のトラブルの対応に追われるため余計に時間がなくなる。 エンジニアとして、要求を理解するために様々なモデリング方法を学習し、適切な箇所でその方法を使用できるスキルの習得は必須であると思った。

気になったモデリング手法

個人的に読んでいて使用してみたいモデリング手法がいくつかあったので、以下に記載する。

• スイムレーンダイアグラム
  業務フローを表現するための図。プロセスを横軸に、役割や部署を縦軸にとって、プロセスがどのような役割や部署によって実行されるのかを表現する。
• データディクショナリ
  システムで使用するデータエンティティに関する情報を表形式で記載したもの。データの定義、データの型、データの長さ、データの制約、データの関連性などを記載する。
• ダイアログマップ
  UI 設計を抽象化した図。フローチャートのような感じで、ユーザーの入力に基づく画面の応答を表現する。

参考文献

(1) カール ウィーガーズ；ジョイ ビーティ. ソフトウェア要求　第 3 版 (Japanese Edition), 日経 BP 社. Kindle Edition.