2. 需求階段
裝修一套新房，屋主一般會告訴裝修隊伍房屋布局、各個部位的裝修要求等，描述和要求越詳細，滿足期望值的可能性越高；地磚是深顏色的，屋主自以為裝修隊伍知道接縫線應該處理成黑色，所以沒有明說，裝修隊伍卻按慣例處理成白色，這產生了爭執(zhí)和返工。所以，需求做得全面和被深度挖掘，后頭階段的工作將開展得非常順利。
判斷是否做好需求的標準是：清楚、完整、一致、可測試：
清楚：需求溝通和描述的用語要通俗化、生活化、簡單化，宜用溝通雙方都能理解的詞匯。忌過多使用技術專用術語，忌模棱兩可的說話或描述；“可能、也許、大概”等不確定的詞語不要使用，這說明需求尚未明確或沒弄明白。
完整：遺漏的需求或早或晚會被暴露，暴露時間越往后，組織付出的代價越大，項目經(jīng)理和項目成員承受的壓力越大；而且如果漏掉的需求屬于關聯(lián)性很強或基礎部分的，那么改動量更大，項目經(jīng)理就等著做惡夢了。
一致：需求包括業(yè)務需求、用戶需求、功能需求（也包括非功能需求）這三個層次，要保證不同層次間表達的內容是一致的、和諧的、涵蓋合同范圍的，這也保證軟件成品不會偏離實現(xiàn)目標。
可測試：需求是設計和測試案例的輸入和參照，可測試性可以保證需求能被理性的驗證和檢查的，避免感性的表述。
2.1 需求說明書
該文檔根據(jù)《項目發(fā)起書》、《可行性報告》、《溝通計劃》、《總體計劃》進行調研編寫而出，是項目后續(xù)階段的基石，工作一定要做到位。項目經(jīng)理整理審核《需求說明書》，召開組織內部評審會，會議內容是比對需求是否都涵蓋合同要求、需求是否合理可行等。通過評審后，如果條件允許，項目經(jīng)理到客戶處做1-3次需求闡述會（超過3次，可能是雙方溝通不暢或調研工作不到位），會上項目經(jīng)理逐條講解需求，聽取客戶反饋——是否有錯誤的需求理解、是否有漏掉的需求等。最后該文檔發(fā)送給甲乙雙方簽署。
常聽到一些項目經(jīng)理抱怨客戶不肯簽署文檔，抱怨改變不了現(xiàn)狀或對項目有幫助，必須跟客戶充分交流找到原因，例如：
文檔描述模糊不完整不清晰，客戶沒有膽量簽署這樣的文檔（文檔沒有很好地整理審核過）。
客戶理解不了文檔內容，有些文檔編寫者會忽略讀者群的知識背景，使用過多專業(yè)術語（沒有給客戶開需求闡述答疑會）。
客戶對文檔有異議，但軟件公司的人給他放下文檔后，再不露面、打電話或發(fā)郵件；一邊他等著反映情況，一邊項目組等著他簽署文件。這明顯是消極溝通帶來的惡果。
世界萬物都有特質，除了那些身經(jīng)百戰(zhàn)做過很多項目的客戶外，大部分客戶容易改變想法或不斷冒出新想法，這是需求階段的特質之一，有些項目經(jīng)理常常抱怨這點并期許“如果客戶能一次拿定主意就好了”，這種想法只能說是美好的但不可行，正如突然要求素食者吃肉嗜肉者吃素一樣，引入業(yè)內流行的一句話："沒有不變的需求，世上的軟件都改動過3次以上，唯一一個只改動過兩次的軟件的擁有者已經(jīng)死了，死在去修改需求的路上。"。這階段適宜跟客戶保持高頻度的溝通交流、保證溝通渠道的順暢、主動幫助客戶完善需求、積極給客戶提供正確專業(yè)的建議等等。
需求說明書定稿后，項目組據(jù)此編寫《美工工作列表》，即美工要做出多少個UI頁面，這些頁面也要讓客戶審閱和簽署的，設計階段會說到。
3. 設計階段
3.1 產品規(guī)格說明書
當軟件多次銷售或多次使用時，需要這份文檔面向一種以上的客戶。它依據(jù)《需求說明書》而編寫，主要是以非技術性的大眾化的語言描述軟件具備的功能，例如第一次用液晶電視，會根據(jù)《產品規(guī)格書》來調試頻道而不是看電路板圖。
3.2 美工UI頁面
美工根據(jù)《美工工作列表》做出UI頁面，項目經(jīng)理一般跟美工討論、完善頁面3-7次（如果次數(shù)過多，說明溝通出現(xiàn)誤差）后定稿。UI頁面很直觀地展示系統(tǒng)外貌，用戶有時會據(jù)此確定軟件整體色系、整體頁面布局是否符合客戶使用習慣、指出誤漏和能優(yōu)化的地方，從而增加用戶滿意度、減少界面返工概率、減少開發(fā)時對界面布局的討論等。
UI頁面一定要往細節(jié)做，除了客戶原因外，做得細的UI頁面能很好地滿足開發(fā)需要，避免項目組成員花費太多無謂時間在界面討論上；把項目同性質事情統(tǒng)一處理，這是有效省時的工作方式。
3.3 系統(tǒng)設計
系統(tǒng)設計文檔的內容主要有硬件網(wǎng)絡圖、軟件技術架構、源代碼文件夾結構、公共設置、模塊設計、數(shù)據(jù)底層架構設計、數(shù)據(jù)庫設計等：
硬件網(wǎng)絡圖：畫出軟件所處的硬件及其網(wǎng)絡分布圖。
軟件技術架構：列出用到的技術，如果是多種技術，闡述技術間的工作方式和關聯(lián)性；闡述技術的特性，盡量以圖片表達。
源代碼文件夾結構：樹狀結構列出存放代碼的所有文件夾結構。
公共設置：所有公用的都放在這里，例如Web Server配置、數(shù)據(jù)庫配置、Java公共類、Struts配置文件、XML文件等等。這部分的描述一定要盡量詳細、深思熟慮、全面涵蓋，因為它們的使用頻率高而且影響范圍廣。
模塊設計：先列出工作分解結構WBS和整體模塊關聯(lián)情況，再分模塊描述其要完成的功能、特性、商業(yè)邏輯、頁面要求（有美工UI頁面的，列出）等等，尤其要給每個頁面定義文件名，模塊之間常有鏈接、調用、包含關系，定好文件名能提高工作效率，避免開發(fā)混亂。這部分建議全組參與，先由技術專業(yè)人員完成1-4個重要模塊的商業(yè)邏輯和數(shù)據(jù)IPO（輸入-處理-輸出）描述后，剩下的由有相同技術背景的組員完成，這能讓組員充分理解需求和提前理清開發(fā)整體思路。
數(shù)據(jù)底層架構設計：現(xiàn)在主流的開發(fā)語言設計模式會分出商業(yè)層和數(shù)據(jù)層，商業(yè)層跟需求有密切關系，數(shù)據(jù)層只關注數(shù)據(jù)存儲和處理，跟需求無關；如果項目資源不夠，這塊可以邀請項目外技術專業(yè)人員協(xié)助完成，或者在需求初期就開始做這部分。主體數(shù)據(jù)底層架構出來后，接著完成1-4個典型模塊的程序流向即可，剩下的照葫蘆畫瓢；當然，如果有時間，全部完成所有模塊的是最好的。
數(shù)據(jù)庫設計：DB數(shù)據(jù)表結構需要進行審核，以保證數(shù)據(jù)結構是最優(yōu)化的。
作者：林佩雯
【?發(fā)表評論?0條?】