軟體需求說明的前世和今生

weixin_34162629發表於2017-06-26

軟體需求說明

軟體需求說明，也稱軟體需求說明書，或者軟體需求規格說明。或者軟體需求規格說明書。 相應的英文是Software requirements specification, 縮寫是SRS。

軟體需求說明是軟體系統需求的規格化說明。是對將要開發系統的行為的說明。它包含功能性需求，也包含非功能性需求，非功能性需求對設計和實現提出了限制。比方效能要求。質量標準，或者設計限制。

英文維基上的最新說明例如以下

A Software requirements specification (SRS), a requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints) .

傳統軟體需求說明書章節演示樣例

依據中國大陸GB 8567-88 計算機軟體產品開發檔案編制指南，軟體需求說明書章節例如以下：

 1引言
   1．1編寫目的 
   1．2背景 
   1．3定義 
   1．4參考資料 
 2任務概述
   2．1目標
   2．2使用者的特點 
   2．3假定與約束 
 3需求規定
   3．1對功能的規定
   3．2對效能的規定 
     3．2．1精度 
     3．2．2時間特性耍求
     3．2．3靈活性 
   3．3輸入輸出要求
   3．4資料管理能力要求
   3．5故障處理要求
   3．6其它專門要求
 4執行環境規定 
   4．1裝置 
   4．2支援軟體 
   4．3介面 
   4．4控制

至今各組織的軟體需求說明書模板儘管經過使用後歷經調整，但往往仍然可以看到上述章節要求的痕跡。

相關歷史

  • 1984年，IEEE公佈了 Guide to Software Requirements Specifications. 參見 http://dx.doi.org/10.1109%2FIEEESTD.1984.119205
  • 1988年。中國大陸公佈了GB 8567-88 計算機軟體產品開發檔案編制指南以及GB9385-88《計算機軟體需求說明編制指南》，這幾項標準中中國大陸影響深遠。非常好的指導了上世紀90年代的軟體開發，也統治了當時中國大陸的軟體工程教材。直到今天仍然有大量企業參照，而當時用例分析方法還沒有流行。
  • 1986年，Ivar Jacobson。UML和統一過程的重要貢獻者。將他在1967年定義愛立信AXE系統的構架時開始書寫使用場境usage scenarios改名為Use Case，即是用例。
  • 1997年11月，UML被OMG全體成員一致通過。並被採納為標準，而用例是當中的關鍵部分。

  • 1998年，使用者故事起源於極限程式設計中。User stories originated with Extreme Programming (XP), whose first written description in 1998 only claimed that customers defined project scope "with user stories, which are like use cases". Rather than offered as a distinct practice, they were described as one of the "game pieces" used in the planning game. However, most of the further literature thrust around all the ways arguing that user stories are "unlike" use cases, in trying to answer in a more practical manner "how requirements are handled" in XP and more generally Agile projects. This drives the emergence, over the years, of a more sophisticated account of user stories.
  • 2001年。 In 2001, Ron Jeffries proposed the well-known Three C's formula, i.e. Card, Conversation, Confirmation, to capture the components of a user story.參見https://en.wikipedia.org/wiki/User_story#History
  • 2008年，中國大陸公佈了GB/T9385-2008 《計算機軟體需求說明編制指南》，它是GB/T9385《計算機軟體需求說明編制指南》的第一次修訂，取代被廢止GB/T9385-1988。

現狀

到眼下的2014年，在軟體需求表達方式領域出現了例如以下三種常見情況：

  1. 仍然基於傳統SRS表達方式。常見的利用word來書寫
  2. 採用用例分析的表達方式，常見的利用UML工具來管理。比方Rose，EA等等
  3. 使用者故事的表達方式。常見的利用條目化（工作項）工具來管理，比方卡片，Jira，VSTS，Scrumworks等

有些組織儘管仍然稱呼需求文件為需求說明書（或者SRS），而實質的表達採用的是用例。這樣的情況歸屬於上述的第2種情況。

這樣包括用例的SRS的常見章節例如以下：

 1 專案概況 
   1.1  產品或系統名稱 
   1.2  產品或系統使用者 
   1.3  執行平臺 
   1.4  詞彙表 
   1.5  資料字典 
 2      效能指標和驗收標準 
 3      功能需求概況 
   3.1  整體概述 
   3.2  功能模組劃分 
   3.3  功能塊編碼 
 4      模組1 [比如]使用者組織 
   4.1  模組概述 
   4.2  業務邏輯規則 
   4.3  用例圖 
   4.4  用例1 [比如]用例：使用者登入 
     4.4.1      描寫敘述 
     4.4.2      相應的原始需求 
     4.4.3      前提條件 
     4.4.4      事件流 
     4.4.5      使用者介面 
     4.4.6      後置條件、特別要求和擴充套件點 
   4.5  用例2實現 
     4.5.1      描寫敘述 
     4.5.2      相應的原始需求 
     4.5.3      前提 
     4.5.4      事件流 
     4.5.5      使用者介面 
     4.5.6      後置條件、特別要求和擴充套件點 
   4.6  外部介面 
 5      模組2 格式同第5章 
   5.1  概述 
   5.2  業務邏輯規則 
   5.3  用例圖 
   5.4  用例1實現 
   5.5  用例2實現 
   5.6  外部介面 
 6      模組3…n 
 7      資訊保安方面需求 
   7.1  許可證方面需求 
   7.2  身份認證和授權方面需求 
   7.3  可恢復性方面需求 
 8      其他非功能性需求 
 9      其他要求

在最新的SWEBOK V3.0中，在這一領域仍然採用了“Software requirements specification”的說法。

可是在中文領域，軟體需求說明書是無法在字面意思上涵蓋：1。不採用SRS寫法的用例分析。2。使用者故事。

因此。提議中文領域相應詞彙是“軟體需求說明"或者“軟體需求規格說明", 沒有“書”字，這種字面意思就行涵蓋用例和使用者故事。

說明：至於表達內部事務的使用者故事是否屬於需求範疇。那是還有一回事，畢竟多數的使用者故事表達的是需求。

相關文章