丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
需求分析是在软件系统分析人员的操作下进行的，在这个过程中，用户和开发者之间需要达成的是对系统的一致性需求认识。实际上，可以把软件系统分析人员看成是软件用户与软件开发技术人员之间的信息通道，其作用是使用户对软件问题的现实描述，能够有效地转变为开发软件的技术人员所需要的对软件的技术描述，以方便技术人员对软件的技术构建。
一、需求分析任务
需求分析需要实现的是将软件用户对于软件的一系列意图、想法转变为软件开发人员所需要的有关软件的技术规格，并由此实现用户和开发人员之间的有效通信，它涉及面向用户的用户需求和面向开发者的系统需求这两个方面的工作内容。
1.用户需求
用户需求是用户关于软件的一系列意图、想法的集中体现，涉及软件的操作方式、界面风格、报表格式，用户机构的业务范围、工作流程，以及用户对于软件应用的发展期望等。因此，用户需求也就是用户关于软件的外界特征的规格表述。实际上，用户需求提出了一个有关软件的基本需求框架，具有以下特点：
（2）用户需求需要以文档的形式提供给用户审查，因此需要使用流畅的自然语言或简洁清晰的直观图表来进行表述，以方便用户的理解与确认。
（3）可以把用户需求理解为用户对软件的合理请求，这意味着，用户需求并不是开发者用户的盲目顺从，而是建立在开发者和用户共同讨论、相互协商的基础上。
（4）用户需求主要是为用户方管理层撰写的，但用户方的技术代表，软件系统今后的操作者，以及开发方的高层技术人员，也有必要认真阅读用户需求文档。
2.系统需求
系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。系统需求需要对系统在功能、性能、数据等方面进行规格定义，由于自然语言随意性较大，在描述问题时容易发生歧义，因此系统需求往往要求用更加严格的形式化语言进行表述，例如PDL伪码，以保证系统需求表述具有一致性。系统需求涉及有关软件的一系列技术规格，包括：功能、数据、性能、安全等诸多方面的问题。
（1）功能需求
功能需求是有关软件系统的最基本的需求表述，用于说明系统应该做什么，涉及软件系统的功能特征、功能边界、输入输出接口、异常处理方法等方面的问题。也就是说，功能需求需要对软件系统的服务能力进行全面的详细的描述。在结构化方法中，往往通过数据流图来说明系统对数据的加工过程，它能够在一定程度上表现出系统的功能动态特征。也就是说，可以使用数据流图建立软件系统的功能动态模型。
（2）数据需求
数据需求用于对系统中的数据，包括：输入数据、输出数据、加工中的数据、保存在存储设备上的数据等，进行详细的用途说明与规格定义。在结构化方法中，往往使用数据字典对数据进行全面准确的定义，例如，数据的名称、别名、组成元素、出现的位置、出现的频率等。当所要开发的软件系统涉及到对数据库的操作时，还可以使用数据关系模型图（ER图）对数据库中的数据实体、数据实体之间的关系等进行描述。
（3）其他需求
其他需求是指系统在性能、安全、界面等方面需要达到的要求。
二、需求分析过程
需求分析是对软件系统的后期分析，需要进行一系列的活动，包括：分析用户需求、建立需求原型、分析系统需求和进行需求验证等，其活动流程如图4-2所示。
（3）系统需求是面向技术人员的。因此，它不仅需要从需求原型中提取系统模型，而且需要对系统模型进行细节化处理，例如：数据流细化、数据字典分解、类模型的定义等，由此获得对系统的详细的技术性需求说明。
（4）对需求框架、系统模型和需求细节等文档进行有效性验证，由此产生出用户方、开发方都能接受的关于软件的需求规格说明书。
三、用户需求获取
优秀软件总是能够最大限度地满足用户需求。因此，有效获取用户需求，是实施软件开发时需要完成的第一项工作。
1.研究用户
2.从调查中获取用户需求
实际上，针对不同的应用项目通常会有不同的调查内容，需要采用不同的调查策略。例如，开发一个信息管理系统，其用户需求调查一般会涉及以下方面的内容：
（1）调查用户的组织机构，包括：该组织的部门组成，各部门的职责等。由此得到的调查结果将作为分析软件系统领域边界的基本依据。（2）调查用户各部门的业务活动，包括：各个部门输入和使用什么数据，如何加工处理这些数据，输出什么数据，输出到什么部门等。这是需求调查的重点内容，其结果将作为分析软件系统工作流程的基本依据。
（3）调查用户对软件系统的各项具体要求，包括：数据格式、操作方式、工作性能、安全保密等方面的要求。
在调查过程中，可以根据不同的问题和条件，使用不同的调查方法。比较常用的调查方法有以下几种：
a.访谈用户
访谈用户就是面对面地跟单个用户进行对话。例如，请用户机构高层人员介绍用户的组织结构、业务范围、对软件应用的期望。
b.开座谈会
c.问卷调查
问卷调查一般是通过精心设计的调查表去调查用户对软件的看法。当面对一个庞大的用户群体时，可能需要采用问卷调查形式进行用户调查。例如在开发通用软件时，为了获得广大用户对软件的看法，就不得不采取问卷方式。如果调查表设计得合理，这种方法很有效，也易于为用户接受。
d.跟班作业
e.收集用户资料
3.通过原型完善用户需求
需求原型可用来收集用户需求，对用户需求进行验证，由此可帮助用户克服对软件需求的模糊认识，并使用户需求能够更加完整地得以表达。例如，用户对软件应该提出哪些方面的服务，操作界面应该如何等可能拿不定主意，为了使用户能够更加直观地表述自己的需求意愿，可以先构造一个原型给用户体验。原型需要根据用户的评价而不断修正，这也有利于挖掘用户的一些潜在需求，使得用户需求能够更加完整地得以表达。一般情况下，开发人员将软件系统中最能够被用户直接感受的那一部分东西构造成为原型。例如，界面、报表或数据查询结果。实际上，在诸多原型中，界面原型是应用得最广泛的原型。如图4-4所示，
需求原型可以建立在用户所提出的需求框架基础上。需求原型的作用是能够方便系统模型的创建。也就是说，需求原型可以方便由用户需求到系统需求的过渡。
（4）仓库以商品品种为基本单位进行管理，所有商品都要由计划部门按品种进行登记，涉及商品编码、名称、类别、库存下限值等数据。其中，商品库存量初始值为零。
（5）仓库商品涉及入库、出库、报损这三种流通方式。凭采购部门填写的入库单进库，凭销售部门填写的出库单出库，凭计划部门制定的报损计划报损。商品的任何流通都需要以流水方式记录到商品流通表中，并对商品库存量进行更新。当商品出库、报损时，必须考虑到该商品的当前库存量是否能够满足操作需要。出库、报损后，若商品库存量低于库存下限值，将自动产生定货请求。
（6）可以按商品类别或品种进行商品库存情况和当月商品流通情况的查询。另外，仓库管理系统需要自动在月底对商品流通数据进行盘查，包括：按月打印商品流通分类汇总报表，并按月备份商品流通数据，然后将已备份的商品流通数据进行合计整理。
四、结构化分析建模
人在求解问题时，首要需要做的是理解问题，并且对问题理解得越透彻，则这个问题就越容易解决。所谓模型，就是为了理解问题而对问题做的一种符号抽象。可以把模型看作为一种思维工具，利用这种工具可以把问题规范地表示出来。模型一般由一组图示符号和组织这些符号的规则组成。因此，分析时期的建模，就是针对用户需求、系统需求等，采用图示方式进行直观描述。软件问题往往是复杂的，而建模可以使问题简化。人的头脑每次只能处理一定数量的信息，模型通过把系统分解成人的头脑一次能处理的若干个子部分，从而减少系统的复杂程度。分析时期建立软件模型的作用是多方面的，可以通过模型实现由用户需求向系统需求的过渡，并可通过模型获得对系统需求的更具细节性的推论。实际上，分析时期产生的模型还可以被引用到系统设计中去，作为设计前导。为了开发复杂的软件系统，往往需要从不同角度去构造系统模型。例如，用于描述系统功能组织结构的层次模型，用于描述系统中数据加工流程的数据流模型，用于描述数据实体及其关系的数据关系模型，用于描述系统行为过程的系统状态模型等。
1.功能层次模型
功能层次模型图使用矩形来表示系统中的子系统或功能模块，使用树形连线结构来表达系统所具有的功能层级关系。实际上，不仅可以使用层次图清晰地说明系统的功能组成关系，也可以使用功能层次图对系统的功能关系进行调整，从而使系统的诸多功能得到更加合理地分配。
2.数据流模型
（1）数据流图特点
数据流模型由DeMarco于1978年提出，并随着他的结构化分析思想一起被广为流行。数据流图用于描述系统对数据的加工过程，其图形符号是一些具有抽象意义的逻辑符号。表4-1所列是数据流图的基本符号。在软件定义时期，数据流图被用来描述系统的逻辑加工步骤。由于数据流图能够为有待开发的系统提供一种简洁的逻辑图形说明，能够方便用户对系统分析的理解，因此，它也被用做开发者和用户之间的信息交流工具。
（2）数据流图的用途
可以依靠数据流图来实现从用户需求到系统需求的过渡。例如，可以将用户需求陈述中的关键名词、动词提取出来，其中的名词可以作为数据流图中数据源、数据存储，而动词则可以作为数据流图中的数据加工进程。
软件系统是复杂的，为了方便问题的解决，有必要将系统进行分解，由此将一个大的复杂问题解剖为许多小的相对简单的问题。例如，可以按照系统的功能构成，将系统分解为许多子系统，各子系统又可以再分解为许多更小的功能模块，由此可以不断深入地了解软件系统的功能细节。由于数据流图使用的是抽象的图形符号，因此，它不仅能够描述系统对数据的加工步骤，而且能够依靠对其图形符号的逻辑细化而方便地实现对系统中数据加工步骤的有效分解。
（3）数据流细化过程
数据流细化的过程即是从上至下对系统功能进行分层描述的过程，如图4-7所示。其中，高层数据流对功能的描述是抽象的，但通过逻辑细化能够深入到系统内部的低层数据流，而使对功能的描述逐步具体化。结构化分析就是基于数据流的细化实现的，它是结构化分析方法的关键。实际上，数据流图对系统的描述可以从任何层面开始，只要那个层面的诸多软件问题是清晰的，则在该层面上获得的数据流图也就可以是清晰的。但是，进入系统的层面越深，则遇到的问题点越多，数据流越复杂。为了更加清楚地表现系统的功能，数据流图往往从容易辨别的高层开始，然后通过数据流的细化逐步深入。这个过程也就是从抽象到具体的解决问题方法在软件分析上的具体体现。
当需要对高层数据流细化以获得对低层数据流的描述时，一种有效的方法是对高层数据流图中的数据加工进行合理分解。通过把一个数据加工分解为多个数据加工可以看到这个数据加工的内部细节。例如，图4-8所描述的“工资管理系统”数据流图。假如“工资管理系统”可以具有以下三项功能：
（1）输入职工名册清单；
（2）从员工的档案工资和业绩工资的计算中产生工资数据；
（3）依据人事部门提供的职工清单按月打印出员工的工资报表。
那么，可以考虑将“工资管理系统”分解为以下三项处理，即：
（1）提供职工清单；
（2）产生工资数据；
（3）打印工资报表。
（2）上一层数据处理“工资管理系统”中不可见的内部数据流变成了可见的外部数据流。
数据流细化被用来分析系统的内部功能构造。然而，面对一个具有一定规模的软件系统，0层数据流图往往只能对其功能进行一般性的高层描述。因此，为了使数据流对系统功能的描述更加具体，数据流细化往往还需要继续深入下去。实际上，可以使用数据流进行软件结构的映射（结构化设计）。一般情况下，假如希望将数据流用于软件设计，则对数据流细化更需要以设计中的模块构件作为分解目标。因此，可以考虑对“工资管理系统”进行更加深入的数据流细化。例如，“工资管理系统”0层数据流图中的“产生工资数据”处理，假如其工资数据的产生涉及数据录入、数据计算等更加具体的数据操作，则“产生工资数据”处理可以进一步分解为：“录入档案工资”、“录入业绩工资”、“计算工资”这三项处理。图4-10即是对“产生工资数据”处理框进一步细化后产生出来的1层数据流图。其中的数据加工流程是：
（2）系统可以从“档案工资表”和“业绩工资表”这两个数据存储读取数据，然后通过“计算工资”的处理产生出“工资数据”数据流。这个数据流将被存入到“工资数据表”中。
（4）数据流图中符号的命名
数据流图中的图形符号一般都需要命名，并遵循以下命名规则：
a.数据接口：使用名词或名词短语命名。例如：人事处、财务处、工资数据录入员、系统管理员、读卡设备、打印设备。
b.数据存储：使用名词或名词短语命名。例如“工资数据表”。当数据存储是存储介质上某个存储单元的存储片段时，其名称还需要用到限定词，例如“在职人员档案工资”。
c.数据流：使用名词或名词短语命名。但为了提高数据流图的清晰度，从数据存储中流出，或流入数据存储的数据流，在不会发生名称混淆的前提下，可以省略名称。例如图4-9中从“档案工资表”、“业绩工资表”流出，或流向“档案工资表”、“业绩工资表”的数据流。d.数据处理：数据处理涉及处理方式与处理对象两方面的内容，一般使用“动词+名词短语”的动宾结构来进行命名。例如，“录入档案工资”、“打印工资报表”。由于对数据流的细化是通过对数据处理的分解实现的，考虑到对细化后的数据流图进行分层检索的便利，可以对处理框进行合适的数字编码。例如，“2.产生工资数据”、“2.1录入档案工资”、“2.2录入业绩工资”、“2.3计算工资”。
（5）数据流图中的数据字典
在需求分析中，数据字典是各类数据描述的集合，能够提供对数据的详细规格定义，并可用于验证数据，以发现系统在数据需求描述中是否出现遗漏。数据流图中的数据字典能够提供对图中的诸多数据元素的更加详细的说明。其一般要求是：
（1）对数据的定义应该是严密、精确、一致的，不能有二义性；
（2）需要对数据流图中的每一个被命名的数据元素进行定义；
（3）需要分类定义各种不同种类的数据元素，或采用类别代号加以区别。数据流图中的数据字典通常包括数据项、数据结构、数据流、数据存储、数据接口和数据处理过程这几个部分的数据内容。其中，数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典就是通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容的。
（1）数据项数据项是不可再分的数据单位。对数据项的描述通常包括以下内容：｛数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系｝
（2）数据结构数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述通常包括以下内容：｛数据结构名，含义说明，组成：｛数据项或数据结构｝｝在定义数据结构时，可以采用以下符号说明数据的组成：=被定义为，表示数据组成。+与，用于连接两个数据分量。[|]或，从若干数据分量中选择一个，方括号中的数据分量用“|”号隔开。m{}n重复，重复花括号内的数据，最少重复m次，最多重复n次。()可选，圆括号内数据可有可无。
3.数据关系模型(ER图)
许多应用软件系统往往需要通过数据库来存储数据。从结构上来看，数据库系统是独立于软件系统之外的专门系统，因此，在系统建模过程中，数据库需要进行专门的分析与设计。其中，需求分析时期建立的数据库模型称为概念模型。
数据关系模型图也称为ER图，是应用最广泛的数据库分析建模工具。数据关系建模方法最早由Chen于20世纪70年代中期提出，它以现实数据为建模依据，通过从现实数据中抽取数据实体、数据关系和数据属性这三类图形元素，建立数据库的概念模型。
（1）数据实体
数据实体是对应用领域中现实对象的数据抽象。例如，课程教学中的教师、学生和课程这三个现实对象，就可以作为数据实体对待。
（2）数据关系
数据关系是指不同数据实体之间存在的联系，包括：一对一、一对多、多对多三种类型的关系。数据关系类型及其描述如表4-6所列。
（3）数据属性
数据属性是指在数据实体与数据关系上所具有的一些特征值。例如，教师的编号、姓名、性别、职称、学历，是教师实体的属性；学生的学号、姓名、性别、专业、班级，是学生实体的属性；课程的课号、课名、学分、计划课时量，是课程实体的属性。而学习的成绩，则是学习关系的属性；讲授的实际课时量，则是讲授关系的属性。在数据关系图中，数据实体用矩形表示，数据关系用菱形表示，数据属性用椭圆形表示。其中，能够用来标记实体的关键属性则通过在属性名称上加下划线来表示。图4-11是教师、学生、课程这三个实体之间存在的教学关系的数据关系图的描述。
对于一些比较复杂的数据关系，为了方便分析，在画数据关系图时可以只画出实体、关系和关键属性，而其一般属性则可以省略，例如图4-12。
4.系统状态模型
（1）状态图特点
状态图于1987年由Harel首先提出，其使用状态、事件等图形符号来描述系统的行为活动，用以反映系统因某个外部事件的干预而由一个可能的状态转换到另一个状态。表4-7所列为状态模型图中一些常用的图形符号及其描述。
状态模型图是通过系统的内部状态、外部事件为基本元素来描绘系统的工作流程的，这种建模方式比较适合于描述一些依赖于外部事件驱动的实时系统。另外，状态模型也被UML建模语言采纳。在面向对象建模之中，状态模型可以用来对对象的状态及其变换进行细节描述。
（2）状态图应用举例
下面是一台全自动洗衣机的大致活动过程：
（1）在洗衣机接通电源以后，洗衣机将进入待命状态。
（2）在洗衣机进入待命状态以后，操作者可以选择“设置”或“工作”。若选择“设置”，洗衣机将进入设置状态；若选择“工作”，洗衣机将进入工作状态。
（3）在洗衣机进入设置状态以后，操作者可以设置洗衣水位，洗衣机工作流程，并可在完成设置之后选择“确定”返回待命状态。
（4）在洗衣机进入工作状态以后，洗衣机将按照设置的流程进行工作。若洗衣机在洗衣过程中选择暂停，洗衣机将进入暂停等待状态；若洗衣机在洗衣过程中出现洗衣故障，洗衣机将鸣报警音，并进入故障等待状态。在洗衣机完成流程规定的工作以后，洗衣机进入结束等待状态。（5）在洗衣机进入暂停等待状态以后，操作者可选择“恢复”，使洗衣机返回工作状态。
（6）在洗衣机进入故障等待状态以后，操作者可在排除洗衣故障之后，选择“恢复”，使洗衣机返回工作状态。
（7）在洗衣机进入结束等待状态以后，操作者可以切断电源结束洗衣过程。根据上述活动内容，可以画出该洗衣机的状态图模型。其状态图模型如图4-13所示。
需要注意的是，图4-13中的工作状态是一个复合状态。也就是说该状态中包含了子状态。假如洗衣机的常规工作流程是：累积洗涤10分钟，然后进入漂洗状态；累积漂洗6分钟，然后进入脱水状态；累积脱水1分钟，然后进入结束鸣音状态。则工作状态的下层子状态图如图4-14所示。
五、需求有效性验证
需求有效性验证是指对已经产生的需求结论所要进行的检查与评价，它是需求分析过程中一个必不可少的环节。需求分析是软件开发过程中一个非常关键的阶段。它是软件设计、实现的基础，同时也是用户对软件产品进行确认的基本依据。但是，需求分析过程中产生出来的结论难免存在问题。例如，某项功能被遗漏了，某些功能之间发生了操作上的冲突，某些数据字节数不够大等。更加重要的是，这些问题看起来或许并不显眼，但它所影响的是软件系统的整体构造。实际情况往往是：需求分析中的小问题，假如是在后续的开发过程中或是在系统开发出来并投入使用以后才被发现，就会导致代价巨大的返工。因此，在需求分析结果出来以后，需要对其进行严格的有效性验证，由此尽早地发现需求文档草稿中存在的问题。
1.需求验证内容
在需求有效性验证过程中，为了确保软件需求的正确性，需要对需求文档草稿从有效性、一致性、完整性、现实性等几个方面进行有效性验证。
（1）有效性验证
需求有效性验证用于确认每一项需求定义都能符合用户的实际需要。由于一个软件系统在其运行过程中一般需要面对许多不同的用户，他们分别会有一些不同的个性需求意愿，因此，有效性验证还包括对用户需求个性差异的协商。
（2）一致性验证
一致性验证用于检查发现在需求文档中可能存在的需求冲突，例如，同一个功能出现了不同的描述或存在相互矛盾的规程约束。
（3）完整性验证
完整性验证用于检查发现用户确实需要的，但没有写入需求文档中一些功能、约束等，以使最终确定下来的需求文档能够更加完整的体现用户的需求意愿。
（4）现实性验证
现实性验证用于检查需求文档中所提出的功能、性能、安全等方面的需求，哪些还不能够利用现有技术加以实现，以确保用户的一系列需求都能够具有现实意义，都能够最终实现。
（5）可检验性验证
可检验性验证用于判断需求文档中的各项需求是否有适合于用户操作的检测方法，可以使得当系统开发完成并交付用户使用时，开发人员能设计出一组合适的检查方法来进行用户需求检验，由此最大限度地保证用户的需求意愿能够得以实现。
2.需求验证方法
在进行需求有效性验证时，需要有一定的方法、工具提供支持。例如，需求评审、需求原型评价和基于CASE工具的需求一致性分析等。
1.需求评审
（1）一致性：需求文档对需求的描述是否有不一致的地方？
（2）完整性：是否还有需要的但没有写到需求文档中的功能？
（3）可检验性：需求描述是否可实际测试？
（4）可读性：需求描述能否被用户读懂？
（5）可跟踪性：是否清晰地记录了需求的出处？
（6）可调节性：需求是可调节的吗？假如需求出现变更，能否不对系统带来太大的影响？
2.需求原型评价
本章4.3.3节主要说明了如何使用需求原型完善用户的需求，但在这个过程中也包括对用户需求的有效性验证。例如，可以根据需求文档为用户创建一个可以运行的系统模型，使用户通过模型进行更加接近实际的系统需求检验。需求原型主要用来提供给用户评价，以方便用户进行需求确认。为了使需求原型评价更加有效，分析人员有必要从不同方面对用户评价作些引导。例如，为了启发用户的评价行为，可以针对界面原型提出以下问题：
（1）界面所显示的功能是你所期望的吗？
（2）有遗漏的功能吗？
（3）有多余的功能吗？
（4）你感觉界面复杂吗？
其一：原型创建工具和目标系统创建工具应该尽量一致，以方便从原型到目标系统的无缝过渡。例如，使用MicrosoftVisualBasic、InpriseDelphi等基于组件的可视化开发工具作为原型创建工具。
3.基于CASE工具的需求一致性分析
如果需求文档中的需求元素是用结构化或形式化语言描述的，则可以使用需求CASE工具来进行需求一致性分析。需求CASE工具的工作流程如图4-15所示。其中，需求处理器用于处理使用形式化语言描述的需求，并将产生的需求结果存入需求数据库中。以后，需求分析器可以使用方法规则或符号规则对需求数据库中的需求结果进行一致性检查，并能够根据检查结论产生出关于需求一致性的分析报告。
六、需求规格定义
需求规格说明书是需求分析阶段需要交付的基本文档，涉及引言、术语定义、用户需求、系统体系结构、系统需求等有关软件需求及其规格的诸多描述与定义。应该说，有关软件系统的一系列需求结论都需要以正式文档的形式写进这份文档之中。需求规格说明书将成为开发者进行软件设计和用户进行软件验证的基本依据，其作用是使软件用户和软件开发者双方在软件正式开发之前能够对需要开发的软件有一个共同认可的规格定义。需求规格说明书具有里程碑的意义，涉及比较广泛的读者群。几乎所有与软件项目有关的人员，包括用户、项目管理人员、系统开发人员、系统测试人员和系统维护人员等，都需要阅读这份文档，并或多或少地受到它的一定范围与程度的约束。
软件用户：提出需求，按照需求规格说明书对软件系统进行验收。
项目管理人员：根据需求规格说明书制定项目详细开发计划，安排项目进程。
系统开发人员：以需求规格说明书为依据进行系统设计与实现。
系统测试人员：以需求规格说明书为依据进行系统有效性测试。
系统维护人员：通过需求规格说明书来帮助对系统功能与构造的认识。
小结:
1.需求分析任务
（1）用户需求用户需求是用户关于软件的一系列意图、想法的集中体现，是用户关于软件的外界特征的规格表述。
（2）系统需求系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。主要包括：功能、数据、性能、安全等诸多方面的需求问题。
2.需求分析过程需求分析是对软件系统的后期分析，需要进行的活动包括：分析用户需求、建立需求原型、分析系统需求和进行需求验证等。
3.用户需求获取
（1）用户调查是最基本的用户需求信息收集方法，比较常用的调查方法包括：访谈用户、开座谈会、问卷调查、跟班作业、收集用户资料。
（2）需求原型可被用来解决用户对软件系统在需求认识上的不确定性。一般情况下，开发人员将软件系统中最能够被用户直接感受的那一部分东西构造成为原型。例如，界面、报表或数据查询结果。
4.结构化分析建模
所谓模型，就是对问题所做的一种符号抽象。可以把模型看作为一种思维工具，利用这种工具可以把问题规范地表示出来。主要的分析模型包括：
（1）功能层次模型。它使用矩形来表示系统中的子系统或功能模块，使用树形连线结构来表达系统所具有的功能层级关系。
（2）数据流模型。用于描述系统对数据的加工过程，其图形符号是一些具有抽象意义的逻辑符号，主要的图形符号包括：数据接口、数据流、数据存储和数据处理。可以依靠数据流图来实现从用户需求到系统需求的过渡。结构化分析就是基于数据流的细化实现的，它是结构化分析方法的关键。
（3）数据关系模型。也称为ER图，是应用最广泛的数据库建模工具。需要通过数据实体、数据关系和数据属性这三类图形元素建立数据关系模型。
（4）系统状态模型。通过系统的外部事件、内部状态为基本元素来描绘系统的工作流程，这种建模方式比较适合于描述一些依赖于外部事件驱动的实时系统。
5.需求有效性验证
需求有效性验证是指对已经产生的需求结论所要进行的检查与评价。一般需要对需求文档草稿从有效性、一致性、完整性、现实性等几个方面进行有效性验证。比较常用的需求有效性验证方法与工具包括：需求评审、需求原型评价和基于CASE工具的需求一致性分析。
6.需求规格定义
需求规格说明书是需求分析阶段需要交付的基本文档，将成为开发者进行软件设计和用户进行软件验证的基本依据，涉及引言、术语定义、用户需求、系统体系结构、系统需求等有关软件需求及其规格的诸多描述与定义。