需求提供者經常不大瞭解系統應該包含哪些內容,因此他們可能會提出不恰當的需求。需要通過系統邊界定義初步剔除那些明顯在系統範圍之外的需求,以免這些需求干擾後續的分析過程。
檢查每項原始需求,將它們區分爲系統需求、過程需求和應該拒絕的需求。考慮如下問題:
- 某項需求是否是基於不完整的或者不可靠的信息做出的?
- 某項需求的實現是否需要在系統已定義的數據庫之外的信息?
- 某項需求是否和系統的核心功能相關?
- 某項需求是否牽涉到系統之外的功能或者設備的性能?
對於問題1和問題2可以判斷是否爲過程需求,如果是過程需求,則要求系統的操作者提供這些信息,否則需要複審系統應該處理的數據。
對於問題3和問題4可以判斷是否是系統邊界以外的需求。如果是,則它可能是不必要的,也可能是無法實現的需求。
對於於操作過程相關的需求和系統邊界之外的需求,必須準備一些技術的和經濟的論據,說明這些需求被拒絕的理由。這些論據應該是基於這個組織已定義的業務目標或者系統可行性研究的結果。
系統邊界的定義和需求的檢驗都需要通過需求的複審來進行,需求的複審之前可以定義適當的分析檢驗表,如:
檢驗表項 | 檢驗內容的描述 |
草率設計 | 該需求是否包含不成熟的設計或實現信息? |
組合需求 | 是單獨的需求還是可以細分爲幾個不同的需求? |
多餘需求 | 只是系統的裝飾而不是真正必須的嗎? |
使用非標準硬件 | 該需求必須使用非標準的硬件還是軟件? |
符合業務目標 | 該需求是否符合已定義的業務目標? |
需求多義性 | 該需求對不同的人是否可能有不同的理解? |
需求可實現性 | 根據現有的實現技術,是否可以實現該需求? |
需求可測試性 | 測試工程師是否可以從需求的表述中導出測試已判斷系統是否符合需求? |