軟體測試中影響軟體需求質量的因素有哪些？

軟體的開發和上線應用，離不開軟體測試這一過程，軟體測試是分析者用來發現軟體缺陷的過程。沒有任何軟體是完全無缺陷的，測試者的目標是減少在專案中找到的缺陷，並且將質量灌輸到軟體應用中。

軟體測試和使用者體驗有非常直接的關係，因為軟體測試者需要透過分析軟體來獲知軟體是否符合使用者的期望。軟體測試是一種設計來適當保障軟體符合使用者所需求的質量活動。

使用者所需求的也就是軟體所需求的，所以軟體需求是保證最終軟體質量最為關鍵的一環，也是軟體測試的基礎。高質量的軟體需求，為產品的最終質量打下了堅實的基礎。

那麼，影響高質量軟體需求質量的因素有哪些？

一、理解性

需求必須是可以理解的，可理解的需求組織方式便於閱讀、評審。下面是一些提高可理解性的方法：

1、根據物件(如使用者、訂單和發票)來組織需求。

2、使用者需求應該按業務過程或者場景來進行組織，這樣，行業專家就能快速判斷是否有遺漏的需求。

3、將功能需求和非功能需求分開，例如，將功能需求和效能需求分開說明。

4、根據詳細程度來組織需求。由需求對系統的影響來決定，例如“系統應該能夠接收訂單”與“系統應該能夠接收銷售點的零售訂單”對系統就有不同的影響。

5、編寫出來的需求應該符合語法規則，樣式應該便於閱讀、評審。如果需求是用word文件編寫的，就應該啟用拼寫檢查選項，同時注意上下文，因為word並不檢查下文是否合適。

6、需求應該是明確的，在需求中應恰當的使用“應該”一詞，而不要使用“將會”或者“應該會”，因為後面兩個詞講的是目標，而不是需求。如果使用非命令式的詞語，這樣表明需求是可選的，可能會導致需求被誤解，可能增加專案成本，也可能使時間週期增加，降低質量，或者出現合同糾紛。

二、必需性

需求應該是必需的。舉個非必須需求的例子。假設下面這個需求已包含在需求規格說明書中：“如果有100個測試用例透過，那麼系統應該是可接受的。”這實際是一個專案過程，而不是需求，不應該記錄在需求規格說明裡。需求必須與正在構建的目標應用或系統相關。

三、可修改

需求及相關資訊必須是可以修改的。選用儲存需求的技術影響著需求的可修改性，例如，字處理器中的需求比需求管理工具(如CaliberRM)中的更難修改。但是，針對非常小的專案，因為需求管理工具成本與學習曲線的關係，字處理器就成了最佳選擇。

一致性也對可修改性有影響。需求的編寫模板結構應該使需求很好呈現，從而方便修改。最佳實踐應把每個需求用唯一識別符號進行標記。任何需求的依賴關係都應該有標註，例如，需求X應該依賴於需求Y。

四、非冗餘

不應該出現重複的需求，否則會引發問題。重複需求會加重維護工作，例如，每次修改某個需求時，也要修改與之重複的那個需求。重複需求還會提高出現注入需求錯誤的可能性。

五、簡潔性

一個好的需求必須杜絕出現冗詞贅句或者多餘資訊。一個簡潔的需求表達應該一語中的，諸如“另一方面”、“然而”、“回想起來”這類詞眼應該杜絕。

六、可測試

可測需求必須可以被驗證確認，也可以說，需求的意圖應該是能夠證明的。不可測試的需求適合測試人員要做客觀解釋的時候。最好就是帶著問題：我是否可以測試這個需求，瞭解它能否行得通?

七、跟蹤性

需求必須是可跟蹤的，這是驗證是否滿足需求的關鍵。複合需求很難跟蹤，可能導致產品測試失敗。例如“系統應該計算出退休金和遺屬撫卹金”就是一個複合需求。透過列表方法可以避免在評審各個需求的跟蹤能力時造成誤解。

八、範圍定義

所有需求必須在指定範圍內定義。專案的範圍是根據為專案建立的所有需求而定的。專案範圍按照對需求的標識、分析和基準線來定義和細化。“跟蹤能力矩陣”有助於保證需求位於指定範圍內。