軟件項(xiàng)目中,需求怎么做?
對于軟件開發(fā)團(tuán)隊(duì)而言,軟件開發(fā)的全過程是:做什么 -> 怎么做 -> 做 -> 成果檢驗(yàn) -> 交付部署;其中,“做什么”對應(yīng)的是需求分析過程,“怎么做”對應(yīng)于軟件架構(gòu)設(shè)計(jì)過程,“做”對應(yīng)于開發(fā)過程,“成果檢驗(yàn)”對應(yīng)于測試,部署由運(yùn)維團(tuán)隊(duì)執(zhí)行后,如果達(dá)到用戶的要求,則軟件上線后進(jìn)入軟件的運(yùn)行生命周期。
在實(shí)際的軟件項(xiàng)目開發(fā)中,“做什么”,“怎么做”和“做”是緊密結(jié)合在一起的,“做”,“成果檢驗(yàn)”和“交付部署”通常也會(huì)是一個(gè)持續(xù)交付過程,“成果檢驗(yàn)”的內(nèi)容會(huì)受到“做什么”的影響,開展“做什么”階段的時(shí)候,也要考慮到如何部署和交付。所以軟件開發(fā)的全過程,都是緊密結(jié)合在一起的,如果刻意劃分為獨(dú)立的幾個(gè)階段,忽視其作為一個(gè)整理的綜合影響,每個(gè)環(huán)節(jié)的實(shí)施過程必然會(huì)遇到因上一階段考慮不周全帶來的問題,從而影響整體開發(fā)效率。
基于此,我們的需求分析,從需求深度劃分,可以分為三個(gè)層次:原始需求分析、業(yè)務(wù)架構(gòu)分析和功能架構(gòu)分析。這三個(gè)層次依次遞進(jìn),沒有嚴(yán)格的界限。
原始需求是從用戶或業(yè)務(wù)角度看到的,或應(yīng)該有的需求,或項(xiàng)目團(tuán)隊(duì)經(jīng)過初步挖掘后整理出來的、未經(jīng)進(jìn)一步提煉的需求。
如果拿做項(xiàng)目與做產(chǎn)品做個(gè)類比,原始需求有點(diǎn)類似與產(chǎn)品經(jīng)理所說的“用戶故事”,由于原始需求可能是開發(fā)者分析出來了,也可能是行業(yè)專家或目標(biāo)客戶 / 用戶提出來的,原始需求可以不止步于“用戶故事”,在該階段做一定的業(yè)務(wù)邏輯的抽取和提煉,對接下來“業(yè)務(wù)架構(gòu)”階段的需求分析也是有幫助的,所以這兩個(gè)階段沒必要確立一個(gè)嚴(yán)格的界限。
例如,對一個(gè)多人博客系統(tǒng)而言,原始需求可能是這樣的:
要有個(gè)所有文章列表
能點(diǎn)擊查閱文章
能評論文章
能創(chuàng)建新文章
能編輯刪除文章
要有權(quán)限機(jī)制
而對于更有經(jīng)驗(yàn)的人而言,原始需求可能更加體系化:
首先,多人博客系統(tǒng)由前臺(tái)展示子系統(tǒng)和后臺(tái)管理子系統(tǒng)構(gòu)成,兩個(gè)子系統(tǒng)的功能可以分別來描述。
前臺(tái)子系統(tǒng)應(yīng)該對任何人可見,該子系統(tǒng)至少包含以下頁面或功能:
文章列表 + 概要頁面
文章詳情頁面
作者主頁
文章評論功能
文章搜索功能
側(cè)邊欄的目錄、tag 等博客經(jīng)典功能
后臺(tái)子系統(tǒng)只對登錄用戶開放,對應(yīng)多人博客而言,該子系統(tǒng)應(yīng)該分用戶組,為不同類型用戶分配不同的權(quán)限,該子系統(tǒng)至少包含以下頁面或功能:
用戶登錄或注冊功能
根據(jù)不同用戶的權(quán)限,登錄后看到不同的頁面或功能
創(chuàng)建新文章
修改或刪除文章
維護(hù)博客名稱描述等內(nèi)容的功能
原始需求階段做的,主要是需求是收集、整理和簡單分析工作,為業(yè)務(wù)架構(gòu)階段的需求分析奠定了基礎(chǔ)。
功能需求
又分為“顯式的功能需求”和“潛在的功能需求”,如上一節(jié)列出的需求,均為顯式功能需求,潛在的功能需求要從多個(gè)角度去考慮,如整理出用戶組、權(quán)限對應(yīng)的完整業(yè)務(wù)邏輯,是屬于可以推測并進(jìn)一步開展工作的潛在功能需求,而修改密碼、個(gè)人信息、用戶管理和忘記密碼等功能,是上面漏掉的、但又會(huì)影響到系統(tǒng)完整性的潛在需求,而需要提供一個(gè)系統(tǒng)初始化接口的功能需求,是站在運(yùn)維實(shí)施角度提出來的潛在需求。
當(dāng)業(yè)務(wù)架構(gòu)梳理過程中,尤其是整理潛在功能需求時(shí),一定會(huì)發(fā)現(xiàn)上一階段疏漏或在上一階段的視角下考慮不到的需求點(diǎn),此時(shí)應(yīng)結(jié)合項(xiàng)目的進(jìn)度要求,考慮是否進(jìn)行一輪需求的迭代和補(bǔ)充。
對上文提到的多人博客系統(tǒng)而言,業(yè)務(wù)架構(gòu)可以設(shè)計(jì)如下:
多人博客系統(tǒng)業(yè)務(wù)架構(gòu)
做好業(yè)務(wù)架構(gòu),是為整個(gè)軟件項(xiàng)目邁出堅(jiān)實(shí)的第一步。業(yè)務(wù)架構(gòu)是需求分析中最重要的階段,經(jīng)歷了整理業(yè)務(wù)架構(gòu)分析的過程,基本上才真正把系統(tǒng)需求梳理出來了,如果簡單粗暴的在需求和開發(fā)之間切出一個(gè)交接面,把交接面放在業(yè)務(wù)架構(gòu)上是比較合適的,系統(tǒng)開發(fā)的底線是要與業(yè)務(wù)架構(gòu)保持一致,后續(xù)的需求迭代或變更,也要基于業(yè)務(wù)架構(gòu)擴(kuò)展或重構(gòu)。
業(yè)務(wù)架構(gòu)對軟件系統(tǒng)開發(fā)也有重要影響。開發(fā)軟件系統(tǒng),通常要求具備充分的可擴(kuò)展性,而可擴(kuò)展性,在需求分析階段就奠定了基礎(chǔ),需求分析做的充分,就能在很大程度上給系統(tǒng)可擴(kuò)展性定性了,當(dāng)增加新功能時(shí),系統(tǒng)能否擴(kuò)展功能,還是系統(tǒng)的某些功能要打破重來,業(yè)務(wù)架構(gòu)階段就能看出端倪。比如,如果想在多人博客系統(tǒng)中增加用戶的社交功能,可以把該功能插入到用戶模塊和個(gè)人模塊中去,也可以單獨(dú)開一個(gè)社交模塊來封閉相關(guān)功能,前者會(huì)更多的打破原有業(yè)務(wù)邏輯,從而改變已有功能的代碼實(shí)現(xiàn),而后者更多的是在新的模塊中梳理業(yè)務(wù)邏輯,開發(fā)新功能,前者重構(gòu)多于擴(kuò)展,而后者擴(kuò)展多于重構(gòu)。所以如果業(yè)務(wù)架構(gòu)設(shè)計(jì)的具有足夠的擴(kuò)展性,相當(dāng)于軟件系統(tǒng)先天具備較強(qiáng)的可擴(kuò)展性。
業(yè)務(wù)架構(gòu)為軟件系統(tǒng)的開發(fā)奠定了基礎(chǔ),在實(shí)際的軟件項(xiàng)目中,通??梢栽诖嘶A(chǔ)上讓需求分析再往前邁一步,將"做什么"和“怎么做”是緊密聯(lián)系起來,承上啟下,我將這部分需求分析稱之為“功能架構(gòu)分析”。
怎么做
做
的階段時(shí),發(fā)現(xiàn)現(xiàn)實(shí)(代碼邏輯和系統(tǒng)實(shí)施)和理想(業(yè)務(wù)邏輯)不一致的概率會(huì)更大,開發(fā)過程中可能會(huì)有更多關(guān)于“需求分析沒做到位”的扯皮,甚至不得不重新返回需求分析階段再次梳理需求,這都會(huì)帶來本可避免的項(xiàng)目進(jìn)度延誤。
所以,需求分析如果只考慮“原始需求”和“業(yè)務(wù)架構(gòu)”兩個(gè)維度,是有盲點(diǎn)的,功能架構(gòu)分析雖然可以作為“怎么做”的第一步,但把它作為“做什么”的最后一步,能有效減少因?yàn)闆]有“向后看”帶來的需求分析不充分的問題,能夠把需求和實(shí)現(xiàn)更緊密的結(jié)合在一起,它在一定程度上對業(yè)務(wù)架構(gòu)做了進(jìn)一步的細(xì)化,也在一定程度上影響了業(yè)務(wù)架構(gòu)的最終成果。
怎么做
這兩個(gè)階段鋪路了,是怎么做
的基礎(chǔ),“怎么做”是架構(gòu)師負(fù)責(zé)的,功能架構(gòu)分析最好也由需要架構(gòu)師來牽頭和落實(shí)。
功能架構(gòu)分析的主要內(nèi)容有 2 點(diǎn):(1)再次提煉和抽象業(yè)務(wù)功能;(2)確認(rèn)和完善非功能需求。
(1)再次提煉和抽象業(yè)務(wù)功能
博客系統(tǒng)比較簡單,其業(yè)務(wù)架構(gòu)和功能架構(gòu)可能基本上是一致的。對于復(fù)雜的業(yè)務(wù)系統(tǒng)而言,業(yè)務(wù)架構(gòu)分析階段提煉的業(yè)務(wù)功能,是有可能被再次提煉的,如:
OA 系統(tǒng)中,我們從業(yè)務(wù)架構(gòu)的視角看,可以整理出如“計(jì)劃管理”、“任務(wù)管理”和“表單管理”等模塊,這些模塊的業(yè)務(wù)流程都會(huì)包含“審批流程”、“短信通知”、“郵件通知”等基礎(chǔ)功能,這些功能在每個(gè)業(yè)務(wù)模塊中,功效類似,但在業(yè)務(wù)架構(gòu)的視角和顆粒度上,不一定能清晰的表達(dá)出來,但梳理功能架構(gòu)的時(shí)候,可以將此作為從相關(guān)業(yè)務(wù)模塊的核心業(yè)務(wù)邏輯中剝離的非核心業(yè)務(wù)邏輯,作為基礎(chǔ)功能模塊放到功能架構(gòu)的恰當(dāng)位置。
OA 系統(tǒng)中,可能還存在一些功能模塊,涉及到上傳附件、預(yù)覽或下載附件等功能,甚至在此之外還會(huì)有獨(dú)立的“文檔管理”模塊,順著上一段的思路,我們可能都意識(shí)到了“文件存儲(chǔ)管理”也可以獨(dú)立出來作為基礎(chǔ)功能模塊來實(shí)現(xiàn);而有相關(guān)開發(fā)經(jīng)驗(yàn)的人還知道,文件有大有小,大文件存儲(chǔ)、管理和消費(fèi)的業(yè)務(wù)邏輯和零散小文件類似業(yè)務(wù)邏輯的實(shí)現(xiàn)及性能上可能會(huì)有很大差別,導(dǎo)致不同的應(yīng)用場景對應(yīng)不同的實(shí)現(xiàn)方案,如某些業(yè)務(wù)場景下,該模塊是可以與系統(tǒng)其它模塊集成在一起的,而另外一些場景下,該模塊需求獨(dú)立出來,單獨(dú)服務(wù)器部署,另外文件的存儲(chǔ)、備份和恢復(fù)機(jī)制等,也都要考慮進(jìn)去。這些都是使得看似簡單的文件存儲(chǔ)功能,在具體實(shí)現(xiàn)和實(shí)施上非常麻煩,而這些可能是“業(yè)務(wù)架構(gòu)分析”中難以避免的盲點(diǎn)。
所以業(yè)務(wù)架構(gòu)分析階段,雖然能夠做到把業(yè)務(wù)需求和邏輯完整的整理出來,但不一定能把構(gòu)成每個(gè)業(yè)務(wù)邏輯的單位功能一一提煉和組織起來,也可能會(huì)因?yàn)槿狈δ荛_發(fā)和系統(tǒng)性能上的背景知識(shí),忽視某些需要單獨(dú)處理的功能或模塊的特殊性,為系統(tǒng)的穩(wěn)定性和可擴(kuò)展性埋下隱患,所以,在業(yè)務(wù)架構(gòu)分析之后,在開發(fā)之前,一定要做“功能架構(gòu)分析”。
業(yè)務(wù)架構(gòu)是面向用戶的,功能架構(gòu)是面向開發(fā)者的,功能架構(gòu)和業(yè)務(wù)架構(gòu)是一致的,且功能架構(gòu)可以看做是業(yè)務(wù)架構(gòu)的超集。
(2)確認(rèn)和完善非功能需求
非功能需求方面的考慮,其實(shí)已經(jīng)屬于架構(gòu)師在怎么做
階段的起步了,怎么做
的主要成果是軟件架構(gòu),而設(shè)計(jì)軟件架構(gòu)要考慮的兩個(gè)維度是“業(yè)務(wù)架構(gòu)”和“業(yè)務(wù)量級(jí)”。設(shè)計(jì)軟件架構(gòu),一方面要保證軟件系統(tǒng)的功能符合用戶預(yù)期,另一方面,也是更重要的是,軟件系統(tǒng)要能被正常部署、使用、維護(hù)和監(jiān)控,前者對應(yīng)的是原始需要和業(yè)務(wù)架構(gòu)的初級(jí)階段,后面面向的是潛在的功能需求和非功能需求。
非功能需求,通常要考慮系統(tǒng)的存儲(chǔ)能力、吞吐能力和容錯(cuò)能力等,最常見的就是我們常說的“日活”或“并發(fā)”,這些性能指標(biāo)會(huì)影響到我們的軟件架構(gòu),例如,上面提到的多人博客系統(tǒng),可能大部分情況下可能只有幾千到一兩萬的日活,這種情況下單體架構(gòu)肯定能撐得住,但如果這個(gè)多人博客系統(tǒng)是 Tumblr 或 Medium 話,就必須是分布式架構(gòu)。確立非功能需求,一方面是為了保證我們的軟件架構(gòu)能夠支撐起我們的業(yè)務(wù)量,另一方面也是為了防止我們對軟件架構(gòu)做過度設(shè)計(jì),為系統(tǒng)開發(fā)帶來不必要的復(fù)雜度。另外,這也為系統(tǒng)的性能測試提供了依據(jù)。
綜上,在軟件項(xiàng)目中,如果要把需求分析做到位,止于功能架構(gòu)分析才是保險(xiǎn)的。
最后,上文中還要一些內(nèi)容沒有講清說透,做以下補(bǔ)充:
軟件項(xiàng)目團(tuán)隊(duì),需求可以由專人負(fù)責(zé),也可以分?jǐn)偟剿虚_發(fā)者身上,但無論何種情況,需求分析盡量全員參與進(jìn)去,以避免后續(xù)階段在理解需求上浪費(fèi)沒必要的時(shí)間。
軟件項(xiàng)目的主要參與者是計(jì)算機(jī)相關(guān)背景的開發(fā)者,而軟件項(xiàng)目面向的卻是各行各業(yè),對于有行業(yè)專業(yè)背景限制的項(xiàng)目,如建筑、金融、醫(yī)療領(lǐng)域的業(yè)內(nèi)應(yīng)用,團(tuán)隊(duì)里需要有行業(yè)專家,以保證做原始需要分析和業(yè)務(wù)架構(gòu)分析是,能夠接地氣,成果符合甚至超出預(yù)期。
需求分析階段通常也要提供原型,原型設(shè)計(jì)的主要工作,要在業(yè)務(wù)架構(gòu)分析階段定稿。
功能架構(gòu)分析和軟件架構(gòu)設(shè)計(jì)是緊密結(jié)合在一起的,沒有嚴(yán)格的界限,“做什么”和“怎么做”之間的度,各項(xiàng)目團(tuán)隊(duì)需要結(jié)合實(shí)際情況自行把握。
需求做不到位,項(xiàng)目做不好,先想清楚再做開發(fā)。
做項(xiàng)目和做產(chǎn)品是不盡相同的,本文面向的是做軟件項(xiàng)目,如果你的團(tuán)隊(duì)是做產(chǎn)品的,可能要在實(shí)踐過程中要再做變通。