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