1、系统需求分析文档主要内容：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 个或几个用例描述。3.2 补充需求由于用例毕竟主要针对功能性需求，因此还会有一些其它的补充需求遗漏，因此在本小节中就是将这些东西补充出来。这些补充需求大部分集中在非功能需求之上，包括以下几个方面的内容：1） 易用性：例如指出普通用户和高级用户要高效地执行某个特定操作所需的培训时间；指出典型任务的可评测任务次数；或者指出需要满足的可用性标准（如 IBM 的 CUA 标准、Microsoft 的 GUI 标准。2） 可靠性：包括系统可用性（可用时间百分比、使用小时数、维护访问权、降纸模式操作等） ；平均故障间隔时间（MTBF，通常表示为小时数，但也可表示
6、为天数、月数或年数） ；平均修复时间（MTTR ，系统在发生故障后可以暂停运行的时间） ；精确度（指出系统输出要求具备的精密度、分辨率和精确度）；最高错误或缺陷率（通常表示为 bugs/KLOC，即每千行代码的错误数目或 bugs/function-point，即每个功能点的错误数目） ；错误或缺陷率（按照小错误、大错误和严重错误来分类：需求中必须对“严重”错误进行界定，例如：数据完全丢失或完全不能使用系统的某部分功能） 。3） 性能：包括对事务的响应时间（平均、最长） ；吞吐量（例如每秒处理的事务数） ；容量（例如系统可以容纳的客户或事务数） ；降级模式（当系统以某种形式降级时可接受的运行模
7、式） ；资源利用情况：内存、磁盘、通信等。4） 其它：包括用户界面要求、联机帮助系统要求、法律许可、外购构件，以及操作系统、开发工具、数据库系统等设计约束。4.支持信息支持信息用于使软件需求规格说明书更易于使用。它包括：目录、索引、附录等。附录：用例说明模板 1(经典模板)编者说明：随着 UML 的日益普及，用例（ Use case）分析技术也在需求实践中广泛被采用。但是也有许多团队在使用该技术时，只画出了用例图，而缺少了用例说明，其实这是一个严重的误区。而本模板就将指导你编写该说明。1.用例名称1.1 简要说明简要说明用例的作用和目的。该小节的篇幅不要太长。2.上下文图在此小节中，有一个只包
8、括本用例和所有与该用例相关的 Actor 和其它用例组成的，一个用例图的局部。3. 事件流3.1 基本流当 Actor 采取行动时，用例也就随即开始。用例总是由 Actor 启动的，用例应说明Actor 的行为及系统的响应，可按照 Actor 与系统进行对话的形式来逐步引入用例。要注意的是，用例描述应该说明系统内发生的事情，而不是事件发生的方式与原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。当然你也可以通过项目词汇表来定义这些信息，使得用例中的内容被简化，从而不致于让用例描述陷入过多的细节内容。如果存在一些
9、相对比较简单的备选流，只需少数几句话就可以说明清楚，那么也可以直接在这一部分中描述。但是如果比较复杂，还是应该单独放在备选流小节中描述。一幅图胜过千言万语，因此建议在这一小节中，除了叙述性文字之外，你还可以引用UML 中的活动图、顺序图、协作图、状态图等手段，对其进行补充说明。3.2 备选流3.2.1 第一备选流正如前面所述，对于较复杂的备选流应单独地说明。3.2.1.1 备选支流如果能使表达更明确，备选流又可再分为多个支流。3.2.2 第二备选流在一个用例中很可能会有多个备选流。为了使表达更清晰，应将各个备选流分开说明。使用备选流可以提高用例的可读性，并防止将用例分解为过多的层次。应切记，用
10、例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。4. 非功能需求在这个小节中，主要对该用例所涉及的非功能性需求进行描述。由于其通常很难以在事件流中进行表述，因此单列为一小节进行阐述。这些需求通过包括法律法规、应用程序标准、质量属性（可用性、可靠性、性能、支持性等） 、兼容性、可移植性，以及设计约束等方面的需求。在这些需求的描述方面，一定要注意使其可度量、可验证，否则就容易流于形式，形同摆设。5. 前置条件用例的前置条件是执行用例之前必须存在的系统状态。6. 后置条件用例的后置条件是用例一执行完毕系统可能处于的一组状态。7. 扩展点此用例的扩展点，通常是用例图中的 ext
11、ent 关系。用例说明模板 2(单列表格式)编者说明：如果你觉得文本描述不够清晰，也可以采用如本文档模板所示的表格式的描述方式。用例# 用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。使用语境 用例目标，是一个较长的描述，甚至包括触发条件。范围 用例的设计范围，在设计时将系统作为一个黑盒来考虑。级别 概要、用户目标、子功能三者之一。主执行者 也就是该用例的主 Actor，在此应列出其名称，并简要描述。项目相关人员 利益项目相关人员利益 项目相关人员名称 项目相关人员取得的利益 前置条件 也就是激发该用例，所应该满足的条件。后置条件 也就是该用例完成之后，将执行什么动作
12、。成功保证 描述当目标完成后，环境的变化情况。触发事件 什么引发用例，例如时间事件。步骤 活动1 在这里写出触发事件到目标完成以及清除的步骤。2 描述3步骤 分支动作1a 引起分支的条件扩展活动或子用例名称技术和数据变化 1 变化列表用例说明模板 3(双列表格式)编者说明：本模板是对上一模板的补充，如果你想更好地捕捉系统的响应，那么就可以采用本表格所示的格式。有时，为了更好地捕获系统的响应，对于场景描述（主成功场景、扩展场景）在上表的基础上变成如下表所示的双列：步骤 用户 系统用例说明模板 4(文本式)编者说明：相信用过用例分析技术的，对用例应该多少细有很大的疑问，而 Alistair Coc
13、kburn 率先将其进行分级：概要、用户目标、子功能，如果你对他的思想有认同，则该模板就适合于你。1.用例名：用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。2.使用语境：用例目标，是一个较长的描述，甚至包括触发条件。3.范围：用例的设计范围，在设计时将系统作为一个黑盒来考虑。4.级别：用来表示该用例是在描述哪个级别上的功能，通常包括概要、用户目标、子功能三种。这三种级别的划分是 Alistair Cockburn 在编写有效用例一书是提出的。5.主执行者：也就是该用例的主 Actor，在此应列出其名称，并给予简要描述。1. 项目相关人员利益说明该用例对项目相关人员能
14、够带来什么好处。2. 前置条件：也就是激发该用例，所应该满足的条件。3. 后置条件：也就是该用例完成之后，将执行什么动作。4. 成功保证：描述当目标完成后，环境的变化情况。5. 触发事件：什么引发用例，例如时间事件。6. 主成功场景在这里写出触发事件到目标完成以及清除的步骤。步骤编号：动作描述步骤编号：动作描述7. 扩展：在这里写出扩展情况，每次写一个扩展，每个扩展都应指向主场景的特定步骤。被改变步骤 条件：动作或子用例 被改变步骤 条件：动作或子用例 8. 技术和数据变化列表在这里写出场景中因技术或数据变化而引起的可能分支。步骤或变化编号：变化列表步骤或变化编号：变化列表9. 相关信息项目所
15、需要的所有附加信息。数据要求说明书(ISO 标准)编者说明：如果在你的项目中有大量要求数据存储、数据采集等方面的需求，那么你就应该专门将这些需求进行整理，以数据要求说明书的形式表现出来。1引言1.1 编写目的说明编写这份数据要求说明书的目的，指出预期的读者。1.2 背景a.待开发软件系统的名称；b.列出本项目的任务提出者、开发者、用户以及将运行该项软件的计算站或计算机网络系统。1.3 定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1.4 参考资料列出有关的参考资料。 2数据的逻辑描述对数据进行逻辑描述时可把数据分为动态数据和静态数据。2.1 静态数据列出所有作为控制或参考用的静
16、态数据元素。 2.2 动态输入数据列出动态输入数据元素。 2.3 动态输出数据列出动态输出数据元素。 2.4 内部生成数据列出向用户或开发单位中的维护调试人员提供的内部生成数据。2.5 数据约定说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制。对于在设计和开发中确定是临界性的限制更要明确指出。3数据的采集 3.1 要求和范围按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。3.2 输入的承担者说明预定的对数据输入工作的承担者。如果输入数据同某一接口软件有关，还应说明该接口软件的来源。3.3 预期处理对数据的采集和预处理过程提出专门的规定，包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。对于需经模拟转换或数字转换处理的数据量，要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。3.4 影响说明这些数据要求对于设备、软件、用户、开发单位所可能产生的影响。
