非功能性需求是除開功能性需求外需要滿足的系統要求,可以理解為系統的質量要求,一般包括效能、安全性、可靠性、可用性、可維護性、完整性、可測試性、有效性等。細分下來有很多,不過前輩們和一些權威機構幫我們做了很好的歸類。
常見的軟體質量模型有:
● jim mccall 軟體質量模型(1977 年)我個人認為ibm的rup裡的「furps+」是比較好的方法,可以作為檢查表來用,避免需求遺漏;而iso的軟體質量模型當然是最權威的了。下面簡單說明一下這兩個方法。● barry w. boehm 軟體質量模型(1978 年)
● furps/furps+ 軟體質量模型
● r. geoff dromey 軟體質量模型
● iso/iec 9126 軟體質量模型(1993 年)
● iso/iec 25010 軟體質量模型(2011 年)
● 功能性(functional):特性、功能、安全性;● 可用性(usability):人性化因素、幫助、文件;
● 可靠性(reliability):故障頻率、可恢復性、可**性;
● 效能(performance):響應時間、吞吐量、準確性、有效性、資源利用率;
● 可支援性(supportability):適應性、可維護性、國際化、可配置性。
● 「+」是指一些輔助性的和次要的因素,比如:
○ 實現(implementation):資源限制、語言和工具、硬體等;
○ 介面(inte***ce);強加於外部系統介面之上的約束;
○ 操作(operation):對其操作設定的系統管理;
○ 包裝(packaging)例如物理的包裝盒;
○ 授權(legal):許可證或其他方式。
但是對於需求分析師來說,調研非功能性需求比調研功能性需求難很多。其中乙個原因是非功能性需求沒有放之四海而皆準的通用標準。我們經常在寫需規的時候都會複製貼上一些常見的指標,如:
但實際上非功能性需求很難做到具體的量化,例如同樣是模糊查詢,對固定需求分析師如何做好非功能性需求求也有所不同。
另乙個非功能性需求不好調研的原因是它更接近架構設計的範疇,是架構師考慮的事,剛好這些是需求分析師不擅長的,正因為這個不擅長也導致需求分析師經常選擇性的忽略這部分內容。
那麼應該如何調研非功能性需求呢?我認為可以從以下幾方面出發考慮。
第一,時刻關注非功能性需求
在調研業務需求時,要時刻留意功能實現對非功能性指標所帶來的影響,並在調研過程中有意識地了解系統執行的相關情況,例如客戶提供的硬體裝置,使用者量,業務量,業務辦理頻率、峰值等問題。
第二,讓架構師提前參與
對於一些客戶明確提出的關鍵指標或可預見的問題,如大資料應用的效能問題,或者像可靠性、可用性等問題,需要讓架構師提前考慮,在技術上給出解決方案。
第三,多總結
功能性需求和非功能性需求
需求定義 需求 requirement 就是系統 更廣義的說法是專案 必須提供的能力和必須遵從的條件。需求分類 1 在一般使用中,需求按照功能性 行為的 和非功能性 其它所有的行為 來分類。功能性需求是說有具體的完成內容的需求。非功能性需求是指軟體產品為滿足使用者業務需求而必須具有且除功能需求以外的...
非功能性需求
所謂非功能性需求,是指軟體產品為滿足使用者業務需求而必須具有且除功能需求以外的特性。軟體產品的非功能性需求包括系統的效能 可靠性 可維護性 可擴充性和對技術和對業務的適應性等。下面對其中的某些指標加以說明。在這裡可以看到非功能性需求涉及的範圍很廣,軟體產品本身不是孤立存在的,還涉及到諸多外在環境的影...
軟體 非功能性需求
軟體需求分為功能需求和非功能性需求,常常會因為注重功能需求而忽略了非功能性需求,以下是對常見幾類非功能性需求的總結。非功能性需求 1 定義 軟體產品為滿足使用者業務需求而必須具有且除功能需求以外的特性。2 影響 影響著產品是否能夠持續穩定並高效的提供服務。3 常見類別 效能需求 響應時間 吞吐量 資...