任务描述
需求分析是软件生命周期中一个非常重要的过程，它决定着整个软件项目的质量，也是整个软件开发的成败所在。本环节任务是完成软件需求规格说明书。
知识点 ：软件需求规格说明书的编写
重 点 ：软件需求规格说明书内容的学习
难 点 ：软件需求规格说明书的理解与编写
内 容 ：软件需求规格说明书的编写
任务指导
一. 软件需求规格说明书的定义
参考需求分析定义：需求分析（软件工程学术语）_百度百科
二. 软件需求规格说明书内容分析
1. 项目概述
1.1 产品介绍
提示：
（1）说明产品是什么，什么用途。
（2）介绍产品的开发背景。提供关于发起这个软件开发的业务组织的概要，包括业务组织的使命及业务目标
1.2 产品范围
提示：描述待开发软件产品的范围。在描述中应该包括：
（1）描述软件产品的特征
（2）介绍软件的功能，并进行简要说明
（3）描述软件产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。（做什么，不做什么）
（4）说明软件应用
（5）描述软件的相关的收益、目的和目标等
此处的描述应与之前的项目文档的类似描述保持一致。说清楚产品范围的好处是：
（1）有助于判断什么是需求，什么不是需求；
（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；
（3）有助于控制需求的变更。
1.3 用户群体及角色
提示：
（1）描述本产品面向的用户（客户、最终用户）的特征。
（2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？
（3）根据用户的特征，按照功能、位置和设备类型等识别每一类用户。明确每一类型的用户的数量，以及他们使用软件的特点。根据这些特点划分产品中定义的角色及其工作职责，填写在下表中，各种角色的具体行为将在功能性需求中描述。软件产品用户的特征会影响特定的需求。许多人在软件生命周期的运行和维护阶段使用软件。这些人是用户、操作员、系统维护人员。这些人的某些特点，如教育水平，经验和技术专长，可能成为软件的运行环境的重要制约因素。
表1 用户群体及角色示例
| 角色名称 | 职责描述 |
1.4 运行环境
提示：描述软硬件运行环境。包括硬件平台、操作系统和版本，以及用户、服务器和数据库的地理位置。列出系统必须和平共存的其他软件组件或应用程序，前景和范围文档中可能包含这样的高层信息。
表2 运行环境要求示例
| 需求名称 | 详细要求 |
1.5 假设、依赖和约束
提示：列举软件产品的假设、依赖和约束。但不是每个产品都同时具备这三个条件。
假设 描述那些影响在软件需求说明书描述的需求的假设。假设是那些在项目的生命周期中被认为是真的因素，如果这种假设改变，会对项目产生负面的影响，包括但不限于最终用户的特点，已知的技术基础设施，资源可用性和资金可用性等。
依赖 描述那些影响在软件需求说明书中描述的需求的依赖。依赖是指在项目的范围和控制之外，并且为了项目取得成功而必须为真的情况。举例来说，一个依赖可能是一个应用程序依赖于一个不同的应用提供具体的数据或者是一个与第三方应用程序的接口需要购买一个应用程序编程接口（API）。
约束 提供各种限制软件的范围和功能的因素的描述，包括但不限于行业标准与规范，业务规则，监管政策，基础设施的限制，资源和许可。约束是通过环境、权利或强制规定施加到解决方案上的限制。约束通过无法改变的边界及限制，制约了解决方案的设计师可供选择的方案。
2. 产品的功能性需求
2.1 整体业务流程图／用例图
提示：以结构化或面向对象的方法绘制出产品整体业务的流程图或用例图。
2.2 功能性需求分类
提示：将功能性需求先粗分再细分，下表中的 功能 A, 功能 A.1等符号应当被替换成有含义的名称。
表3 功能性需求示例
| 功能类别 | 子功能 |
| 功能类别 A | 功能 A.1 |
| 功能 A.2 | |
| … | |
| 功能类别 B | 功能 B.1 |
| 功能 B.2 | |
| … | |
| … |
2.3 功能类别 A
提示：功能类别的名称与分类表中类别名称应保持一致，它是几个子功能总括名称，形如“采购管理”、“私信系统”。
以下提供了每种描述功能需求的子功能的模板。
2.3.1 功能 A.1
提示：当采用功能分解的方式描述功能性需求的时候，按照模板描述所有的子功能。需要按照具体的功能标识及命名每一个功能。
2.3.3.1 描述和优先级
提示：描述功能，并指出该功能的优先级。
2.3.1.2 输入
提示：描述功能输入。
2.3.1.3 操作
提示：描述在功能中执行的操作。
2.3.1.4 输出
提示：描述功能的输出
2.3.2 功能 A.1用例 Y
提示：当采用用例的方式描述功能性需求时，按照模板描述每个用例，按照每一个具体的用例标识以及命名每个用例，其中Y是指定用例的名字。
在每个用例子功能中，指定用例信息，包括角色，前置条件，后置条件，操作流程和替代流程等。
在每个用例子功能中，指定用例信息，包括角色，前置条件，后置条件，操作流程和替代流程等。
表4 用例示例
| 用例名称 | |||
| 用例编号 | |||
| 用例简介 | |||
| 优先级 | |||
| 前置条件 | |||
| 后置条件 | |||
| 操作流程 | 步骤 | 触发者 | 描述 |
| 扩展流程 | |||
| 例外流程 | |||
| 包含 | |||
| 假设 | |||
| 约束条件 | |||
| 输入及约束 | |||
2.3.3 功能 A.2
……
2.3.4 功能 A.2用例Y
……
2.4 功能类别 B
略
3. 产品的非功能性需求
3.1 用户界面需求
提示：描述软件的用户界面需求。用户界面需求用于捕获应用程序的人机界面的预期行为。例如，如果用户通过显示终端操作，说明所需的屏幕内容，任何报告或菜单的内容，输入和输出的相对时间。用户需求可能包括示例的屏幕或报表格式为原型来进行需求的说明。
表5 非功能性需求示例
| 需求名称 | 详细要求 |
3.2 性能需求
提示：描述性能条件以及相关的能力。考虑因素包括：
（1）发生的动态行为或变化（如比率，速率，运动和噪声水平）
（2）涵盖设备的承受能力的量化标准，用于在规定的环境和其他条件下满足用户的需求，包括最低总寿命。说明了需要的持续运行时间以及计划的可用率。
（3）运行的阶段和模式的性能需求
（4）支持的终端数量
（5）支持的并发用户数量
（6）在正常以及峰值负载的条件下，特定时间内可以处理的事务和任务以及数据量
（7）在非正常的工作压力下可接受的性能
3.3 产品质量需求
提示：描述软件的质量特性的需求。需求的描述应该是可度量、可验证的。描述在特性之间（比如安全性和可移植性）之间的权衡关系。质量特性的定义包括正确性、有效性、灵活性、完整性/安全、互操作性、可维护性、可移植性、可靠性、可重用性、可测试性、易用性。
表6 产品质量需求示例
| 主要质量属性 | 详细要求 |
| 正确性 | |
| 健壮性 | |
| 可靠性 | |
| 性能，效率 | |
| 易用性 | |
| 清晰性 | |
| 安全性 | |
| 可扩展性 | |
| 兼容性 | |
| 可移植性 | |
| … |
3.4 其他需求
提示：描述不适合放在前面需求章节中的任何其他的需求。如有些软件系统比较强调信息管理需求、安全需求，也可以在此扩展。
4. 接口
提示：描述应用和其他软件、硬件以及通信协议之间的接口的逻辑特性。每个接口的描述包括：
● 该接口的目的
● 应用接口对应的系统，包括外部的或内部的
● 交换机制
附录A：需求建模与分析报告
建议用Rational Rose对产品需求进行建模与分析。
A.1 需求模型1
A.n 需求模型N
附录B：需求跟踪矩阵
提示：提供指向需求跟踪矩阵的链接，需求跟踪矩阵中说明了在系统需求规格说明中的系统需求、在本软件需求规格说明书中的软件需求以及系统设计中的设计元素之间的对应关系。SRS中的需求跟踪矩阵应该：
● 含有用来说明系统需求与系统设计、软件需求、软件设计等元素之间的可追溯性的列
● 含有用来说明集成、验收、回归、性能测试等的可追溯性的列
● 填入了所有记录在系统需求规格说明中的需求
● 填入了所有记录在系统设计中的设计项
● 填入了所有记录在需求规格说明书中的需求项
● 说明了系统规格说明书中的系统需求与系统设计中的设计项之间的对应关系
● 说明了系统设计中的设计项与需求规格说明中的需求的对应关系
● 说明了每一个需求的出处及来源
附录C：需求确认
提示：主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”。在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。
表7 需求评审报告摘要示例
| 需求评审报告摘要 | |
| 需求文档 | 输入名称，标识符，版本，作者，完成日期，… |
| 需求评审报告 | 输入名称，标识符，评审日期，… |
| 评审结论 | [ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 |
| 评审意见 | |
| 评审小组成员 | 输入评审小组成员 |
表8 需求承诺示例
| 需求承诺 | |
| 需求文档 | 输入名称，标识符，版本，作者，完成日期 |
| 客户承诺 | 承诺… 签字，日期 |
| 项目经理承诺 | 承诺… 签字，日期 |
