來到做產(chǎn)品的第4年硼控，工作中常常聽到這樣的聲音：

“我這里有一個需求要緊急做一下”

“過來討論一下這個需求”

“這是個偽需求，我們不必耗費(fèi)這么多時間”

“它真的看上去那么簡單嗎”

“這個需求我沒明白动壤，我們再討論一下”

“不是說好就這些需求了嗎？怎么又變更了淮逻？還新增了這么多琼懊？”

關(guān)于需求的撕逼也從未停歇，軟件行業(yè)爬早、互聯(lián)網(wǎng)行業(yè)哼丈，每個從業(yè)者每天都會許多需求打交到，為此我們開了數(shù)不盡的三方會議凸椿，數(shù)不盡的評審會議削祈，加班出方案、設(shè)計(jì)、開發(fā)髓抑，可是需求呢咙崎？似乎并未越辯越明，產(chǎn)品也在一次又一次的多方妥協(xié)下推著向前......

需求出了問題會造成大量的加班返工吨拍，對代碼進(jìn)行迭代的代價(jià)更高褪猛，不僅是資源的浪費(fèi)，還會挫傷團(tuán)隊(duì)士氣羹饰，對需求有足夠的認(rèn)識團(tuán)隊(duì)才能開發(fā)出適合的產(chǎn)品伊滋。

需求是一種極其重要的投資。

我們大都知道队秩，需求軟件開發(fā)和軟件管理活動的基礎(chǔ)笑旺，打造一流產(chǎn)品的前提，從業(yè)人員都應(yīng)該致力于需求實(shí)踐活動馍资。

那么需求究竟是什么筒主？它包含了那些內(nèi)容？我們又應(yīng)該如何管理它鸟蟹？為什么這樣做乌妙？相關(guān)的人員？

帶著這問題開啟本書的分享建钥，這也是這本書的行文邏輯藤韵，圍繞著需求的三問作者將會幫助我們改進(jìn)所使用的需求流程，更好地收集和分析需求熊经、編寫和確認(rèn)需求規(guī)范以及在整個軟件開發(fā)周期中管理需求泽艘。

第一章 軟件需求本質(zhì)

需求的定義

我們平日工作能耳熟能詳有關(guān)需求的字眼：用戶需求、軟件需求奈搜、業(yè)務(wù)需求悉盆、功能需求、系統(tǒng)需求馋吗、產(chǎn)品需求焕盟、項(xiàng)目需求、用戶故事宏粤、特性或者約束條件脚翘，計(jì)算機(jī)編程技術(shù)已經(jīng)興起了很多年頭，但從業(yè)者仍對“需求”定義爭執(zhí)不休绍哎，在作者看來沒有必要延續(xù)這種爭執(zhí)来农，，在團(tuán)隊(duì)中最重要的是在定義上達(dá)成共識崇堰，這里他也列出了需求定義的參考：

Flan Sommerville and Pete Sawyer(1997)所提出的觀點(diǎn)：需求是對我們應(yīng)當(dāng)執(zhí)行的任務(wù)的規(guī)范說明沃于。它描述系統(tǒng)的行為特性或?qū)傩陨В梢允且环N對系統(tǒng)開發(fā)進(jìn)程的約束。

需求的層次

過往的經(jīng)驗(yàn)中繁莹，當(dāng)我來到一個新的團(tuán)隊(duì)檩互，在查閱需求文檔和原型設(shè)計(jì)時，雖然有部分關(guān)于功能和交互的說明咨演，但光看這些文檔我往往不太了解用戶要完成什么任務(wù)闸昨，這些內(nèi)容我都是在測試人員協(xié)助我體驗(yàn)產(chǎn)品走流程時才清楚的。

業(yè)務(wù)需求：開發(fā)產(chǎn)品的組織或者獲取產(chǎn)品的客戶所需的高層次業(yè)務(wù)目標(biāo)薄风。（組織為什么要執(zhí)行系統(tǒng)饵较，希望獲得的業(yè)務(wù)收益，關(guān)注點(diǎn)在于組織或提出系統(tǒng)要求的客戶有哪些業(yè)務(wù)目標(biāo)遭赂。比如航空公司希望減少柜臺的工作人員）

用戶需求：描述系統(tǒng)在特定條件下展現(xiàn)的行為循诉。（描述了用戶使用產(chǎn)品必須完成的任務(wù)，用戶滿意度最為關(guān)鍵的產(chǎn)品特性或特征嵌牺，通過用例打洼、用戶故事、時間響應(yīng)表來表示）

功能需求：特定用戶群必須能夠用系統(tǒng)所完成的目標(biāo)或任務(wù)逆粹，或者是用戶期望有的產(chǎn)品屬性（產(chǎn)品在特定條件下所展示出來的行為，主要描述開發(fā)人員需要實(shí)現(xiàn)的功能以滿足用戶需求）

非功能需求：質(zhì)量屬性（易用性炫惩、安全性僻弹、性能）、設(shè)計(jì)和實(shí)現(xiàn)約束他嚷、外部接口蹋绽、系統(tǒng)運(yùn)行的環(huán)境（平臺、可移植性筋蓖、兼容性卸耘、約束）、監(jiān)管和發(fā)行許可粘咖、地域的影響蚣抗，保證這些內(nèi)容都納入需求分析中，功能之外的需求強(qiáng)調(diào)的并不是系統(tǒng)要做什么瓮下，其重點(diǎn)在于系統(tǒng)做得有多棒翰铡。

書中更有典型案例，幫助我們理解需求的層次讽坏。p11（pdf-p36）

平時工作中锭魔，我們多接觸產(chǎn)品說明文檔，其實(shí)就是軟件需求規(guī)范說明（srs）路呜，大多描述的是產(chǎn)品的功能需求迷捧，用于開發(fā)织咧、測試、質(zhì)量保障漠秋、項(xiàng)目管理和相關(guān)項(xiàng)目功能笙蒙。所以才會出現(xiàn)當(dāng)一個新人進(jìn)入團(tuán)隊(duì)，接手一個已經(jīng)迭代幾版的項(xiàng)目時會不清楚業(yè)務(wù)及用戶需求的問題膛堤，在以后的工作中我們就可以分這些層次描述需求說明手趣，確保團(tuán)隊(duì)中每個人都對產(chǎn)品需求有清晰的認(rèn)識。

需求工程

需求工程涵蓋了需求開發(fā)和需求管理肥荔，需求開發(fā)又包括：獲取-分析-規(guī)范說明-驗(yàn)證绿渣。

需求獲取涵蓋需求發(fā)現(xiàn)的所有活動，例如訪談燕耿、研討會中符、文檔分析、原型等誉帅。（識別確定用戶群淀散、理解用戶任務(wù)和目標(biāo)及相關(guān)的業(yè)務(wù)目標(biāo)、應(yīng)用的環(huán)境蚜锨、客戶對產(chǎn)品的預(yù)期）

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 分析需求涉及深入并準(zhǔn)確理解每個需求档插，然后將各個需求以不同的方式表達(dá)出來。 （分析收集到的信息——進(jìn)行區(qū)分亚再、細(xì)分——引出功能需求郭膛、質(zhì)量屬性 —— 將需求分配給系統(tǒng)架構(gòu)所定義的軟件組件？氛悬？——協(xié)商優(yōu)先級）

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 需求規(guī)范說明以一種連貫并結(jié)構(gòu)清晰的方式來表達(dá)和存儲收集到的需求知識则剃。（ 這一步就主要是編寫文檔和圖表了，以便團(tuán)隊(duì)及相關(guān)利益關(guān)系人閱讀如捅、檢查和使用棍现。）

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 需求驗(yàn)證是指確認(rèn)需求信息是正確的，能使開發(fā)人員制定出能滿足業(yè)務(wù)目標(biāo)的解決方案镜遣。（交付相關(guān)文檔和設(shè)計(jì)前解決所有問題己肮，開發(fā)驗(yàn)收測試和標(biāo)準(zhǔn)???能滿足客戶需要達(dá)成業(yè)務(wù)目標(biāo)）

這些過程都不是以一個簡單的線性順序來實(shí)施的，需求開發(fā)過程中需要反復(fù)考量烈涮。

沒有“完美的”需求

需求管理主要是為了預(yù)測和協(xié)調(diào)實(shí)際存在的變更朴肺，最小化對項(xiàng)目的破壞。（確定基線坚洽、通過評審的需求戈稿、計(jì)劃發(fā)布——評估可能的變更——保持需求與項(xiàng)目同步——需求之間的關(guān)系和依賴——跟蹤對應(yīng)的設(shè)計(jì)、代碼讶舰、測試）p16（pdf-41圖表闡釋了需求開發(fā)和管理的區(qū)別）

常見的需求風(fēng)險(xiǎn)p18-20

用戶參與度不夠

規(guī)劃不當(dāng)

用戶需求蔓延

需求模棱兩可

鍍金

忽視干系人

我們可以通過書中列舉的這些問題鞍盗，檢視自己所在的項(xiàng)目中是否存在同樣的問題需了，并嘗試用書中給出的方法予以解決，如持續(xù)的保持與用戶溝通般甲，我個人近期負(fù)責(zé)小程序的醫(yī)學(xué)題庫肋乍，聯(lián)系到了以前的學(xué)醫(yī)的同學(xué)，了解他們?nèi)绾慰悸毞Q的敷存，網(wǎng)上刷題的意愿以及練題的習(xí)慣墓造，對產(chǎn)品設(shè)計(jì)都有很多幫助。

第一章不僅僅包含以上提到的內(nèi)容锚烦，看的過程中甚至覺得每個字都是重點(diǎn)觅闽，這里只列出了個人認(rèn)為重要的小節(jié)。

第二章 從客戶角度審視需求

客戶和干系人

作者特別提出了干系人這個概念涮俄，是指積極參與項(xiàng)目的某個人蛉拙、群體或組織，它們可能會受項(xiàng)目過程和結(jié)果的影響或影響項(xiàng)目的過程和結(jié)果彻亲。潛在的干系人涵蓋很廣孕锄，從直接用戶到項(xiàng)目團(tuán)隊(duì)內(nèi)人員，都可以是干系人苞尝。

為一個項(xiàng)目尋找潛在干系人的時候畸肆，應(yīng)該廣撒網(wǎng)以免忽略一些重要的群體。然后將候選干系人列表縮小為核心人選宙址，這些人能夠帶給你所需的信息恼除，確保你理解所有項(xiàng)目的需求和約束，使團(tuán)隊(duì)能夠交付正確的解決方案曼氛。

書中的反例：如沒有在項(xiàng)目前期確定會受系統(tǒng)影響的全部干系人，到了交付時期令野，可能就會存在功能上的偏差舀患，導(dǎo)致項(xiàng)目延期。

所有干系人共享的同一個目標(biāo)：構(gòu)建一個既實(shí)現(xiàn)業(yè)務(wù)價(jià)值又可以使所有干系人受益的產(chǎn)品气破×那常客戶和開發(fā)團(tuán)隊(duì)要基于這個目標(biāo)進(jìn)行通力合作。

客戶既有權(quán)利也有相應(yīng)的義務(wù)和責(zé)任 p26（pdf-51）

書中詳細(xì)介紹了客戶的權(quán)利和義務(wù)现使，我們在進(jìn)行需求溝通前低匙，可以多和客戶討論這些權(quán)利和義務(wù)（如：用客戶的語言溝通、需求變更碳锈、收到滿意的產(chǎn)品顽冶；向分析師或產(chǎn)品分享業(yè)務(wù)知識、尊重需求可行性的評估售碳、尊重開發(fā)流程等）强重，更好推進(jìn)需求溝通過程绞呈。否則就會出現(xiàn)：

“我需要xxxx功能，什么時候能做好间景？”這樣尷尬的情況佃声。

或許我們沒有和客戶科普這些知識，直接開始了需求開發(fā)倘要，但摩擦和沖突總會在需求溝通中出現(xiàn)不是嗎圾亏？所以倒不如一開始讓他們了解并接受這些權(quán)利和義務(wù)。

建立尊重需求的企業(yè)文化

有的團(tuán)隊(duì)并不尊重需求開發(fā)封拧，認(rèn)為這并不是非做不可志鹃，但是不重視需求開發(fā)的代價(jià)是顯而易見的：出現(xiàn)意料之外的返工、延期或軟件品質(zhì)低劣哮缺。必須讓每個人都了解公司和客戶之間曾經(jīng)因?yàn)樾枨髥栴}而經(jīng)歷的痛苦弄跌。

和開發(fā)測試人員一起評審需求，讓這些“眼尖”的人提前加入需求評審尝苇，開發(fā)人員經(jīng)常能夠提供其他人想不到的信息铛只，比如如何用更簡單的方式完成任務(wù)：什么功能實(shí)現(xiàn)起來非常耗時；哪些是不必要的設(shè)計(jì)約束糠溜；是否有遺漏的需求淳玩，比如異常處理；如何利用技術(shù)創(chuàng)造機(jī)遇非竿，等等蜕着。

領(lǐng)導(dǎo)必須理解這一點(diǎn)：組織需要把高效業(yè)務(wù)分析和需求工程能力作為自己的戰(zhàn)略性核心競爭力。

對需求達(dá)成一致

客戶：承認(rèn)需求描述了他們的需要

開發(fā)：承認(rèn)理解需求并且認(rèn)為它們是可實(shí)現(xiàn)的

測試：承認(rèn)需求是可驗(yàn)證的

管理層：承認(rèn)需求可以達(dá)成他們的業(yè)務(wù)目標(biāo)

但我們要明白大多數(shù)時候红柱，我們不可能在項(xiàng)目早期知道所有的需求承匣，而且需求也會隨著時間變化。

書中也提到在達(dá)不成共識時锤悄，先小心的推進(jìn)項(xiàng)目韧骗，并持續(xù)與干系人保持溝通，要讓他們知道如果要改變需求也有一個成熟的流程零聚。

以上是第二章的主要內(nèi)容袍暴，還是一樣，內(nèi)容很多隶症，都是非常值得借鑒的經(jīng)驗(yàn)政模，書中也不止都是概念和經(jīng)驗(yàn)之談，每章最后都給出了行動表蚂会、可以實(shí)踐的實(shí)例淋样，讓我們著眼于行動。

第三章 需求工程優(yōu)秀實(shí)踐

為了應(yīng)對每個項(xiàng)目的挑戰(zhàn)颂龙，我們需要一個專業(yè)的技能工具箱习蓬，里面積累了各種開發(fā)需求纽什、管理需求的技能。這樣的臨時方案很難取得好的結(jié)果躲叼。作者列出這些需求工程優(yōu)秀實(shí)踐豐富我們的工具箱芦缰。

這些實(shí)踐不會普遍適用于所有的情況，要想應(yīng)用好這些實(shí)踐枫慷，需要利用判斷力让蕾、常識和經(jīng)驗(yàn)。即使是最佳實(shí)踐或听，資深業(yè)務(wù)分析師也要根據(jù)適當(dāng)?shù)那闆r慎重選擇探孝、應(yīng)用和采納。

針對不同部分的需求誉裆，最好實(shí)施不同的實(shí)踐顿颅。舉個例子:針對客戶端來說，使用用例（use case）或用戶界面原型會有幫助足丢，但對服務(wù)器端來說粱腻，接口分析則更有價(jià)值。

獲日兜：

定義產(chǎn)品愿景和項(xiàng)目范圍：愿景和范圍文檔里面包含了產(chǎn)品的業(yè)務(wù)需求绍些，可以使干系人對產(chǎn)品有一致的理解，范圍界定了哪些功能應(yīng)該（或不應(yīng)該）出現(xiàn)耀鸦。

分析：

需求分析包括需求的精煉——使所有干系人都能夠理解并檢查出錯誤柬批、遺漏以及其他缺陷；將概要需求分解成更細(xì)袖订、粒度層次更合適的需求氮帐，建立原型，評估可行性以及協(xié)商優(yōu)先級洛姑。其目標(biāo)是產(chǎn)出符合質(zhì)量和精確性要求的需求揪漩，項(xiàng)目經(jīng)理就可以提供合理的項(xiàng)目計(jì)劃，技術(shù)人員也可以進(jìn)行下一步的設(shè)計(jì)吏口、構(gòu)建以及測試。

需求建模：通過圖表的方式將需求可視化冰更。模型可以揭示出錯誤的产徊、不一致的、缺失的或是冗余的需求蜀细。這樣的模型包括數(shù)據(jù)流圖舟铜、實(shí)體關(guān)系圖、狀態(tài)轉(zhuǎn)移圖奠衔、狀態(tài)表谆刨、會話圖和決策樹等（Beatty and Chen 2012）塘娶。更多關(guān)于建模的信息請參見第5章、第12章和第13章痊夭。

規(guī)范說明：

明確需求來源：需求來源確定了需求的合理性刁岸，通過記錄對應(yīng)的干系人，可以在變更需求時通知他們她我。

記錄業(yè)務(wù)規(guī)則：包括公司政策虹曙、政府法規(guī)、標(biāo)準(zhǔn)和算法番舆。與項(xiàng)目需求相互獨(dú)立酝碳，存在周期比項(xiàng)目更長。有些規(guī)則會引申出功能需求恨狈，反過來又會強(qiáng)化這些規(guī)則疏哗，所以要定義這些需求及其對應(yīng)的規(guī)則之間的鏈接關(guān)系。更多信息請參見第9章禾怠。

記錄非功能需求：思維必須跳出功能的局限返奉，才能想到讓產(chǎn)品成功的一些質(zhì)量特性柄慰。這些特性包括性能平挑、可靠性贫途、易用性吧黄、可修改性等晦攒。同樣纠脾，要記錄外部接口需求巩螃、設(shè)計(jì)和實(shí)現(xiàn)上的約束璧针、國際化方面的考慮及其他的非功能需求坦袍。更多信息請參見第14章十厢。

驗(yàn)證：

驗(yàn)證保證需求的正確性、展示期望的質(zhì)量特性并滿足用戶需要捂齐。

測試需求：為需求寫測試蛮放，要你考慮系統(tǒng)是否正確實(shí)現(xiàn)系統(tǒng)功能。記錄特定情況下產(chǎn)品的預(yù)期行為奠宜；與客戶一起走查包颁，確保它反應(yīng)了用戶的真實(shí)期望；與需求相對應(yīng)压真，確保沒有需求被遺漏娩嚼；

模擬需求：用商業(yè)工具來模擬計(jì)劃中的系統(tǒng)。迅速搭建一個可運(yùn)行的系統(tǒng)模型滴肿，讓用戶與模擬系統(tǒng)交互來驗(yàn)證需求和作出設(shè)計(jì)決策岳悟。

需求管理：

建立需求變更流程：變更流程應(yīng)當(dāng)定義如何提出、分析和解決需求變更。缺陷跟蹤工具可以支持這種變更控制流程贵少。第28章呵俏。

維護(hù)一個需求跟蹤矩陣：維護(hù)一個需求可跟蹤矩陣把每個功能需求與設(shè)計(jì)、實(shí)現(xiàn)它的代碼以及驗(yàn)證它的測試相互聯(lián)系起來滔灶。第29章普碎。

本章作者從7個方面簡單介紹了需求工程的優(yōu)秀實(shí)踐，想要具體了解這些內(nèi)容可以詳細(xì)查閱書中對應(yīng)的章節(jié)宽气，這里僅按需求分析和管理列出了本人以前工作沒注意到和不夠了解的方法随常。

以上就是《軟件需求》第一部分的分享，除了前三章萄涯，作者單獨(dú)列出第四章介紹了業(yè)務(wù)分析師绪氛，我們以后單獨(dú)分享。