更多技术性文章请关注 合伙呀
1 引言
1.1 产品定义
1.1.1 产品目标
<应将软件产品与业务策略联系起来进行描述>
1.1.2 行业背景
1.1.3 产品适用范围
1.2 文档描述
1.2.1 编写目的
<介绍本文档索要描述的内容，罗列编写本文档的作用与意义。可以指明作为什么步
骤的参考、什么步骤的依据。需求分析说明书一般能够作为软件设计的基础，能够作为设计评审和产品评审的依据。还需要指明本文档不负责什么——提出的不负责
内容应尽可能给出哪个文档负责的建议>
1.2.2 编写过程
1.2.3 文档适用范围
<列举软件需求规格说明所针对的不同读者。例如开发人员、项目经理、营销人员、用户、测试人员或文档编写人员。描述文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议>
1.3 文档约定
1.3.1 内容约定
<例如，说明高层需求的优先级是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自身的优先级>
1.3.3 格式约定
<描述编写文档时所采用的格式标准或排版约定，包括正文风格、提示区或重要符号>
1.4 术语和缩略语
1.5 符号含义
<列举所有的特殊符号并介绍其含义>
1.6 参考文献
<列举了编写本文档所参考的资料或其他资源。在这里应该给出详细的信息，包括标题的名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。需求分析说明书的参考文献可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档>
2 任务概述
2.1 产品目标分析
<根据产品定义和行业背景，说明该产品是否是产品系列中的下一成员，是否是成熟
产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的、自含型产品；以及概述做到这些的方法。如果本产品需求上为某一个大产品的一
部分，则要说明这部分软件是怎样与整个系统相关联的>
2.2 用户特点分析
<根据实际用户情况，指出软件应该如何满足用户需要。分析使用该产品的不同用户类并描述他们相关的特征。特别应注意将该产品的重要用户类与那些不太重要的用户类区分开>
2.3 假定约束分析
2.3.1 直接约束
<指出为达到所需要的功能、性能，并满足各种约束条件，所需要满足的条件。包括需要的软件产品支持，需要的硬件以及其它支持等>
2.3.2 选择约束
<确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。可能的限制包括以下内容：
甲、必须使用或者避免的特定技术、工具、编程语言和数据库
乙、所要求的开发规范或标准（例如，如果有客户的公司负责软件维护，就必须定义转包者所使用的设计符号表示和编码标准）
丙、企业策略、政府法规或工业标准
丁、硬件限制，例如定时需求或存储器限制
戊、数据转换格式标准>
2.3.3 引入约束
<引入约束可能包括打算要用的商业组件或有关开发或运行环境的问题。你可能认为
产品将符合一个特殊的用户界面设计约定，但是另一个需求分析人员却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。此外，确定
项目对外部因素存在的依赖。例如，如果你打算把其他项目开发集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其他文
档（例如项目计划）中了，那么在此就可以参考其他文档>
2.4 功能分析
<概括地总结产品所具有的主要功能。例如用列表的方法给出。也可以用图形表示主要的需求分组以及他们之间的联系>
3 外部接口需求
<本节用以保证产品与外部组件或其它软件正确连接。这包括所有功能产生的外部接口需求>
3.1 用户界面
<陈述所需要的用户界面统一规范风格。这可能包括但不限于：所有界面统一的布局、页面元素、功能；将要采用的图形用户界面（GUI）标准或产品系列的风格；屏幕布局或解决方案的限制；快捷键；错误信息显示标准>
3.2 硬件接口
<描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质>
3.3 软件接口
<描述该产品与其他外部组件（由名字和版本识别）的连接，包括数据库、操作系
统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。
如果必须用一种特殊的方法来实现数据共享机制，例如在多任务操作系统中的一个全局数据区，那么就必须把它定义为一种实现上的限制>
3.4 通信接口
<描述与产品所使用的通信功能相关的需求，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制>
4 系统功能描述
<根据需求，抽取出软件元素。软件元素包括“访问数据库”、“响应网络请求”或“生成统计图片代码”等内容>
4.1 系统结构
<描述系统的总体功能划分，以及从中抽取出的所有软件元素。可以考虑用对应关系表总体描述一下各个功能使用软件元素的情况>
4.2 功能甲
4.2.1 优先级
<提出了对该系统特性的简短说明并指出该特性的优先级是高、中，还是低。或者你还可以包括对特定优先级部分的评价，例如利益、损失、费用或风险，其相对优先等级还可以从1（低）到9（高）>
4.2.2 响应序列
<如果此功能能够对输入或其它系统事件产生响应，应描述同样对这些事件能够产生响应的其它功能与当前功能谁优先。优先序列包括对键盘或鼠标的多重捕获，也包括Tab键造成的页面元素跳转的顺序>
4.2.3 功能组成
<描述此功能由哪些软件元素构成>
4.2.4 功能详述
<详细描述功能。包括在各种操作下产生的效果。应描述产品如何响应可预知的出错条件或者非法输入或动作。必须唯一地标示每一个需求>
4.2.5 界面内容
<包括应该显示的内容，界面可接受的操作和信息、操作重要程度优先级。在保证严格完成需求的前提下，尽可能给设计工作留下充足的自由选择空间>
4.3 功能乙
4.3.1 优先级
<提出了对该系统特性的简短说明并指出该特性的优先级是高、中，还是低。或者你还可以包括对特定优先级部分的评价，例如利益、损失、费用或风险，其相对优先等级还可以从1（低）到9（高）>
4.3.2 响应序列
<如果此功能能够对输入或其它系统事件产生响应，应描述同样对这些事件能够产生响应的其它功能与当前功能谁优先。优先序列包括对键盘或鼠标的多重捕获，也包括Tab键造成的页面元素跳转的顺序>
4.3.3 功能组成
<描述此功能由哪些软件元素构成>
4.3.4 功能详述
<详细描述功能。包括在各种操作下产生的效果。应描述产品如何响应可预知的出错条件或者非法输入或动作。必须唯一地标示每一个需求>
4.3.5 界面内容
<包括应该显示的内容和信息重要程度优先级。在保证严格完成需求的前提下，尽可能给设计工作留下充足的自由选择空间>
……
5 非功能需求
5.1 性能需求
<阐述需求中要求的性能对应于软件的性能，并将之定量化。应解释性能需求的原理
以帮助开发人员做出合理的设计选择。如果性能需求很不完善，应将其补充。完整的性能需求应包括但不限于相互合作的用户数或者所支持的操作、响应时间以及与
实时系统的时间关系；容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表中的最大行数；各种功能的响应时间；内存、计算资源、存储资源的消耗。可
能需要针对每个功能需求或特性分别陈述其性能需求>
5.2 安全需求
5.2.1 系统安全需求
<详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则>
5.2.2 数据安全需求
<关于数据完整性或与私人问题相关的需求也应在此处描述。这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。你可能更喜欢通过称为完整性的质量属性来阐述这些需求>
5.3 其它软件质量属性
<详尽陈述与客户或开发人员至关重要的其他产品质量特性。这些特性必须是确定、定量的并在可能时是可验证的。至少应指明不通属性的相对侧重点。例如易用程度优于易学程度，或者可移植性优于有效性>
6 其他需求
<定义在软件需求规格说明的其他部分未出现的需求，例如国际化需求或法律上的需
求。还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。在模板中加入与你相关的新部
分。如果你不需要增加其它需求，就省略这一部分>
7 尚未解决的问题
8 附件
附录甲：分析模型
<这个可选部分包括后涉及到相关的分析模型的位置，例如数据流程图、类图、状态转换图或实体关系图>
9 相关资料
<相关资料的重要内容摘抄。资料本身需要等级在1.3介绍的参考资料中>
