軟件需求（第3版） [Software Requirements, 3rd Edition] pdf epub mobi txt 電子書下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[美] Karl Wiegers，Joy Beatty 著，李忠利，李淳，孔晨輝，霍金健譯

下載連結在頁面底部

facebook linkedin mastodon messenger pinterest reddit telegram twitter viber vkontakte whatsapp 複製連結

想要找書就要到靜流書站

windowsfront.com

立刻按 ctrl+D收藏本頁

你會得到大驚喜!!

齣版社：清華大學齣版社

ISBN：9787302426820

版次：3

商品編碼：11883958

品牌：清華大學

包裝：平裝

叢書名：微軟技術叢書

外文名稱：Software Requirements, 3rd Edition

開本：16開

齣版時間：2016-02-01

用紙：膠版紙

頁數：572

字數：656000#

具體描述

編輯推薦

　　STC（美國技術通信學會）卓越奬獲得者，國際業務分析師協會CBA兼執行VP推*。

　　敏捷開發和大數據時代的軟件需求百科*書！

　　一流業務分析師，項目經理，産品經理/産品負責人，創業CEO，商業顧問/谘詢的工具和參考書。

　　特色：

　　這本經典名著經過需求領域兩大領軍人物的聯袂打造，得以*麵升級和擴展，包含更多、更新的主題、實例和洞見。通過本書介紹的需求工程實踐、工具和技術，讀者可以提升需求引導、捕獲、開發、管理和分析能力，並把這些行之有效的技術與技巧運用到工作當中，在盡可能減少成本、增強維護性和避免返工的同時，交付定位更準確、質量更優良的軟件産品/服務。

　　特色主題：

　　準確鎖定關鍵的利益乾係人並與他們展開閤作

　　聚焦於業務目標，對需求進行引導和分析

　　需求的文檔、優先級排定、驗證和重用

　　原型和創建需求的可視化模型

　　管理變更申請、範圍蔓延和需求風險

　　理解和明確指定客戶質量需求

　　針對數據需求和報錶類需求提供指導

　　第3版特色：

　　包含*新的實例、實踐與技術，體現需求領域的新進展

　　凝聚需求領域兩大領軍人物多年的心血，素材來自培訓課程、演講和工作坊，有實操性

　　循序漸進，闡述如何將有效需求實踐應用於敏捷項目和其他各種特殊項目，比如業務流程自動化、軟件包方案、外包、增強型、替換型和嵌入式係統等項目

　　重點聚焦於業務分析師的角色和成功業務分析師應該具備的核心競爭力

　　尤其適閤業務分析師、開發人員、項目經理和其他軟件項目乾係人閱讀和參考

內容簡介

　　作為經典的軟件需求工程暢銷書，經由需求社區兩大知名領袖結對*麵修訂和更新，覆蓋新的主題、實例和指南，*方位討論軟件項目所涉及的所有需求開發和管理活動，介紹當下的所有實踐。書中描述實用性強的、高效的、經過實際檢驗的端到端需求工程管理技術，通過豐富的實例來演示如何利用實踐來減少訂單變更，提高客戶滿意度，減少開發成本。書中的用例、業務規則和商業工具*麵修訂以體現現狀和未來的趨勢。

　　本書尤其適閤具備一定軟件開發過程經驗的業務分析師、需求分析師、項目經理和其他軟件項目涉眾。

作者簡介

　　作者簡介：

　　Karl Wiegers（卡爾·魏格斯）博士，*球公認的軟件需求工程、過程改進和軟件質量專傢，享有盛譽的技術作傢，他發錶很多文章，他的經典著作《軟件需求》係列版本對需求領域有著舉足輕重的影響。

　　Karl在伊利諾大學獲得有機化學博士學位。除瞭計算機，他的愛好還包括品酒、彈吉他、寫歌錄歌和參與公益活動。

　　Joy Beatty（喬伊·貝蒂），軟件需求社區的領袖，曾經協助財富500強中很多企業建立卓越業務分析中心。

　　Joy是IIBA《BABOK指南》的主要貢獻者，CBAP（認證業務分析師）。她具有豐富的培訓經驗和錶達能力，培訓過幾韆名業務分析師，曾經發錶很多文章和演講。她還是《軟件需求與可視化模型》的作者之一。

　　Joy畢業於普渡大學，獲得計算機科學與數學雙學士學位。業餘時間，她喜歡劃船、遊泳和野炊。

　　譯者簡介：

　　李忠利，精一天使公社CEO，CODEX中國創新委員會聯閤發起人。他擁有14年TMT行業經驗，先後供職於用友、SYNNEX和百度等知名企業，曆任技術管理、總經理助理和精益教練等工作。他擅長互聯網創新業務/産品的孵化和指導，打造企業內部創新模式。曾親自推動某外企400人規模的研發模式整體轉型。作為布道者，在國內某知名ERP企業*創研發模式創新和帶領敏捷教練團隊成功使用創新方法來推動軟件産品綫的效率改進。代錶譯著有《管理3.0：培養和提升敏捷領導力》（被譽為“21世紀的管理聖經”）《敏捷武士》和《Scrum敏捷産品管理》。

　　李淳，gilean谘詢顧問，敏捷和精益倡導者、實踐者。通過的認證有Lean Kanban Advanced Practitioner、Certified Scrum Master、Certified Scrum Product Owner、PMP等。先後供職於用友和易車等公司，擔任過程序員、研發經理、架構師和産品經理。

　　自2011年至今，緻力於在傳統項目管理方式中推廣敏捷理念、精益創業方法和看闆方法，先後在項目研發和需求溝通過程中嘗試引入敏捷和精益的價值觀和開發實踐，在縮短産品交付周期的同時項目質量，還增進瞭團隊內、不同團隊間、團隊與客戶之間的信任和溝通成效，在*短的時間內使客戶颳目相看，項目取得瞭預期的效果。

　　霍金健，百度資深交付經理與敏捷教練，具有豐富的項目管理、敏捷實施、持續集成和配置管理的實戰經驗。目前緻力於推動互聯網創新産品管理和敏捷項目管理能力提升。2014年初加入百度，負責公司戰略産品的敏捷改進和産品交付工作，通過運營和度量驅動的方式，結閤業務目標和團隊特點取得瞭突齣的成效。

　　多次受邀在敏捷中國、Scrum Gathering和敏捷之旅等專業大會分享企業研發實踐心得。代錶譯著有《看闆實戰》。

　　孔晨輝，賽門鐵剋中國研發中心高級軟件工程師，主要從事軟件項目跟蹤與管理解決方案的研究與開發工作。國傢軟件水平資格認證的高級信息係統項目管理師，PMBar項目管理社區成員。

精彩書評

　　專傢推*：

　　“業務分析領域的經典著作之一，第3版尤其體現瞭這一專業領域過去十年的進展和新趨勢。”

　　——Kevin Brennan， IIBA（國際業務分析師協會）*席業務分析師兼執行副總裁

　　“軟件需求的百科*書。”

　　——清華大學教授，中國軟件行業協會過程改進分會名譽副會長

　　好書熱評

　　《軟件需求（第3版）》是目前非常有用的需求指南。兩位作者Wiegers和Beatty覆蓋瞭目前業務分析師應該知道的實踐*景。無論是需求規範的老手，還是剛開始做項目的新手，都可以將本書作為桌邊案頭的必備參考書。

　　——Gary K. Evans，Evanetics公司敏捷教練和用例專傢

　　這簡直就是三連冠，Karl Wiegers和Joy Beatty攜第3版再創佳績。從1999年第1版起，《軟件需求》提供的指南就已經成為我在需求谘詢工作中的實踐基礎。我要嚮新手和有經驗的從業人員鼎力推*此書。

　　——Roxanne Miller，Requirements Quest總裁

　　需求方麵很好的書，又更上瞭一層樓！在第3版中，新主題的範圍延展到覆蓋整個項目場景。在敏捷環境中使用需求很有意義，因為所有相關人員都要瞭解新係統的基本功能和用途，並且敏捷開發人員現在也是受眾，必須好好掌握書中的內容。

　　——Stephen Withall，《軟件需求模式》作者

　　《軟件需求（第3版）》終於問世，長久的等待是值得的。這是一本完整的實踐指南，讀者可以從中學到許多對工作有用的實踐。我特彆喜歡書中包含的例子和很多實操方案，可以方便地在真實生活場景中實踐它們。

　　——Christof Ebert博士，Vector Consulting Services管理總監

　　Karl和Joy升級瞭軟件需求領域的開創性著作，對上一版擇其優並加以改進。這一版保留瞭此前版本中所有業內人員必備的參考，還擴展到足以應對當今復雜商業和技術環境所麵臨的挑戰。不論什麼技術、業務領域、方法論或項目類型，都可以藉助本書嚮客戶交付更好的成果。

　　——Shane Hastie，Software Education*席知識工程師

　　Karl Wiegers和Joy的這本有關需求的新書對前一版進行瞭精彩的補充。大型軟件應用的需求是本世紀難以解讀的業務話題之一。此書有助於解讀這一粗略的主題。

　　——T. Capers Jones，Namcook Analytics公司副總裁兼CTO

　　簡單地說，對於每個參與定義和管理軟件開發項目的人（這本書既是必讀之書，又是一本重要的參考。在今天的現代軟件開發世界中，太多人認為需求實踐是用於“無障礙”敏捷的。Karl和Joy對漸進管理需求的方法進行詳細說明，並闡述瞭如何采用日新月異的方法實現軟件交付。

　　——Mark Kulak，Borland公司軟件開發總監

　　我看到Karl Wiegers和Joy Beatty*麵更新瞭這本有關軟件需求的書。我特彆喜歡其中如何在敏捷項目中使用高效需求實踐的新話題，因為近日來，我們這方麵的谘詢服務越來越多。這些在不同需求實踐中的實踐指南和真實案例是無價之寶。

　　——Doreen Evans，Robbins Gioia公司需求和業務分析實踐管理總監

　　作為Karl經典好書《軟件需求》的早期用戶，我對新版早就迫不及待，望穿鞦水瞭，而且它絕對沒有讓我失望。多年以來，從大型的、新型的零起點項目，到采用現成的商業現貨方案和快速發布敏捷實踐，IT開發的重點已經發生很大的變化。在第3版中，Karl和Joy探討瞭這些新開發方法在需求過程中的內涵，還給齣瞭寶貴的建議，這些建議不是基於教條的，而是從他們在需求領域廣泛而深入的經曆提煉齣來的有效實踐。

　　——Howard Podeswa，Noble公司CEO，《業務分析師手冊》作者

　　如果要找一本實踐指南來瞭解什麼是軟件需求、如何創建需求以及如何使用需求，《軟件需求（第3版）》是不二之選。這本書的內容有用、易懂，可以帶你完整瞭解如何應對需求相關的一般場景。結閤許多故事、案例研究、趣聞軼事和實例，這本書讀起來引人入勝。

　　——Laura Brandenburg，CBAP（認證業務分析師），Bridging the Gap站長

　　怎樣纔能使好需求容易理解？在添加內容時，可以像Karl和Joy所做的那樣，確立*麵的産品願景，處理敏捷方麵的問題，盡可能重用需求，處理軟件包和外包項目，確定具體用戶類彆。可以由錶及裏查看需求，解決流程和風險的問題，而不隻是確定功能。

　　——Donald J. Reifer，Reifer Consultants公司總裁

　　本書新版隨業務的發展與時俱進，既在第2版的基礎上進行瞭深化，又讓分析師真切瞭解到如何應對敏捷開發的大潮，如何使用特性進行範圍控製，如何提升需求收集技術，如何開展建模。Wiegers和Beatty聯袂打造的這本書是專業人士的必讀經典。

　　——Keith Ellis，Enfocus Solutions公司總裁兼CEO，《業務分析標杆》作者

《軟件需求》讀後感係列之一-無題亂彈

作者：淡淡如菊

好幾年前，當我轉型成為一名業務分析師時，我苦惱於自己並不十分懂得這個職位究竟要做什麼，要怎麼做，要怎麼做好。所以我在網絡上搜尋所有可以買得到的相關書籍，以求獲得一些指導，其中也包括《軟件需求》（第2版）。在那個時候，這本著作係統的知識點給瞭我很多啓發，我盡量從似懂非懂到有樣學樣，在實踐中去思考如何改進，然後再次去實踐。不僅僅是*初閱讀的時光，後續這幾年的工作過程中，當我遇到一些需求相關的問題的時候，我也會重新打開這本書，翻閱相關的章節，以求迴到*初的狀態，去理解本源，並再次齣發去解決當下的問題。這次拿到新鮮齣爐的第三版，我的感受是，第三版很好地保留瞭之前的精髓，並在其基礎上補充瞭很多關於敏捷開發流程的觀點。這次也有非常強大的翻譯團隊，閱讀的感覺更流暢，這是一本非常適閤軟件開發領域的從業人員閱讀的書籍，尤其是對需求分析感興趣的朋友。我的個人觀點是業務分析師都應該擁有一本以備隨時參考。

這次十多位朋友一起讀這本書，大傢在微信上展開瞭很多討論，也激發瞭我的靈感，所以想提筆寫一寫打動我的一些章節。我不知道自己能否寫一個係列，但我今天打算從業務分析師的培養說起，呼應本書第四章的內容。

書中提到業務分析師的培養可以是前用戶，前開發人員和測試人員，前（或兼職）項目經理，主題專傢或者菜鳥（新人）。不管哪一種角色，轉型成為業務分析師，都會有各自的優勢或者劣質，如果能發揮優勢，改進薄弱環節，那麼在成為一名成功的業務分析師的道路上就有瞭好的開始。現在我也有帶領一個業務分析師團隊，我們的團隊成員有前開發人員，前測試人員，也有新人。我本人也是半路齣傢，是一名軟件開發程序員轉型過來的。我的理解是，軟件開發過程中的每個角色都要或多或少具備軟件需求分析的功能，而其中的業務分析師當然是*應該具備這個技能的工作。那麼除瞭文中提到的不同的人員轉型到這個工作的優勢劣勢以外，我就隨便談幾點的想法吧：

為用戶畫像的潛意識

需求分析的工作離不開和用戶溝通，我們常常會說需求獲取，但和用戶溝通並不是一個簡單的單方嚮從用戶獲取需求的過程。不同的業務分析師去和同一個用戶聊，也許會得到完*不一樣的需求。我還在做程序員的時候，因為當時的團隊沒有BA這個角色，所以老闆派我去用戶現場瞭解他們的工作內容。那會完*是菜鳥齣場，也沒有需求獲取的技巧和技術可言。當我去到現場，接待我的是一位熱情的前輩，因為對方很配閤，所以進展還不錯，然後有一天我決定在工作之餘約她齣去一起吃飯。吃飯的時候，大傢都很放鬆，她跟我聊瞭很多，她從哪裏來，為何選擇瞭我們公司，她對工作的看法和期許，她每天花很多時間在上班路上的睏擾，甚至還有她的寵物。飯局後，我還在現場呆瞭一段時間，我明顯感覺到我的工作進展的更加順利瞭，說不齣是什麼原因，但很顯然彼此的信任增加瞭。後來，當我們開始去設計這個係統的時候，我會常常想到她，想象如果是她在用這個係統，她的反應會是怎樣，她會覺得好用嗎，她會睏擾嗎？當年的我並不明白，這個和用戶溝通的過程就是一個實實在在為用戶畫像的過程，除瞭明白她的工作，我們更應該去瞭解用戶真實的麵目，不是要刨根問底，但你要理解她自身的一些和係統有關的狀況。比如她的教育背景，她對電腦的熟悉程度，她對工作的成就感在哪裏，如果係統能幫到她，她的幸福感在哪裏。如果你在和用戶溝通的過程中，會為瞭這樣的發現而喜悅，那麼我想你會適閤往業務分析師這個方嚮發展的。

解決需求問題的成就感

我的*一份工作是軟件工程師，當年有幸進入瞭一傢提供電信行業解決方案的知名公司。加入公司一個月後，因為前輩們紛紛被挖角，我們幾個菜鳥被迫上瞭*一綫。當時擺在我們眼前的項目，就是某通信公司引入瞭*新製式的交換機，話單的采集和分揀程序需求需要重新梳理並參與測試評比。當時的新交換機廠商是北電網絡，他們在國內的工程師隻負責設備調試，對於係統的軟件問題隻能幫忙聯係加拿大的工程師進行中間協調。我們能拿到的所有的文檔都是英文的，內部更是充斥著大量的通信術語，語言的障礙以及對這個領域的不熟悉，是否能如期完成需求梳理，當時的我們覺得任務艱巨。為瞭盡快搞定這個需求工作，我一頁頁翻看這份文檔，不懂的字句求助Google，不能理解的設計用郵件求助外國工程師，*後總算理齣瞭話單生成的機製，采集的要求，以及話單的構成，並整理齣詳細的數據字典。後續的故事就是，我們一幫菜鳥基於自己的需求理解，開發完成瞭話單采集及分揀程序，我們的程序在各大廠商對新交換機處理能力的測評中，獲得瞭處理速度快、準確度高的評價，榮登三甲。所以說，需求分析的工作，程序員也可以做好的。如果你是一位對於需求分析工作特彆有興趣的程序員，如果你也確實覺得這樣的工作能給你帶來成就感，那麼不如適當的往這個方嚮曆練一下吧。你可以選擇轉型，也可以隻是將其作為自己成為項目經理必備的技能。我的理解是，不會分析需求的程序員不是好的項目經理。

所謂菜鳥

有誰不是從菜鳥開始的呢？對於剛剛走齣校門的人來說，成為一名業務分析師是進入信息技術領域的一個很好的切入點，優點在於他或者她對需求流程的工作原理幾乎沒有什麼先入為主的概念。畢業生要學習的東西很多，工作職責，開發流程，理解開發人員、測試人員，瞭解用戶，掌握基本的業務知識，懂得如何有效的獲取需求。我們無法奢求一個剛走齣校門的孩子，既懂得需求分析的知識，又掌握瞭實際的技巧。菜鳥要做的是，保持對這份工作的熱忱，快速學習，快速成長。成為一名業務分析師所基本的知識，本書能給你*好的解答。至於技能嗎，要在實踐中掌握，希望本學習小組的各位能多點分享這部分啦。但**重要的，是菜鳥的心，可以是決心，信心，恒心，世上無難事隻怕有心人。

(原文鏈接：http://www.jianshu.com/p/86437a10783d?utm_campaign=hugo&utm;_medium=reader_share&utm;_content=note&utm;_source=weixin-friends&from;=singlemessage&isappinstalled;=1)

精彩書摘

　　第1章

　　軟件需求的本質

　　“喂，Phil嗎？我是人事部的Maria。我們在使用你開發的人事係統時遇到一個問題。有位職員剛剛把她的名字改成Sparkle Starlight，但我們無法在係統中改。你能幫個忙嗎？”

　　“那麼她是結婚瞭，隨老公姓Starlight？”

　　“沒有，她沒結婚，隻是改名字瞭，”Maria迴答道，“問題就齣在這裏。好像我們隻能在某人婚姻狀況發生變化時纔能在係統中改名。”

　　“好吧，是，我從來沒想過有人可能會改自己的名字。當初我們在討論係統的時候，你可沒告訴過我有這種可能性。” Phil答道。

　　“我以為你知道任何人隨時都可以閤法更改名字呢，”Maria迴應道，“我們得在星期五之前解決這個問題，否則Sparkle就領不到工資瞭。你可以在此之前修復這個bug嗎？”

　　“這不是什麼bug，好嗎？！” Phil反駁道，“我從沒想過你們需要這項功能。我現在正忙著做一個新的績效評估係統。你所說的問題我隻能在月底修復，但周五之前肯定不行，抱歉。下次如果再有類似情況，請早點告訴我，並請提供書麵材料。”

　　“那我怎麼和Sparkle說呢？”Maria追問道，“如果她領不到工資，會很難過的。”

　　“嗨，Maria，這不是我的錯，”Phil抗議道，“如果當初你早提醒我你需要能夠隨時更改某人的姓名，這種事情就不會發生。你不能因為我沒猜透你的想法就怪我。”

　　Maria怒瞭，但又無可奈何，隻好厲聲說：“是，你說的都對！好吧，這種破事兒讓我對電腦簡直是恨之入骨。問題解決好瞭，就馬上打電話告訴我，可以嗎？”

　　如果你是以上對話中的客戶一方，就會明白無法使用軟件係統來完成一項基本任務多麼令人沮喪。你會痛恨自己得求著開發人員，因為關鍵變更請求最終掌握在他們手中。另一方麵，開發人員也很沮喪，因為他們隻有在係統開發完成之後纔會明白用戶期待有哪些基本功能。對於開發人員來說，更惱火的是，得中斷手頭的項目去修正以前已經完成的係統（因事先未被明確告知而疏忽的需求）。

　　軟件中的很多問題大多數來源於人們瞭解、記錄、協商和修改産品需求的方法不當。就Phil和Maria這個例子而言，問題就包括：信息收集不正規；功能隱晦；對假設功能有理解上的分歧；需求指定不明確以及變更過程不正規。很多研究錶明，軟件産品中發現的缺陷有40%～50%是在需求階段埋下的“禍根”（Davis 2005）。在具體說明客戶需求和管理客戶需求過程中用戶輸入不足和有誤，是造成項目失敗的罪魁禍首。盡管證據確鑿，但很多組織仍然在實行這些沒有什麼成效的需求方法。

　　在軟件項目中，所有乾係人的利益交接點主要集中在需求方麵。（更多乾係人方麵的內容，參見第2章）這些乾係人包括客戶、用戶、業務分析人員和開發人員等。如果處理得當，這種交接既可以讓客戶滿意，又能鼓舞開發人員。若處理不當，則會引發誤解和摩擦，最終降低産品質量和業務價值。正是由於需求是軟件開發和項目管理活動的基礎，因此所有乾係人都應該緻力於需求實踐活動，這是打造一流産品的前提。

　　但開發和管理需求確實很難！既沒什麼捷徑，也沒有任何靈丹妙藥。另外，很多組織都在朝著一個目標努力，要找到一種能適應不同情景但又有共性的技術。本書後麵將講到很多這樣的實踐。這些實踐假定你正在開發一種全新的係統。但是，它們中的多數也可用於改進、替換以及重構項目（詳見第21章），還可以用於融閤商業現成品的（COTS）打包解決方案項目（詳見第22章）。即使項目團隊遵循敏捷開發過程漸進式構建産品增量，團隊也要理解每一個增量所涉及的需求（詳見第20章）。

　　本章將幫助你：

　　* 理解軟件需求領域所用的一些關鍵術語；

　　* 區分産品需求和項目需求；

　　* 區分需求開發和需求管理；

　　* 警惕可能齣現的與需求相關的一些問題。

　　給自己的需求把把脈

　　要想對組織中現有的需求實踐做一次快速體檢，就對比下列問題，看看有多少條齣現於你最近的項目中。如果其中有三四條以上與你的經曆相符，那麼本書就是為你量身定做的。

　　* 從來沒有清晰製定過項目的業務目標、願景和範圍。

　　* 客戶太忙，沒有時間與分析師或開發人員共同處理需求。

　　* 團隊無法與用戶代錶直接互動，不理解他們的具體需要。

　　* 客戶認為所有的需求都很關鍵，因此沒有對需求排定優先級。

　　* 開發人員在寫代碼時遇到瞭模棱兩可或者遺漏的信息，所以隻能靠猜。

　　* 開發人員與乾係人溝通的重點集中於用戶界麵展示或者特性，並沒有關注用戶要使用軟件完成的具體任務。

　　* 需求從來沒得到過客戶的認可。

　　* 客戶認可瞭某個發布或者迭代的需求，但事後又不斷更改。

　　* 不斷接受客戶的需求變更請求，項目範圍隨之擴大，由於沒有增加資源或者刪減功能，進度最後完全被打亂。

　　* 有人提齣瞭變更請求，但被忽略，沒人知道特定變更請求的具體狀態。

　　* 客戶提齣特定的功能要求，而且開發人員也建好瞭，但就是沒有人用過。

　　* 在項目接近尾聲時，雖然滿足規範說明，卻不滿足客戶或業務的目標。

　　軟件需求的定義

　　人們在討論需求時，開始經常會遇到專業術語問題。人們從不同的角度闡述同一樣東西，例如：用戶需求、軟件需求、業務需求、功能需求、係統需求、産品需求、項目需求、用戶故事、特性或者約束條件。人們又賦予瞭不同的需求交付物多種稱謂。對於開發人員來說，客戶所定義的需求聽起來更像是一種高級産品概念。對於用戶來說，開發人員所說的需求理念可能聽起來更像一種具體的用戶界麵設計。這種理解上的偏差讓人睏惑，令人沮喪。

　　關於“需求”的一些解釋

　　即使計算機編程技術已經有很多年頭，軟件從業者仍然在激辯“需求”的準確定義。我們不想在本書中繼續這種爭論，隻想從實用定義的角度簡單錶述一下。

　　顧問布萊恩·勞倫斯（Brian Lawrence）認為，需求是“任何能夠驅動設計做齣選擇的東西。”這種口語化定義不錯，因為很多信息都印證瞭他的說法。畢竟，開發需求的目的就是要做齣閤適的設計選項，最終滿足客戶需要。另外一種定義認為需求是産品所必備之屬性，目的是嚮乾係人提供價值。這也沒錯，但不太準確。我們比較傾嚮於Ian Sommerville and Pete Sawyer （1997）所提齣的觀點：

　　需求是對我們應當執行的任務的規範說明。它描述係統的行為特性或屬性，可以是一種對係統開發進程的約束。

　　這個定義認為“需求”是多種不同類型的信息的統稱。需求涵蓋來自客戶視角的外部係統行為以及來自開發人員視角的一些內部特徵。它們包含係統在特定條件下的行為和屬性，使目標用戶覺得係統易於甚至樂於上手。

　　字典中的“需求”

　　字典對“需求”的解釋為：“被命令或者強製性的東西；需要或者必要。”這與軟件界所使用的“需求”不是一個含義。人們有時會懷疑是否有必要對需求進行優先級排序，因為有的低優先級需求可能永遠不會被實現。人們認為如果對某些東西的需求不是太強烈，就說明它們不是需求。可能是這樣，但我們管這類信息叫什麼？如果將當前項目中的需求推遲到未來某個不確定的發布之中，它還是需求嗎？當然是。

　　軟件需求包含一個時間維度。它們可能是描述目前係統性能的現在時。或者它們可能是近期（高優先級）、中期（中等優先級）或者想象中（低優先級）的未來。甚至可能是過去時，也就是那些曾經被人指定但後來又被捨棄的需要。我們沒必要浪費時間爭論某個東西是否是需求，即使知道自己會為瞭某個閤理的業務原因而永遠不執行它。需求就是需求。

　　需求的層次和種類

　　由於有很多不同類型的需求信息，所以我們現在需要用一組形容詞來修飾一下被人們賦予太多意義的“需求”。錶1-1列齣瞭需求領域的一些常用術語。

　　錶1-1 一些類型的需求信息

　　術語

　　定義

　　業務需求

　　開發産品的組織或者獲取産品的客戶所需的高層次業務目標

　　業務規則

　　策略、綱領、標準或者製度，能夠定義或者約束某些方麵的業務。雖然本身並不是軟件需求，但它卻是一些類型的軟件需求的鼻祖

　　約束

　　對開發人員在産品設計和構建上的限製條件

　　外部界麵需求

　　對軟件係統和用戶、其他軟件係統或硬件設備間的關聯進行說明

　　特性

　　單個或者多個為用戶提供價值的、有邏輯關係的係統性能，可以通過一個功能需求集閤進行描述

　　功能需求

　　描述係統在特定條件下展現的行為? 續錶

　　術語

　　定義

　　非功能需求

　　描述係統必須展現的屬性或者特性，或者必須遵守的約束

　　質量屬性

　　一種非功能需求，描述的是服務或者一個産品的性能特徵

　　係統需求

　　包含多個子係統的産品的頂層需求，子係統可以是軟件，也可以是軟硬件

　　用戶需求

　　特定用戶群必須能夠用係統所完成的目標或任務，或者是用戶期望有的産品屬性

　　軟件需求有三種不同的層次：業務需求、用戶需求和功能需求。此外，每個係統都包含某種類彆的非功能需求。不同種類的需求如圖1-1中的模型所示。正如統計學傢喬治E.?P.?巴剋斯（George E. P. Box）的一句名言所述：“從本質上講，雖然一切模型都是錯誤的，但有些還是有作用的。”（Box and Draper 1987）。這句話用來形容圖1-1真是恰如其分。這個模型也許並不全麵，但提供的方案非常實用，可以幫助組織需求方麵的知識。

　　圖1-1所示橢圓中的內容代錶需求信息的種類，長方形錶示儲存信息的文件。實綫箭頭錶示具體類型的信息通常儲存於所示文件之中。（業務規則、係統需求應與軟件需求獨立存儲，例如存儲在業務規則目錄或者係統需求規範說明之中。）虛綫箭頭代錶一種信息起源於或者受另外一種信息的影響。此圖沒有具體展示數據需求。數據受控於功能，因此數據需求貫穿於這三個層次的需求之中。第7章有很多這些不同種類的需求信息的示例。

　　圖1-1 各類需求之間的關係。實綫代錶“被存儲於”；虛綫代錶“起源”?或“影響”

　　業務需求描述組織為什麼要執行係統（組織希望獲得的業務收益）。其關注點在於組織或者提齣係統要求的客戶有哪些業務目標。我們假設有傢航空公司打算把機場的櫃颱工作人員成本降低25%。為此，人們通常想到的是建一個自助服務終端，供乘客在機場自行檢票。項目的齣資方、目標客戶、實際用戶的管理層、市場部門或者産品規劃部門一般都會有業務需求。我們喜歡將業務需求記錄在願景或者範圍文件之中。還有一些戰略性指導文件有時也會用於此目標，包括項目圖錶、業務實例以及市場（或者營銷）需求文件。第5章的主要內容是對業務需求進行詳細說明。考慮到本書的主旨，我們假定已經確定瞭業務需求或市場機遇。

　　用戶需求描述瞭用戶使用産品必須完成的目標或者任務，並且這個産品要能夠為人提供價值。用戶需求主要還包括對用戶滿意度最為關鍵的産品特性或特徵的描述。用例（Kulak and Guiney 2004）、用戶故事（Cohn 2004）以及事件響應錶都是用戶需求的錶示方式。理想狀態下，這種信息由實際用戶代錶提供。用戶需求錶達的是用戶通過係統來完成哪些具體工作。通過航空公司網站或者機場自助檢票機“辦理登機手續”是“用例”的典型例子。如果將其寫為“用戶故事”，同樣的用戶需求可能是這樣的：“作為一名乘客，我想辦理登機手續，以便能夠登機。”還有一點我們不能忘記，即大多數項目都有若乾個用戶類彆和其他乾係人，我們還必須獲取它們的需求。第8章將對這種層次的模型進行解釋。有些人喜歡用“乾係人的需求”這個更廣義的術語來說明各類乾係人比直接客戶更能提供需求。這當然沒有問題，但是我們要在這個層級集中注意力，理解實際用戶要用這個産品完成哪些具體目標。

　　功能需求說的是産品在特定條件下所展示齣來的行為，主要描述開發人員需要實現的功能以便用戶能夠完成自己的任務（用戶需求），進而滿足業務需求。這三種需求環環相扣，對項目的成功至關重要。人們經常將功能需求記錄為傳統意義上的“應當”句式：“乘客應當能夠隨時打印自己已經辦好登機手續的所有航段的登機牌”或者“如果乘客信息沒有指定座位偏好，航班預訂係統就應當為它分配。”

　　業務分析師（BA）①將功能需求記錄在軟件需求規範說明（software requirements specification，SRS）之中，盡可能詳盡地描述人們對軟件係統的預期行為。SRS用於開發、測試、質量保障、項目管理和相關項目功能。它的稱謂很多，包括業務需求文件、功能規範說明、需求文件等。SRS可以是一個報告，由存儲在需求管理工具中的信息所生成。由於它已成為一種行業標準術語，所以我們在本書中將其統稱為“SRS”（ISO/IEC/IEEE 2011）。要想進一步瞭解SRS，請參見第10章。

　　係統需求描述瞭人們對某個産品的需求，而這個産品由多個組件或者係統子集組成（ISO/IEC/IEEE 2011）。“係統”在此不單單是信息名義上的係統。所有軟件或軟件、硬件係統子集都可以算是係統。甚至人和過程也是係統的一部分，因此某些特定的係統功能可以分配給人。有些人使用“係統需求”這個詞來錶達對軟件係統的具體需求，但我們在本書中並不這樣使用該術語。

　　超市收銀員的工作颱算是“係統”的一個典型例子。超市裏有與稱重設施相連的條形碼掃描儀和手持式條形碼掃描儀。收銀員有鍵盤、顯示器和現金抽屜。我們在超市裏麵還可以發現用於刷積分卡、信用卡或者藉記卡的讀卡器和PIN盒，甚至還有自動找零機。甚至還可以看到三颱打印機分彆打印購物小票、信用卡簽單和優惠券，隻不過這些對你來說無關緊要。這些硬件設備都在軟件控製下互相關聯。隨後，業務分析師根據係統或者産品的整體需求提取具體功能，將其分配給這些組件係統子集中的某一個，同時瞭解它們之間的接口。

　　業務規則包括公司政策、政府法規、工業標準以及計算算法。在第9章中，將說明業務規則本身並不是軟件需求，因為它的存在已經超齣瞭任何特定軟件應用的範圍。然而，它們又經常決定著係統為瞭切閤相關規則而必須包含哪些功能。正如公司安全策略一樣，業務規則有時又引申齣具體的質量特性，這些特性又以功能的方式由開發人員實現。因此，特定的功能需求可以追溯到具體的業務規則。

　　除瞭功能需求，SRS還包含某些類彆的非功能需求。質量屬性也被人們稱為質量因子、服務需求質量、約束以及“***性”。它們從不同角度描述産品特徵，例如性能、安全性、易用性和可移植性，這些對於用戶、開發人員和維護人員來說都非常重要。還有一些非功能需求描述係統與外部世界的接口，包括與其他軟件係統、硬件組件、用戶以及溝通界麵的關聯。在創建産品的過程中，開發人員的選擇受限於設計和實現約束。

　　非功能需求到底是什麼？

　　要想對組織中的現有需求實踐做一次快速體檢，就需要對比下列問題，看看有多少條齣現於你最近的項目。如果其中有三四條以上與你的經曆相符，那麼本書就是為你量身定做的。

　　在項目接近尾聲時，雖然滿足瞭規範說明，卻不滿足客戶或業務的目標。

　　多年以來，人們從廣義上將軟件産品需求分為功能需求或者非功能需求。功能需求理解起來很容易，它們描述的是係統在不同條件下能夠被用戶觀察到的行為。然而，大多數人都不喜歡“非功能”這個術語。因為這個形容詞強調的是需求不是什麼，並沒有說明需求是什麼。很遺憾，對於這個問題，至今沒有一個令人滿意的答案。

　　功能之外的需求強調的並不是係統要做什麼，其重點在於係統做得有多棒。它們對係統最重要的特徵或屬性進行描述，包括係統的易用性、易用性、安全性和性能等很多特徵，這些都在第14章中有所體現。有些人將非功能需求等同於質量屬性，但這過於狹隘。例如，設計和實現約束也是非功能需求，外部接口需求也是。

　　還有其他一些非功能需求，它們描述的是係統運行環境，例如平颱、可移植性、兼容性和約束。很多産品還受兼容性、監管和發行許可的影響。我們甚至還要考慮到産品的地域性需求，例如用戶的文化、語言、法律、貨幣、專有名詞、拼寫和其他特徵。雖然此類需求被歸入功能需求，但業務分析師仍然可以從中獲得大量的功能，確保係統的所有行為和屬性符閤用戶的預期。

　　盡管有其局限性，但由於沒有一種閤適的替代選項，所以我們在本書中仍使用“非功能需求”這一術語。這類信息的名稱是否準確並不重要，但要保證將它們納入需求獲取和分析活動。交付的産品雖然囊括所有預想的功能，但用戶還是不喜歡，因為它不符閤人們對其産品質量（通常未明確錶達）的預期。

　　一個特性包含一個或者多個邏輯上有關聯的係統功能，能夠為用戶提供價值，這些由一組功能性需求來共同描述。客戶預想的産品特性清單與描述客戶的任務相關的需求不能畫等號。網頁瀏覽器的書簽、拼寫檢查、為運動器械設定定製鍛煉程序、殺毒軟件中病毒庫的自動升級，這些都是典型的特性。特性包含多種用戶需求，每種需求都錶示特定的功能需求必須實現，以便用戶能完成用戶需求中所描述的任務。圖1-2就是一個特性樹，也可以說是一個分析模型，展示的是特性如何層層分解為更小的特性組，這些小特性與具體的用戶需求關聯，最終引齣功能需求（Beatty and Chen 2012）。

　　圖1-2 特性、用戶需求和功能性需求之間的關係

　　為瞭解釋這些不同類型的需求，我們假設在開發某個文本編輯程序的新版本。“在6個月內將非美國地區的銷量增加25%”可以算是一種業務需求。市場部發現參與競爭的産品隻有英語拼寫檢查器，因此他們決定新版本要包括一個多語種拼寫檢查器特性。對應的用戶需求可能包含諸如“為拼寫檢查器選擇語言”“發現拼寫錯誤”和“將詞添加到字典”這樣的任務。拼寫檢查器有很多獨立的功能需求，涉及的操作包括高亮拼寫錯誤的單詞、自動糾錯、顯示建議替代選項、用正確的單詞整體替代拼寫錯誤的單詞。易用性需求明確指定如何使用特定語言和字符集來定位軟件的使用區域。

　　……

前言/序言

　　推薦序：軟件需求的百科全書

　　鄭人傑

　　當前，軟件承載著人類的專業知識和實踐經驗，進入瞭社會生活的各個領域，它已經深入到人們的工作和日常生活，呈現齣無處不在的景象。而軟件産業己成為社會經濟發展的先導性和戰略性産業，成為信息産業和國民經濟新的增長點和重要支柱。與此同時，人們對軟件開發的産品也相應地提齣瞭更高的要求，包括高質量、低成本和易用性，等等。

　　經過多年的實踐，我們開始認識到，確定軟件需求是軟件産品生命周期中最關鍵的一個環節。對於軟件這一不可見的邏輯實體來說，它的研發和傳統産業的産品相比有著很大差彆。軟件需求決定著産品開發的目標，同時，軟件需求也是開發項目策劃的依據。然而，做好軟件需求工作並不容易。如果項目開始時需求工作做得不到位，開發項目的大廈就將建立在不牢固的基礎上。自從上世紀七十年代開始，本人在軟件工程領域的教學、科研和開發實踐中深深地理解到軟件需求工作的重要意義，也曾親身經曆過一些軟件開發項目由於在初期階段對需求工作不夠重視，就匆忙開展後續工作，緻使項目最終受到嚴重後果的懲罰。例如，用戶對交付的産品不滿意，由於不適用不得不返工，延期再交付。然而，返工導緻的額外成本投入不僅會使開發組織的高管人員失望，開發人員也因要付齣更多的勞動而怨聲載道，最終導緻開發組織的聲譽受到影響。實際上，這種人們不願看到的事件不斷發生，也有著它的客觀原因。比如，軟件人員對項目提齣的業務領域知識和相關技術並不熟悉，並且軟件人員通常並不隻是麵對一個應用領域，而是常常在開發一個産品，初歩熟悉一個領域之後，下一個開發任務又會麵臨另一個全新的領域。此外，當今各應用領域的技術和市場情況大多處於迅速發展和演變之中。另一方麵，主觀上經常齣現的情況則是，軟件開發人員未能在項目的需求階段很好地和用戶配閤，充分吸收和聽取用戶的意見，或是接受應用領域知識和技術的培訓，等等。

　　據本人瞭解，多年以來，市麵上也有不少有關軟件需求領域的專業書籍。但本書第3版在我讀後，確實令我感到它的與眾不同，令我贊嘆。沒有想到，這本書竟然對軟件需求工作提供瞭如此全麵、係統、詳盡和具體的闡述。過去很長時間以來，人們對軟件需求工作的理解是片麵的，常常稱其為“需求分析”，以為需求工作隻是對需求進行分析。其實，需求分析固然重要，但還有更為重要的。那就是需求獲取、需求說明、需求驗證和需求管理等。許多軟件項目的教訓錶明，問題齣現的根源恰恰在於需求獲取和需求驗證方麵存在缺陷。

　　本書的另一特點是不僅講原則、方法，而且還對軟件項目的工作提供瞭具體的指導。比如，不同項目類型的需求（第Ⅲ部分）、需求工程的實施（第Ⅴ部分）以及在附錄部分給齣的“需求實踐自評”、“問題問診指南”和“範例需求文檔”都具有很強的指導性、可操作性和可遵循性。無疑，在這些實踐性指導的部分中滲透著作者多年的工作經驗，甚至是親曆的教訓，非常值得廣大讀者認真地學習和吸取。

　　本人以為，在軟件需求方麵本書如此全麵詳盡，又是具有相當深度的指導性讀物，稱之為“軟件需求手冊”並不為過，甚至可以堪稱“軟件需求的百科全書”。

　　高校信息技術類專業的研究生完全可以用本書作為學習參考書。對於高校教師和科研機構的研究人員以及軟件開發機構的開發人員和管理人員都會將其作為必備的參考。

　　正是基於對本書的上述評價，本人願意積極嚮廣大讀者推薦，並且充分相信本書必將在一定程度上促進他們的專業工作，最終成為他們的良師益友。

　　譯序：試問需求從何而來

　　譯者團隊代錶李淳

　　這是一個全民創業、萬眾創新的時代。無論初創企業還是大型企業，無論互聯網巨頭還是傳統行業公司，都在思考這樣的問題：“我們的風口在哪裏？”

　　隨著大數據、O2O、移動互聯、物聯網、開放平颱、雲計算等技術術語越來越快速地進入公眾的視野，為商業創新帶來瞭巨大的機遇，更為新時代的軟件開發提齣瞭機會和挑戰。我們看到，微博、微信、手機打車等一批新興商業模式如雨後春筍般滲入到人們的生活，為人們帶來極大的便利。然而，我們還看到，在這些成功的商業模式身後，流淌著無數“失敗者”的血淚。大量新企業、新項目勞神費力，投入大把時間，大把燒錢，上綫後卻發現提供的産品和服務無人問津。

　　為什麼？因為我們需要的並不是“等風來”，閉門坐在辦公室裏等需求是行不通的。

　　以往，一切都源自老闆的一個想法。然後大傢便會在辦公室裏討論，各種頭腦風暴，然後選擇其中認為不錯的方案來寫需求文檔，進行技術評估……（中間省略一韆步）……直至最後交付。然後，就有瞭大傢都知道的然後，簡直讓人痛心疾首！

　　在我看來，閉門造齣來的需求通常都有這樣的共同特性。

　　1. 希望在上綫的一刹那一舉形成可行的商業模式

　　通常，當一個成功的商業模式被大眾所接受時，人們看到的便是一個具有百萬韆萬級規模的市場群體在進行消費。然而，人們看不到的是這些商業模式成功之前所遭受的屢屢失敗。無疑，這些成功的商業模式在給人們設立瞭標杆之後，也給人們帶來瞭不切實際的幻想：“一定要交付能夠一舉成功的産品或服務。”

　　2. 假設最初的想法是正確的

　　不切實際的預期伴隨著一種扭麯的力場，讓人誤將想法假設為事實。於是，幾乎沒有人認真思考最初的想法是否真的正確？

　　信息洪泛使得未來是愈發不可精確預知，試問每個想法能有多大的可能性是正確的呢？

　　3. 認為專傢就在辦公室裏

　　頭腦風暴，討論，最終民主集中為辦公室裏的權威人士，可能是老闆、上級甚至在辦公室裏工作年頭最長的那個人。他們的決策依據往往是經驗。然而，當你滿懷希望想要創新的時候，就已經意味著沒有人會有經驗，所有意見決策都往往是靠猜的。

　　4. 上綫之前，知道這個想法的客戶數量為0

　　為瞭確保我們“一舉成名”，讓那個不切實際的幻想變成現實，我們會對外嚴格保密，一齣辦公室便絕口不提。因為我們害怕這個想法被彆人搶走，更害怕客戶否定尚未達到我們心中“完美標準”的産品。然而，飛得越高摔得越痛，當上綫時纔開始尋找客戶，我們的幻想將宣告災難性的破滅。

　　幸運的是，近十年間，人們開始意識到這一問題，發現正確的需求變得愈發重要，各種新的創新方法不約而同地嚮人們傳達齣下麵這四大新的理念。

　　1. 成功的商業模式需要依靠對正確需求的持續積纍

　　商業模式的成功需要一個從0到1的過程，而非一蹴而就。在這個過程中，失敗的可能性遠遠超過成功，所以為瞭更快地成功，就要快速而頻繁地失敗，更快速從失敗中學習，更快地積纍點滴成功。拋棄不切實際的幻想，不要再苛求“完美”，主動擁抱失敗，讓商業模式自然生長齣來！

　　2. 要獲得正確的需求，需要專傢不斷否定你的猜想

　　擁抱失敗不等於魯莽地冒險，漫無目的地四處挖井，而是要使需求不再失敗。因此，最好辦法就是讓專傢頻繁地對你的猜想證僞，用反饋和數據來指導接下來的行動，直到需求無限趨近於恰到好處。

　　3. 真正的專傢是會購買你的産品或服務的客戶

　　需求之所以有存在的意義，歸根結底是因為有客戶願意為此買單。因此，要想做到擁抱失敗，持續證僞，你要做的便是不斷與客戶溝通，找齣這兩個問題的答案：1）為什麼你的産品無法吸引他們的注意力？2）為什麼他們不會為你所假設的需求買單？

　　真正的專傢不是辦公室中的權威，客戶纔是！主動和他們溝通，積極嚮他們提問，收集他們的數據，聆聽他們的心聲，讓他們告訴你什麼是錯，什麼是對。

　　4. 走齣辦公室

　　既然客戶不在你的辦公室，世界那麼大，何不齣去看看呢？走齣辦公室，找到客戶，發現真正的需求！

　　在此，我想對本書的作者Karl Wiegers和Joy Beatty緻敬，他們一直在告訴我們一個道理：“正確的需求高於正確地需求。”我還要衷心感謝一同翻譯此書的譯者、編輯、設計等，感謝清華大學齣版社為我們帶來如此經典而權威的著作。

　　再次，願所有讀者能與我們一起共勉：“不要等風來，走齣辦公室，去找風！”

　　前言

　　幾十年過去瞭，許多軟件組織仍然難以瞭解、記錄和管理自己的産品需求。之所以如此多的信息技術項目無法完全成功，主要原因在於用戶輸入匱乏、需求不完整、需求變化以及對業務目標的誤解。一些軟件團隊疏於從客戶和其他來源收集需求。客戶往往沒有時間或耐心參與需求工作。在許多情況下，項目參與人員甚至無法就“需求的確切含義”達成共識。正如有作者所指齣的：“工程師寜願破譯Kingsmen 1963年的經典派對歌麯Louie Louie，也不願意破譯客戶需求。”（PerterSon 2002）

　　十多年前，《軟件需求（第2版）》齣版發行。十年對技術界而言真的是一段漫長的時間。許多事情在這期間已經發生瞭變化，但仍然有一些沒有變。過去十年中，軟件需求主要呈現齣以下幾個趨勢。

　　* 業務分析被認為是一門專業的學科，專業認證和組織已經興起，比如“國際業務分析師協會”和“國際需求工程協會”。

　　* 基於數據庫的需求管理工具和需求開發輔助工具（如原型、建模和仿真）日趨成熟。

　　* 敏捷開發方法的使用越來越廣泛，處理敏捷項目需求的技術也在不斷演進。

　　* 可視化模型越來越廣泛地應用於闡述需求知識。

　　那麼，哪些不曾發生變化呢？這一話題重要而且意義深遠，原因有兩個。其一，許多軟件工程和計算機科學的本科教材依然不夠重視需求工程（包括需求開發和需求管理）的重要性。其次，我們這些軟件領域從業人員骨子裏一直癡迷於通過技術和過程方案來應對挑戰。其實有時並未意識到需求收集以及許多軟件和係統項目工作中，普遍麵臨的最大挑戰是人與人如何互動。盡管許多工具都可以用於幫助地理分散的人們展開有效的協作，但沒有哪一種神奇的新技術能夠將此自動化。

　　我們相信，第2版中提到的實踐依然廣泛有效並適用於軟件項目的需求開發和管理。為瞭滿足具體情況的需要，業務分析師、産品經理或産品負責人需要發揮自己的創造力，對這些實踐進行精心調整和測量。在第3版中，新增一章介紹敏捷項目中的需求把控，其他幾章中也增加有新的內容，介紹如何在敏捷開發環境中使用和調整需求實踐。

　　在軟件開發中，溝通總是重於計算機操作，但在教學課程和項目工作中，卻往往注重計算機操作而忽視人際溝通。本書提供數十種工具用於加強溝通和幫助軟件從業人員、管理人員、市場營銷人員以及客戶使用更有效的需求工程方法。這裏提及的技術是一套工具包，其中包含主流的“優秀實踐”，而非奇炫的新技術或某種聲稱能解決所有需求問題的復雜方法論。本書講瞭無數趣聞軼事和八卦故事，都是真人真事，講述著典型的需求相關經曆，你可能也曾有過相關的經曆。可以找到“真實故事”圖標，瞭解精選自各種項目經曆的真人真事。

　　自從本書1999年第1版問世以來，我們曆經項目無數，並且已授課好幾百場，為來自不同規模和類型的企業和政府機構的學員傳授軟件需求知識。我們發現，無論是本地團隊還是分布式團隊，無論使用傳統開發方法還是敏捷開發方法，這些實踐對任何項目幾乎都有幫助。這些技術不隻適用於軟件項目，還適用於硬件和係統工程項目。與其他任何技術性實踐一樣，需要憑藉良好的判斷力和經驗瞭解如何纔能最有效地使用這些方法。要將這些實踐想象成工具，藉助於這些工具，可以確保在項目中與閤適的人進行有效的溝通。

　　本書的價值

　　在所有可以采取的軟件過程改進中，讓人們收獲最多的就是改進需求實踐。我們介紹的技術都是實踐證明有效的，能夠從以下幾個方麵提供幫助。

　　* 從項目開始，寫高質量的需求，盡可能減少返工，盡可能提升生産率。

　　* 交付高質量的信息係統和商業産品，實現業務目標。

　　* 管理範圍蠕變和需求變更，既緊盯目標，又確保可控。

　　* 獲得更高客戶滿意度。

　　* 降低維護、改進和支持成本。

　　我們的目標是幫助改進所使用的需求流程，更好地收集和分析需求、編寫和確認需求規範以及在整個軟件開發周期中管理需求。我們所介紹的技術全部都是務實求真的。我們兩人已經多次使用這些技術，而且每次這樣做，總是能夠得到很好的結果。

　　本書的讀者

　　包括軟件在內的任何係統，隻要需要定義或瞭解其需求，任何人都能從這本書中找到有用的信息。本書主要麵嚮開發項目中擔任業務分析師或需求工程師的個人或群體，既包括全職專傢，也包括臨時填補分析師角色的其他團隊成員。第二個讀者群體包括架構師、設計師、開發人員、測試人員以及必須瞭解與滿足用戶預期並參與創建和評審有效需求的其他技術團隊成員。負責製定（使産品獲得商業成功的）功能和屬性規範的市場人員和産品經理會發現這些實踐非常有用。項目經理能從本書中學到如何對項目需求工作進行規劃和跟蹤，如何處理需求變更。此外，乾係人也屬於本書讀者群體，為瞭滿足業務、功能和質量需要，他們也會參與産品定義工作中。對於最終用戶、需要購買或承建軟件産品的客戶以及許多其他乾係人，本書能夠幫助他們瞭解需求流程的重要性及其所扮演的角色。

　　內容概覽

　　本書共五個部分。第I部分從相關定義切入。如果是企業內部的技術人員，請與關鍵客戶分享第2章中的“客戶開發夥伴”小節。第3章概述幾十種需求開發和管理的優秀實踐以及一個需求開發流程整體框架。業務分析師的角色是第4章的主題，這一角色還有很多其他的名稱。

　　第II部分首先講項目的業務需求定義技術。接著專門介紹如何找到正確的客戶代錶，如何從他們那裏收集需求，如何記錄用戶需求、業務規則、功能性需求、數據需求以及非功能性需求。第12章介紹許多可視化模型，從不同角度闡述需求並對自然語言文本加以補充。第15章講述使用原型降低風險。隨後介紹需求排優先級、需求確認、需求重用的方法。最後介紹需求如何影響項目工作的其他方麵。

　　第III部分屬於新增內容，各章為各種具體類型的項目推薦最有效的需求方法，具體類型包括：開發任何類型産品的敏捷項目、改進型和替換型項目、引入軟件包方案的項目、外包項目、業務過程自動化項目、業務分析項目以及嵌入式和其他實時係統。

　　需求管理的原則和實踐是第IV部分的主題，重點講述用於處理需求頻繁變更所需的技術。第29章介紹如何進行需求跟蹤，如何將獨立的需求與原始需求連接起來，如何將需求與下遊的開發交付物連接起來。第V部分最後介紹用戶改進團隊需求開發和需求管理行為的商業工具。

　　本書的最後一部分是第V部分，這一部分幫助你從概念走嚮實踐。第31章幫助你嚮團隊開發流程中導入新的需求技術。第32章介紹項目中一些需求相關的常見風險。附錄A的自我評估能夠幫助你選擇改進時機成熟的領域。其他兩個附錄包括一個疑難解答和一些需求文檔樣例，以便你能夠看到全景。

　　案例學習

　　為瞭說明本書所介紹的方法，我們提供若乾事例，這些事例來自我們做過的真實項目，尤其是化學品追蹤係統這個中型信息係統。彆擔心，瞭解這個項目不需要懂化學。案例過程中的討論貫穿全書始終。無論組織要構建什麼軟件，這些對話都能與你産生共鳴。

　　從原則到實踐

　　鼓起勇氣，剋服障礙進行變革，並將新知識付諸於行動，是很睏難的事情。為幫助進行需求改進，大多數章都在最後給齣行動練習，幫助你立即開始學以緻用。許多章都提供建議模闆，包括各種需求文檔、評審檢查清單、需求排優先級電子錶格、變更控製流程以及許多其他的流程資源。這些內容可以在本書配套內容網站下載，網址為http://aka.ms/SoftwareReq3E/files，可以通過它們馬上上手。從小的改進開始，從現在開始，宜早不宜遲。

　　有些人不願意嘗試新的需求技術。使用本書來教一教自己的同行、客戶以及經理。提醒他們以往項目中所遇到的需求相關問題，並和他們討論嘗試使用新方法能帶來哪些潛在的收益。

　　要想使用更好的需求開發實踐，無需啓動一個新的開發項目。第21章討論瞭各種技術在改進型和替換型項目中的用法。增量實施需求實踐是一種低風險的過程改進方法，可以為你的下一個重要項目做足準備。

　　需求開發的目標是積纍一係列足夠好的需求，使團隊能夠以可接受的風險水平設計和構建産品的下一個部分。需要對需求工作投入足夠的重視，纔能降低返工、産品驗收不通過以及計劃“爆炸”所帶來的風險。本書提供的工具能夠讓正確的人落實到行動上，為正確的産品開發正確的需求。

　　勘誤&本書支持

　　我們已經力求確保本書及其輔助內容的準確性。在本書齣版發行之後，書中的任何錯誤都將列在以下網址：http://aka.ms/SoftwareReq3E/errata。

　　如果發現未列齣的錯誤，同樣可以在這裏進行報告。

　　如果需要其他支持，請發送電子郵件至微軟齣版社圖書支持郵箱：mspinput@microsoft.com。

　　請注意，上述地址不提供對微軟軟件産品的支持。

　　讓我們聆聽你的心聲

　　在微軟齣版社，讀者的滿意是我們的頭等大事，讀者反饋是我們最有價值的資源。請告訴我們你對本書的想法：http://aka.ms/tellpress。

　　調查很短，我們會閱讀您的每一個評論和想法。先感謝您的貢獻！

　　保持聯係

　　讓我們保持順利的溝通！我們的推特地址是http://twitter.com/MicrosoftPress。

　　緻謝

　　寫這樣一本書離不開整個團隊的努力，遠遠不隻是我們兩位作者的貢獻。很多人花時間對書稿進行評審，提齣無數改進建議，我們對此深錶感謝。我們特彆感謝Jim Brosseau、Joan Davis、Gary K. Evans、Joyce Grapes、Tina Heidenreich、Kelly Morrison Smith以及Joyce Statz博士為我們提齣寶貴意見。其他評審人員還包括Kevin Brennan、Steven Davis、Anne Hartley、Emily Iem、Matt Leach、Jeannine McConnell、Yaaqub Mohamed以及John Parker。我們還要感謝Tanya Charbury、Mike Cohn、Alex Dean博士、Ellen Gottesdiener、Shane Hastie、James Hulgan、Phil Koopman博士、Mark Kulak、Shirley Sartin、Rob Siciliano以及Betsy Stockdale，他們從各自的專業角度對具體章節提供瞭非常詳盡的意見。我們特彆感謝Roxanne Miller和Stephen Withall，感謝他們深刻的見解和無私的參與。

　　我們與許多人就書中的主題進行瞭探討，從他們的個人經驗和他們發給我們的資源材料中，我們學到很多東西。我們對Jim Brosseau、Nanette Brown、Nigel Budd、Katherine Busey、Tanya Charbury、Jennifer Doyle、Gary Evans、Scott Francis、Sarah Gates、David Gelperin博士、Mark Kerin、Norm Kerth、Scott Meyers博士、John Parker、Kathy Reynolds、Bill Trosky、Ricardo Valerdi博士以及Ian Watson博士的貢獻錶示贊賞。我們還要感謝讓我們在“真實故事”中分享其趣聞軼事的人。

　　Seilevel公司的許多工作人員也為本書提供瞭大力支持。他們對具體章節進行評審、參與快速意見和體驗調查、分享他們寫的博客、編輯定稿、繪圖並幫助我們解答各類業務問題。在此我們要感謝Ajay Badri、Jason Benfield、Anthony Chen、Kell Condon、Amber Davis、Jeremy Gorr、Joyce Grapes、John Jertson、Melanie Norrell、David Reinhardt、Betsy Stockdale以及Christine Wollmuth。他們的工作為我們減輕瞭壓力。我們特彆贊賞Candase Hokanson對編輯工作的投入。

　　還要感謝微軟齣版社的許多工作人員，包括組稿編輯Devon Musgrave和項目編輯Carol Dillingham，S4Carlisle Publishing Services的項目編輯Christian Holdener、編審人員Kathy Krasuse。感謝校對人員Nicole Schlutt、索引製作人員Maureen Johnson、排版人員Sambasivam Sangaran以及産品製作人員Balaganesan M.、Srinivasan R.與Ganeshbabu G.。作者Karl對Devon Musgrave和Ben Ryan長期以來建立的閤作和友誼給予高度評價。在我們這麼多年的需求培訓班中，有上韆名學員提供反饋和問題，激勵著我們深入思考需求問題，我們從中得到瞭莫大的幫助。我們的谘詢經曆和讀者提齣的引人深思的問題，使我們不斷瞭解到從業人員在日常工作中遇到的睏難並幫助我們思考。請與我們分享你的經曆，發送電子郵件到 karl@processimpact.com 或者 joy.beatty@seilevel.com。

　　一如既往，Karl要感謝他的妻子Chris Zambito。一如既往，整個過程中她都很有耐心而且脾氣極好。Karl還要感謝Joy鼓勵他參與這個項目中以及Joy對這個項目聽做的瞭不起的貢獻。與Joy一起工作真的很開心，她還使這本書增添瞭很多價值。很高興能夠和她一起不斷討論、一起艱難決定並在交稿前一起對書稿進行精雕細琢。

　　Joy特彆感謝他的丈夫Tony Hamilton這麼快就再次支持她的寫作夢想；還有她的女兒Skye，讓她每天輕鬆保持工作與生活的平衡；還有Sean和Estelle，讓傢庭時光充滿歡樂。Joy還想專門感謝Seilevel的全體員工，感謝他們齊心協力推動軟件需求領域嚮前發展。她特彆感謝兩位同事兼朋友：Anthony Chen對她寫這本書提供瞭至關重要的支持；Rob Sparks不斷鼓勵Joy為此付齣努力。最後，Joy重點感謝Karl允許她和他一起閤著，每天都教她一些新知識，百分之百的愉快閤作！