管理信息系統
需求規格說明書編寫指南
文檔屬性：
文檔編號 |
|
文檔版本 | V1.0 |
保密級別 |
|
擬製 |
|
審覈 |
|
批准 |
|
修改記錄：
日期 | 修改章節 | 修改類型* | 修改描述 | 修改人 | 版本 |
03.8.10 | All | A | 創建 | 張昱 | 1.0 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*修改類型分爲 A - ADDED M - MODIFIED D – DELETED
1、概述
指南
目的：
介紹系統的開發背景。
內容：
l 軟件名稱和版本
l 系統目標
l 客戶和用戶
l 產品理念
l 文檔約定
l 參考文獻
方法和要點：
l 1.1節填寫軟件名稱和版本
l 1.2節填寫軟件開發目標，要求用量化的指標說明問題。可以參考《用戶需求報告》
l 1.3節填寫客戶和用戶。通常，購買軟件的組織或個人是軟件的客戶；軟件的具體使用人員是軟件的用戶。
l 1.4節填寫產品理念，包括對產品的預期；產品的意義；產品的價值；產品的理論依據等。
l 1.5節填寫文檔約定，包括文檔編號約定、命名標準、功能項描述約定、優先級說明、參考需求描述約定。
l 1.6節填寫參考文獻。包括參考的軟件、文檔和著作等。
1.1 軟件名稱和版本
1.2 目標
1.3 客戶和用戶
1.4 產品理念
1.5 文檔約定
需求優先級說明
優先級別 | 重要程度 | 說明 |
優先級1 [A1] | 最優先 | 必須實現。本文中未做特別表明的需求，優先級均默認爲優先級1。 |
優先級2 [A2] | 優先 | 爭取實現，如困難，可以變通的方式實現 |
優先級3 [A3] | 中等 | 爭取以變通的方式實現，如困難，則考慮到再升級時實現 |
優先級4 [C4] | 可以等待 | 再升級時必須實現 |
優先級5 [C5] | 不太必要 | 再升級時以變通的方式實現 |
1.6 參考文獻
2、術語表
指南
目的：
列出需要說明的概念、術語和縮寫，以便讀者能夠準確而一致地理解文檔內容。
內容：
l 業務術語和縮寫
l 容易產生歧義的計算機屬於和縮寫。
方法和要點：
l 關注重要的、頻繁出現的、不常見的、容易出現歧義的名詞、術語和縮寫。
l 如果術語較多，建議將術語分類。
l 對於名詞、術語和縮寫的解釋儘量採用權威解釋，儘量標明出處。
l 必要時添加圖表輔助說明。
3、綜合描述
指南
目的：
綜合概括系統的應用情景。讓用戶和開發人員對系統，以及系統涉及到的相關方面有一個整體的認識。
內容：
l 系統的背景和範圍
l 組織結構
l 崗位定義
l 作業流程
l 單據、賬簿和報表
l 功能結構
l 功能列表
l 運行環境
方法和要點：
啓用新系統後：
l 組織結構、崗位和流程將有哪些變化？
l 單據、賬簿和報表將帶來哪些改變？
l 系統的總體結構是什麼？
l 系統提供哪些主要的功能？
l 系統的應用環境是什麼？
本章回答上述問題。
計算機系統的啓用，很可能爲企業帶來新的管理思想和經營方式，原有的組織結構、崗位定義和作業流程將面臨變化。原有的組織結構可能被調整，原來的崗位可能撤銷或合併，原來的部分手工操作可能被計算機系統所取代。伴隨計算機系統的啓用，還可能建立新的部門，並派生出新的崗位，原來的流程將被全面梳理。一個計算機系統的啓用，如果“換湯不換藥”，不對原有組織、崗位和流程進行一遍梳理，那麼計算機系統產生的價值將得不到體現，時間一長，很可能從基層操作人員中萌生牴觸情緒，最終流於形式。當然，並不一定使用計算機系統以後，組織、崗位和流程一定會變，有可能用戶一開始已經建立了適應計算機管理的組織和流程，或者計算機系統的啓用，不足以改變現有組織和流程，那麼，不變也是對的。
單據、賬簿和報表是流程的載體，如果流程發生變化，單據、賬簿和報表往往也發生相應的變化。啓用計算機系統後，藉助計算機系統強大的處理能力，用戶可能查詢到更多的數據，單據的格式也可能更趨於靈活、統一。基於上述原因，應該描述變化後的單據、賬簿和報表。
系統功能結構，描述了我們對系統的“大局觀”。這部分內容對於設計人員理解需求具有很大的幫助，同時可以驗證分析人員是否正確設定了系統邊界以及功能設計是否清晰合理。
系統功能列表，從產品角度代表了對客戶的一種承諾。功能列表從管理角度講，、可以導出到“需求設計實現測試覆蓋列表”中，作爲設計、實現和測試追溯的源頭。
功能結構和功能列表，概括地給出了系統的總體規格。
系統的運行環境，將描述系統運行的軟件、硬件和網絡環境，以及大致的物理部署情況，其中還包括外設，特殊接口，第三方控件，中間件等。
下面是對本章各節的具體分工：
l 3.1節描述業務背景和範圍。
l 3.2節描述使用該系統後，用戶的組織結構以及部門職責。如果有《用戶需求報告》，可以省略和《用戶需求報告》相同的內容。如果沒有《用戶需求報告》，則不能省略這部分內容。
l 3.3節描述使用該系統後，用戶的崗位定義。如果有《用戶需求報告》，可以省略和《用戶需求報告》相同的內容。如果沒有《用戶需求報告》，則不能省略這部分內容。
l 3.4節描述使用該系統後，用戶的業務流程。如果有《用戶需求報告》，可以省略和《用戶需求報告》相同的內容。如果沒有《用戶需求報告》，則不能省略這部分內容。
l 3.5節描述使用該系統後，用戶使用的單據、賬簿和報表。如果有《用戶需求報告》，可以省略和《用戶需求報告》相同的內容。如果沒有《用戶需求報告》，則不能省略這部分內容。
l 3.6節給出功能結構，建議用圖形輔助文字的形式進行描述。應當綜合、概括地說明問題，避免陷入具體細節。
l 3.7節給出功能列表。必要時對功能進行分類。建議使用編號進行管理。建議建立優先級。
l 3.8節給出系統運行的硬件、軟件環境，包括大致的物理部署。
3.1 背景和範圍
3.2 系統的組織結構
組織結構圖
部門職責列表
部門 | 職責 |
|
|
|
|
|
|
|
|
|
|
|
|
3.3 系統的崗位定義
崗位定義表
崗位 | 所在部門 | 崗位職責 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.4 系統的作業流程
3.5 系統的單據、賬簿、報表格式
3.6 功能結構
3.7 功能列表
編號 | 功能項 | 優先級 | 功能簡要說明 | |
|
|
|
|
|
|
|
|
| |
|
|
|
| |
|
|
|
|
|
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|
|
|
|
|
| |
|
|
|
| |
|
|
|
| |
3.8 運行環境與物理部署
4、功能需求
指南
目的：
用Use Case契約的形式給出詳細的功能需求。
內容：
參見樣例。
方法和要點：
功能需求描述的一般要求。見下表。
功能需求的描述約定。見下表。
界面元素描述約定。見下表。
指南：功能需求的一般要求
正確 | 準確地描述要交付的功能。用戶決定需求的正確性。 |
明確 | 每個需求都有一種且只有一種解釋。 |
一致 | 文檔內容保持一致 文檔與前期工作產品保持一致。 |
完整 | 包括所有的重要需求。 |
恰當 | 恰當地限制需求範圍，合理地使用需求約束。 不指定任何設計或實施細節，不附加軟件之外的更多約束。 |
可實現 | 每個需求必須是可是實現的。 |
可跟蹤 | 每個需求都有明確的標識符。 每個需求的來源都是確定的。 |
可驗證 | 每個需求是可驗證的。 |
可修改 | 允許在結構和樣式不變的情況下，方便地對更改需求。 |
易理解 | 容易被客戶和開發人員理解。 |
可複用 | 容易被同類項目或產品複用。 |
優先級 | 每個需求都有明確的優先級。 |
指南：功能需求描述約定
編號 | <功能項編號> | 優先級 | <功能項的優先級> |
功能描述 | <功能項的簡要描述> | ||
交叉引用 | <所引用的其他功能編號> | ||
前置條件 | <用戶可以執行該功能的前提或條件> | ||
典型操作 | |||
用戶操作<逐條列舉用戶可能的操作，包括分支> | 系統響應<系統對用戶操作作出的反映> | ||
1)
| 1)
| ||
2)
| 2)
| ||
3)
| 3)
| ||
4)
| 4)
| ||
後置條件 | <該功能完成實現後，對業務系統的影響> <該功能完成實現後，系統的狀態> | ||
異常 | <發生的例外情況> | ||
參考界面 | |||
<界面圖片> | |||
指南：界面元素描述約定
數據項 | 數據描述 | 約束 | 能否修改 | 初始值 |
<可見的元素> | <功能和作用> | <顯示格式和範圍> | <能否修改> | <初始值> |
<其他的元素> | <功能和作用> | <約束和範圍> | - | <初始值> |
5、公共部件
指南
目的：
提取可以複用的公共部件，減少文檔冗餘。
內容：
打印和預覽。
條件查詢
權限
……
方法和要點：
基於增加複用和減少文檔冗餘的目的，建議分析人員將需求階段比較明顯的可以複用的需求規格項提取出來，獨立成章，這樣做的優點有兩個：
1. 可以作爲設計人員設計複用部件的依據。
2. 文檔中使用這些共用部件的部分直接引用到公共部件，不需要重複說明，從而減少文檔冗餘。
6、業務建模
指南
目的：
以第4章功能需求中定義的UseCase爲線索，建立業務模型。
內容：
參考業務建模樣例。
方法和要點：
參考業務建模指南。
7、數據實體
指南
目的：
識別數據實體和實體關係。
內容：
實體關係圖
實體描述
方法和要點：
業務系統往往使用關係型數據庫。數據實體是建立關係型數據庫數據結構的重要依據。
數據實體的重要來源是單據、賬簿、報表，以及業務建模過程中識別出的永久保存對象。
數據實體的要素爲：實體名、屬性和實體關係。
指南：實體關聯圖樣例
指南：實體描述模板
名稱 | <數據實體的名稱> | ||||||
註釋 | <數據實體的註釋> | ||||||
數據量的估計 | <數據容量的估計（按行）> 行 | <數據量的估計(按字節)> K | |||||
索引 | <索引，根據情況可以不填> | ||||||
別名 | 列名 | 數據類型 | 空值 | 缺省 | 規則 | 註釋 | |
<中文名稱> | <正式的名稱> | <數據類型> | <能否爲空> | <能否缺省> | <是否主外鍵> | <註釋> | |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
8、非功能需求
指南
目的：
描述系統的非功能性需求
內容：
l 外觀
l 易用性
l 性能
l 可靠性
l 質量要求
l 其他
方法和要點：
l 8.1節填寫期望的產品外觀，包括：
顯示方式
顯示風格
外觀傾向
外觀意圖
……
l 8.2節填寫易用性要求，包括
易操作
易學習
易理解
……
l 8.3節填寫系統性能。包括：
速度
效率
可用性
準確性
吞吐量
響應時間
恢復時間
……
l 8.4節填寫可靠性。包括：
故障的頻率/嚴重性
可恢復性
可預見性
準確性
平均故障響應時間（MTBF）
……
l 8.5節填寫質量要求。
千行Bug數。
……
l 8.6節填寫其他非功能性需求。
8.1 外觀
8.2 易用性
8.3 性能
8.4 可靠
8.5、質量要求
8.6、其他
9、其他描述
9.1 開發環境
9.2 設計和實現上的限制
9.3 需求—分配需求對應情況
需求—分配需求對應情況 | |
需求（按需求的編號，從小向大遞增） | 分配需求（對分配需求編的號） |
|
|
|
|
|
|
|
|
|
|
|
|
10、附錄：
10.1 待定問題列表
10.2 附件
