從需求到設計：如何設計出客戶想要的產品（十週年紀念版）

by Donald C. Gause

Partial ContentsPart 1: Negotiating a Common Understanding1. Methodologies Aren't Enough2. Ambiguity in Stating Requirements3. Sources of Ambiguity4. The Tried but Untrue Use of Direct QuestionsPart II: Ways to Get Started5. Starting Points6. Context-Free Questions7. Getting the Right People Involved8. Making Meetings Work for Everybody9. Reducing Ambiguity from Start to FinishPart III: Exploring the Possibilities10. Idea-Generation Meetings11. Right-Brain Methods12. The Project's Name13. Facilitating in the Face of ConflictPart IV: Clarifying Expectations14. Functions15. Attributes16. Constraints17. Preferences18. ExpectationsPart V: Greatly Improving the Odds of Success19. Ambiguity Metrics20. Technical Reviews21. Measuring Satisfaction22. Test Cases23. Studying Existing Products24. Making Agreements25. EndingBibliographyIndex

大約有90%的產品開發案是失敗的，其中30%並沒有開發出任何產品，其他的雖然有產品問世，但人們不喜歡，或從來不使用；即便使用了，也是毛病一大堆。

做好需求分析，是新產品成功的關鍵

本書是暢銷書《你想通了嗎？》兩位作者又一傑作。他們總結與各大小企業合作60餘年的經驗，來探討新產品開發過程中最困難的部分——如何設計出「高品質」的產品或系統。在本書裡，「品質」的定義是：「符合客戶的需求」。

為什麼有那麼多新產品的專案會胎死腹中？為什麼新東西要符合客戶的需求這麼難？由此看來，客戶需求、品質、與客戶溝通、設計等等環節，都大有學問。而且，可能客戶「自己都說不清楚自己要什麼」。

因此，要做出客戶想要的產品或系統，不僅需要專案管理的技巧，還要先做好「客戶需求分析」，這就是本書的主題，內容包括：需求要件（requirements）、減少語意曖昧（ambiguity）、使用者參與、激發概念的會議、專案命名、調和衝突、客戶要什麼（功能、特性、限制、偏好、期望）、技術審查、測試使用者滿意度、黑箱測試等等。還有許多實際案例，以及豐富的心得分享與建議。

本書中提到的技巧，曾經成功運用於許多產品或系統──包括電腦硬體、電腦軟體、汽車、家具、建築、消費性產品、書籍、影片、訓練課程等等。

本書對於新產品專案的所有利害關係人——團隊成員、客戶、使用者、還有必須綜觀全局掌控進度的經理人，都大有幫助。本書可以幫助你有效帶領團隊，讓新產品專案邁向成功！

名家書評：
如果你想要開發一樣新產品，你應該讀這本書。──Watts S. Humphrey, 卡內基美隆大學軟體工程學院

高斯和溫伯格……點出了產品開發過程中，最隱微但最重要的環節：對於需求要件必須有適當的了解。本書運用啟發性的實例，提供了一整套的工作方法。──Barry Boehm，加州大學洛杉磯分校，《軟體工程經濟學》作者

對於系統分析師的智識提升很有幫助。──Tom DeMarco，知名軟體顧問，《Peopleware》、《最後期限》作者

看過本書之後，你永遠不會再相信「過時的需求要件」──不論是誰交給你，或給你的時候多麼嚴肅認真。有了這本書，你可以自己去發掘真正的需求要件。　　　　　　　　　　　──Ken de Lavigne，IBM品質學院資深成員

書名已明確指出，要有高品質的設計，必須先做好客戶需求分析；內容涵蓋其社會的、心理的和智識的過程與實務。高斯和溫伯格是這領域裏經驗豐富的高手。　　　　　　　　　　　　　──Harlan D. Mills，佛羅里達理工學院教授

這是我們長期渴望而且迫切需要的書……也是第一本討論如何溝通產品的需求要件的書……以確保產品有價值。──Judy Noe，The Strategic Advantage合夥人

本書從流程的觀點，來談如何明確地掌握客戶的需求……透過生動的例子，直言不諱而且易於了解。高斯和溫伯格清楚說明，需求要件作業不只是一項管理工具，也是開發新產品的驅動力。──Gabriel A. Pall，朱蘭學院副總裁

Genres: Nonfiction, Design, Business, Technology, Programming, Engineering, Software

400 pages, Paperback

First published September 1, 1989

Reviews

[Henriette · Rating 4 out of 5]

A very informative book. The writing style is similar to other Weinberg books, so even though the subject matter is serious, in my case work related it is an easy and enjoyable read. The summaries at at the end of each chapter form a useful cliff notes version that I plan to return to.

[Richp · Rating 2 out of 5]

This is not an actively bad book. It has some good stuff, especially about thinking outside the box, even about an inside the box problem. But, for a heavyweight subject, it is quite lightweight despite the middleweight package.

The authors were consultants at the time they put this together, not lead (or rank and file) requirements developers. It shows not only by the artificial examples, but especially by the repetitive and blatant references to one of the co-author's other books (as opposed to many of the excellent books in the bibliography). This is sales pitch more than a text. I'm not ticked off myself. I only paid a buck for a barely used edition and I have the time since I am retired. But I did requirements analysis and development for a number of years, I find reason to suspect the previous owner of my copy was stuck with this as a course text, and I think she got much less than she paid for.

[Omar Trejo · Rating 3 out of 5]

Good basic overview of requirement exploring techniques.

[James Boling]

I confess I have not been disciplined enough to forge through much of this. What I have read of it has shown potential and this is an important topic for IT work of course.

[Kim · Rating 2 out of 5]

You can't tell right away, but almost immediately you know this book is dated. Ignoring the amusing clip art, the fact that the author has to spell out "electronic mail" is a big clue.

Nevertheless, there is some use to this, but much of it is elementary. The advantage to the book is that it helps you check yourself and your team for bad patterns. Much of the content is stuff you probably assume you are doing right, but that it does not hurt to check.

Skip to the "generating ideas" section, however, if you want a good laugh - there may be a suggestion involving silly hats. *sigh*

[Nynke Fokma · Rating 4 out of 5]

[Anna Epishcheva · Rating 3 out of 5]

First 100 pages are good for structuring that you already know, but next 160 are dated, last paragraph also worth to read. Good book for speed-reading

[Carl Klutzke · Rating 4 out of 5]

When I read this book, it opened my eyes and began a change in my career. I've reread it a couple of times since then. Highly informative and eminently readable.

[Drew Mathers]

A collection of methods for requirements analysis with an emphasis on identifying missing requirements.