軟件文檔

需求（Requirements）

標題及做者
1 目的和範圍(從技術和業務的角度)
2 利益相關者識別，例：
    項目負責人：
    高級管理人員：
    項目團隊成員：
    項目的客戶：
    資源管理器：
    部門經理：
    產品用戶組：
    項目測試人員：
    任何受項目影響的小組：
    項目完成時受項目影響的任何小組：
    該工程的分包商：
    項目顧問：
3 市場評估和目標人口統計
4 產品概述和用例
畫用例圖。
5 需求
5.1 功能需求(例如產品應該作什麼)
5.2 可用性需求，例：
    - 系統中全部超過0.5秒的延遲都會產生一個對話框，上面寫着「請等待」。
    - 在不超過3次點擊的狀況下，能夠從主窗口到達任何給定的系統功能。
    - 不須要鼠標，只須要鍵盤就能夠完成任何給定的任務。
    - 全部屏幕都有一個幫助按鈕。 給定屏幕上的幫助按鈕必須爲屏幕上的每一個控件提供至少一個「主題」。
5.3 技術要求(例如安全、網絡、平臺、集成、客戶端)
5.4 環境要求
5.5 支持需求
5.6 交互需求(例如，產品應該如何與其餘系統協做)
6 假設
可能出現但未經肯定的需求。
在訂價時假設過多，極可能表明您不知道該第一時間交付什麼，最好將假設做爲問題從新表述給涉衆。
您的目標是確認假設是否爲需求。
這裏還包括是否有可能影響項目的經濟因素（如使用第三方的付費產品）？是否有數據質量要求？以什麼形式交付？
7 約束（例如時間、成果、資源、性能、架構）
8 依賴關係
每項任務的前後順序。
9 高級工做流計劃、時間線和里程碑(經過項目計劃定義更多細節)
10 評估計劃和績效指標

架構 / 設計（Architecture/Design）

軟件設計是將軟件需求轉換爲實現階段所需的軟件組件，接口和數據的表示的過程。

下面的模板是改編自 IEEE 軟件設計描述推薦的實踐。 更多信息請參閱 IEEE 1016

(團隊名) 
(項目名) 
設計文檔
名稱: 
實驗室: 
工做站: 
日期: 
<br/>
目錄
<br/>
1. 引言
1.1 目的
指定此SDD的用意及其目標受衆。 （例如「本軟件設計文檔描述了 XX 的架構和系統設計...」）。
1.2 邊界
提供軟件的描述和邊界，並闡述項目的意圖，目的和好處。這將爲您的產品的簡要描述提供基礎。
1.3 概述
提供本文檔的概覽和結構。
1.4 參考資料（可選）
列出參考的文檔。
1.5 定義和縮略語（可選）
提供可能存在的全部術語，首字母縮略詞和縮寫的定義，以正確解釋 SDD。這些定義應該是 SDD 中最可能不爲讀者所知的條目。

2. 系統概述
概述項目的功能，上下文和設計。必要時提供背景信息。

3. 系統架構
3.1 架構設計
開發用來實現系統的完整功能的模塊化程序結構，並解釋模塊之間的關係。這是對系統職責如何劃分而後分配給子系統的高級概述。肯定每一個高級子系統並賦予角色或職責。描述這些子系統如何相互協做以實現所需的功能。不要過多描述關於各個子系統的細節。架構設計的主要目的是大體瞭解系統分解的方式和緣由，以及各個部分如何協同工做。提供一個圖表，顯示主要子系統和數據存儲庫及其聯繫。必要時請描述該圖表。
3.2 分解描述
提供架構設計中子系統的分解。根據須要補充文字。您能夠選擇提供函數描述或面向對象的描述。有關函數描述，請提供頂層數據流圖（DFD）和結構分解圖。對於OO描述，提供子系統模型，對象圖，泛化層次圖（若是有），聚合層次圖（若是有），接口規範和序列圖。
頂層數據流圖：top-level data flow diagram（DFD）
結構分解圖：structural decomposition diagrams
子系統模型：subsystem model
對象圖：object diagrams
泛化層次圖：generalization hierarchy diagram(s)
聚合層次圖：aggregation hierarchy diagram(s)
接口規範：interface specifications
序列圖：sequence diagrams
3.3 設計理由
討論選擇3.1中描述的架構的緣由，包括關鍵議題和權衡考慮過的架構。您能夠討論考慮過的其餘架構，前提是您解釋了爲何不選擇它們。
581/5000

4. 數據設計
4.1 數據描述
解釋如何將系統的信息域轉換爲數據結構。描述主要數據或系統實體的存儲，處理和組織方式。列出所有數據庫或數據存儲項。
4.2 數據字典
按字母順序列出系統實體或主要數據及其類型和說明。若是您在3.2節中提供了函數描述，請列出全部函數和函數的參數。若是您提供了OO描述，請列出對象及其屬性，方法和方法的參數。

5.組件設計
在本節中，咱們將以更系統的方式仔細研究每一個組件的做用。若是您在3.2節中給出了函數描述，請以過程描述語言（PDL）或僞代碼給出3.2中每一個列出的函數的算法摘要。若是您給出了OO描述，請以PDL或僞代碼給出3.2中全部對象的每一個對象成員函數的算法摘要。必要時描述本地數據。

6. 人機接口設計
6.1 用戶界面概述
從用戶的角度描述系統的功能。說明用戶如何使用您的系統來完成全部預期的功能以及將爲用戶顯示的反饋信息。
6.2 屏幕圖像
展現用戶界面。這些界面能夠手繪或您可使用自動繪圖工具。只是讓它們儘量準確。（方格紙效果很好。）
6.3 屏幕對象和動做
討論屏幕對象和與屏幕對象關聯的行爲。

7. 需求矩陣
提供一個交叉引用，將組件和數據結構跟蹤到 SRS（Software Requirements Specification：軟件需求說明書）文檔中的需求。
使用表格格式顯示哪些系統組件知足SRS的哪一個功能需求。經過 SRS 中提供的數字/代碼引用到功能要求。

8.附錄（可選）
附錄能夠直接或經過引用包含在設計文檔內，以提供有助於理解軟件設計文檔的細節。

技術（Technical）

用戶（End user）

營銷（Marketing）

參考

• Product requirements document - Wikipedia
• Requirements, constraints, and assumptions – MattG's Weblog
• What is the best way of formally expressing usability requirements? - Stack Overflow
• Requirements, Assumptions, and Constraints
• How to Define Project Assumptions, Constraints, Dependencies and Critical Success Factors - SaS PMO - Confluence
• Software Design Document Template Components
• sdd_template.pdf