軟件需求說明

軟件需求說明(英語:Software requirements specification),也稱軟件需求說明書軟件需求規格說明軟件需求規格說明書,縮寫是SRS。軟件需求說明是軟件系統需求的規格化說明,是對將要開發系統的行為的說明。軟件需求說明是在商業需求規格英語usiness requirements(或稱為利益相關者需求規格,StRS)產生後再建立的模型。它包括功能性需求非功能性需求,非功能性需求對設計和實現提出了限制,比如性能要求,質量標準,或者設計限制,也可能會包括用例,敘述在理想情形下,使用者使用軟件的方以及需要提供給的介面。

軟件需求說明是客戶和供應商(或承包商)協議的基礎,說明軟件產品應該有的機能(若是由行銷所驅動的專案,會是行銷部門以及開發部門進行這些討論)。軟件需求說明是在具體的系統設計階段之前,嚴謹的需求評估。這也是預估產品成本、風險以及時程的實務性基礎[1]。若適當的使用軟件需求說明,可以預防軟件專案的失敗[2]

軟件需求說明文件會列出專案開發上,充份且必要的需求資訊[3]。在推導需求的過程中,開發者需要對要開發的產品非常清楚,有透澈的瞭解。這是靠專案團隊和客戶在產品開發過程中很詳細且持續的溝通達成的。

軟件需求說明可能是承包商可交付英語deliverable資料項目說明英語data item descriptions中的一項[4],也有可能是其他組織要求文件中的一部份。 軟件需求說明多半是由技術寫作人員系統架構師程式設計師所撰寫[5]

傳統的軟件需求說明書

編輯

中國大陸對軟件需求說明是根據 GB8567-88《計算機軟件產品開發文件編制指南》進行編寫的,雖然此標準到2008年就已經廢止,但其影響深遠,至今各組織的軟件需求說明書模板雖然經過使用後歷經調整,仍然有明顯的該標準痕跡,可以說形成了傳統的軟件需求說明書的寫法。

相關歷史

編輯
  • 1984年,IEEE發佈了Guide to Software Requirements Specifications. [6]
  • 1988年,中國大陸發佈了GB8567-88《計算機軟件產品開發文件編制指南》以及GB9385-88《計算機軟件需求說明編制指南》[7],這幾項標準中中國大陸影響深遠,很好的指導了上世紀90年代的軟件開發,也統治了當時中國大陸的軟件工程教材。直到今天仍然有大量企業參照,而當時用例分析方法還沒有流行。
  • 1986年,UML統一過程的重要貢獻者Ivar Jacobson,將他在1967年定義愛立信AXE系統的構架時開始書寫使用場境usage scenarios改名為Use Case(用例),即是用例。
  • 1997年11月,UML被OMG全體成員一致通過,並被採納為標準,而用例是其中的關鍵部分。
  • 1998年,用戶故事起源於極限編程中,
  • 2008年,中國大陸發佈了GB/T9385-2008 《計算機軟件需求說明編制指南》 [8],它是GB/T9385《計算機軟件需求說明編制指南》的第一次修訂,代替被廢止GB/T9385-1988。

近狀

編輯

到2014年為止,在軟件需求表達方式領域出現了如下三種常見情況:

  1. 仍然基於傳統SRS表達方式,常見的利用word來書寫
  2. 採用用例分析的表達方式,常見的利用UML工具來管理,比如Rose,EA等等 [9]
  3. 用戶故事的表達方式,常見的利用條目化(工作項)工具來管理,比如卡片,Jira,VSTS,Scrumworks等

有些組織雖然仍然稱呼需求文檔為需求說明書(或者SRS),而實質的表達採用的是用例,這種情況歸屬於上述的第2種情況。

在最新的SWEBOK V3.0[10]中,在這一領域仍然採用了「Software requirements specification」的說法。

但是在中文領域,「軟件需求說明書」是無法在字面意思上涵蓋「不採用SRS寫法的用例分析」和「用戶故事」的。

說明:至於表達內部事務的用戶故事是否屬於需求範疇,那是另一回事,畢竟多數的用戶故事表達的是需求。

需求異味

編輯

需求也會有類似代碼異味的情形,需求異味(requirements smell)是指需求規格上的問題,需求不一定不對,但會在實現上造成困難[11]

需求異味的例子包括有主觀語言、模糊的副詞及形容詞、最高級以及否面敘述等[11]

相關條目

編輯

參考資料

編輯
  1. ^ Bourque, P.; Fairley, R.E. Guide to the Software Engineering Body of Knowledge (SWEBOK). IEEE Computer Society. 2014 [17 July 2014]. (原始內容存檔於2014-12-28). 
  2. ^ Software requirements specification helps to protect IT projects from failure. [19 December 2016]. (原始內容存檔於2018-01-30). 
  3. ^ Pressman, Roger. Software Engineering: A Practitioner's Approach. Boston: McGraw Hill. 2010: 123. ISBN 9780073375977. 
  4. ^ DI-IPSC-81433A, DATA ITEM DESCRIPTION SOFTWARE REQUIREMENTS SPECIFICATION (SRS). everyspec.com. 1999-12-15 [2013-04-04]. (原始內容存檔於2017-12-09). 
  5. ^ Donn Le Vie, Jr. "Writing Software Requirements Specifications (SRS)"頁面存檔備份,存於互聯網檔案館). 2010.
  6. ^ 830-1984 - IEEE Guide to Software Requirements Specifications
  7. ^ GB9385-88 計算機軟件需求說明編制指南
  8. ^ GB/T9385-2008 《计算机软件需求说明编制指南》. [2014-04-19]. (原始內容存檔於2014-04-19). 
  9. ^ 張秋余 楊玥 王雪 王鵬 賈志龍 基於用例的需求建模方法 《計算機工程與設計》 2006年19期
  10. ^ Guide to the Software Engineering Body of Knowledge V3.0 SWEBOK V3.0. [2014-04-19]. (原始內容存檔於2014-04-13). 
  11. ^ 11.0 11.1 Femmer, Henning; Méndez Fernández, Daniel; Wagner, Stefan; Eder, Sebastian. Rapid quality assurance with Requirements Smells. Journal of Systems and Software. 2017, 123: 190–213. S2CID 9602750. arXiv:1611.08847 . doi:10.1016/j.jss.2016.02.047.