目標
系統需求分析過程的目的是將<strong>已定義的干係人需求轉化為<strong>系統需求集以指導系統設計。
收益
系統需求分析是整個產品研發的基礎，完備的表述、清晰無歧義的定義、結構化組織的系統需求是高效開發和功能測試的基石。
工作產品
溝通記錄
評審記錄
變更控制記錄
追蹤記錄
分析報告
接口需求文檔
系統需求規範
驗證準則
基礎實踐
BP1: 確定系統需求
通過干係人需求和干係人需求變更識別系統的功能和能力。確定功能和非功能系統需求，形成系統需求規範。
NOTE 1: 影響功能和能力的標定參數也是系統需求的一部分。
NOTE 2: 對於干係人的需求變更應用SUP.10.
解讀
- 系統需求的確定要考慮所有的干係人，包括內部和外部干係人的輸入，不要遺漏對系統有影響或被系統影響的相關方。
- 系統需求不是干係人需求的簡單拷貝，系統需求是干係人需求的衍生和細化，需求的條目數量一般遠多於干係人需求。
- 不僅要確定功能性需求，還要包含非功能性部分
BP2: 結構化系統需求
在系統需求規範中<strong>結構化系統需求
NOTE 3: 執行優先級通常包括功能內容到計劃發佈的分配，參考 SPL.2.BP1.
解讀
- 系統需求以結構化的形式進行組織，並統一於形成的系統需求規範中。結構化的方式使需求結構更清晰，有助於提高需求管理效率。
- 系統需求規範需要被記錄，例如Word文檔進行記錄，也可以基於商業工具進行記錄，例如DOORS/DNG/Polarion。
BP3: 分析系統需求
分析已確定的系統需求，包括需求間的依賴關係，以保證正確性、技術可行性和可驗證性。分析成本和進度影響和技術影響。
NOTE 4: 對成本和進度的影響分析支持項目估算的調整，參考 MAN.3.BP5.
解讀
- 系統需求分析設計需求依賴關係、風險、正確性、可行性、可驗證性、成本和時間等諸多因素。
BP4: 分析對運行環境的影響
識別已確定的系統與運行環境的其他元素間的接口。分析系統需求將會對這些接口和運行環境的影響。
BP5: 確立驗證準則
為系統需求制定驗證準則，驗證準則定義了需求驗證所需的定量和定性方式 。
NOTE 5: 驗證準則展示了一條需求可以基於達成一致的約束被驗證，其通常作為開發系統測試用例或其他確保系統需求遵循性的驗證方式的輸入。
NOTE 6: 不能通過測試覆蓋的驗證由SUP.2過程覆蓋。
解讀
- 驗證準則表明了需求驗證基於的方式，定義了什麼是 "完成" ，是判斷需求是否被滿足的準則。
BP6: 確立雙向追蹤
確立干係人需求和系統需求間的<strong>雙向可追蹤性
NOTE 7: 雙向追蹤性支持覆蓋度分析、一致性分析和影響分析
解讀
- 雙向追蹤關係可以通過維護跟蹤矩陣，或者基於工具提供的鏈接功能。關聯方向可以做適當的區分，並制定有意義的表述關聯關係的詞彙。
BP7: 保證一致性
確保干係人需求和系統需求的一致性
NOTE 8: 一致性由雙向追蹤性支持，並可以通過評審記錄進行展示。
BP8: 傳達達成一致的系統需求
傳達達成一致的系統需求以及對系統需求的更新到所有相關方。
解讀
- 達成一致的系統需求和需求變更必須被所有的相關方知曉，以溝通記錄的形式進行記錄。
閱讀更多 瘋狂架構 的文章
