パパッと見るブックレビュー『【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術/清水 吉男』
はじめに
今日は『【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術』という本のブックレビューをしたいと思います。
パパッと見るブックレビューのコンセプト
レビューをパパッと見て、紹介した本が見た方の今の課題にマッチしているかどうかをパパッと判断できることをコンセプトとしています。
それではブックレビュースタートです。
そして月が変わりましたのでフォトギャラリーの画像を変更します。今月は『笹いと』さんのイラストを拝借します。ありがとうございます!
ブックレビュー『【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術』
本の紹介・読んだ目的など
【タイトル】【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術
【著者(敬称略)】清水 吉男
【発行日】2010/5/1
【発行所】技術評論社
[読んだ目的]
1、要件定義のポイントを知る
[何でこの本を知ったか]
Amazonで検索した
[ブクログでつけた★の数]
★★★★★
この本はこんな人にオススメ
要件定義(要求仕様決め)について知りたい人
開発をうまく進めたい人
開発で一歩先に進みたい人
著者:清水 吉男さんって?
Amazonから引用します。(出版当時のプロフィール)
上記は当時のプロフィールで、清水さんは2017年にお亡くなりになっているようです(参考)。ご冥福をお祈りいたします。
私が読み取ったこの本のメッセージ
「 要求仕様をしっかりと決め、開発をスムーズに進め、開発業務を続けよう 」
私が感じたこの本のポイント
入り口の要求仕様がしっかり描けていないと設計・開発・試験工程で手戻りが発生し、余計に工数をかけることになり開発がスムーズにいかなくなる、よって要求仕様をしっかり書くことが重要
要求仕様とは要求+仕様。仕様だけでなく、その仕様の上位概念である要求を、最初に必ず書く。仕様をいきなり思いついても上位にさかのぼり要求を書く
要求は文章で書く。その中の動詞と目的語が仕様となる
要求仕様書は顧客、設計者・開発者、試験者が認識のずれなく特定(Specify)、合意できる文章
要求仕様はそのまま設計者が設計できる状態まで落とし込む。設計できる状態でないものは仕様ではない。
チャプター紹介
読後ひと言感想(読んだ直後にブクログに投稿したもの)
目的:要件定義のポイントを知る
要旨
要求とはシステムで実現してほしいこと。機能要求、品質要求、その他制限の3つがある
要求の仕様化≒要件定義
多くのバグは要求の仕様化がしっかりされていないことに起因する
USDMとは、要求から使用を抜け漏れなく導き出す技術である
要求は文章で書く。正しい仕様の範囲を定義し、動詞と目的語から仕様を網羅で導き出す
要求からのブレイクダウンがポイント。仮に仕様を思いついたとしても、その仕様だけでを抜け漏れがある可能性があるので、上位概念である要求を考え、そこから導き出される仕様を網羅的に考える
要求仕様書とは、システムで実現してほしいことについて、テストフェーズ含めた関係者がその内容について認識ずれなく具体的にイメージ(特定)できる文章のこと。また設計者がそのまま設計に入れる=必要な情報が全てある文章
要求に対して理由を必ずつける。各関係者が本意を確認し正しく判断するため
テンプレート:カテゴリー→要求(要求番号)→理由→説明、仕様分類名(グループ化)→仕様(仕様番号)。要求は二階層になる場合がある
良いと思った点3つ
改めて要求の仕様化の大切さを認識した。最初が肝心
いきなり仕様(具体)で進めるのではなく、上位の要求(抽象)を考えてから付随する仕様を考えるという手法になほどなど思った。ファクト→抽象化→転用の話とリンクした
実経験からの言葉で書かれているので説得力を感じることができた
私の読後トライ
USDMで要求仕様を書く(仕事で書いてみました!)
常に上位概念(要求は何か、本質は何か)を考える
その他メモ
なし
おわりに
いかがでしたでしょうか。パパッと自分の課題にあっているか判断できましたでしょうか。
以上、パパッと見るブックレビュー『【改訂第2版】[入門+実践]要求を仕様化する技術・表現する技術』でした!
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか?