|
軟件研發(fā)自然離不開需求，而且我常說：需求是源頭，需求的質(zhì)量最為關(guān)鍵，也就是我們經(jīng)常說的，首先要做對事情，“做正確的事” 比“正確地做事” 更重要。需求這么重要，那么我們搞清楚需求自然也就很重要，但是許多研發(fā)同學(xué)（包括測試同學(xué)）都搞不清什么是需求，傻傻分不清 “業(yè)務(wù)需求、用戶需求和系統(tǒng)需求”，一談需求就會提 “系統(tǒng)的功能、性能” 等，完全忽視業(yè)務(wù)需求，正如文章 “業(yè)務(wù)需求與系統(tǒng)功能，你分清楚了嗎？” 所描述的場景： 小艾：“新來的那位資深 QA 同學(xué)技術(shù)很不錯，感覺對業(yè)務(wù)理解還是不夠，想要他講一下 XX Feature（特性）的業(yè)務(wù)，結(jié)果他一上來就打開系統(tǒng)，給我們演示具體的操作流程……” |
我也曾經(jīng)看到過某企業(yè)的一個正式文檔，如下所示，標(biāo)題明明是“業(yè)務(wù)需求總體描述”，但一上來就是“主要功能模塊”，絲毫沒有業(yè)務(wù)需求的描述。 （錯誤的業(yè)務(wù)需求描述文檔） 功能需求不是業(yè)務(wù)需求，甚至可以說是業(yè)務(wù)需求的解決方案（非功能特性是解決方案的約束條件），因?yàn)楣δ芡茄邪l(fā)人員定義和設(shè)計(jì)的，通過實(shí)現(xiàn)某項(xiàng)功能來滿足用戶需求，所設(shè)計(jì)的功能只是其中的一個方案。為了滿足不同的業(yè)務(wù)需求，完全可以設(shè)計(jì)不同的功能、不同的UI（用戶界面），例如：通過用戶名/口令登陸系統(tǒng)，是一個 “登錄” 功能需求，它要解決的問題是用戶身份驗(yàn)證，我們也可以通過U盾、指紋、人臉識別等各種功能解決這個問題。你可能感覺某個功能好用、實(shí)現(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)計(jì)、計(jì)算要補(bǔ)交的個稅額度等。業(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è)務(wù)需求通常通過MRD（市場需求文檔）、用業(yè)務(wù)領(lǐng)域的術(shù)語來描述，一般由業(yè)務(wù)人員和市場調(diào)研人員提出來。有些開創(chuàng)性的軟件產(chǎn)品，意味著目前還不存在那樣的市場，而是挖掘某一類群體所面臨的問題（痛點(diǎn)）、所擁有的欲望或潛意識等，從而去解決這類問題或滿足這類潛在的需求。
是不是有了這些業(yè)務(wù)需求，就可以討論系統(tǒng)的功能或非功能特性了？別急，還沒有到系統(tǒng)需求這個層次。你想一想，在敏捷中常常用于需求描述的“用戶故事” 還沒出現(xiàn)呢！那“用戶故事” 是什么？是什么需求？“用戶故事” 是用例（Use Case）另一種說法，其實(shí)就是用戶行為分析，把它歸為“用戶角色需求”：作為一個特定的用戶角色，想通過做什么到達(dá)什么目的。在某個特定的業(yè)務(wù)活動 或 業(yè)務(wù)流程中，不同的用戶（end user）角色（roles）發(fā)揮不同的作用，其行為是不一樣的，即需求也是不一樣的。例如，在個人辦稅（申報）活動中，要區(qū)分收入超過12萬和不到12萬的用戶，也要區(qū)分是自己申報還是代理人申報、是否為外籍人士或港澳臺人員等。不同的用戶，在同一個活動（如 辦稅）中所要處理的事務(wù)有差別，期望的結(jié)果也不一樣。
把用戶角色的需求，進(jìn)一步擴(kuò)展到干系人需求，包括系統(tǒng)運(yùn)維、技術(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)功能來實(shí)現(xiàn)。為了保證業(yè)務(wù)服務(wù)能正常開展，還需要軟件系統(tǒng)具有良好的性能、兼容性、安全性和可靠性等支撐。
下面用一張圖來說明三個層次的軟件需求：業(yè)務(wù)需求、干系人需求和系統(tǒng)需求之間的關(guān)系。
如果從測試角度看，你可以寫覆蓋業(yè)務(wù)需求的用例（通常是end-to-end用例，即覆蓋業(yè)務(wù)流程圖中基本路徑的E2E用例）；你也可以寫覆蓋用戶角色需求的用例（通常采用基于場景的測試方法而設(shè)計(jì)的用例），即用戶故事的驗(yàn)收標(biāo)準(zhǔn)（AC）、BDD GWT場景的實(shí)例化結(jié)果（相當(dāng)于在AC、GWT的基礎(chǔ)上加上具體的測試數(shù)據(jù)）。你也可以針對系統(tǒng)功能寫功能測試用例、針對安全性做滲透測試、針對性能做負(fù)載測試，等等。所以，當(dāng)你談測試覆蓋率時，一定要從某個需求層次的高度去談。
|
