【文章內(nèi)容簡介】 或系統(tǒng)使用方案的角度出發(fā)，描述和總結使用者利用該軟件產(chǎn)品或系統(tǒng)能夠做的事或能夠完成的任務。功能需求根據(jù)上述使用者需求列出的使用方案，列出開發(fā)者必須為軟件產(chǎn)品或系統(tǒng)實現(xiàn)的功能。性能需求1. 運行速度、容量、并發(fā)性能 2. 對資源的利用率 3. 對外界輸入的反饋速度和準確性 4. 對差錯的負荷能力 系統(tǒng)需求o 必須適應的運行環(huán)境的要求 （包括運行平臺、網(wǎng)絡及其他硬件要求）o 與其他系統(tǒng)兼容的要求 （包括與操作系統(tǒng)、數(shù)據(jù)庫、瀏覽器及其他應用軟件的兼容要求）o 與外部其他系統(tǒng)和組件的接口要求 質(zhì)量需求o 對用戶重要的質(zhì)量標志 （可靠性、效率性、靈活性、安全性、互操作性、穩(wěn)定性、健全性、可用性）o 對開發(fā)者重要的質(zhì)量標志 （可維護性、多用轉換性、重復使用性、可測試性）其他需求不屬于上述需求范圍的，但受到其他環(huán)境和商業(yè)合同影響的要求。 1. 國家或地區(qū)的任何特別的標準 2. 軟件使用界面的特別要求 3. 與知識產(chǎn)權有關的要求 4. 軟件所面對的市場和行業(yè)的規(guī)范 5. 客戶的特別要求 開發(fā)的局限對開發(fā)的成功與否起很大影響的因素，是開發(fā)能力的局限： 1. 人員的局限 2. 技術的制約和局限 3. 客戶的特別要求 表 51 需求分析告《需求分析報告》的編制方式可以是多樣的，例如把所有“非功能性需求”組織成“外部接口需求”、“質(zhì)量屬性需求”和“需求約束”?！救纾簣D52】圖 52 需求規(guī)格說明書 界面原型設計 明確了系統(tǒng)的關鍵需求后，就可以進行界面原型設計工作，獲取用戶的反饋，盡快確定產(chǎn)品的界面基調(diào)。同時要編寫一份《界面設計概要》文檔，作為后續(xù)的界面設計工作的指導?！督缑嬖O計概要》的內(nèi)容包括：o 設計的理念 o 理念的來源或參考 o 設計的要點 o 與類似產(chǎn)品界面的對比 架構設計 架構設計從關鍵需求開始，建立概念性的架構，并逐步細化和驗證。最終生成架構設計說明書和架構基線代碼。架構設計的方法：可以從幾個不同的視角進行架構設計，然后匯總綜合得出完整的設計。（架構設計的五個視圖【如：圖53】）圖 53 架構設計的五視圖《架構設計說明書》的內(nèi)容包括：概 述說明編寫的目的、適用范圍以及設計原則等。邏輯架構關注功能。其設計著重考慮功能需求。 1. 細化功能單元 2. 發(fā)現(xiàn)通用機制 3. 細化領域模型 4. 確定子系統(tǒng)接口和交互機制 開發(fā)架構關注程序包。其設計著重考慮開發(fā)期質(zhì)量屬性，如可擴展性、可重用性、可移植性、易理解性和易測試性等。 1. 確定要開發(fā)或直接利用的程序包之間的依賴關系 2. 確定采用的技術、框架等 數(shù)據(jù)架構關注持久化數(shù)據(jù)的存儲方案。其設計著重考慮“數(shù)據(jù)需求”。 1. 持久化數(shù)據(jù)存儲方案 2. 數(shù)據(jù)傳遞、數(shù)據(jù)復制、數(shù)據(jù)同步等策略 運行架構關注進程、線程、對象等運行時概念，以及相關的并發(fā)、同步、通信等問題。其設計著重考慮運行期質(zhì)量屬性，例如性能、可伸縮性、持續(xù)可用性和安全性等。 1. 確定引入哪些進程與線程 2. 確定主動對象、被動對象，以及控制關系 3. 處理進程線程的創(chuàng)建、銷毀、通信機制、資源爭用等 4. 協(xié)議設計 物理架構關注軟件系統(tǒng)最終如何安裝或部署到物理機器。其設計著重考慮“安裝和部署需求”。 1. 確定物理配置方案 2. 確定如何將目標程序映射到物理節(jié)點 總 結基于上述的設計進行總結，并描述架構基線。表 52 架構設計說明書架構設計的另一個重要任務是編寫架構基線代碼，基線代碼表述和驗證架構，同時也是指導后續(xù)開發(fā)的基礎代碼。架構基線代碼的內(nèi)容包括：o 所有工程項目 o 工程目錄結構 o 軟件包結構 o 導入所有依賴包 o 基礎公共代碼 o 架構框架代碼 o 架構框架示例代碼和測試代碼 o 數(shù)據(jù)庫框架 圖 54 和圖 55 展示了軟件架構師的工作和成功的軟件架構設計包含的內(nèi)容：圖 54 軟件架構師的工作圖 55 成功的軟件架構設計1 軟件構建軟件可以分階段進行構建，每個階段可以使用增量的方式開發(fā)，用通過若干個Build構建，最后發(fā)布階段性產(chǎn)品成果。（注意：在這里 ，名詞“階段”的含義和本文其他地方的含義不一樣） 階段計劃 構建階段計劃的內(nèi)容包括：o 確定本階段要實現(xiàn)的功能 o 列出階段任務 o 計劃Build構建數(shù)量 o 細化《開發(fā)進度表》中本階段的工作內(nèi)容 Build 構建 詳見：下一節(jié) 階段產(chǎn)品發(fā)布 構建階段完成后發(fā)布階段產(chǎn)品成果，向用戶展示并接受用戶反饋，同時做好階段總結?！栋l(fā)布清單》的內(nèi)容包括：o 產(chǎn)品版本號和日期 o 改正的Bug o 修改的功能 o 實現(xiàn)的新功能 o 其他說明 《階段總結報告》的內(nèi)容包括：o 階段任務的完成情況 o 進度計劃的執(zhí)行情況 o 用戶的反饋情況 o 本階段碰到的主要問題 o 下一階段的改進建議 2 Build 構建Build構建以增量的方式執(zhí)行階段的開發(fā)任務，每個Build構建的周期一般不超過兩星期，每一次Build構建都會發(fā)布為一個內(nèi)部版本，并提交測試。測試發(fā)現(xiàn)的問題留待以后的Build構建解決。 Build計劃 《Build計劃》的內(nèi)容包括：o 本次Build的版本號o 本次Build的歷時o 本次Build的工作任務 167。 要解決的遺留Bug 167。 本應由以前的Build實現(xiàn)的，但推遲到本次Build實現(xiàn)的功能 167。 要實現(xiàn)的新功能 167。 其他工作任務 o 工作任務分配 需求細化 根據(jù)《Build計劃》，細化本次Build要實現(xiàn)的需求，細化到能進行詳細設計為止。有了細化的需求后就編寫本次Build的測試計劃?！稖y試計劃》的內(nèi)容包括：o