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

著者：清水吉男
発売元：技術評論社

目次

第１部　要求仕様にまつわる問題
第２部　要求仕様を書く
第３部　要件管理と計測

感想

すごいや、この本。

プロジェクトが燃えてしまう大体の理由が、要求仕様の漏れ。

もしくは、要求で夢見てしまったクライアントと、開発側のギャップ。

言わば田植えというか、イネの発芽といえるような要求仕様書の作成をちゃんとしましょうよね、というお話。

平たく言うと、曖昧さをなくし、しっかりとわかり易い文章で要求仕様書を書きましょうという話なんですけれどね。

「それが一番難しいんじゃ！」と突っ込まれそうですけれどね。

その方法が「第2部 要求仕様書を書く」にしっかり書かれておるのです。

第2部の中身は

・要求の役割
・要求には「範囲」がある
・要求の表現
・要求表現の難しさ
・「範囲」をあらわしているか
・すべての”動詞”を表現しているか
・要求には「理由」がある
・なぜ「理由」にこだわるか
・要求と理由でセット
・慣れないうちは理由に要求がまじる
・必要なら「説明」を付ける
・要求の理解を助けるもの
・用語集への展開
・要求のカテゴリ化
・コンテキスト図でシステムの境界を明確にする
・システムの世界を分割する
・要求のモレを防ぐことが重要
・品質要求を確認する
・品質要求の表現
・機能に付随する品質要求
・製品・システム全体に属する品質要求

となっております。

この中でも刺さったのが「理由」って箇所だな。

なんでその機能が必要なのか？そもそもその機能が必要なのか？その定義っていうか、それがはっきりしていなきゃ、何も出来ないよねって話だよな。

「ダイエット」したい理由は何か？で、ダイエットの方法は大きく異なってくるものね。

あとは「第8章要求を仕様化する」ってパートですな。

仕様とはそもそも何か？それは

仕様とは、要求（実現してほしいこと）を満たすべき”具体的な振る舞い”の記述

なんだよな。

その記述内容が特定できる書き方になっていないとダメなんだよな。

あと

「否定表現」などの曖昧な表現を避ける

もよい。

否定文だと、いろんな条件で推察できちゃうからな。

推察しちゃダメなんだよな。

IF モードが”待機”のとき THEN受信したデータを加工しない

って記述にするのよね。

いやいや、この本、勉強になるね。

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?