【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？

投稿元：

レビューを見る

仕様仕様って言われても何のことやらさっぱりだったのでお勉強。読んでもわからなかったのは悪い例そのまんまな仕様書だったからっぽいことがわかってちょっとほっとしました。

投稿元：

レビューを見る

仕事のために勉強のため読みました。

自分の場合は仕様書を特に作成せず、打ち合わせを何回も重ねて仕様を固めて来ました。正直この本に書いている様に書くのはなかなか大変だなと思いましたが、話し合いの中で、書くと話すと言う意味では変わってしまう部分はありますが、とても参考になりました。

かなりボリュームはありますが、システム開発に携わる人は一度読んでおくといいと思います。

投稿元：

レビューを見る

要求をとらえること、要求という包みの中に、仕様を入れていくこと。そして、そのような要求や仕様がどのような理由によって裏付けられているかを記すこと。

似たような内容の繰り返しが多いが、だからこそ重要なポイントがわかりやすい。

ただ、誤字脱字が多すぎる。要求や仕様を「文書」で書き残すことの大切さを唱える本だけに、これは非常に残念。

しかし、この点に関して目をつぶれば、システム開発に関わる人たちにとって重要な示唆を与えてくれる本だと思う。

投稿元：

レビューを見る

何を作るとよいかということをここでは「要求」という漢字2文字で表現しています。仕事によっては「制約」という場合もあります。

これらの制約を仕様として記述するのが不十分だと，
何を，どういう条件で試験すればいいかが分からないため，
結果として，何度も作り直しをしないといけないこともあります。

システム設計の基本的なところを，清水吉男さんの経験に基づいて、うまく整理しているところがよいでしょう。

参考文献も，海外でも流通している基本文献をあげているので，
国際的な展開に役立てることもできるでしょう。

2011年の11月には，上海で開催された世界ソフトウェア品質会議でも関連発表があったので，参考にするとよいでしょう。

また，2011年6月の派生開発カンファレンス2011での
藤倉 俊幸さんの
ユースケースとUSDMにセミフォーマル手法を適用した要求検証
が，本書の内容を発展させるよい鍵だと思いました。

投稿元：

レビューを見る

清水さんの本を読んだのは、これで3冊目です。

冗長とか読みにくいとかいう感想は一緒です。でも、まずは、それを書いておかないとね。

そのように、本としては、いまいちな本書がこんなに読まれているのは、そこに卓越したオリジナリティと実用性があるからだと思います。

★★★

本書では、清水さんのUSDM（Universal Specification Describing Manner）について書かれています。
改訂版なので16ページ増えています。

USDMは、要求仕様書の書き方です。仕様書というからには、
「仕様書」は「Specification」の日本語ですが、どのような状態かわからないままこの言葉を使っていると思います。英和辞書を引いても「仕様」「詳細」「明細」といった意味が書かれているだけでほとんど役に立ちません。「USDM」では「Specification」を、関係者がその内容について“特定できた（Specify）状態"、すなわち同じもの（こと）をイメージしている状態と定義します。
が満たされている必要があると筆者は主張します。

そのために、
　・ 要求には特定しやすいように番号を振る
　・ 仕様にも同様に番号を振る
　・ 要求と理由と説明と仕様は区別して書く
　・ 複数の要求はカテゴリにまとめる
　・ 要求自体の階層化は2段までとする
といった具体的なテクニックが書かれ、さらにチェックマーク欄などを加えた具体的フォーマットが示されています。

★★★

USDMの価値は、要求に対して理由を紐づけることで要求の依頼者の真意とのズレを無くし、さらに仕様を要求と離れないように、しっかりと関連付けて明確にしていることにあると思います。

そして、それをExcelという追加修正しやすいツールで記載しているところが実用性を上げています。

★★★

本書を読む前に、Twitterで@mkoszkさんが
USDMで用いている要求は一般に使われている要求とは違う。USDMにおける要求は、「範囲」を表すようにしている。それは、状態や条件の場合分けがあり、連続する振る舞いを表現するため、一般に要求と思われているものよりも文章が長くなり、複数の動詞が含まれることになる。#USDM
posted at 01:22:35

という理解でよいのかしら？ #USDM
posted at 01:22:50

USDM本が改訂される理由は、「仕様は要求に含まれる”動詞”およびその”目的語”にある」ということを全面に押し出すためと書かれている。 #USDM
posted at 01:32:09

この理解がまだ不十分なのだが、今のところの理解を書いておこう。複数の動詞が含まれる要求を分解して、一つ一つの動詞にするだけではなく、その動詞が書かれた背景や情景、シーンや状態を見極め、書かれていない”動詞”を抽出するというものだ。 #USDM
posted at 01:34:52

この考え方はHAYST法におけるFV表の”目的機能"を導き出す方法と似ている気がしている。USDMで抽出された"動詞"とFV表に書かれた”目的機能"は、表現された結果は違うものだけれども、その過程が似ている気がしている。 #USDM
posted at 01:38:46

FV表の目的機能は、システム機能では無い。どちらかというと要求に近いと思われる。そのため、USDMと似ている気がしているだけで、やっぱり違うのかもしれない。
posted at 01:48:51
書かれていたので、今回、FV表との違いを意識して読みました。

その結果分かったことは、
@mkoszk 半分位読んだのですが、USDMの要求仕様とFV表の目的機能とは重なるところは多いのですが違うものでした。目的機能の方は「欲しいかどうか」は重視しません。
posted at 12:31:43

@mkoszk 半分しか読んでいないのでUSDMの方は確信はないのですが、FV表の方は基本機能を考えてから目的機能に戻ります。そうすることで今回の商品にはあるいは過剰品質かもしれないけど再利用や保守で必要となる機能を見つめます。
posted at 12:54:33

「理由」と「目的」は似ているけど違うものです。そこがUSDMとFV表との本質的な違い。理由は「何故？」と掘り下げる思考で、目的は「本来はどうなの？」と登っていくもの。開発用には掘り下げる方が良いし、テストでは視野が広がるので本質に目を向けるのが良いだろう。
posted at 18:18:26
です。

FV表のFは智美塾合宿の結果Fg（ゴールを意識した機能）ということが分かってきたのですが、「機能」から「目的」を問う方向なのです。

つまり、FV表の「目的機能」は、「その機能は何のためにあるの？」「その機能が果たすべき目的は何なの？」「そもそも、どうして作ろうと考えたの？」という解決空間を拡げる上部へ展開していく方向です。

一方で、USDMの「理由」は、「その要求がでてきた理由や背景はなんだっけ？」「何故、依頼者はこんな要求を出してきたんだっけ？」というように要求の依頼者の真意と要求仕様書を記述する開発者やレビューアとの認識のズレをふせぐための「要求の掘り下げ」です。

これは、どちらが良いという話ではなく、要求を仕様化していくためには、それはさまざまな選択肢の中から仕様を確定していく行為ですから、清水さんの「理由｣の方向で分析するのがよいのです。

そして、できた機能に対してテストする時には、書かれた要求や仕様が間違っていることもあるわけですから、「目的」展開を行ってゴールの認識を共有して（Fをレビューして）テスト設計に持っていくのがよいわけです。

ということで、長文になりましたが、お勧めです（たぶん、初版の方をお読みの方が多いと思いますが）。

投稿元：

レビューを見る

　仕様を作成する方法について、著者のこれまでの経験に基づいて述べられているので一定の説得力があった。しかし、自身の経験と考えに過信ともいえる自信をもっており、経験したことのない方法論や嫌いな方法論、一方的に使えない方法であるとして切り捨てている姿勢には疑問が残る。また誤解されて広まった内容を鵜呑みにしている。もちろん参考になる部分は多かったが、とにかく気に入らないものは排除するという筆者の姿勢がそれに疑念を抱かせる要因となってしまっていた。

投稿元：

レビューを見る

著者のセミナーに出席後購入。
述べてる手法は素晴しいんだけど、話があっち飛びこっち飛びするせいで、文章全体にまとまり感が無く読み易いとは言い難い。

投稿元：

レビューを見る

要求仕様化に限らず、「設計」という行為に携わる人間は、全員が読むべき本。要件分析のやり方に悩むエンジニアは多いが、必ず何らか助けになるはず。
内容は難解ではないが、幅が広いのと実務に合わせてイメージするのが少し難しいので、何度か繰り返して読むのが効果的だろうと思う。

投稿元：

レビューを見る

一通り読み終えた。
わかりやすいとは言えないが納得する内容。
今までよりもちょっとだけ前プロセスでの品質作り込みに意識がいきそう。

もう一度６〜８章を読み直して要求の定義と要求の仕様化についてまとめてみようと思う。

投稿元：

レビューを見る

要求と仕様と理由を分けて記述し、それらをセットで紐づき構造にする。
軽視されがちな仕様変更時にも常に要求に立ち帰って影響範囲や制約逸脱を確認できる記述方式が望ましい。派生開発及び要求仕様記述の集大成として上記ノウハウを詰め込んだフォーマットとして、USDMと要求トレーサビリティマトリクスを提案されている。

投稿元：

レビューを見る

どのレベルまでが要件定義で、どこからが設計かはよく問題になるけど、“要求の仕様化”という見方でそのラインを考えたことはなかったなぁと実感。本の内容で中心になるUSDMは普段使ってるけど、やっぱり急いで次工程に進んでいるのが現状なので、そのあり方について考えさせられる内容でした。。。

投稿元：

レビューを見る

ちょっと読みにくい
ちょっと独自なスキーマなので理解するのが大変
デファクトスタンダードとの関連がもっと明確ならいいのだが

投稿元：

レビューを見る

何かこう独りよがり感はある．例えば仕様書作成のツールとして「WordではなくてExcel」を勧めるのだが，内容を読むと表形式で書けるなら何でもいい感じで，つまりMS以外の選択肢を知らないで書いてるんじゃないかという．ただ，内容としてはまあ正しそう．Agileディスってるけど，安易に飛びつく層に対しての説得力はあると思う．

投稿元：

レビューを見る

・良書。
・ユーザから提示された仕様に対して、常に要求をひもづける事で、機能要件だけでなく、非機能要件までも洗い出すいう考えは、今までなんとなく感覚的にやっていたが、それだと品質が安定しない（属人的スキルだと、人が変わると品質も変わるし、同じ人でも、時期によって品質が変わる）と感じていた。当書で薦める手法（USDM）は、EXCEL書式の要求仕様を作製する事で、USDMの書式がある程度ガイドの役目を果たし、自分が作業する際も見落としが減るし、またチーム・レビューをする際にも、レビュアーが見やすい書式を使用する事で、気付きの機会を増やし、上流工程でのなるべくバグ洗い出そうという手法の様に思えた。

投稿元：

レビューを見る

http://hinbeee.blog31.fc2.com/blog-entry-1744.html