我的軟件經(jīng)驗(yàn)之<四>----需求設(shè)計(jì)

2. 需求階段
裝修一套新房，屋主一般會(huì)告訴裝修隊(duì)伍房屋布局、各個(gè)部位的裝修要求等，描述和要求越詳細(xì)，滿足期望值的可能性越高；地磚是深顏色的，屋主自以為裝修隊(duì)伍知道接縫線應(yīng)該處理成黑色，所以沒(méi)有明說(shuō)，裝修隊(duì)伍卻按慣例處理成白色，這產(chǎn)生了爭(zhēng)執(zhí)和返工。所以，需求做得全面和被深度挖掘，后頭階段的工作將開展得非常順利。

判斷是否做好需求的標(biāo)準(zhǔn)是：清楚、完整、一致、可測(cè)試：

清楚：需求溝通和描述的用語(yǔ)要通俗化、生活化、簡(jiǎn)單化，宜用溝通雙方都能理解的詞匯。忌過(guò)多使用技術(shù)專用術(shù)語(yǔ)，忌模棱兩可的說(shuō)話或描述；“可能、也許、大概”等不確定的詞語(yǔ)不要使用，這說(shuō)明需求尚未明確或沒(méi)弄明白。
完整：遺漏的需求或早或晚會(huì)被暴露，暴露時(shí)間越往后，組織付出的代價(jià)越大，項(xiàng)目經(jīng)理和項(xiàng)目成員承受的壓力越大；而且如果漏掉的需求屬于關(guān)聯(lián)性很強(qiáng)或基礎(chǔ)部分的，那么改動(dòng)量更大，項(xiàng)目經(jīng)理就等著做惡夢(mèng)了。
一致：需求包括業(yè)務(wù)需求、用戶需求、功能需求（也包括非功能需求）這三個(gè)層次，要保證不同層次間表達(dá)的內(nèi)容是一致的、和諧的、涵蓋合同范圍的，這也保證軟件成品不會(huì)偏離實(shí)現(xiàn)目標(biāo)。
可測(cè)試：需求是設(shè)計(jì)和測(cè)試案例的輸入和參照，可測(cè)試性可以保證需求能被理性的驗(yàn)證和檢查的，避免感性的表述。
2.1 需求說(shuō)明書
該文檔根據(jù)《項(xiàng)目發(fā)起書》、《可行性報(bào)告》、《溝通計(jì)劃》、《總體計(jì)劃》進(jìn)行調(diào)研編寫而出，是項(xiàng)目后續(xù)階段的基石，工作一定要做到位。項(xiàng)目經(jīng)理整理審核《需求說(shuō)明書》，召開組織內(nèi)部評(píng)審會(huì)，會(huì)議內(nèi)容是比對(duì)需求是否都涵蓋合同要求、需求是否合理可行等。通過(guò)評(píng)審后，如果條件允許，項(xiàng)目經(jīng)理到客戶處做1-3次需求闡述會(huì)（超過(guò)3次，可能是雙方溝通不暢或調(diào)研工作不到位），會(huì)上項(xiàng)目經(jīng)理逐條講解需求，聽取客戶反饋——是否有錯(cuò)誤的需求理解、是否有漏掉的需求等。最后該文檔發(fā)送給甲乙雙方簽署。

常聽到一些項(xiàng)目經(jīng)理抱怨客戶不肯簽署文檔，抱怨改變不了現(xiàn)狀或?qū)?xiàng)目有幫助，必須跟客戶充分交流找到原因，例如：

文檔描述模糊不完整不清晰，客戶沒(méi)有膽量簽署這樣的文檔（文檔沒(méi)有很好地整理審核過(guò)）。
客戶理解不了文檔內(nèi)容，有些文檔編寫者會(huì)忽略讀者群的知識(shí)背景，使用過(guò)多專業(yè)術(shù)語(yǔ)（沒(méi)有給客戶開需求闡述答疑會(huì)）。
客戶對(duì)文檔有異議，但軟件公司的人給他放下文檔后，再不露面、打電話或發(fā)郵件；一邊他等著反映情況，一邊項(xiàng)目組等著他簽署文件。這明顯是消極溝通帶來(lái)的惡果。
世界萬(wàn)物都有特質(zhì)，除了那些身經(jīng)百戰(zhàn)做過(guò)很多項(xiàng)目的客戶外，大部分客戶容易改變想法或不斷冒出新想法，這是需求階段的特質(zhì)之一，有些項(xiàng)目經(jīng)理常常抱怨這點(diǎn)并期許“如果客戶能一次拿定主意就好了”，這種想法只能說(shuō)是美好的但不可行，正如突然要求素食者吃肉嗜肉者吃素一樣，引入業(yè)內(nèi)流行的一句話："沒(méi)有不變的需求，世上的軟件都改動(dòng)過(guò)3次以上，唯一一個(gè)只改動(dòng)過(guò)兩次的軟件的擁有者已經(jīng)死了，死在去修改需求的路上。"。這階段適宜跟客戶保持高頻度的溝通交流、保證溝通渠道的順暢、主動(dòng)幫助客戶完善需求、積極給客戶提供正確專業(yè)的建議等等。

需求說(shuō)明書定稿后，項(xiàng)目組據(jù)此編寫《美工工作列表》，即美工要做出多少個(gè)UI頁(yè)面，這些頁(yè)面也要讓客戶審閱和簽署的，設(shè)計(jì)階段會(huì)說(shuō)到。

3. 設(shè)計(jì)階段
3.1 產(chǎn)品規(guī)格說(shuō)明書
當(dāng)軟件多次銷售或多次使用時(shí)，需要這份文檔面向一種以上的客戶。它依據(jù)《需求說(shuō)明書》而編寫，主要是以非技術(shù)性的大眾化的語(yǔ)言描述軟件具備的功能，例如第一次用液晶電視，會(huì)根據(jù)《產(chǎn)品規(guī)格書》來(lái)調(diào)試頻道而不是看電路板圖。

3.2 美工UI頁(yè)面
美工根據(jù)《美工工作列表》做出UI頁(yè)面，項(xiàng)目經(jīng)理一般跟美工討論、完善頁(yè)面3-7次（如果次數(shù)過(guò)多，說(shuō)明溝通出現(xiàn)誤差）后定稿。UI頁(yè)面很直觀地展示系統(tǒng)外貌，用戶有時(shí)會(huì)據(jù)此確定軟件整體色系、整體頁(yè)面布局是否符合客戶使用習(xí)慣、指出誤漏和能優(yōu)化的地方，從而增加用戶滿意度、減少界面返工概率、減少開發(fā)時(shí)對(duì)界面布局的討論等。

UI頁(yè)面一定要往細(xì)節(jié)做，除了客戶原因外，做得細(xì)的UI頁(yè)面能很好地滿足開發(fā)需要，避免項(xiàng)目組成員花費(fèi)太多無(wú)謂時(shí)間在界面討論上；把項(xiàng)目同性質(zhì)事情統(tǒng)一處理，這是有效省時(shí)的工作方式。

3.3 系統(tǒng)設(shè)計(jì)
系統(tǒng)設(shè)計(jì)文檔的內(nèi)容主要有硬件網(wǎng)絡(luò)圖、軟件技術(shù)架構(gòu)、源代碼文件夾結(jié)構(gòu)、公共設(shè)置、模塊設(shè)計(jì)、數(shù)據(jù)底層架構(gòu)設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)等：

硬件網(wǎng)絡(luò)圖：畫出軟件所處的硬件及其網(wǎng)絡(luò)分布圖。
軟件技術(shù)架構(gòu)：列出用到的技術(shù)，如果是多種技術(shù)，闡述技術(shù)間的工作方式和關(guān)聯(lián)性；闡述技術(shù)的特性，盡量以圖片表達(dá)。
源代碼文件夾結(jié)構(gòu)：樹狀結(jié)構(gòu)列出存放代碼的所有文件夾結(jié)構(gòu)。
公共設(shè)置：所有公用的都放在這里，例如Web Server配置、數(shù)據(jù)庫(kù)配置、Java公共類、Struts配置文件、XML文件等等。這部分的描述一定要盡量詳細(xì)、深思熟慮、全面涵蓋，因?yàn)樗鼈兊氖褂妙l率高而且影響范圍廣。
模塊設(shè)計(jì)：先列出工作分解結(jié)構(gòu)WBS和整體模塊關(guān)聯(lián)情況，再分模塊描述其要完成的功能、特性、商業(yè)邏輯、頁(yè)面要求（有美工UI頁(yè)面的，列出）等等，尤其要給每個(gè)頁(yè)面定義文件名，模塊之間常有鏈接、調(diào)用、包含關(guān)系，定好文件名能提高工作效率，避免開發(fā)混亂。這部分建議全組參與，先由技術(shù)專業(yè)人員完成1-4個(gè)重要模塊的商業(yè)邏輯和數(shù)據(jù)IPO（輸入-處理-輸出）描述后，剩下的由有相同技術(shù)背景的組員完成，這能讓組員充分理解需求和提前理清開發(fā)整體思路。
數(shù)據(jù)底層架構(gòu)設(shè)計(jì)：現(xiàn)在主流的開發(fā)語(yǔ)言設(shè)計(jì)模式會(huì)分出商業(yè)層和數(shù)據(jù)層，商業(yè)層跟需求有密切關(guān)系，數(shù)據(jù)層只關(guān)注數(shù)據(jù)存儲(chǔ)和處理，跟需求無(wú)關(guān)；如果項(xiàng)目資源不夠，這塊可以邀請(qǐng)項(xiàng)目外技術(shù)專業(yè)人員協(xié)助完成，或者在需求初期就開始做這部分。主體數(shù)據(jù)底層架構(gòu)出來(lái)后，接著完成1-4個(gè)典型模塊的程序流向即可，剩下的照葫蘆畫瓢；當(dāng)然，如果有時(shí)間，全部完成所有模塊的是最好的。
數(shù)據(jù)庫(kù)設(shè)計(jì)：DB數(shù)據(jù)表結(jié)構(gòu)需要進(jìn)行審核，以保證數(shù)據(jù)結(jié)構(gòu)是最優(yōu)化的。

作者：林佩雯

QQ在線咨詢