Good SRS, 軟體需求規格, SRS範本 <<SRS 指引>> 分享鏈結
在軟體系統開發的過程中, 我們都會不自覺的寫出一些東西. 在剛開始工作的前幾年, 並不覺得寫出的內容有什麼問題, 隨著時間的過去, 回頭看看寫以前的東西, 發現每次寫的內容範圍都不一樣, 內容的層次也高高低低, 沒有個準. 幾年之後, 終於找到時間整理一下這些想法.
軟體需求規格書 (SRS) 在軟體開發的過程中是由系統分析人員負責撰寫. 在本質上 SRS 是在描述軟體(系統) 提供哪些功能 ? 如何與外部系統或硬體互動 ? 與使用者之間介面的行為, 系統可在怎樣的環境中提供服務… 在 SRS 中沒有提到的就是如何實作出這些程式. 因為這些是屬於軟體設計說明(SDD) 範圍, 不屬於SRS.
軟體系統需求規格書 目錄
1. 企業需求
有如雲等級的 UseCase (目標不應該太多)
重點應該在於要滿足企業的哪些目標.
2. 使用者需求
以使用者的需要, 想要做的事情, 希望解決的問題, 希望達到的目標來做為章節。
我認為應該有一份使用者需求 "清單"，再依照每一條需求詳加說明.
使用者需求發掘重點...
1. 使用者在執行公司政策時遇到的問題，問題的解決方案為何？
2. 使用者因應公司政策而提出新的流程或解決方案，要求系統必須配合其流程增加(修改)功能特性(Feature)。
*) 使用者包含 CIM 本身
聚焦
在了解問題時請不斷的詢問自己以下的問題,
1. 使用者在現況遇到怎樣的問題 ?
2. 這些問題對使用者造成什麼影響 ?
3. 使用者認為可能的原因是什麼 ?
4. 使用者希望如何改善 ?
5. 使用者認為這樣的改善可以增進哪方面的效率 ?
6. 誰可以執行這樣的作業? 是否需要誰的允許才可執行?
『假設』是我們信以為真的事情。
除非你知道顧客的假設是什麼，否則不可能予以驗證。當你要證實顧客的需求時，你得先確定他的假設是正確的。
2.1 現狀與未來
2.2 需求清單
2.3 URxx_<希望解決的問題>
1. Input: 找出問題
＊使用者在現況遇到怎樣的問題 ?
＊這些問題對使用者造成什麼影響 ?
＊使用者認為可能的原因是什麼 ?
2. Process:
＊分析上述問題的真正原因為何?
＊利用 5W2H 層層深入, 就像在撥洋蔥一樣.
＊What : 問題是什麼？
＊Why : 為什麼會有這個問題？ 為什麼覺得這是個問題？
＊Where : 問題會在哪邊發生？
＊Who : 誰覺得這是個問題？這個問題和誰相關？誰對問題的解決方案有影響力？
＊When：問題何時會發生？問題何時要被解決？
＊How : 問題如何發生？如何證實可以解決這個問題？
＊How much : 有多少效益？要花多少成本？完成要多久？ROI ?
3. Output: 寫出真正問題的解決方案
4. 與使用者談論如何驗證此方案能解決他們的問題
5. Validation:
＊整體思考方式需從問題導向至解決方案
＊必需要能驗證方式
＊使用者需求必須能達成解決方案
＊不可出現模糊的形容 (如: 變好，改善, 比例, 變快...)
＊規格說明文法必須正確。在一句話中至少要有主詞+ 動詞+ 受詞。
＊需求必須給予編號
2.4 URxx_<想要做的事情>
3. 系統需求編號方式
4. 系統規格書
4.1 序言
4.1.1 目的
4.1.2 範圍
4.1.3 系統概述
4.1.3.1 子系統 A
4.1.3.2 子系統 B
4.1.4 術語詞彙
4.1.4.1 系統術語
4.1.4.2 企業術語
4.2 系統功能描述
4.2.1 概觀
4.2.1.1 功能介紹
4.2.1.2 環境圖
4.2.1.3 使用者特徵
4.2.1.4 設計與實作限制
4.2.1.5 假設與相依
4.2.1.6 操作概念與腳本
4.2.1.7 介面需求
4.2.1.7.1 系統界面
4.2.1.7.2 用戶界面
4.2.1.7.1.1 UI
4.2.1.7.3 硬體界面
4.2.1.7.4 軟體界面
4.2.1.7.4.1 API
4.2.1.7.4.2 與外部系統之間
4.2.1.7.5 通信界面
4.2.1.7.6 記憶體限制
4.2.1.7.7 場所適應需求
4.2.2 業務/系統實體
4.2.3 資料模型
4.2.3.1 概念資料模型
4.2.4 功能或作業需求
4.2.4.1 <模組>
4.2.4.1.1 功能描述
4.1.4.1.2 功能需求清單
4.1.4.1.3 使用案例圖
4.1.4.1.4 操作概念與腳本
4.1.4.1.5 使用案例組
4.1.4.1.5.1 SUCxxx: XXXXX
4.1.4.1.5.2 UCxxx: XXXXX
4.2.5 非功能性需求
4.2.6 設計與實做限制
4.3 <子系統功能描述>
4.4 需求分配
4.5 未解決的議題
留言列表
軟體世界 
