全文約6300字磷脯，閱讀需12分鐘柠衅。
前言：《軟件需求工程》是軟件開發(fā)和產(chǎn)品經(jīng)理的必修課氛赐，本文是根據(jù)分享膠片整理而成筷登，作為針對新人產(chǎn)品經(jīng)理的簡介性文章剃根，目的是讓產(chǎn)品經(jīng)理在開始需求分析工作之前，對軟件需求的相關常識有所理解前方。
1. 需求工程
需求分析階段作為軟件生命周期的第一個階段狈醉，其重要性毋庸置疑。在20世紀80年代惠险，逐步形成了軟件工程的子學科——軟件需求工程苗傅。90年代后，需求工程成為軟件界研究的重點之一班巩。從1993年起渣慕，每兩年舉辦一次需求工程國際研討會（ISRE）；1994年起抱慌，每兩年舉辦一次需求工程國際會議（ICRE）逊桦。一些關于需求工程的工作小組相繼成立，使需求工程的研究得到了迅速進展遥缕。
1.1 需求的定義
IEEE軟件工程標準詞匯對需求的定義：
1）用戶解決問題或達到目標所需的條件或能力卫袒；
2）系統(tǒng)或部件要滿足合同宵呛、標準单匣、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力；
3）反映上述的條件或能力的文檔說明（SRS宝穗，軟件需求規(guī)格說明書）户秤。
對需求的通俗解釋 ：
1）需求來源于用戶的一些“需要”；
2）這些“需要”被分析逮矛、確認后形成完整的文檔鸡号；
3）該文檔詳細地說明了產(chǎn)品“必須或應當”做什么。
需要說明的是：并沒有一個清晰的须鼎、毫無二義性的“需求”術語定義存在鲸伴。真實的“需求”實際上在人們的腦海中府蔗，甚至在腦海深處自己都不知道」埃“任何文檔形式的需求（比如：需求規(guī)格說明書）都只是一個模型/一種敘述（Lawrence 1998）”姓赤。我們需要確保的是所有項目風險承擔者（stakeholders，干系人）在描述需求的文字的理解上務必達成共識仲吏。
1.2 需求的三個層次
1）業(yè)務需求是高層用戶（即客戶）提出的不铆，比較籠統(tǒng)、寬泛裹唆，在項目視圖與范圍文檔中說明誓斥。
2）用戶需求是最終用戶（即實際使用者）提出的，已經(jīng)比較具體了许帐，在實例文檔或方案腳本中說明劳坑。
3）產(chǎn)品需求是開發(fā)團隊需要的（甲方監(jiān)理也需要），定義了開發(fā)人員要實現(xiàn)的軟件功能成畦，使得用戶能完成他們的業(yè)務泡垃，從而滿足業(yè)務需求。
業(yè)務需求和用戶需求都是用通俗語言描述的羡鸥，即用戶能看懂的語言蔑穴；產(chǎn)品需求是用技術語言描述的，是開發(fā)人員能看懂的語言惧浴。用戶和開發(fā)人員是在用不同的視角觀察需求的存和，他們看到的內(nèi)容是不一樣的。就軟件而言衷旅，這里的產(chǎn)品需求就是軟件需求捐腿。
這樣的解釋可能還不容易理解，我來舉個“咖啡店新老板要更換定制咖啡杯”的例子柿顶。
業(yè)務需求：咖啡店老板要訂做一種咖啡杯茄袖。
找高層用戶調(diào)查和確認需求是一件痛苦的事，因為他們不關注需求具體內(nèi)容嘁锯，甚至常常不知道具體需求宪祥，他們關注的是“高屋建瓴”的比較務虛的內(nèi)容，例如：咖啡杯要用家乘、要漂亮之類的蝗羊。
真正去調(diào)研需求，需要先識別出產(chǎn)品的最終用戶群仁锯，選出用戶代表耀找，對用戶代表進行調(diào)研。這里的用戶代表為：消費者业崖，喝咖啡野芒；服務員-端咖啡蓄愁；洗碗工-洗杯子。針對消費者調(diào)研可以采用問卷調(diào)查的方式來獲取用戶需求狞悲；針對服務員和洗碗工可以采用用戶訪談的方式來獲取用戶需求涝登。
用戶需求：
1）消費者希望“杯子不能燙手”。消費者反饋：原來的杯子手柄很短效诅，杯身隔熱效果很差胀滚，拿杯子的時候，手指容易被燙乱投。
2）服務員希望“杯子在托盤上要穩(wěn)咽笼，不容易滑倒”。服務員反饋：原來的杯子瘦且高戚炫，杯底很滑剑刑，用托盤端盛滿咖啡的杯子時，杯子在托盤上容易打滑或傾倒双肤。
3）洗碗工希望“杯子要容易清洗”施掏。洗碗工反饋：原來的杯子內(nèi)壁不夠光滑，咖啡漬很難清洗茅糜。
這樣的用戶需求似乎很清楚了七芭，但是你得明白這只是針對用戶側(cè)，對開發(fā)人員來說還是不清楚蔑赘，因為這是自然語言描述的內(nèi)容狸驳，不是技術語言描述的內(nèi)容，開發(fā)人員無法針對此開展工作缩赛。
你還需要把以上內(nèi)容翻譯成為技術語言描述的產(chǎn)品需求：
1)? 采用隔熱材料耙箍，導熱率λ < 1.22 W/(m.K)，厚度> 5mm酥馍。經(jīng)過原型測試辩昆，采用了這樣的材料和厚度做成的杯子，加入100℃的熱咖啡時旨袒，杯子外壁的溫度大約50℃汁针，輕微觸碰時不會感覺燙手。
2)? 杯底的靜摩擦系數(shù) μ > 0.5峦失，滿杯的重心高度 h < 10cm扇丛。經(jīng)過原型測試术吗，符合這種要求的杯子在裝滿咖啡時尉辑，不容易打滑或傾倒。
3)? 杯內(nèi)壁表面粗糙度 Ra < 1.0较屿。經(jīng)過原型測試隧魄，符合這樣要求的陶瓷表面不容易附著咖啡液體卓练，很容易清洗。
拿到這樣的產(chǎn)品需求购啄，開發(fā)人員就可以開展工作了：
根據(jù)產(chǎn)品需求1襟企，開發(fā)人員可以從工廠常用的陶瓷材料里選擇符合要求的，然后把杯子設計為略高于指定厚度狮含。
根據(jù)產(chǎn)品需求2顽悼，開發(fā)人員可以把咖啡杯的底座設計為條紋或其他形式來加大摩擦系數(shù)，然后把咖啡杯設計較矮較寬的外形几迄，以滿足在滿杯時的重心要求蔚龙。
根據(jù)產(chǎn)品需求3，開發(fā)人員可以對咖啡杯的內(nèi)壁采用某種拋光或鍍釉的工藝來達到表面比較光滑的要求映胁。
這就是需求的三個層次：高層用戶關注業(yè)務目標的實現(xiàn)木羹，最終用戶關注業(yè)務執(zhí)行的效率和使用體驗，開發(fā)人員關注產(chǎn)品需求是否準確和清晰解孙。
產(chǎn)品經(jīng)理就比較慘了坑填，需要從多種角度去描述需求：高層用戶視角的需求，即市場需求文檔MRD弛姜；最終用戶視角的需求脐瑰，即業(yè)務需求文檔BRD；開發(fā)人員視角的需求廷臼，即產(chǎn)品需求文檔PRD（或軟件需求文檔SRS）蚪黑。
“需求”，這是所有人都可以說上幾句的話題中剩。但最專業(yè)的忌穿，還是產(chǎn)品經(jīng)理描述的需求，這正是產(chǎn)品經(jīng)理的價值所在结啼。
1.3 需求工程RE
應用已證實有效的技術掠剑、方法進行需求分析，確定客戶需求郊愧，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征的一門學科朴译，即需求工程。需求工程通過合適的工具和記號系統(tǒng)地描述待開發(fā)系統(tǒng)及其行為特征和相關約束属铁，形成需求文檔眠寿，并對用戶不斷變化的需求演進給予支持。
通俗地說焦蘑，需求工程就是把工程方法引入到需求領域盯拱，用工程方法開發(fā)清晰的、一致的，沒有沖突狡逢、重疊和遺漏的需求宁舰，用工程方法來管理需求和控制變更。
1.4 軟件需求工程SRE
軟件工程的子學科奢浑，一門分析并記錄軟件需求的學科蛮艰，它把系統(tǒng)需求分解成一些主要的子系統(tǒng)和任務，把這些子系統(tǒng)或任務分配給軟件雀彼，并通過一系列重復的分析壤蚜、設計、比較研究徊哑、原型開發(fā)過程把這些系統(tǒng)需求轉(zhuǎn)換成軟件的需求描述和一些性能參數(shù)仍律。
需求工程是系統(tǒng)工程和軟件工程的分支，分為系統(tǒng)需求工程（針對由軟硬件共同組成的整個系統(tǒng)）和軟件需求工程（專門針對純軟件部分）实柠。我們都知道軟件需求是指用戶對目標軟件系統(tǒng)在功能水泉、行為、性能窒盐、設計約束等方面的期望草则。軟件開發(fā)的最終目的是生產(chǎn)出滿足客戶需求的軟件產(chǎn)品，滿足客戶需求是軟件開發(fā)的本質(zhì)蟹漓。
1.5 為什么有軟件需求工程
軟件需求是軟件開發(fā)中的關鍵問題炕横，沒有需求就沒有軟件。
開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么葡粒。最困難的概念性工作是編寫出詳細的需求份殿，包括所有面向用戶、面向機器或其他軟件系統(tǒng)的接口嗽交，此工作一旦失誤卿嘲，將會帶來極大的危害，修改也極其困難夫壁。
——Frederick P. Brooks拾枣，《No Silver Bullet》
備注：Frederick P. Brooks，60年代初只有29歲時就主持了被稱為人類從原子能時代進入信息時代標志的IBM/360系列計算機的開發(fā)工作盒让，取得輝煌成功梅肤，名噪一時。他作為硬件和軟件的雙重專家和出色的教育家始終活躍在計算機舞臺上邑茄，在計算機技術的諸多領域中都做出了巨大的貢獻姨蝴，直到69歲才獲得遲來的榮譽——1999年的圖靈獎。
需求是軟件項目成功的核心肺缕，良好的需求可以減少開發(fā)后期的返工和整個維護階段的工作左医，做好需求等于項目成功了一半授帕。
1.6 需求是如此困難
需求是以交流為核心的工作，如果在開發(fā)過程的各個環(huán)節(jié)缺乏交流或交流不恰當炒辉，就會導致下圖（如果學計算機豪墅，你必定見過此圖）的效果泉手。
客戶如此描述需求：我有三個小孩黔寇，我需要一個能三個人用的秋千。它由一繩子吊在我家花園里的樹上斩萌。
項目經(jīng)理如此理解：秋千這東西太簡單了缝裤，不就是一塊板子，兩邊用繩子吊起來颊郎，掛在樹的兩個枝椏上嘛憋飞。
分析員如此設計：真是無知的項目經(jīng)理，兩個樹枝掛上秋千哪還能蕩得起來姆吭？除非是把樹從中截斷再用支架支起來榛做，這樣就滿足要求了。
程序員如此編碼：哦内狸，兩條繩检眯，一塊板，一棵大樹昆淡，接在樹的中段锰瘸。太簡單了，“啪啪啪（敲擊鍵盤的聲音）”昂灵，搞定避凝！
商業(yè)顧問如此詮釋：您的需求我們已經(jīng)完成了，我們通過人體工學和工程力學等多方面研究眨补，實現(xiàn)了本產(chǎn)品管削。本著為顧客服務出發(fā)，我們的秋千產(chǎn)品在使用時撑螺，將給您帶來如同游樂園里的過山車一樣刺激的感受佩谣，如同你在地面上坐沙發(fā)一樣的舒適與安全。
資料員如此寫文檔：這么小的工程沒有文檔很正常实蓬，只要有需求說明書與合同就可以了茸俭。
實施人員如此交付：我們的產(chǎn)品用戶自己都可以完成安裝，只要把繩子系在樹上就可以了安皱。
客戶得到如此結(jié)果：花了建過山車的投資调鬓，得到個如此產(chǎn)品，也是醉了酌伊。
維戶人員如此支持：我們提供不了什么技術支持腾窝，但我們態(tài)度很好缀踪，我們的隊伍在成長中。
項目完成了虹脯，真實的需求也清楚了：客戶需要一個跳圈驴娃，給三個小孩養(yǎng)的小狗訓練和玩耍。
很明顯循集，項目開始時客戶也不知道真實的需求唇敞，他表述的只是他理解的需求（小孩曾經(jīng)給他說過，但顯然他并沒有認真聆聽）咒彤。項目經(jīng)理沒有認真調(diào)研需求疆柔，他甚至根本不知道最終用戶是誰。項目經(jīng)理和分析員之間镶柱，分析員和程序員之間旷档，明顯沒有良好的交流和反饋。像漏斗一樣歇拆，每個環(huán)節(jié)都在遺失信息鞋屈；像傳聲筒游戲一樣，每個環(huán)節(jié)都在加入自己想當然的理解故觅。所以厂庇，最終的結(jié)果必然的天差地別！最重要的是逻卖，他們缺一個打通各個環(huán)節(jié)的產(chǎn)品經(jīng)理宋列。
對于產(chǎn)品經(jīng)理，有個常識你必須知道：
用戶嘴里說的评也，不一定是他腦子里想的炼杖。他腦子里想的，也不一定就是業(yè)務實際運行的情況盗迟。業(yè)務的現(xiàn)狀坤邪，不一定是合理的，也許正是客戶需要你幫助改進的罚缕。
所以艇纺，我們要傾聽用戶，但不能完全按照用戶說的去做邮弹；我們要傾聽多方用戶代表黔衡，特別是要關注那些互相沖突、需要妥協(xié)的部分腌乡；我們不光要聽用戶怎么說的盟劫，還要看他怎么做的；我們要聽免費用戶的免費意見与纽，更要聽付費用戶的付費意見侣签；我們要聽用戶的意見塘装，更要聽決定付錢的客戶的意見；等等影所，自己總結(jié)吧蹦肴，自己總結(jié)的才是最適合自己的，我一時不想展開了猴娩。
1.7 軟件需求工程框架
軟件需求工程是軟件工程及相關專業(yè)的一門必修課阴幌。
CMMI對軟件需求的描述：需求開發(fā)RD（3級），需求管理REQM（2級）
1）需求獲日湍纭：從用戶獲取裂七、挖掘需求皆看。
2）需求分析：提煉用戶需求仓坞，分析轉(zhuǎn)化。需求分析的過程重視用戶參與腰吟。需求定義：把分析得到的需求文檔化无埃，編制需求規(guī)格說明書。
3）需求驗證：確定需求準確毛雇、完整嫉称，得到實現(xiàn)，對應測試活動灵疮。
4）需求變更控制：對需求的變更進行控制织阅，降低影響。
5）需求跟蹤：監(jiān)控需求在開發(fā)過程中不走樣震捣、不遺漏荔棉。
2. 需求開發(fā)
2.1 CMMI關于需求開發(fā)的描述
SG1 干系人的需要、期望蒿赢、約束與接口得到收集并轉(zhuǎn)化為客戶需求润樱。
SP1.1 挖掘干系人對產(chǎn)品生命周期所有階段的需要、期望羡棵、約束與接口壹若。
SP1.2 將干系人的需要、期望皂冰、約束與接口轉(zhuǎn)換為劃分了優(yōu)先級的客戶需求店展。
SG2 客戶需求得到提煉與細化，以開發(fā)產(chǎn)品與產(chǎn)品組件需求秃流。
SP2.1 依據(jù)客戶需求赂蕴，建立并維護產(chǎn)品與產(chǎn)品組件需求。
SP2.2 為各產(chǎn)品組件分配需求剔应。
SP2.3 功能之間（或者是對象或其它邏輯實體之間）的接口進行了識別睡腿。
SG3 需求得到分析與確認语御。
2.2 需求獲取方法
相比“需求獲取”，我個人更喜歡“需求挖掘”這個詞席怪。因為“需求獲取”讓我感覺需求就是樹上的果子应闯、地里的莊稼，只要產(chǎn)品經(jīng)理去采摘就可以了挂捻。這樣的描述碉纺，未免低估和輕視了得到需求的困難。反之刻撒，“需求挖掘”讓我感覺需求是地里的金子等礦藏骨田，需要產(chǎn)品經(jīng)理去彎腰、埋頭挖掘声怔，而且挖掘了也不一定有成果态贤，因為你需要尋找正確的地方挖，否則只能是徒勞醋火。另外悠汽，在很多人都挖過的地里，你只有挖得更深才可能挖到礦藏芥驳。
常見的需求挖掘方法有：
1)? 客戶交流
2)? 技術引導
3)? 競品分析
4)? 市場調(diào)研
5)? 問卷調(diào)查
6)? 其他
客戶交流是最常用的需求挖掘方法柿冲。大多數(shù)情況下，用戶雖然知道自己的需求兆旬，但他們并不一定能或者也不想準確表達他們的需求是什么假抄。如果用戶第一次告訴你需求就是這些了，不要輕易相信他丽猬，繼續(xù)刨根問底宿饱，直到你們都筋疲力盡。
產(chǎn)品經(jīng)理作為一個需求分析者宝鼓，所謂的聆聽客戶需求刑棵，指必須透過客戶所提出的表面需求理解他們的真實需求，避免理解不同會帶來的期望差異愚铡。盡量把客戶所持的假設解釋清楚蛉签，特別是那些發(fā)生沖突的部分，甚至要逐字逐句去理解沥寥，以明確客戶沒有表達清楚但又想加入的特性或特征碍舍。
有經(jīng)驗的產(chǎn)品經(jīng)理能深入地理解客戶的業(yè)務（可以提取做大量準備工作），甚至就是業(yè)務專家邑雅，這樣他才能通過詢問客戶一些合適的問題（需要提前設計）片橡，從而挖掘出高價值的用戶需求。
2.3 需求分析方法
需求分析方法大致分為兩類：模型法和原型法淮野，都可以從不同角度說明需求捧书，把一些模糊的需求變得清晰吹泡，便于理解，減少返工经瓷。不管是模型爆哑，還是原型，都是用來增強自然語言描述的需求規(guī)格說明舆吮，而不是代替揭朝。
模型一般分為面向過程的模型和面向?qū)ο蟮哪Ｐ蛢深悺＝⑿枨竽Ｐ偷姆治鲞^程色冀，稱為“需求建模”潭袱。建模的目的是把模糊的東西搞清晰，把復雜的東西搞簡化锋恬，而不是把簡單的東西搞復雜（這是商務人員做的事屯换，比如：電信運營商的話費套餐）。
原型法是一種減少軟件項目失敗風險的技術伶氢，它可以加快開發(fā)進度趟径，增加用戶滿意度矛纹，減少需求錯誤和用戶界面缺陷棘伴。
2.4 需求建模
常用的面向過程的需求建模方法：
- 功能模型：數(shù)據(jù)流圖DFD歇式。
- 行為模型：流程圖Flow Chart。
- 狀態(tài)模型：狀態(tài)遷移圖STD蕾盯。
- 數(shù)據(jù)模型：實體關系圖ERD
常見的面向?qū)ο蟮男枨蠼７椒ǎ?/p>
- 功能模型：用例圖。
- 行為模型：活動圖蓝丙。
- 狀態(tài)模型：狀態(tài)圖级遭。
- 交互模型：時序圖（也叫“順序圖”）。
2.5 原型設計
建立原型的目的是為了解決在產(chǎn)品開發(fā)早期需求不確定的問題渺尘，利用這些不確定來判斷系統(tǒng)中那一部分需要建立原型和希望從用戶對原型的評價中獲得什么信息挫鸽。其優(yōu)點是能減少軟件項目失敗風險，加快開發(fā)進度鸥跟，增加用戶滿意度丢郊，減少需求錯誤，尤其是界面錯誤医咨。其風險是當用戶或項目經(jīng)理看到一個正在運行的原型枫匾，會以為產(chǎn)品即將完成。
對于發(fā)現(xiàn)和解決需求中的二義性拟淮，原型是一種很好的方法干茉。關于原型，不在這里贅述了很泊，后面會另起一文角虫。
常用的原型設計方法：
1）草圖（手繪圖）沾谓。
2）線框圖。
3）交互原型戳鹅。
4）高保真原型搏屑。
原型法不僅是需求分析方法，同時是需求驗證方法粉楚，例如：戰(zhàn)斗機的設計過程辣恋，必須要經(jīng)過原型機來測試驗證設計思路和設計效果，才能達到試驗機（更高程度的原型機）和量產(chǎn)機模软。第一代小米手機的設計伟骨，也是經(jīng)歷原型機、工程機和量產(chǎn)機的過程燃异。
2.6 需求定義的方法
- 采用需求文檔模板携狭。
- 指明需求的來源。
- 為每項需求建立編號回俐。
- 設定需求優(yōu)先級逛腿。
- 記錄業(yè)務規(guī)范。
- 創(chuàng)建需求跟蹤矩陣仅颇。
- 其他方法单默。
2.7 好需求的標準
清晰：不同的讀者只能從需求文檔中得到唯一的解釋說明，沒有二義忘瓦。所以表述中不要出現(xiàn)“也許搁廓、大概、可能耕皮、左右”之類的表述模糊的詞語境蜕，比如：響應時間5秒左右，寬度大概10米凌停。
完整：一個不能少粱年，所有功能都要描述。
一致：上下文一致罚拟，局部與整體一致台诗。
可行：每一項需求必須在已知系統(tǒng)和環(huán)境的限制范圍內(nèi)可以實現(xiàn)，不能是空中樓閣舟舒。
可驗證：每一項需求必須能夠用測試用例或其他方法來驗證是否按定義實現(xiàn)了拉庶。
可跟蹤：每一項需求必須能與HLD、LLD秃励、Code氏仗、UT、IT、ST等各階段工作產(chǎn)品對應跟蹤皆尔。
3. 需求管理
3.1 CMMI關于需求管理的描述
SG 1? 管理需求
SP 1.1 理解需求
SP 1.2 獲得對需求的承諾
SP 1.3 管理需求變更
SP 1.4 維護需求的雙向可追溯性
SP 1.5 確保項目工作與需求間的協(xié)調(diào)一致
3.2 需求管理的方法
1）確定需求變更控制過程呐舔，建立CCB（需求變更控制委員會）。
2）進行需求變更影響分析慷蠕，跟蹤變更影響的工作產(chǎn)品珊拼。
3）建立需求基準版本和需求控制版本文檔。
4）維護需求變更的歷史記錄流炕，跟蹤每項需求的狀態(tài)澎现。
5）使用需求管理工具，衡量需求穩(wěn)定性每辟。
6）其他方法剑辫。
3.3 需求變更控制
大師說：“沒有不變的需求，世上的軟件都改動過3次以上渠欺，唯一只改動過兩次的軟件的擁有者已經(jīng)死了妹蔽，死在去修改需求的路上∧咏”
需求變更是正常的胳岂，但不加控制的需求變更是不正常的。所以舔稀，不怕需求變更乳丰，但要嚴格控制，要讓客戶知道變更的代價（影響和成本）镶蹋，客戶在理解變更的代價后再拍板會理智很多成艘。
需求變更的原因：客戶說不清楚需求；需求自身經(jīng)常變動贺归；分析人員或客戶理解有誤。
需求變更控制不是為變更設置障礙断箫，而是建立一個渠道和過濾器拂酣，保護客戶和開發(fā)者雙方的權益，減低變更的影響仲义。
參考資料
[1]? CMMI-DEV 1.3
