软件需求说明，也称软件需求说明书，或者软件需求规格说明，或者软件需求规格说明书， 对应的英文是Software requirements specification, 缩写是SRS。

软件需求说明是软件系统需求的规格化说明，是对将要开发系统的行为的说明。它包括功能性需求，也包括非功能性需求。

传统软件需求说明书章节示例

根据中国大陆GB8567-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. ^[3]。
• 1988年，中国大陆发布了GB8567-88《计算机软件产品开发文件编制指南》以及GB9385-88《计算机软件需求说明编制指南》^[4]，，这几项标准中中国大陆影响深远，很好的指导了上世纪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 《计算机软件需求说明编制指南》 ^[5]，它是GB/T9385《计算机软件需求说明编制指南》的第一次修订，代替被废止GB/T9385-1988。

现状

到目前的2014年，在软件需求表达方式领域出现了如下三种常见情况：

1. 仍然基于传统SRS表达方式，常见的利用word来书写
2. 采用用例分析的表达方式，常见的利用UML工具来管理，比如Rose，EA等等 ^[6]
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^[7]中，在这一领域仍然采用了“Software requirements specification”的说法。

但是在中文领域，软件需求说明书是无法在字面意思上涵盖：1，不采用SRS写法的用例分析；2，用户故事。

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

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

参考资料