我們可以將一份好需求整體總結為以下8個特點：完整性、可行性、可驗證性、不含糊性、一致性、正確性、可理解性、可修改性。
1.完整性
- 所有外部需求都應被確認。
- 需求包含功能、性能、設計限制、接口等關鍵要素。
- 軟件外部的輸入數據類別應完整，要明確指定對有效和無效輸入值的響應，比如，對于“電壓大于20V時，......”，應該增加“電壓小于20V時，......”。
- 術語應明確定義。
2.可行性
- 能夠在系統及其使用環境的已知能力和限制范圍內實現。
- 技術上能不能做。
- 不需要以過高的成本或其他突出損失來實現。
3.可驗證性
- 每一條需求都是可驗證的。
- 不需要以太高的成本去驗證。
- 需求應定義明確，比如，“經常會出現”、“性能良好”、“HMI美觀”就不可驗證。
- 理論上要成立，比如，“車機永遠不能死機”是無法去驗證的。
4.不含糊性
- 每條需求只有一種解釋。
- 應有明確定義的術語表。
- 對于創建者和使用者都是明確的。
- 動詞更勝于名詞。
- 應有主語，比如，“每50ms發送一次信號”就語焉不詳。
- 不要使用“和”、“或”、“如果”、“但是”這些承接詞，比如，“在遇到故障時，控制器應記錄DTC，并點亮儀表燈”應拆分為兩條。
- 自然語言自帶含糊性，需獨立第三方評審。
5.一致性
- 需求內部沒有沖突。
- 需求與上級文檔一致。
- 需用的術語要統一。
6.正確性
- 需求描述是針對產品的。
- 與相關文檔進行比對，比如，上級規范、base項目文檔以及相關標準。
- 客戶或用戶視角下的評審。
- 基于追溯關系來檢查。
- 工具或流程無法確保正確性。
7.可理解性
- 足夠精簡，內容有任何刪減都會導致含義變化。
- 不需要以過高的成本去理解。
- 應增加適當的注釋。
- 使用這些需求的角色都能理解。
- 充分使用圖和表，比如，時序圖、功能塊圖、真值表等。
8.可修改性
- 容易修改并還能保持原有的結構和風格。
- 具有連貫且易于閱讀的結構，包括目錄和引用。
- 不冗余，即同一需求在需求規范中僅出現一次。
- 需要出現多次時，可以使用引用的方式。
- 每條需求都是獨立的，而不是與其他需求混在一起。
9.寫在最后
整體來說，撰寫需求時，要干脆利落，要“毫無感情”。
轉自汽車電子與軟件
