リスト：要求定義関連書籍 を表示しています。（全 10 件）

要求工学の基本やIEEEなどの規格に忠実に、"要求とは？"から始まり、要求の引き出し、要求分析、SRS（要求仕様）のまとめ方、要求管理まで
じつに網羅的に、著者の経験談も交えて丁寧に解説されており、米国での評判に納得しました。翻訳も一般的な訳語(でもJISの訳語とはかなり違う)、"ですます調"で、良いと思いました。書籍の性格上、特に要求プロセスについて何か著者独特のものが示されているわけではありませんが、まず基本的な知識をと思っている方には最適だと思います。要求プロセスで何か読んでみたい場合は、ロバートソン夫妻の「要件プロセス完全修得法」（三元社 ISBN 488303111X ）が良いと思います。（有名で本書でも参考文献になってます。ただし日本版は翻訳が悪い）（neu-neu / 2004-01-04）

ソフトウエア開発に最も重要なのが、要求をとらえる（見いだす・理解する・構築する）こと。この本は、そのことを再任し視させてくれるし、要求をとらえ文書化するための様々なテクニックを網羅すると共に、関連づけ、使えるように手助けをしてくれる。ユーザに近い位置にいる人もそうでない人も、ソフトウエアは何のために作るのかを、日々確認するために、一度読んでおく方がいい。動かない（動かす価値のない）コンピュータシステムを再生産することのないように。（osm10 / 2005-05-21）

文章表現が若干堅苦しく、少し読むのに疲れるものの、記載されている内容は非常に素晴らしい。
何が素晴らしいかと言うと、SI会社やコンピュータメーカー等のSEやSAが、要求定義段階で見落としがちだが、本来やるべきことが明確に書かれており、要求定義の重要性を述べるだけのつまらない本ではない。
実践に応用する（実案件に置き換える）ことこそ必要なものの本質的に決めておかなければならないアイテムを述べ、なぜ必要かを説いている。
プロジェクトの成否に関わる重要だが、軽く見られがちな要求定義におけるSEやSAのバイブルとなりうる本であると思う。（velvetblue / 2003-08-28）

要求工学に関するトピックを網羅した良書で、これさえ読めば要求工学の知識は完璧と言えるでしょうが、問題は内容盛りだくさんなことで、なかなか全てをこなすことは難しいと思います。Part Iは必須でしょうが、Part IIからは、実際には拾い読みになるのではないでしょうか。
32ページに顧客と開発側が満たすべき10箇条がそれぞれ書かれていますが、著者が先ず言いたいことはここでしょう。この20箇条が満たされるのであれば、その後はかなりうまくいくと思います。でも、実際にはなかなか...
本書は厚すぎる、と思われる方には、同様の内容でよりコンパクトの、"The Software Requirements Memory Jogger"という小さな書物があります。Ellen Gottesdienerが著者です。
（加納 裕 / 2008-08-01）

確かに網羅的に説明してあるのですが、実際に、この場合は
どうすればいいのか？　を探して使うという利用法には向いて
いないようです。
（masabun / 2006-04-29）

顧客の声を引き出すのが、システム設計の基礎中の基礎。
請負開発であっても、市場に投入するパッケージ品であっても、
顧客の要求が何であり、その要求をどのように手元で管理するか。
効率的なシステム設計には必須の事項だ。
人と人との相互作用については、要求引き出しの際も、
実際のシステムの運用の際も、同様の技術が必要だと思う。（kaizen / 2009-07-27）

この本は要件プロセスを探す手順を懇切丁寧に、体系的に教えてくれる本です。ですので、正しく要件を設定して、システムを設計することまでは教えてくれません。あくまでも要件を探す方法論だと思います。でも、すごい方法論です。と高価ですが、何かしらのシステムを（ＳＥに限らず、社会学者などなど）構築しようと思っている方は、私的購入をしても損はないはずです。
もし迷うことがあるとしたら、原著を買うか翻訳本を買うかだと思います。翻訳のレベルが「訳した」というだけで、「日本語に訳した」のレベルではないので非常に読みにくいのが心残りです。（ダルタニャン / 2004-01-22）

今使われている用語に合わせて訳してほしい。せっかく良い本なのにもったいない。（ / ）

デ・マルコ氏、ワインバーグ氏、RUPのラショナル社がオススメã-ていたので読みまã-た。要求分析のコンサルタントであるロバートソン夫妻が、実際に現å 'でç"¨ã„ている要求分析のためのãƒ-ロセス「ボレーレ・ãƒ-ロセス」ã‚'解説する本です。ボレーレ・ãƒ-ロセスという固有名がついていますが、奇ã‚'てらった所もあいまさも無く、作業順序や成果物まで詳ç'°ã«è¼‰ã›ã¦ã‚り、上流工程のå...¥é-€è€...にも最適です。特にＤＯＡやオãƒ-ジェクト指å'に偏るとã"ろも無いのでどちらã‚'実践されていても自分たちのãƒ-ロセスの一部とã-てはまると思います。å"¯ä¸€ã®ãƒžã‚¤ãƒŠã‚¹ç‚¹ã¯ç¿»è¨³ã§ã™ã€‚ã"の本はè'-è€...が、できるだã'読è€...にわかりやすく、親ã-みやすく努力ã-て書かれているã"とが、挿絵のかわいさや作業名からもにじみ出ているのですが、å¹'é!...ã®IBMのOBのæ-¹ãŒç¿»è¨³ã•ã‚Œã¦ã„るので、80å¹'代頃までのIBMのマニュアルのような訳語です。ISO/JIS規格のSLCPやオãƒ-ジェクト指å'もã"存じ無いようで「適å½"な訳語が無いから」という理ç"±ã§ã€Œé©å½"な訳語がæ-¢ã«ã‚る」単語ã‚'独自の訳語に置き換えています。ã"れは次の版でなã‚"とかã-て欲ã-いです。とりあえず原書と併ç"¨ã-ています。（neu-neu / 2003-07-13）

要件定義の手順を知りたい人には良い本です。初心者から熟練者まで役にたちます。値段が高いので個人で購入するのは勇気がいると思いますが、それ以上の価値を提供してくれる内容となっています。　ただし、題名の通り、プロセスの"修得"が目的なので、この本だけで要件定義ができるようにはなりません。この本の内容を実践して要件定義を"習得"する必要があります。　　　修得：学問や技術などを学んで、身につけること。　　　習得：経験を通して習い覚えること。　　　（goo辞書より）（ / 2004-01-19）

デ・マルコ氏、ワインバーグ氏、RUPのラショナル社がオススメしていたので読みました。要求分析のコンサルタントであるロバートソン夫妻が、実際に現場で用いている要求分析のためのプロセス「ボレーレ・プロセス」を解説する本です。ボレーレ・プロセスという固有名がついていますが、奇をてらった所もあいまさも無く、作業順序や成果物まで詳細に載せてあり、上流工程の入門者にも最適です。特にＤＯＡやオブジェクト指向に偏るところも無いのでどちらを実践されていても自分たちのプロセスの一部としてはまると思います。著者の、読者にできるだけわかりやすく、親しみやすくしようと努力して書かれていることが、挿絵のかわいさや作業名からもにじみ出ています。（neu-neu / 2003-07-19）

努力をしている人がいる。それはそれは、傍で見ていても真剣で、真摯で、必死だ。でも成果は得られない。むしろ事態は悪化していく。不幸は累積し、当人は燃え尽き、不満を周囲にぶつけ、時にはその不幸を他人のせいにし、孤立していく…。
実はこのような状態の多くは、「問題を解けない」から発生するのではなく、「正しい問題を見つけていないから」発生する。問題を解いても、解いても、問題が解決されないのは、「問題だと思っている事」が実は「問題の本質ではない」ために起こる。本質ではないため、問題を解決したつもりでも別の形で再噴出するのだ。
この本、多くの人に推奨している。が、大抵の「この本を読むべき人」は「忙しいから」「それどころではないから」と言って、この本を読まずに間違った問題を解き続けている。そして、忙しさが減らないと嘆き続ける。
是非、この本を読んでください。自分は関係ないと思っている人、読んでください。そんな暇は無いと言う人、読んでください。これはそんな「思い込みが激しいがゆえに、問題を正しく把握していないあなた」のための本なんです。（fjの教祖様 / 2007-06-14）

「自分に見えてないことは何か？」。問題に直面した時、このように自問できれば、いい方かも知れません。後になって、「なんで今まで気付かなかったんだろう？」と思うことの方が多いかも知れません。この本のメッセージは「問題は解くことより、何が問題か正しく把握することの方が難しい。しかし、問題把握にもコツはある。」です。
本書の中の非常に簡単な事例について考えている内に、以下について新たな気付きが得られることと思います。
１．自分はどんな思いこみをしやすいか？
２．自分の思いこみに気付くにはどうしたらよいか？
ちなみに原書は"Are Your Lights On?: How to Figure Out What the Problem Really Is"。訳は少々分かり難いところもありがすが、これは原書の言葉遊びの雰囲気を伝えようとした結果。間違った訳はないはずで、あまり心配なさいませんよう。（ / 2003-05-06）

「問題は解くより発見する方がずっとむずかしく、ずっと面白い。
―実人生で本当にものをいうのはそこなのだ。」
・・我々の多くの過ちは、
「問題は何なのか？」を確認する前に、答えを出そうとしていることにある、
という指摘は目からウロコ。
日頃、考えている・・・と思っていることが、条件反射的に反応しているだけなのかもしれない。
要求分析・要件定義にとりかかる前はもちろん、システム構築で悪戦苦闘しているのであれば
なおのこと、
少しの時間手をとめて、一読をお勧めします。（papillon / 2006-09-29）

この本が発行されてすぐ読み、その後も多くの人に推薦してきた。
われわれシステム屋にとって、またビジネスマン全体にとって、
問題発掘、問題発見は最も基本となる能力であり、その能力を
磨くための的確な指針を与えてくれている。
この本を読んで面白い、と感じた人は優秀なシステム屋やビジネスマンに
なれる素養があるが、さっぱり分からん、つまらん本や、と思った人は
何度も何度も読み返してみてください。
訳は多少手抜きというかビジネス用語になつていないとは思いますが
出版社が数学の本の専門ですからそれは大目に見ましょう。（三浦文篤 / 2003-08-03）

この本１０年程、前に購入して、昨日読み返していました。こちらのサイトに偶然入り参加しようかなと思いました。 この本他の人が書いているように、問題解決のプロセスを色々なケースで、おもしろく解説していてとても、参考になります。自分の問題解決能力の影には、こんな本もスキルとしてあったなあと、懐かしく思い起こしました。
残念なところは、英語圏での書籍なので、タイトルの事例についても、英文と日本語訳でのギャップが目立つため、原書でのジョークや、ユーモアが今一つ、伝わっていあにような感じを受けました。（ / 2001-02-26）

要求仕様について合意するための具体的な方策が体系的に列記されている。
ワインバーグの書籍では、一番何度も読み返して利用している本である。
実際に経験したこと、実際に思い当たることなどが、沢山書かれていて共感できる。
要求仕様を明確にせずに、後で手直しについて騒いでいる人達が、何故この本を読まないか不思議である。手直しが儲け頭なので、要求仕様を明確にするとお金にならないということなのでしょうか？
（kaizen / 2008-07-08）

ソフトウェア開発で収入を得ている全ての人に本書を勧めます。一概にソフトウェア開発と言っても、プログラム経験が無いに等しい方から開発ソフトウェアの全体像を知らないままプログラムを作成する方々まで、多岐に渡る範疇を含みます。そして、ソフトウェア開発中には必ずと言って良いほど、作業手戻りや抜けなど発生します。この根本原因についての検討を本書では行われています。内容構成としては、S/Wに対する要求分析と開発の進め方をシミュレートして、我々に身近な問題点を洗い出していくものです。（ / 2000-12-01）

その名の通り要件定義フェーズの為の本である。示唆に富んだ内容を「保証印ゴキブリ退治器」、「収束設計プロセスセミナー」などの比喩を使って面白く書いてくれていてとても読みやすくなっている。
　要件定義フェーズをあつかった本は、"いかに曖昧さを減少させるか"、"いかにユーザーニーズをコントロールするか" といった収束手法に傾倒しがちなものが多い中、"いかに関係者のアイデアを引き出すか"、"いかにユーザーの満足度を高めていくか"、などニーズ生成手法にも力を入れている。その根底には、"ユーザーの満足度＝プロジェクトの成功尺度"という当たり前だが軽視しがちな基本がしっかりと根付いている印象を受けた。
　要件定義の初め方から終わり方まで抑えるべきポイントを具体例をもって示してくれていて新しい発見もあったし、参考にもなった。ただアプローチの具体例はいかにもアングロサクソン的なものが多く、日本的なアプローチへのアレンジは要りそうだ。（dat247 / 2002-05-23）

本書のよいところは、アオキさんのレビューに尽くされています。非常に多くの研修機関や大学の情報系学科で推奨されてもいます。でもなぜか、持っている人が少ないようだ。考えてみたら、本書の前提として、ソフトウェア工学、特に要件工学を、それなりにわかっている必要がありそうです。Wieger "Software Requirement" MicrosoftPress,や　Alan Davis "Software Requirement" Prentice Hall　あたりを押さえておくと、この本の本当のおもしろさがよくわかります。（ / 2002-03-01）

気楽に面白くよめる。ワインバーグだからね。
若いエンジニアだったら予習になり、ベテランだったら自分も同じような経験をしたねと楽しくよめるでしょう。
品質管理の仕事をしている人はよむといいね。品質のもつ意味が違って見えてくるでしょう。
比較的、価格も高いが、名人の話を聞くと考えれば、安いものですよ。（アマ・チュア / 2006-05-17）

本書は、要求の導き出しから仕様化、要求の変更管理までを網羅している。
システム開発において、的確な要求を導き出すという永遠のテーマについて書かれた良書。
ＨｏｗＴｏ本と読み物としての二つの側面をもつ。
要求導き出しのテクニックなど、具体例をあげ解かり易く書かれているので、これから上流工程へ携わるビギナーの方にもお奨めできる。
また、訳本ではあるが、文章は平易で読みやすいのが大変良かった。（日本語訳、監修の方のご苦労が伺える仕上がりになっている）
本書では、要求の導き出しから仕様化の間に「要求のトリアージ」を行うことを推奨している。システム開発において、予算と納期、要求のバランスをとることは大変重要である。
この時点でボタンの掛け違いをすると、大抵の場合、納期遅延や予算超過などプロジェクトの失敗を招くことになる。
本書の第３章で取上げられている「要求のトリアージ」では、要求を選び出すための技術について触れられており、参考になった。（ＫＩＴＴＹ / 2007-01-08）

顧客の要求を実現するために、パソコンのようなコンピュータを利用しない方がよい場合がほとんどです。
iPODのような、新しい機材を作る方がよい場合もあります。
顧客要求の真髄を知るには、ありとあらゆる思いこみを排除して、無になるのもよいかもしれません。
本書のような方法もあると思いました。
（kaizen / 2008-11-20）

ソフトウェア開発において、ユーザの真の要求を引き出すノウハウを事例を交えて語った本。ただユーザから要求を聞き出すのではなく、本当に求められているモノを探り当てるという点がポイントである。だが、契約社会であるアメリカと異なり、"つきあい"や力関係が重視される日本では本書を受け入れる素地が出来ていないと思う。
確かに、ソフトウェア開発において要求定義(Requirement Definition)は重要である。これさえキチッとしていれば、後はウォーターフォール・モデルに従って開発すれば目的のアウトプットが出る筈である。しかし、30年近い私のソフトウェア開発経験において、プロジェクトの開始時に顧客からの要求定義が明確化されていた事は皆無である。その上、本書のように要求仕様(顧客の外部仕様)に請負先が口を挟める機会も皆無に近い。顧客が要求仕様を明確化しない癖に、当方で積極的な提案をしようものなら黙殺・叱責されるのがオチである。顧客と請負先とがビジネスライクに対等に「要求」の検討をする余地がないのが実情である。
ソフトウェア開発という工学的な分野に、日本的因習が入り込んでいるのが実態であり、これを何とかしなければ本書の提案も役に立たない。日本的経営にも良い点はあるのだが、せめて工学的分野の仕事はビジネスライクで進めたい。（紫陽花 / 2007-09-22）

「要求」という観点からプロジェクトマネジメント全体を考察した本ということで、
プロジェクトマネジメントの教本だと思って読み進めると、かなり違和感があると思います。
プロジェクトの成功には要求の掘り出し・コントロールが必要で、それにはプロトタイピングや
短周期でのリリースなどのアジャイル的な手法が適しているというのが全体を通した主張で、
そのため、各章で内容や結論が重複している箇所も結構あるように感じました。
ただソフトウェア開発が単に納期やコストを満たしたという表面的な成功ではなく、ユーザーに
とって革新的なメリットをもたらすという本来の意味で成功するためには、要求が欠かせない
ものであるということは再認識できました。
他にも、要求の重要度を2つの尺度で測定する、ユーザーが業務を語っているのかソリューションを
語っているのかを明確に区別する、など部分的に参考になる箇所は結構ありました。
ソフトウェア開発がこの本で提示されているような、ユーザーとベンダーがアイディアを出し合い
よりよいものを作っていくという世界になっていくことを願うとともに、そのために何が必要
なのかは今後、現場で日々考えていこうと思います。（司馬遼ファン / 2007-10-28）

ソフトウエア開発において要求を理解することは大切なことですが、
さらに顧客も気付いていないような要求を引きだす方法について、
学べる本だと思ったのですが、内容はプロジェクト管理の広範囲に渡り、
主題から離れているような気がしました。
ただ、ステークホルダーの分析については非常に参考になりました。（なか / 2008-12-28）

ユースケースを書くということ自体は、ビジネスモデリングやシステム設計のあらゆる段階で応用できるということはよく言われているし、説明されればなるほどごもっともと納得できるが、いざ書こうと思うと、一体何を記述すればいいのか分からなくなる。
それはユースケースというのが本質的にはただの散文の集まりにすぎないからであり、根本的にはユースケースの書く側の問題の捉え方・整理の仕方に全てかかっているからじゃないだろうか。
それなのに従来のこの手の本といえば、書き方と簡単な例を示すだけで、具体的に何を根拠にして書くのかということに対して比較的無頓着な傾向があったと思うし、それを読んだ読者は一度は分かった気になるが、再びワープロに向かうと「何を書けばいいのかわからない」となることがあまりにも多かったように思う。
それに対して、この本はユースケースを書くために必要となる「視点」を読者に与えており、ユースケースといえど、所詮は散文の集まりであるのだから使う時と場所、問題把握のための視点と整理という基準をどのように持つかということを丁寧に教えている。
多角的・広範な議論が記されており、変に隔たっているとも思えず、そのため非常に実用的だと思える。
またユースケースというものがシステム設計・開発においてどのような位置を占めるべきなのかについてもきちんと述べているので、木を見て森を見ずということもないだろう。
個人的には、この本を読んで、ユースケースを書くというのは完全に一つの技法をマスターすることなのだとつくづく痛感した。
現在提唱されているシステム開発プロセスは全てユースケースを中心に駆動しており、要件把握・問題の優先順位・複雑さの検討等、ユースケースなしには考えられないし、仮にそのようなプロセスを踏まなかったとしても、従来のシステム開発にも十分すぎるくらい応用可能なのは間違いない。
散文を書くという基本的な技能でありながらそれほどまでに重要な要素になり得る、ユースケースを書くということを学ばないのは完全に損であるし、またお茶を濁したような書き方の例だけ挙げた本など読むだけ時間の無駄と思う。
そんなわけで、ユースケースをこれから学ぼうという人や書き方が分からないという人に、この本は最適な視点と技法を与えてくれる（少なくとも与え得る）一冊だと思う。
＃但し、ユースケースの書き方だけに３００頁もあるのか辟易する可能性は否定しない(^^;（taka-m / 2003-01-24）

プログラム仕様を書く最初のドキュメントであるユースケースの書き方の本
まず0章と1章でユースケースとは何かということとUMLで記述した
ユースケース図で概要を示しています。
第一部でユースケースを説明しています．
ふるまいの契約としてのユースケース（2章）の内容どおりに
契約の範囲（3章スコープ）利害関係（4章）と最後に書式（11章）
までユースケースについて述べています．
第2部ではユースケースの疑問点として他の設計書との関連や
ユースケース自体のさらに詳細な説明が行われています。
第3部として50ページあまりを使って要約しています．
すばらしいです！訳もすばらしいこともありとてもわかりやすく
過不足なくユースケースが理解できます。
2001年と古めの本なのですが全然古くありません．辞書のように
厚いわけではないのですが、ふと疑問を持ったときに読み返すと
必要な内容が載っています．役に立つという言葉どおりの本です。
（親カッパ / 2008-04-12）

システム開発の起点となり、後続の開発フェーズの品質、コスト、納期に多大なる影響を与える要求分析。
その要求分析の品質を高めるスキルを希求する方にはお勧めの本です。
要求分析の重要性が喧伝される割に、具体的にどのようなプロセスを経てどのように表現されたものが品質の高い要求分析結果なのか、満足のいく答えを得られないことも多いですが、この本はその答えを明確に示してくれているように思います。
ユースケースというと人型と楕円からなるＵＭＬのユースケース図のことしか思い浮かばない人もいるかもしれません。
しかし、ヤコブソンがＯＯＳＥで提唱し、統一プロセスに引き継がれているユースケースの概念は、アクターとシステムが実現すべき目的との関係を明確にし、システムの振る舞いを記述する手法、すなわち要求を分析する手法として非常に優れたものです。そしてそれはまたユースケース駆動開発として、統一プロセスにおける要求管理の根幹をなす概念でもあります。
この本の著者であるコーバーンは、ユースケースの書き方、使い方につき極めて実践的に分かりやすく説明しており、どのように書かれたユースケースがよいユースケースかを示してくれています。ユースケースについて書かれた本はいくつか読みましたが、ユースケースの書き方を説明している本の中では本書が一番優れいると思います。
（上昇志向 / 2006-10-21）

今までいろいろとユースケースについての本を探してきましたがやっと
現場で使えることのできる本が見つかりました。
洋書が和訳されている本を読むと機械的に訳してあって意味が分からないと
いうものが多いですがこの本はそんなことありません。
きちんと解説してあって読みやすいです。
要求分析からユーザと開発者のコミュニケーションの道具として
どんなふうにユースケースを活用していけばいいのかが理解できました。
早速使ってみたいと思っています。（ / 2002-01-15）

　たとえば、自然言語でもプログラミング言語であっても、文法的に正しく書いただけでは最低のコミュニケーションしかできません。表現力のある日本語を書けば文学になりますし、構造化された綺麗なコードであれば人間も追いやすく結果として再利用もしやすいものになります。
　要件定義のレベルで使うユースケースという言語の記述でそういうレベルの力をつかるためにはとても優れた本だと思いました。いい例だけが書かれた本というのは他にもあるかもしれませんが、この本の優れた点は、様々な生の事例を引用し、それぞれどこがよくてどこがいけないかを解説してくれるところです。自分の書いたものが、どう評価されるか、どこを直せばいいか、を考えながら読み進められます。
ユースケースで要件を記述していくということにいままでリアリティを感じませんでしたが、それは勉強した事例での記述がよくなかったからかもしれません。いい例と悪い例を見比べて学んでいくことで理解が深まるのはどんな言語でも同じなのですね。（jimmy / 2002-09-26）