監(jiān)理公司管理系統(tǒng) | 工程企業(yè)管理系統(tǒng) | OA系統(tǒng) | ERP系統(tǒng) | 造價(jià)咨詢管理系統(tǒng) | 工程設(shè)計(jì)管理系統(tǒng) | 甲方項(xiàng)目管理系統(tǒng) | 簽約案例 | 客戶案例 | 在線試用
X 關(guān)閉

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

申請(qǐng)免費(fèi)試用、咨詢電話:400-8352-114

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

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

清楚:需求溝通和描述的用語(yǔ)要通俗化、生活化、簡(jiǎn)單化,宜用溝通雙方都能理解的詞匯。忌過(guò)多使用技術(shù)專(zhuān)用術(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ō)明書(shū)
該文檔根據(jù)《項(xiàng)目發(fā)起書(shū)》、《可行性報(bào)告》、《溝通計(jì)劃》、《總體計(jì)劃》進(jìn)行調(diào)研編寫(xiě)而出,是項(xiàng)目后續(xù)階段的基石,工作一定要做到位。項(xiàng)目經(jīng)理整理審核《需求說(shuō)明書(shū)》,召開(kāi)組織內(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)理逐條講解需求,聽(tīng)取客戶反饋——是否有錯(cuò)誤的需求理解、是否有漏掉的需求等。最后該文檔發(fā)送給甲乙雙方簽署。

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

文檔描述模糊不完整不清晰,客戶沒(méi)有膽量簽署這樣的文檔(文檔沒(méi)有很好地整理審核過(guò))。
客戶理解不了文檔內(nèi)容,有些文檔編寫(xiě)者會(huì)忽略讀者群的知識(shí)背景,使用過(guò)多專(zhuān)業(yè)術(shù)語(yǔ)(沒(méi)有給客戶開(kā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)幫助客戶完善需求、積極給客戶提供正確專(zhuān)業(yè)的建議等等。

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

3. 設(shè)計(jì)階段
3.1 產(chǎn)品規(guī)格說(shuō)明書(shū)
當(dāng)軟件多次銷(xiāo)售或多次使用時(shí),需要這份文檔面向一種以上的客戶。它依據(jù)《需求說(shuō)明書(shū)》而編寫(xiě),主要是以非技術(shù)性的大眾化的語(yǔ)言描述軟件具備的功能,例如第一次用液晶電視,會(huì)根據(jù)《產(chǎn)品規(guī)格書(shū)》來(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)化的地方,從而增加用戶滿意度、減少界面返工概率、減少開(kāi)發(fā)時(shí)對(duì)界面布局的討論等。

UI頁(yè)面一定要往細(xì)節(jié)做,除了客戶原因外,做得細(xì)的UI頁(yè)面能很好地滿足開(kāi)發(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ò)圖:畫(huà)出軟件所處的硬件及其網(wǎng)絡(luò)分布圖。
軟件技術(shù)架構(gòu):列出用到的技術(shù),如果是多種技術(shù),闡述技術(shù)間的工作方式和關(guān)聯(lián)性;闡述技術(shù)的特性,盡量以圖片表達(dá)。
源代碼文件夾結(jié)構(gòu):樹(shù)狀結(jié)構(gòu)列出存放代碼的所有文件夾結(jié)構(gòu)。
公共設(shè)置:所有公用的都放在這里,例如Web Server配置、數(shù)據(jù)庫(kù)配置、Java公共類(lèi)、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)系,定好文件名能提高工作效率,避免開(kāi)發(fā)混亂。這部分建議全組參與,先由技術(shù)專(zhuān)業(yè)人員完成1-4個(gè)重要模塊的商業(yè)邏輯和數(shù)據(jù)IPO(輸入-處理-輸出)描述后,剩下的由有相同技術(shù)背景的組員完成,這能讓組員充分理解需求和提前理清開(kāi)發(fā)整體思路。
數(shù)據(jù)底層架構(gòu)設(shè)計(jì):現(xiàn)在主流的開(kāi)發(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ù)專(zhuān)業(yè)人員協(xié)助完成,或者在需求初期就開(kāi)始做這部分。主體數(shù)據(jù)底層架構(gòu)出來(lái)后,接著完成1-4個(gè)典型模塊的程序流向即可,剩下的照葫蘆畫(huà)瓢;當(dāng)然,如果有時(shí)間,全部完成所有模塊的是最好的。
數(shù)據(jù)庫(kù)設(shè)計(jì):DB數(shù)據(jù)表結(jié)構(gòu)需要進(jìn)行審核,以保證數(shù)據(jù)結(jié)構(gòu)是最優(yōu)化的。

作者:林佩雯

QQ在線咨詢