It isn't that they can't see the solution. It is that they can't see the problem. G. K. Chesterton Requirements are essential Requirements are the key to project success. We all know this, but we often forget n and pay the price. Many projects, both in industry and in the public sector, fail to do what is needed. They deliver late, over budget, and poor quality. Missing out on requirements is disastrous. Who this book is for Writing Better Requirements is designed as a short, convenient overview for practising systems engineers and others who find they need to write requirements. Because it is about practical techniques, it should be useful in many different kinds of system and software project. We aim to enable readers to write requirements good enough for successful systems to be specified, designed, and tested against them. This book should also form a useful introduction for students who want to learn how to get started with requirements. What this book does and does not cover This book specifically focuses on how to discover and express requirements. It is not about system specification, nor how to make a design that meets user needs, nor even about how users should ensure their requirements are met.Since users own the requirements, these must be expressed in a way users can understand. This book treats requirements as simple pieces of text, supported by operational scenarios and informal diagrams. Many attempts have been made to improve on these simple means, using more formal structures and notations with varying success. We have not tried to cover all these approaches. To place requirements in context, the book must of course cover some aspects of the development process. Project management, verification, quality assurance, and the development life cycle are all closely linked with requirements n indeed each of these areas is meaningless in isolation. But in this book, we concentrate on the tasks of capturing and writing requirements. Each chapter contains exercises to help readers to practice their skills. We recommend some good books for readers who want to go beyond writing good requirements to other aspects of systems and requirements engineering. Getting the best from this book This book is meant to be read in the order in which it is written, taking the reader through a disciplined process of identifying, gathering, organizing, and reviewing. This is vital for success. Each chapter introduces a stage in the requirements process. Key terms are defined informally, explained, and illustrated with examples and exercises to develop the practical skills of good requirements writing. These skills involve looking at problems, dealing with people, looking critically at what is being written, and reviewing requirements effectively. Reviewing is to some extent a separate skill and can be looked at separately; the others belong together in a more or less strict sequence. Structure of this book We begin by illustrating the importance of requirements. You may need this chapter to convince other people that they have a problem. Too many projects have poor requirements, and never recover. If you are already convinced, you can skip this introductory chapter. We then show in a non-technical way how to define a problem, in close co-operation with the only people who know what the problem is, the users. The body of the book steps through the process, looking at: how to capture requirements from users; how to organize these into a clear message from users to developers; techniques for the special kind of writing needed for requirements; how to review requirements informally at every stage, then formally. Practical Exercises All the chapters in the body of the book contain practical exercises for the reader. These are designed to take about half an hour each. Some are sufficiently open-ended for more extended self-instruction, or student projects. We recommend that readers attempt each exercise, at least briefly, to get an actual feeling for the difficulties involved. At the back of the book are short answers to all the questions, with hints to the reader for more complete projects. Problems before Solutions If the message of this book can be stated in a sentence, it is: Get agreement on what people want, before attempting to create solutions. Finding out what is needed, instead of rushing into presumed solutions, is the key to every aspect of system development. Most technical problems can be solved, given determination, patience, a skilled team n and a good definition of the problem to be solved. Acknowledgements We would like to thank the anonymous reviewers who checked the book so carefully; our wives and families for tolerating us while we wrote; and all our consultancy, training and workshop clients who experienced the material first-hand and showed us the way it needed to be explained. We are specially grateful to Richard Marshall for reading an early draft, and to Professor Ken Jackson for his perceptive and precise comments. 0321131630P05292002
評分
評分
評分
評分
讀完這本厚厚的書,我最大的感受是它的“係統性”和“可移植性”。它沒有局限於任何特定的行業或技術棧,無論是金融係統的核心模塊開發,還是一個麵嚮消費者的移動應用迭代,書中的原則和方法論都適用。作者構建的這套知識體係是高度自洽的,從業務目標定義到具體的技術規格描述,各個層級之間的邏輯銜接如同精密機械般緊密。讓我特彆受益的是對“度量”的強調。書中反復指齣,一個好的需求必須是可測試的,而可測試的前提是其結果是可度量的。它提供瞭一套從宏觀業務指標(如轉化率提升百分比)到微觀係統指標(如錯誤率低於韆分之一)的層級化指標設定框架。這套框架的價值在於,它真正將“需求”這個文檔和最終的“商業成功”緊密地綁定在瞭一起。當我閤上這本書時,我明白這並不是一本讀完就可以束之高閣的工具書,而更像是一本可以伴隨我職業生涯不斷迴顧和實踐的“方法論聖經”。它教會我的不是固定的招式,而是培養一套持續質疑、精確錶達和有效協作的思維模式。
评分這本書的深度不僅僅停留在“如何寫”的層麵,更深入探討瞭“誰來寫”以及“如何達成共識”的軟技能部分。我個人認為,這部分內容是許多同類書籍所缺失的。作者用瞭相當大的篇幅來討論需求溝通中的權力動態和認知差異。書中分析瞭分析師、産品經理、開發人員以及最終用戶之間的信息壁壘,並提齣瞭打破這些壁壘的具體策略,比如采用“三方會談”模式來共同定義驗收標準,而不是讓分析師單方麵記錄。最讓我印象深刻的是對“隱含假設”的剖析。作者指齣,很多項目失敗的根源並非是需求寫錯瞭,而是因為雙方對於某些基礎性的行業規則或技術環境存在未被言明的共同假設,一旦這個假設被推翻,整個需求鏈就會斷裂。為瞭對抗這種風險,書中提供瞭一套“假設清單驅動的提問法”,它強迫讀者主動去挑戰那些被視為理所當然的前提條件。這種將心理學和溝通技巧融入技術寫作的跨界處理,極大地提升瞭這本書的獨特性和實用價值,讓我意識到,寫好需求,首先是一種高階的人際溝通能力。
评分這本書的敘事節奏把握得相當老練,完全不像某些技術書籍那種平鋪直敘、乾巴巴的風格。作者似乎非常懂得如何將枯燥的理論融入到引人入勝的案例流中。我讀到關於“非功能性需求”的那一章時,深有體會。以往我對性能、安全這些概念總是感到模糊,覺得它們更像是項目末期測試時纔需要操心的事情。然而,這本書通過一個虛構的電商平颱升級案例,清晰地展示瞭如果不將響應時間、並發處理能力等寫進早期文檔,後續團隊在架構選型上會走多大的彎路,以及由此帶來的成本激增。作者沒有直接批判瀑布模型或敏捷模型的優劣,而是巧妙地利用這個案例,展示瞭在不同開發範式下,需求文檔的形態和側重點應該如何靈活調整。最讓我拍案叫絕的是,書中穿插瞭幾組“需求審查清單”,這些清單並非是官方標準,而是作者根據多年經驗提煉齣來的“防坑指南”。例如,其中一項提醒我注意識彆那些帶有“通常”、“大概”、“盡快”這類模糊詞匯的錶述,並提供瞭一套替換方案,要求用可量化的指標來替代。這種實操性極強的工具輸齣,使得這本書的價值遠遠超齣瞭理論探討的範疇,更像是一份可以隨時拿齣來對標的實戰工具箱。
评分從排版和細節來看,編輯團隊顯然也下瞭不少功夫,這使得閱讀體驗本身就成瞭一種享受。書籍采用瞭大量的圖錶和流程圖來輔助解釋復雜的概念,這些圖錶的設計非常簡潔,去除瞭所有不必要的裝飾元素,直奔主題。例如,書中用一個“需求演化路徑圖”清晰地展示瞭從模糊的業務目標到具體的驗收標準,中間經曆瞭哪些信息的損耗和提煉過程。這種視覺化的呈現方式,對於我們這種需要經常嚮非技術背景的管理者匯報進度的專業人士來說,簡直是救星。我發現自己可以輕易地截取其中的某個圖錶,直接放入演示文稿中,並能快速地嚮聽眾解釋清楚我們當前的需求成熟度。而且,書中在討論需求文檔的版本控製和變更管理時,所采用的語言非常具有前瞻性。它沒有固守傳統的“凍結需求”觀念,而是接受瞭需求是必然會變化的現實,轉而重點教授如何建立一個健壯的“變更控製流程”,確保每一次修改都有據可查、影響可控。這體現瞭作者對現代軟件開發環境的深刻理解,即靈活性與可控性之間微妙的平衡藝術。
评分這本書的封麵設計,那種沉穩的深藍色調,配上燙金的字體,初看之下就給人一種專業、可靠的感覺。我拿起它的時候,期待著能從中找到一些能立刻提升我日常工作效率的“速效藥”。翻開目錄,裏麵的章節劃分得異常清晰,從基礎的概念界定,到深入的場景應用,邏輯鏈條非常完整。我尤其欣賞作者在引言部分對“為何要寫好需求”的闡述,那段話不僅僅是陳詞濫調地強調其重要性,而是從項目失敗的案例齣發,層層遞進,構建瞭一種不寫好需求就無法達成商業目標的緊迫感。它沒有急於拋齣復雜的模型,而是先用一係列生動的比喻,將抽象的需求文檔具象化,比如把優秀的需求比作建築的藍圖,而糟糕的需求就像是手繪的草圖,看似有形狀,但結構隨時可能崩塌。這種由淺入深的講解方式,極大地降低瞭初學者的閱讀門檻,讓我感覺自己並不是在啃一本晦澀的技術手冊,而是在聽一位資深的項目經理分享他的實戰經驗。書中對“用戶故事”的探討也十分到位,不僅僅是羅列“作為一個[角色],我想要[目標],以便於[價值]”的句式,而是深入解析瞭如何通過訪談技巧挖掘齣用戶真正潛在的需求,而不是他們口頭上說的那些“想要”的東西。這部分內容,對我重塑與利益相關者溝通的方式起到瞭立竿見影的作用。
评分 评分 评分 评分 评分本站所有內容均為互聯網搜索引擎提供的公開搜索信息,本站不存儲任何數據與內容,任何內容與數據均與本站無關,如有需要請聯繫相關搜索引擎包括但不限於百度,google,bing,sogou 等
© 2026 book.quotespace.org All Rights Reserved. 小美書屋 版权所有