《软件需求分析编写规范手册》由会员分享，可在线阅读，更多相关《软件需求分析编写规范手册（8页珍藏版）》请在金锄头文库上搜索。
1、软件需求分析编写规范手册 V1.0 1. 文档概述 该部分主要是对软件需求规格说明书文档进行基本的描述，包括该文档的目的、范围、 术语定义、参考资料以及概要。 软件需求规格说明书用来系统、完整地记录系统的软件需求。该软件需求说明书的基 础是用例分析技术。因此该文档中应包括用例模型、补充规约等内容。 1.1 目的 在此小节中，主要对软件需求规格说明书的目的做一概要性说明，通常软件需求规格 说明书应详细地说明应用程序、子系统的外部行为，还要说明非功能性需求、设计约束，以 及其它的相关因素。 1.2 范围 系统是有范围的，而不是无限扩展的，对于无限扩展的需求是无法进行描述的。因此， 在本小节应该对该
2、说明书所涉及的项目范围进行清晰的界定。指定该规格说明书适用的软件 应用程序、 特性或者其它子系统分组、其相关的用例模型。当然在此也需要列出会受到该文 档影响的其它文档。 1.3 定义、首字母缩写词和缩略语 与其它文档一样，该文档也需要将本文档中所涉及的所有术语、缩略语进行详细的定 义。还有一种可简明的做法，就是维护在一个项目词汇表中，这样就可以避免在每个文档中 都重复很多内容。 1.4 参考资料 在这一小节中，应完整地列出该文档引用的所有文档。对于每个引用的文档都应该给 出标题、标识号、日期以及来源，为阅读者查找这些文档提供足够详细的信息。 1.5 概述 在本小节中，主要是说明软件需求规格说明
3、书各个部分所包含的主要内容，就像一个 文章摘要一样。同时也应该对文档的组织方式进行解释。 2. 整体说明 在本节中，将对整个软件需求进行总体性的描述，以期让读者对整个软件系统的需求 有一个框架性的认识。也就是说， 该节中主要包括影响产品及其需求的一般因素，而不列举 具体的需求。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求 子集等方面的内容。 2.1 用例模型 在本小节中，将列出该软件需求的用例模型，该模型处于系统级，对系统的特性进行 宏观的描述。在此应该列出所有的用例和Actor的名称列表，并且对其做出简要的说明， 以及在图中的各种关系。 2.2 假设与依赖关系 在软件
4、系统的开发过程中，存在许多假设和依赖关系。在本小节中应列举出所有的重 要的技术可行性假设、子系统或构件可用性假设，以及一些可行性的假设。 3. 具体需求 3.1 用例描述 增加用户用例 用例 # 增加用户（这里的用户涵盖系统管理员和普通用户） 使用语境系统管理员登录后，进入系统管理， 点击用户管理， 来到用户管理 界面， 点击增加用户，可以添加用户了。再填入用户信息时，可选 则是否为管理员， 从而对用户的权限进行了设置，把用户分为了系 统管理员和普通用户。 范围开始于新增用户也页面，结束于添加用户成功后的页面。 级别子功能 主执行者系统管理员 前置条件必须是系统管理员成功登录后，才可进行添加用
5、户的操作。 后置条件添加成功用户后， 新添加的用户可进行登录，然后可根据自己的角 色来对系统进行相应的操作。 成功保证登录的用户必须是系统管理员，保证系统管理员登录成功；添加的 用户信息必须合法，保证用户的基本必备信息完整。 触发事件再添加用户界面，添加所需的用户信息，完成后点击添加按钮。 描述步骤活动 1 进入添加用户界面。 2 添加所需的用户信息。 3 点击添加按钮。 技 术 和 数 据 变化1 添加成功后，系统中增加了一个新的用户。 用例图 如果你使用用例建模技术，那么你已经通过用例定义了系统的大部分功能性需求和一 些非功能性需求。因此，在软件需求规格说明书只需将这些具体的用例描述，整理
6、在一起， 全部放在该小节之中。当然也可以将用例描述做为附件，在此列出引用， 只是这样做并不利 于阅读。建议在组织形式上采用以“软件需求”为线索，在每个需求中，填入对应的1个或 几个用例描述。 3.2 补充需求 由于用例毕竟主要针对功能性需求，因此还会有一些其它的补充需求遗漏，因此在本 小节中就是将这些东西补充出来。这些补充需求大部分集中在非功能需求之上，包括以下几 个方面的内容： 1）易用性： 例如指出普通用户和高级用户要高效地执行某个特定操作所需的培训时间；指出典型任 务的可评测任务次数；或者指出需要满足的可用性标准（如IBM 的 CUA 标准、 Microsoft 的 GUI 标准。 2）
7、可靠性： 包括系统可用性（可用时间百分比、使用小时数、维护访问权、降纸模式操作等）；平 均故障间隔时间（MTBF ，通常表示为小时数，但也可表示为天数、月数或年数）；平均修 复时间（ MTTR ，系统在发生故障后可以暂停运行的时间）；精确度（指出系统输出要求具 备的精密度、分辨率和精确度）；最高错误或缺陷率（通常表示为bugs/KLOC，即每千行 代码的错误数目或bugs/function-point，即每个功能点的错误数目）；错误或缺陷率（按 照小错误、 大错误和严重错误来分类：需求中必须对“严重”错误进行界定，例如：数据完 全丢失或完全不能使用系统的某部分功能）。 3）性能： 包括对事务的响应时间（平均、最长）；吞吐量（例如每秒处理的事务数）；容量（例如 系统可以容纳的客户或事务数）；降级模式（当系统以某种形式降级时可接受的运行模式）； 资源利用情况：内存、磁盘、通信等。 4）其它： 包括用户界面要求、联机帮助系统要求、法律许可、外购构件，以及操作系统、开发工 具、数据库系统等设计约束。 4.支持信息 支持信息用于使软件需求规格说明书更易于使用。它包括：目录、索引、附录等。
