《《论文_系统需求分析文档主要内容(定稿)》》由会员分享，可在线阅读，更多相关《《论文_系统需求分析文档主要内容(定稿)》（13页珍藏版）》请在金锄头文库上搜索。
1、系统需求分析文档主要内容:1. 文档概述该部分主要是对软件需求规格说明书文档进行基本的描述，包括该文档的目的、范围、 术语定义、参考资料以及概要。软件需求规格说明书用来系统、完:整地记录系统的软件需求。该软件需求说明书的基 础是用例分析技术。因此该文档中应包括用例模型、补充规约等内容。L1目的在此小节中，主耍对软件需求规格说明书的目的做一概要性说明，通殆软件需求规 格说明书应详细地说明应用程序、子系统的外部行为，还要说明非功能性需求、设计约 束，以及其它的相关因素。1.2范围系统是有范围的，而不是无限扩展的，对于无限扩展的需求是无法进行描述的。因 此，在本小节应该对该说明书所涉及的项目范用进行
2、淸晰的界定。指建该规格说明书适 用的软件应用程序、特性或者其它子系统分组、其相关的用例模型。当然在此也需要列 出会受到该文档影响的其它文档。1.3定义、首字母缩写词和缩略语与英它文档一样，该文档也需要将本文档中所涉及的所有术语、缩略语进行详细的 定义。还有一种可简明的做法，就是维护在一个项目词汇表中，这样就可以避免在每个 文档中都重复很多内容。1.4参考资料在这一小节中，应完整地列出该文档引用的所有文档。对于每个引用的文档都应该给出标题、标识号、日期以及来源，为阅读者査找这些文档提供足够详细的信息。1.5概述在本小节中，主要是说明软件需求规格说明书各个部分所包含的主要内容，就像一 个文章摘要一
3、样。同吋也应该对文档的组织方式进行解释。2. 整体说明在本节中，将对整个软件需求进行总体性的描述，以期让读者对整个软件系统的需求 有一个框架性的认识。也就是说，该节中主要包括影响产殆及其需求的一般因素，而不列举 具体的需求。主要包括产品总休效果、产品功能、用八特征、约束、假设与依赖关系、需求 子集等方面的内容。2用例模型在本小节中，将列出该软件需求的用例模型，该模型处于系统级，对系统的特性进 行宏观的描述。在此应该列出所有的用例和Acs的名称列表，并I1XJM做出简要的说 明，以及在图中的各种关系。2.2假设与依赖关系在软件系统的开发过程中，存在许多假设和依赖关系。在本小节中应列举出所有的 重
4、耍的技术可行性假设、子系统或构件可用性假设，以及-些可行性的假设。3. 具体需求如果说第二章节是框架，那么本节就是血肉。在本节中，应该详细列出所有的软件需 求，其详细程序应使设计人员能够充分理解并且进行设计的要求，同吋也应该给予测试人员 足够的信息，以帮助他们来验证系统是否满足了这些需求。整个需求的纽织可以采用用例描 述进行。3.1用例描述如果你使用用例建模技术，那么你己经通过用例定义了系统的大部分功能性需求和 些非功能性需求。因此，在软件需求规格说明书只需将这些具体的用例描述，整理在 一-起，全部放在该小节Z中。当然也可以将用例描述做为附件，在此列出引用，只是这 样做并不利于阅读。建议在组织
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简要说明简要说明用例的作用和目的。该小节的篇幅不要A长。2. 上下文图在此小节中，有一个只包
8、括本用例和所有与该用例相关的Actor和英它用例纽成的，个用例图的局部。3. 事件流3基本流当Acto采取行动吋，用例也就随即开始。用例总是山Actor启动的，用例应说明Actor 的行为及系统的响应，可按照AckM与系统进行对话的形式来逐步引入用例。要注意的是，用例描述应该说明系统内发生的事情，而不是書件发生的方式与原I大1。 如果进行了信息交换，则需指出來冋传递的具体信息。例如，只表述主角输入了客户信息就 不够明确。垠好明确地说主角输入了客戸姓名和地址。当然你也可以通过项目词汇表來定义 这些信息，使得用例中的内容被简化，从血不致于让用例描述陷入过多的细节内容。如果存在一些相对比较简单的备选
9、流，只需少数几句话就可以说明清楚，那么也可以 直接在这一部分中描述。但是如果比较复杂，还是应该单独放在备选流小节中描述。一幅图胜过千言万语，因此建议在这一小节中，除了叙述性文字之外，你还可以引用 UML中的活动图、顺序图、协作图、状态图等于段，对英进行补充说明。3.2备选流3.2.1第一备选流止如前面所述，对于较复杂的备选流应单独地说明。321备选支流如果能使衣达更明确，备选流又可再分为多个支流。3.2.2第二备选流在一个用例中很可能会有多个备选流。为了使表达更清晰，应将各个备选流 分开说明。使用备选流可以提高用例的可读性，并防止将用例分解为过多的层次。 应切记，用例只是文本说明，其主要目的是
10、以清晰、简洁、易于理解的方式记录 系统的行为。4. 非功能需求在这个小节中，主要对该用例所涉及的非功能性需求进行描述。山于其通常很难以在 事件流中进行表述，因此单列为一小节进行阐述。这些需求通过包括法律法规、应用程序标 准、质量属性（可用性、可靠性、性能、支持性等）、兼容性、可移植性，以及设计约束等 方面的需求。在这些需求的描述方面,一定要注意使其可度量、可验证,否则就容易流于形 式，形同摆设。5. 前置条件用例的前置条件是执行用例之前必须存在的系统状态。6. 后置条件用例的后置条件是用例一执行完毕系统可能处于的一组状态。J7. 扩展点眦用例的扩展点，通常是用例图中的extent关系。用例说明
11、模板2（单列表格式）编者说明:如果你觉得文本描述不够淸晰，也可以采用如本文档模板所示的农格式的描述方式。用例#用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。使用语境用例H标，是一个较长的描述，甚至包括触发条件。范围用例的设计范围，在设计时将系统作为一个黑盒來考虑。级别概要、用户目标、子功能三者主执行者也就是该用例的主Actor,在此应列出英名称，并简要描述。J项目相关人员利益项目相关人员利益项目相关人员名称项目相关人员収得的利益前置条件也就是激发该用例，所应该满足的条件。后置条件也就是该用例完成Z后，将执行什么动作。成功保证描述当目标完成后，环境的变化情况。触发事件
12、什么引发用例，例如时间事件。描述步骤活动1在这里写出触发事件到目标完成以及清除的步骤。J23扩展步骤分支动作la引起分支的条件活动或子用例名称技术和数据变化1变化列表用例说明模板3（双列表格式）编者说明：本模板是对上一模板的补充，如果你想更好地捕捉系统的响应，那么就可以采用本农 格所示的格式。有时，为了更好地捕获系统的响应，对于场景描述（主成功场最、扩展场呆）在上表的基础上变成如下农所示的双列:步骤用户系统用例说明模板4（文本式）编者说明：相信用过用例分析技术的，对用例应该多少细有很大的疑问，而Alistair Cockburn率先 将其进行分级：概要、用户目标、子功能，如果你对他的思想有认同
13、，则该模板就适合于你。1. 用例名：用例名应是一个动词短语,应让读者一目了然地从名字中就可以知道该用例的目标。2. 使用语境：用例目标，是一个较长的描述，其至包括触发条件。3. 范围:用例的设计范围，在设计时将系统作为一个黑盒來考虑。J4. 级别：用来表示该用例是在描述哪个级别上的功能，通帘包括概要、用户目标、子功能三种。这三种级别的划分是Alistair Cockbum在编写有效用例一书是提出的。5. 主执行者：也就是该用例的主Actor,在此应列出其名称，并给予简要描述。1. 项目相关人员利益说明该用例对项目相关人员能够带来什么好处。2. 前置条件：也就是激发该用例，所应该满足的条件。3.
14、 后置条件：也就是该用例完成Z后，将执行什么动作。】4. 成功保证：描述当冃标完成后，环境的变化情况。5. 触发事件：什么引发用例，例如时间事件。6. 主成功场景在这里写出触发事件到目标完成以及淸除的步骤。步骤编号#:动作描述步骤编号#:动作描述7. 扩展：在这里写出扩展情况，每次写一个扩展，每个扩展都应指向主场景的特定步骤。被改变步骤条件：动作或子用例被改变步骤条件：动作或子用例8. 技术和数据变化列表在这里写出场景中因技术或数据变化而引起的可能分支。步骤或变化编号#:变化列衣步骤或变化编号#:变化列表】9. 柑关信息项目所需要的所有附加信息。数据要求说明书（ISO标准）编者说明：如果在你的项目中有大量要求数据存储、数据采集等方而的需求，那么你就应该专门将 这些需求进行整理，以数据要求说明书的形式农现出來。1引言1编写目的说明编写这份数据要求说明书的目的，指出预期的读者。1.2背景a. 待开发软件系统的名称；b. 列出本项目的任务提出者、开发者、用户以及将运行该项软件的计算站或计算机 网络系统。1.3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1.4参考资料列出有关的参考资料。2. 数据的逻辑描述对数据进行逻辑描述时可把数据分为动态数据和静态数据。2静态数据列出所有作为控制或参考用
