本文详细阐述了软件需求分析的重要性和过程，包括用户需求的获取、系统需求的定义，用例图的构建，以及需求有效性验证的方法。强调了在软件开发前期进行深入需求分析以确保软件满足用户实际需求和业务目标的重要性。
软件需求分析
目录
软件需要解决的是用户所面临的现实问题，但是，这些现实问题需要由软件技术人员来解决。开发软件的技术人员精通计算机技术，但并不熟悉用户的业务领域；而用户清楚自己的业务，却又不太懂计算机技术。对于同一个问题，技术人员和用户之间可能存在认识上的差异。因此，在软件技术人员着手设计软件之前，需要由既精通计算机技术又熟悉用户应用领域的软件系统分析人员，对软件问题进行细致的需求分析。需求分析是软件工程过程中一个重要的里程碑。在需求分析过程中，软件系统分析人员通过研究用户在软件问题上的需求意愿，分析出软件系统在功能、性能、数据等诸多方面应该达到的目标，从而获得有关软件的需求规格定义。
需求分析是在软件系统分析人员的操作下进行的，在这个过程中，用户和开发者之间需要达成的是对系统的一致性需求认识。实际上，可以把软件系统分析人员看成是软件用户与软件开发技术人员之间的信息通道，其作用是使用户对软件问题的现实描述，能够有效地转变为开发软件的技术人员所需要的对软件的技术描述，以方便技术人员对软件的技术构建。
一、需求分析任务
需求分析需要实现的是将软件用户对于软件的一系列意图、想法转变为软件开发人员所需要的有关软件的技术规格，并由此实现用户和开发人员之间的有效通信，它涉及面向用户的用户需求和面向开发者的系统需求这两个方面的工作内容。
1.1用户需求
用户需求是用户关于软件的一系列意图、想法的集中体现，涉及软件的操作方式、界面风格、报表格式，用户机构的业务范围、工作流程，以及用户对于软件应用的发展期望等。因此，用户需求也就是用户关于软件的外界特征的规格表述。实际上，用户需求提出了一个有关软件的基本需求框架，具有以下特点：
（1）用户需求直接来源于用户，可以由用户主动提出，也可以通过与用户交谈，或对用户进行问卷调查等方式获取。由于用户对计算机系统认识上的不足，分析人员有义务帮助用户挖掘需求，例如，可以使用启发的方式激发用户的需求想法。如何更有效地获取用户需求，既是一门技术，也是一门思维沟通艺术。
（2）用户需求需要以文档的形式提供给用户审查，因此需要使用流畅的自然语言或简洁清晰的直观图表来进行表述，以方便用户的理解与确认。
（3）可以把用户需求理解为用户对软件的合理请求，这意味着，用户需求并不是开发者用户的盲目顺从，而是建立在开发者和用户共同讨论、相互协商的基础上。
（4）用户需求主要是为用户方管理层撰写的，但用户方的技术代表，软件系统今后的操作者，以及开发方的高层技术人员，也有必要认真阅读用户需求文档。
1.2系统需求
系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。系统需求需要对系统在功能、性能、数据等方面进行规格定义，由于自然语言随意性较大，在描述问题时容易发生歧义，因此系统需求往往要求用更加严格的形式化语言进行表述，例如PDL伪码，以保证系统需求表述具有一致性。系统需求涉及有关软件的一系列技术规格，包括：功能、数据、性能、安全等诸多方面的问题。
（1）功能需求
功能需求是有关软件系统的最基本的需求表述，用于说明系统应该做什么，涉及软件系统的功能特征、功能边界、输入输出接口、异常处理方法等方面的问题。也就是说，功能需求需要对软件系统的服务能力进行全面的详细的描述。在结构化方法中，往往通过数据流图来说明系统对数据的加工过程，它能够在一定程度上表现出系统的功能动态特征。也就是说，可以使用数据流图建立软件系统的功能动态模型。
（2）数据需求
数据需求用于对系统中的数据，包括：输入数据、输出数据、加工中的数据、保存在存储设备上的数据等，进行详细的用途说明与规格定义。在结构化方法中，往往使用数据字典对数据进行全面准确的定义，例如，数据的名称、别名、组成元素、出现的位置、出现的频率等。当所要开发的软件系统涉及到对数据库的操作时，还可以使用数据关系模型图对数据库中的数据实体、数据实体之间的关系等进行描述。
（3）其他需求
其他需求是指系统在性能、安全、界面等方面需要达到的要求。
二、需求分析过程
需求分析是对软件系统的后期分析，需要进行一系列的活动，包括：分析用户需求、建立需求原型、分析系统需求和进行需求验证等。
（1）需求分析可以可行性分析中软件系统的高层模型为前提，首先需要进行的是分析用户需求，由此可以提出关于软件的需求框架。
（2）由于用户对计算机信息系统认识上的模糊性，以致直接来源于用户的需求想法往往存在着许多缺陷，例如：需求冲突、需求遗漏。为提高用户需求的有效性，可以按照需求框架的要求建立需求原型让用户确认，然后再通过需求原型去提取系统模型。
（3）系统需求是面向技术人员的。因此，它不仅需要从需求原型中提取系统模型，而且需要对系统模型进行细节化处理，例如：数据流细化、数据字典分解、类模型的定义等，由此获得对系统的详细的技术性需求说明。
（4）对需求框架、系统模型和需求细节等文档进行有效性验证，由此产生出用户方、开发方都能接受的关于软件的需求规格说明书。
三、用户需求获取
优秀软件总是能够最大限度地满足用户需求。因此，有效获取用户需求，是实施软件开发时需要完成的第一项工作。
3.1研究用户
在建立软件抽象模型过程中，用户可以被当作为一个抽象概念，泛指诸多从系统获得服务的系统以外的对象，例如：软件使用机构，软件操作人员，以及从软件获得信息服务的其他系统或设备。也就是说，可以把用户看作为系统的外部应用接口。但从软件的商业服务角度来看，用户则主要是指购置软件的机构、使用软件的部门、操作软件的人。软件是为用户开发的，为了使软件能够更好地为用户服务，在软件需求阶段，软件开发者应该尽量充分地和用户进行沟通，了解用户的意图。例如，用户希望软件为他提供哪些方面的服务，用户在操作软件时有哪些工作习惯，喜欢什么样的工作界面等。软件往往需要为各种不同的用户服务，例如，用户机构负责人、使用软件的部门主管、软件操作人员，他们都是用户，但由于所处位置不同，因此会有不同的需求。软件操作人员大多需要较长时间地操作软件，因此他们会特别关心软件的工作方式、界面布局；使用软件的部门主管则一般不会直接操作软件，但他需要从软件中得到年度报表之类的打印数据，因此比较关心软件能够提供哪些方面的报表，报表格式如何等。用户情况是复杂的，为了更好地研究用户，有必要对软件用户做一些分类，例如：按软件需求层次不同，将用户分为高层用户、中层用户和基层用户；按使用软件时间长短不同，将用户分为熟练用户和非熟练用户；按是否直接操作软件系统，将用户分为直接用户和间接用户。
3.2从调查中获取用户需求
直到今天，用户调查仍是最基本的用户需求信息收集方法。应该说，用户需求信息来源是多方面的，为了保证用户需求的完整性，在需求分析过程中，软件系统分析人员往往需要调查各类能够代表用户意愿的相关人员。
实际上，针对不同的应用项目通常会有不同的调查内容，需要采用不同的调查策略。例如，开发一个信息管理系统，其用户需求调查一般会涉及以下方面的内容：
（1）调查用户的组织机构，包括：该组织的部门组成，各部门的职责等。由此得到的调查结果将作为分析软件系统领域边界的基本依据。
（2）调查用户各部门的业务活动，包括：各个部门输入和使用什么数据，如何加工处理这些数据，输出什么数据，输出到什么部门等。这是需求调查的重点内容，其结果将作为分析软件系统工作流程的基本依据。
（3）调查用户对软件系统的各项具体要求，包括：数据格式、操作方式、工作性能、安全保密等方面的要求。
在调查过程中，可以根据不同的问题和条件，使用不同的调查方法。比较常用的调查方法有以下几种：
a.访谈用户
访谈用户就是面对面地跟单个用户进行对话。例如，请用户机构高层人员介绍用户的组织结构、业务范围、对软件应用的期望。
b.开座谈会
当需要对用户机构的诸多部门进行业务活动调查与商讨时，可以考虑采用开一个座谈会的方式。这既有利于节约调查时间，又能使各部门之间就业务问题进行协商，以方便对与软件有关的业务进行合理分配与定位。
c.问卷调查
问卷调查一般是通过精心设计的调查表去调查用户对软件的看法。当面对一个庞大的用户群体时，可能需要采用问卷调查形式进行用户调查。例如在开发通用软件时，为了获得广大用户对软件的看法，就不得不采取问卷方式。如果调查表设计得合理，这种方法很有效，也易于为用户接受。
d.跟班作业
跟班作业就是软件分析人员亲身参加用户单位业务工作，由此可直接体验用户的业务活动情况。这种方法可以更加准确地理解用户的需求，但比较耗费时间。
e.收集用户资料
尽管有待开发的软件需要在较长时间以后才能交付用户使用，但跟软件有关的工作用户却一直在以其他方式或通过其他系统进行着，并且也一直在产生结果。用户资料主要就是指这些结果，例如：年度汇总报表、提货单、工资表等。软件分析人员应该认真收集这些资料，由此可以更加清楚地认识用户的软件需求。
3.3通过原型完善用户需求
需求原型可用来收集用户需求，对用户需求进行验证，由此可帮助用户克服对软件需求的模糊认识，并使用户需求能够更加完整地得以表达。例如，用户对软件应该提出哪些方面的服务，操作界面应该如何等可能拿不定主意，为了使用户能够更加直观地表述自己的需求意愿，可以先构造一个原型给用户体验。原型需要根据用户的评价而不断修正，这也有利于挖掘用户的一些潜在需求，使得用户需求能够更加完整地得以表达。一般情况下，开发人员将软件系统中最能够被用户直接感受的那一部分东西构造成为原型。例如，界面、报表或数据查询结果。实际上，在诸多原型中，界面原型是应用得最广泛的原型。如图1所示，需求原型可以建立在用户所提出的需求框架基础上。需求原型的作用是能够方便系统模型的创建。也就是说，需求原型可以方便由用户需求到系统需求的过渡。
图1 需求原型
（1）仓库管理系统将被计划部门、仓库管理部门、采购部门、销售部门的相关工作人员使用。其中，计划部门制定商品计划，涉及：设置商品类别、登记商品、制定商品报损计划和进行商品流通数据汇总；仓库管理部门完成仓库的日常管理，涉及：商品入库、出库、报损和查询等多项操作；采购部门可以查询商品库存情况、打印商品定货报表；销售部门可以查询商品库存情况和提交商品定货请求。
（2）由于不同部门有不同的任务，因此系统需要提供针对部门的权限管理机制和针对工作人员的登录注册机制。系统将通过一位系统管理员进行部门授权与工作人员注册管理。
（3）进入仓库管理系统的工作人员需要有惟一的个人身份标识，它既是工作人员登录系统时的身份验证依据，也是工作人员在进行商品操作时的经手人标记。尽管工作人员的姓名也可以用做其身份标识，但不同的工作人员有可能会出现姓名重复，因此有必要为工作人员设置一个专门的身份标识码。
（4）仓库以商品品种为基本单位进行管理，所有商品都要由计划部门按品种进行登记，涉及商品编码、名称、类别、库存下限值等数据。其中，商品库存量初始值为零。
（5）仓库商品涉及入库、出库、报损这三种流通方式。凭采购部门填写的入库单进库，凭销售部门填写的出库单出库，凭计划部门制定的报损计划报损。商品的任何流通都需要以流水方式记录到商品流通表中，并对商品库存量进行更新。当商品出库、报损时，必须考虑到该商品的当前库存量是否能够满足操作需要。出库、报损后，若商品库存量低于库存下限值，将自动产生定货请求。
（6）可以按商品类别或品种进行商品库存情况和当月商品流通情况的查询。另外，仓库管理系统需要自动在月底对商品流通数据进行盘查，包括：按月打印商品流通分类汇总报表，并按月备份商品流通数据，然后将已备份的商品流通数据进行合计整理。
四、结构化分析建模
人在求解问题时，首要需要做的是理解问题，并且对问题理解得越透彻，则这个问题就越容易解决。所谓模型，就是为了理解问题而对问题做的一种符号抽象。可以把模型看作为一种思维工具，利用这种工具可以把问题规范地表示出来。模型一般由一组图示符号和组织这些符号的规则组成。因此，分析时期的建模，就是针对用户需求、系统需求等，采用图示方式进行直观描述。软件问题往往是复杂的，而建模可以使问题简化。人的头脑每次只能处理一定数量的信息，模型通过把系统分解成人的头脑一次能处理的若干个子部分，从而减少系统的复杂程度。分析时期建立软件模型的作用是多方面的，可以通过模型实现由用户需求向系统需求的过渡，并可通过模型获得对系统需求的更具细节性的推论。实际上，分析时期产生的模型还可以被引用到系统设计中去，作为设计前导。为了开发复杂的软件系统，往往需要从不同角度去构造系统模型。下面介绍用例图的概念及画法。
4.1用例图的概念
用例图（Use Case Diagram）是用户与系统交互的最简表示形式，展现了用户和与相关的用例之间的关联关系。通过用例图，人们可以获知系统不同种类的用户和用例：
用例图呈现出谁将是相关的用户？
用户希望系统提供什么样的服务？
用户需为系统提供什么样的操作？
4.2用例图的构成元素
用例图主要有4个构成元素：
（1）参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类外部实体的抽象。
建立系统的外部用户模型，并对系统边界外对象做描述
每个参与者可以参与一个或多个用例，每个用例也可以有一个或者多个参与者
（2）系统（System）是用例图的一个组成部分，代表的是一个软/硬件或-一个活动等，并不是真正实现的软件系统。系统边界，指系统与系统之间的界限:
一般我们所说的系统都是由一系列的相互作用的元素形成的具有特定功能的整体
一个系统往往本身又可以是另一个更大系统的组成部分
因此我们需要把系统用边界区分开来，系统边界以外的系统和其他关联部分，我们称为系统环境。
（3）用例（Use Case）用来描述系统提供给参与者的服务或功能。
用例由某个参与者来执行
用例把执行的结果反馈给参与者
用例在功能上具有完整性:从参与者接受输入，产生的结果输出给参与者
（4）关系（Association），表示参与者和用例间的关联关系。
从图中可看出：所有的用例都放在一个系统边界内，说明它们属于一个系统。参与者在系统边界外面，说明参与者并不属于系统，但参与者驱动与之关联用例的执行。
4.3用例图的特点
（1）用例用以描述系统的功能，这个功能是指外部使用者看到的系统功能，不需反映功能的实现方式。
（2）用例用以描述参与者提出的一些可见需求，对应具体的目标参与者。并且用例必须由参与者激活才能执行，即每个用例至少有一个参与者。
（3）用例反映系统与用户的交互过程，可具有交互的信息传递。
五、需求有效性验证
需求有效性验证是指对已经产生的需求结论所要进行的检查与评价，它是需求分析过程中一个必不可少的环节。需求分析是软件开发过程中一个非常关键的阶段。它是软件设计、实现的基础，同时也是用户对软件产品进行确认的基本依据。但是，需求分析过程中产生出来的结论难免存在问题。例如，某项功能被遗漏了，某些功能之间发生了操作上的冲突，某些数据字节数不够大等。更加重要的是，这些问题看起来或许并不显眼，但它所影响的是软件系统的整体构造。实际情况往往是：需求分析中的小问题，假如是在后续的开发过程中或是在系统开发出来并投入使用以后才被发现，就会导致代价巨大的返工。因此，在需求分析结果出来以后，需要对其进行严格的有效性验证，由此尽早地发现需求文档草稿中存在的问题。
5.1需求验证内容
在需求有效性验证过程中，为了确保软件需求的正确性，需要对需求文档草稿从有效性、一致性、完整性、现实性等几个方面进行有效性验证。
（1）有效性验证
需求有效性验证用于确认每一项需求定义都能符合用户的实际需要。由于一个软件系统在其运行过程中一般需要面对许多不同的用户，他们分别会有一些不同的个性需求意愿，因此，有效性验证还包括对用户需求个性差异的协商。
（2）一致性验证
一致性验证用于检查发现在需求文档中可能存在的需求冲突，例如，同一个功能出现了不同的描述或存在相互矛盾的规程约束。
（3）完整性验证
完整性验证用于检查发现用户确实需要的，但没有写入需求文档中一些功能、约束等，以使最终确定下来的需求文档能够更加完整的体现用户的需求意愿。
（4）现实性验证
现实性验证用于检查需求文档中所提出的功能、性能、安全等方面的需求，哪些还不能够利用现有技术加以实现，以确保用户的一系列需求都能够具有现实意义，都能够最终实现。
（5）可检验性验证
可检验性验证用于判断需求文档中的各项需求是否有适合于用户操作的检测方法，可以使得当系统开发完成并交付用户使用时，开发人员能设计出一组合适的检查方法来进行用户需求检验，由此最大限度地保证用户的需求意愿能够得以实现。
5.2需求验证方法
在进行需求有效性验证时，需要有一定的方法、工具提供支持。例如，需求评审、需求原型评价和基于CASE工具的需求一致性分析等。
六、需求规格定义
需求规格说明书是需求分析阶段需要交付的基本文档，涉及引言、术语定义、用户需求、系统体系结构、系统需求等有关软件需求及其规格的诸多描述与定义。应该说，有关软件系统的一系列需求结论都需要以正式文档的形式写进这份文档之中。需求规格说明书将成为开发者进行软件设计和用户进行软件验证的基本依据，其作用是使软件用户和软件开发者双方在软件正式开发之前能够对需要开发的软件有一个共同认可的规格定义。需求规格说明书具有里程碑的意义，涉及比较广泛的读者群。几乎所有与软件项目有关的人员，包括用户、项目管理人员、系统开发人员、系统测试人员和系统维护人员等，都需要阅读这份文档，并或多或少地受到它的一定范围与程度的约束。
•软件用户：提出需求，按照需求规格说明书对软件系统进行验收。
•项目管理人员：根据需求规格说明书制定项目详细开发计划，安排项目进程。
•系统开发人员：以需求规格说明书为依据进行系统设计与实现。
•系统测试人员：以需求规格说明书为依据进行系统有效性测试。
•系统维护人员：通过需求规格说明书来帮助对系统功能与构造的认识。
783
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
