要求を仕様化する技術・表現する技術

要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?

今頃読んだ。有名な本っぽいので。

実務的に役に立つ。のだが、独特の世界観があるので読むのが辛い。そこを乗り切れば大丈夫だし、がんばれば乗り切れるレベル。

何が辛いと言って、要求仕様がない現状がいかにダメダメかを切々と説く前半が辛い。とにかく冗長だし、この本を読むような人は痛感してることだろうから、時間がない人は全く読まなくてもいい。
また、全体的に用語が自分の知る言葉とは微妙にずれていて読みづらかった。最初に言葉の定義をして欲しかった*1。そもそも「要求仕様」という言葉の解釈が不思議で、(Software) Requirement Specificationと言ったら、普通はRequirementをspecifyするものだろうと思うのだが、著者はRequirement「と」Specification(何を？？)だと言う。また、CMMを良く引く割には、機能要求・非機能要求と言わずに、機能要求・品質特性(品質仕様)という言い方を使うところがまた分かりにくかった。あ、機能仕様だっけ？　まあいいやどうでも。

151ページ、第二部「要求仕様を書く」からが本題で、性格分け、レベル分け、インタビューによる作成方法、具体例などを交えて「要求」と「仕様」を書いていくやり方を説明する。ここは確かに参考になる。EXCELを使おうとか、関係者にこういう前提条件を了解してもらうよう根回しすべき、みたいな実務に近い指南があるのも、実用書として良い。多分。

本編中の重要な部分をかいつまんでメモっておく。

• 要求仕様書は要求のツリーからなる。
• 要求は必ず一つの理由を持つ。理由が超重要。
• 要求は範囲を示す。
• 要求は適当に階層化せよ。多くても三層程度。階層の深さは揃えるべき。

×
要求=温度を計測する
理由=水温を設定温度に維持するため

○
要求=ボイラーの水温をこまめに測定して設定温度を維持する
理由=燃料の消費を最小限に抑えたいから

• 要求は必ず(一つまたは複数の)仕様を持つ。
• 仕様は検証可能かつ、設計を(ぎりぎりで)特定しない形である。ただし仕様は(理由があれば)設計を大いに誘導して良い。そうすべき。
• 目に見えるものは全て仕様。
• 仕様の記述は開発者と合意できる詳細度で良い。ベテラン開発者と新人相手では異なっていて当然。(認定仕様)
• 要求および仕様は適当にグループ分けせよ。分割の基準は4つ(構造化設計のモジュール分割手法による)。MECEを意識せよ。
  • 時系列分割
  • 構成分割
  • 状態分割
  • 共通分割
• 品質要求をきちんと記述せよ。
• ここまで来たら変更を恐れない。FIXにこだわらず、要件管理を行うこと。
• ちゃんと顧客とコミュニケーションを取れ。
• 変更要求においては、変更する部分を説明する要求仕様書を書く。

この本の極意は、

• 理由を意識することによって、要求の理解を深める
• 要求からロジカルに導かれた、検証可能な合意を持つ
• 理解と合意を分別し、かつ関連させる

かな？
従来から機能要求、非機能要求を繰り返し叩いていくやり方に慣れている人にとっては、暗黙知を形式知にしてくれた感じではないか。ただ、「要求とは何か」という問いの答えは最後まで無かった。まあ禅問答かな、それは。

P.S.
要求仕様とか設計書とかは法律にこそ適用されるべき。更新の要件管理と、バージョン管理と、成果物（最終形態）は分けて保守されるべき。

*1:良い仕様書は言葉の定義にページが割かれているはずだとか言いつつ、この本に無いってのはどうなんだ。