需求分析的步骤

3.1.3　需求分析的步骤

软件的需求分析不是一蹴而就的，由于软件问题的复杂性，使得软件分析人员在需求分析的初期很难准确地描述出目标软件系统的需求，这就表明需求分析是一个不断迭代、不断优化，直到获取最终准确需求的过程，在这个过程中，用户也要积极地参与进行，协助软件分析人员获取需求、确认需求，使需求分析可顺利进行。因此，需求分析的步骤可用图3.2所示的流程图来表示：

图3.2　需求分析的主要步骤

一、分析系统的数据要求

软件系统的本质是处理数据的过程。它接收外部世界提交的数据（如用户输入两个数值“10”和“20”），并对其进行处理或变换（如对“10”和“20”实施加法运算），最后再把处理的结果（“30”）输出给用户。所以，软件需求分析的起点是对目标软件的数据要求展开分析。结构化分析方法就是以分析数据为核心的软件工程方法学。

二、分析系统的逻辑，建立系统逻辑模型

在获取对目标软件系统数据的清晰要求之后，软件设计人员就应该遵循软件所处应用环境的业务逻辑，着重分析构成软件的各个元素，逐步逐层地细化软件的功能，并对各功能的合理性进行客观地评估，最终以形式化的方式形成描述目标软件系统的逻辑模型。作为结构化分析方法的重要工具，其需求分析过程中的逻辑模型主要有：数据流图、数据字典、加工处理和数据存储等。

三、修订开发计划

在软件项目的最初阶段需要制定描述软件开发过程中的计划进度安排，该计划会对软件过程实施中的时间、人力、物力等各种资源进行大致的分配，软件开发人员必须较好地遵循该计划展开软件的研发工作。而随着需求分析的深入，软件设计者对目标软件系统的构成会有一个更加清晰的认识（功能、性能的需求更清楚了），从而能够更加准确地把握软件开发过程中的资源协调、分配、调度，因此，在需求分析中一旦建立了针对目标软件系统的完整的、正确的逻辑模型之后，软件项目管理者就有必要重新修订软件项目的计划进度，保证软件项目的顺利实施。

四、构造原型

原型就是一个“小软件”，它是最终开发出来的目标软件系统的“子集”。原型的开发并不是必要的，但如果用户提出来的某个目标软件系统是一种全新的软件系统，那么，软件设计人员为了获取对软件系统的准确需求，就必须先开发出一个可以运行的原型系统，并由用户对其进行操作实践，期望用户给出对原型系统的评价，最终指引软件设计人员去快速、准确、完整地把握用户的需求。

在理想情况下，软件设计人员只需开发一个原型就可获取目标软件系统的全部需求，但在实际情况下，软件问题有它独特的复杂性，一个原型远不能满足需要。例如，在特定的软件生命期模型中，原型生命期模型和螺旋生命期模型就是运用原型进行需求收集的典型代表。其中软件设计人员需要开发多个原型，渐进地获取对需求的认识，直到需求完全获取，这也是符合人类对事物的认识必须由浅入深、由模糊到准确的客观过程。

此外，可运行的原型系统在软件设计人员和用户之间架起了一座相互信任、相互理解的桥梁。一方面软件设计人员通过多个原型的开发不断地逼近最终的需求，尽可能地还原用户对需求的理解。而另一方面用户通过原型的使用获取了对需求的理性认识，并将这些认识传达给软件设计人员，有助于软件开发者准确地定义需求，同时由于原型是可运行的且不断完善的，故用户在使用原型的过程中必会更加信赖软件设计人员有能力完成任务软件系统，为软件的顺利实施创造了良好的氛围。

当然，原型的开发受限于开发计划、开发成本、软件生命期模型等因素，作为软件设计者需要全面考虑影响原型开发的各个因素，从而决定如何开发原型以及究竟开发多少原型。

五、验证软件的需求

需求分析完成之后必须对其结果进行验证和评估，以保证其正确性。软件开发的巨大风险是：在软件测试阶段发现软件的需求不准确、不完整，甚至是根本不能满足用户的要求。所以，作为软件生命期的重要起始阶段，需求分析获取的软件需求描述是软件设计、程序编码及软件测试等后续阶段成功实施的关键保证，准确的需求可以有效地降低软件开发过程中的不确定性，减少需求变更的次数，从而有助软件开发的顺利实施。

衡量软件需求的标准如下，且这些需求已经按其重要性依次排列：

1.正确性

需求规格说明书中的需求描述，首先必须是能正确代表用户提出的针对目标软件系统的合理要求，即需求与用户保持一致。如“学生信息管理系统”的用户提出仅对在校所有学生进行学生信息的管理，故该目标软件的需求描述必须围绕这个中心展开分析，若出现“教师信息管理”的需求则必是错误的需求，因为它没有与用户保持一致。

2.无歧义性

需求规格说明书中的需求表达，软件设计人员在保证数据流图、数据字典等正确的基础之上还应使其没有任何歧义，即对软件工程术语的语义解释是唯一的、统一的。如对数据精度的定义是16位，一旦确定则所有的数据精度必须都是16位，其他描述均为错误需求。

3.完整性

需求同样必须是完整的，不能遗漏任何用户的合理需求。它应该包括功能、性能、运行、出错处理、接口等各种需求。如单机版的“学生信息管理系统”主要包括功能、性能、出错处理、运行等类型的软件需求。

4.可验证性

可验证性是需求是否可行的表示，即在经济、技术、法律均可行的前提之下，每一条需求都可以得到验证和确认。如“学生信息管理系统”对数据检索提出“检索模块每分钟可检索100～150条学生记录”，该需求描述必须可确认才具有实际意义。

5.一致性

需求描述在需求规格说明书中前后必须保持一致，各种命名应该统一。如“学生信息检索加工”的命名，在任何层次的数据流图、数据处理描述、数据字典中都必须保持一致。

6.可理解性

需求规格说明书应该清晰、可读、便于理解。它是软件开发者与用户、软件分析人员与软件设计、软件测试人员联系的纽带，故对需求的描述不能太专业，应多使用图、表的直观形式来表达需求，提高软件需求的可理解性。如“学生输入学号信息到学生信息管理系统，系统根据学生学号检索数据库，最后提交检索出的学生基本信息结果给学生”是对软件需求的描述，如果用数据流图可以非常直观地描述，从而提高了需求的可理解性。

7.可修改性

需求描述在需求规格说明书中的组织，应该保证对其进行修改所引起的需求规格说明书的变更最小。如“学生信息管理系统”需要增加“教师信息管理”的基本功能，那么需求规格说明书中的章节排列应该能很方便地增加这部分功能。

8.可追踪性

需求规格说明书必须将分析获取的需求与用户原始的需求准确地联系在一起，即每一项需求都有自己的源头。如“学生信息管理系统”中的“按学生的学号顺序进行成绩排序”的需求必然来源于用户对学生成绩进行排序的原始需求。

六、编写软件需求规格说明书

需求分析的最终成果是“需求规格说明书”，软件分析人员根据从用户处获取的对目标软件系统的原始需求，按标准的文档格式，运用数据流图、数据字典、加工描述等工具清晰、准确地描述出需求。它是软件分析人员与用户进行需求确认的桥梁，也是软件分析人员与软件设计人员进行设计沟通的渠道，它是一种用户文档，在软件成功开发并经过测试、评审之后交给用户。