軟件研發(fā)自然離不開需求,，而且我常說：需求是源頭,，需求的質(zhì)量最為關(guān)鍵，也就是我們經(jīng)常說的,，首先要做對事情,，“做正確的事” 比“正確地做事” 更重要。需求這么重要,，那么我們搞清楚需求自然也就很重要,，但是許多研發(fā)同學（包括測試同學）都搞不清什么是需求，傻傻分不清 “業(yè)務(wù)需求,、用戶需求和系統(tǒng)需求”,，一談需求就會提 “系統(tǒng)的功能、性能” 等,，完全忽視業(yè)務(wù)需求,，正如文章 “業(yè)務(wù)需求與系統(tǒng)功能，你分清楚了嗎,？” 所描述的場景：

小艾：“新來的那位資深 QA 同學技術(shù)很不錯,，感覺對業(yè)務(wù)理解還是不夠，想要他講一下 XX Feature（特性）的業(yè)務(wù),，結(jié)果他一上來就打開系統(tǒng),，給我們演示具體的操作流程……”

我也曾經(jīng)看到過某企業(yè)的一個正式文檔，如下所示,，標題明明是“業(yè)務(wù)需求總體描述”,，但一上來就是“主要功能模塊”，絲毫沒有業(yè)務(wù)需求的描述,。

（錯誤的業(yè)務(wù)需求描述文檔）

功能需求不是業(yè)務(wù)需求,，甚至可以說是業(yè)務(wù)需求的解決方案（非功能特性是解決方案的約束條件）,，因為功能往往是研發(fā)人員定義和設(shè)計的，通過實現(xiàn)某項功能來滿足用戶需求,，所設(shè)計的功能只是其中的一個方案,。為了滿足不同的業(yè)務(wù)需求，完全可以設(shè)計不同的功能,、不同的UI（用戶界面）,，例如：通過用戶名/口令登陸系統(tǒng)，是一個 “登錄” 功能需求,，它要解決的問題是用戶身份驗證,，我們也可以通過U盾、指紋,、人臉識別等各種功能解決這個問題,。你可能感覺某個功能好用、實現(xiàn)得不錯,，但把它放在一個特定的業(yè)務(wù)環(huán)境中,，它可能就有問題，如缺乏安全性,，不能滿足業(yè)務(wù)要求,。這也就是說，脫離業(yè)務(wù)環(huán)境來討論軟件系統(tǒng)的功能是沒有意義的,，所以今天的軟件質(zhì)量模型ISO/IEC 25010把之前單純的 “功能” 改為“功能適應(yīng)性”,，功能必須適應(yīng)業(yè)務(wù)環(huán)境才是有效的、有價值的,。說到這里,，你大概了解什么是 “業(yè)務(wù)需求（Business Requirements）” ,，那就是解決特定業(yè)務(wù)領(lǐng)域中的一個問題,，例如：在個人納稅業(yè)務(wù)中，解決的問題主要有：所在區(qū)域（省,、市）所有納稅人方便申報個稅,、個人收入?yún)R總、已繳的稅款統(tǒng)計,、計算要補交的個稅額度等,。業(yè)務(wù)需求具體的表現(xiàn)為業(yè)務(wù)流程、業(yè)務(wù)規(guī)則,、業(yè)務(wù)角色,、業(yè)務(wù)數(shù)據(jù)、業(yè)務(wù)可管理性,、業(yè)務(wù)發(fā)展等,，針對業(yè)務(wù)也可以建模,，也就是人們通常所說的領(lǐng)域建模和商業(yè)畫布等，有圖為證,。

（業(yè)務(wù)建模示意圖）

（商業(yè)畫布/業(yè)務(wù)分析模板）

（商業(yè)畫布示例）

業(yè)務(wù)需求通常通過MRD（市場需求文檔）,、用業(yè)務(wù)領(lǐng)域的術(shù)語來描述，一般由業(yè)務(wù)人員和市場調(diào)研人員提出來,。有些開創(chuàng)性的軟件產(chǎn)品,，意味著目前還不存在那樣的市場，而是挖掘某一類群體所面臨的問題（痛點）,、所擁有的欲望或潛意識等,，從而去解決這類問題或滿足這類潛在的需求。

是不是有了這些業(yè)務(wù)需求,，就可以討論系統(tǒng)的功能或非功能特性了,？別急，還沒有到系統(tǒng)需求這個層次,。你想一想,，在敏捷中常常用于需求描述的“用戶故事” 還沒出現(xiàn)呢！那“用戶故事” 是什么,？是什么需求,？“用戶故事” 是用例（Use Case）另一種說法，其實就是用戶行為分析,，把它歸為“用戶角色需求”：作為一個特定的用戶角色,，想通過做什么到達什么目的。在某個特定的業(yè)務(wù)活動 或 業(yè)務(wù)流程中,，不同的用戶（end user）角色（roles）發(fā)揮不同的作用,，其行為是不一樣的，即需求也是不一樣的,。例如,，在個人辦稅（申報）活動中，要區(qū)分收入超過12萬和不到12萬的用戶,，也要區(qū)分是自己申報還是代理人申報,、是否為外籍人士或港澳臺人員等。不同的用戶,，在同一個活動（如 辦稅）中所要處理的事務(wù)有差別,，期望的結(jié)果也不一樣。

把用戶角色的需求,，進一步擴展到干系人需求,，包括系統(tǒng)運維、技術(shù)支持,、銷售,、市場等相關(guān)人員的需求,。今天，軟件作為一種服務(wù),，這些干系人的需求更為顯著,，他們也可以看成是軟件系統(tǒng)的廣義用戶。

我們所構(gòu)建的軟件系統(tǒng)最終是為用戶所用,，所以我們所構(gòu)建的系統(tǒng)需要更好地滿足最終用戶不同角色的需求,，即系統(tǒng)的功能是為了支持用戶的需求，而業(yè)務(wù)需求要分解成用戶角色需求,，在敏捷中就是將業(yè)務(wù)需求（產(chǎn)品故事 Epic）分解為用戶故事,，而用戶故事又需要具體的系統(tǒng)功能來實現(xiàn)。為了保證業(yè)務(wù)服務(wù)能正常開展,，還需要軟件系統(tǒng)具有良好的性能,、兼容性、安全性和可靠性等支撐,。

下面用一張圖來說明三個層次的軟件需求：業(yè)務(wù)需求,、干系人需求和系統(tǒng)需求之間的關(guān)系。

(不同層次的軟件需求的關(guān)系)

（軟件不同層次需求之間的另一種表達）

如果從測試角度看,，你可以寫覆蓋業(yè)務(wù)需求的用例（通常是end-to-end用例,，即覆蓋業(yè)務(wù)流程圖中基本路徑的E2E用例）；你也可以寫覆蓋用戶角色需求的用例（通常采用基于場景的測試方法而設(shè)計的用例）,，即用戶故事的驗收標準（AC）,、BDD GWT場景的實例化結(jié)果（相當于在AC、GWT的基礎(chǔ)上加上具體的測試數(shù)據(jù)）,。你也可以針對系統(tǒng)功能寫功能測試用例,、針對安全性做滲透測試、針對性能做負載測試,，等等,。所以，當你談測試覆蓋率時,，一定要從某個需求層次的高度去談,。

如果大家像 從一則笑話 看產(chǎn)品需求獲取與分析 所描述的那個學生那么認真對待需求，相信大家一定能把 軟件需求 搞清楚?? 

（15個專場中的一個專場）