软件需求说明的前世和今生

软件需求说明

软件需求说明，也称软件需求说明书，或者软件需求规格说明。或者软件需求规格说明书。 相应的英文是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。用户故事。

因此。提议中文领域相应词汇是“软件需求说明"或者“软件需求规格说明", 没有“书”字，这种字面意思就行涵盖用例和用户故事。

说明：至于表达内部事务的用户故事是否属于需求范畴。那是还有一回事，毕竟多数的用户故事表达的是需求。