需求工程论文

浅谈对软件需求的认知

中文摘要：

需求分析作为软件生命周期的第一个阶段，其重要性越来越突出。许多大型应用系统的失败，最后大都归结到需求分析。要么是需求分析不彻底，导致反复多次进行需求分析，导致后续的设计、编码和测试无法顺利进行；要么是客户需求不断变化，同样导致反复修改代码，延误时间。所以缺乏用户参与、不完整的需求及不断变更需求，是导致信息技术项目不能按进度安排和资金预算完成全部功能的主要原因。

需求分析首先会得到一份用户需求报告，它是软件生命周期的第一个里程碑，也是后续工作的基础，需求的错误不仅仅是早期的错误，它会在后续的设计和实现中延续。因此，需求分析是软件设计和实现过程的基础，是软件项目成功与否的重中之重。

英文摘要：

Requirements analysis, as the software life cycle first stage, its importance has become increasingly prominent. The failure of many large applications, mostly due to the demand for

the final analysis. Needs analysis is either incomplete, leading to repeated demand

analysis, resulting in subsequent design, coding, and testing can not proceed smoothly;

either the customer needs are constantly changing, the same result repeatedly modify the

code, delaying time. Therefore, the lack of user involvement, incomplete requirements and

ever-changing needs is leading information technology projects can not by schedule and

budget funds to complete all of the features of the main reasons.

Needs analysis will first get a user needs report, which is software life cycle, the first

milestone is the basis for follow-up, demand is not only an early error error, it will

follow the design and implementation of continuity. Therefore, the needs analysis is the process of software design and implementation based on the success of software projects is a

top priority.

一、需求是基础

软件需求是指开发软件产品的目标用户对该软件产品的功能、性能、设计约束和其它方面的期望和要求，它是软件开发者和用户交互的一个过程，任何一方的不投入都会导致项

目的失败。评判一个软件项目成功的标准是看它是否解决了用户的问题，而用户的问题的具体体现就是用户的需求。需求阶段的每一个不慎都有可能导致软件实现阶段的返工，但是很多需求具有隐蔽性，连用户都不清楚自己的需求，这时就要开发者对用户要求进行探寻，与用户尽量达成一致，用科学的分析方法帮助找出用户的真正需求。

二、需求的工作流程

通过弄清业务流程和数据流程的手段，达到与客户共同确定业务模型、功能模型、性能模型、接口模型的目标。通过评审，与客户达成一致的理解，让客户确认，在需求报告上签字，这就是需求分析的目的。业务需求的参与者主要是业务流程分析员，对企业目前的业务流程进行评估，确定进行何种程度的业务建模；用户需求重心是如何收集用户需求，确定角色和用例，获取需求的方法倾向组织访谈会；功能需求依赖于用户需求，是用户需求在系统上的一个映射，为用户做一个软件原型是一个很好的方法。

三、需求的获取

需求获取是需求分析的基础，正确、完整的获取需求是保证项目成败的关键。下面通过需求陈述、创建构想文档、确定需求来源、需求收集的方法这4个方面进行阐述。

1.需求陈述。需求工程是软件开发中管理需求的过程。需求工程创建的第一份文档是需

求陈述，用于在项目开发之初理解客户的需求。需求陈述是一份文档，陈述软件方案

的需要，并对可能的规格要求加以说明。并用来明确软件开发的用途，他不仅要说明

软件有什么用，还要在宏观层面上明确软件应具备的特性。

2.创建构想文档。构想文档是为软件开发团队创建的，有助于开发人员明了项目的目的

和范围。从宏观层面上显示软件的需求，为待开发项目提供一个结构清晰的概要，确

保项目的计划、设计和开发等阶段能依次有序地展开。因此构想文档的组成应包括：

公司描述，需求概要，项目目标，项目利益相关者，软件主要功能，项目约束。

3.确定需求来源。需求抽取是从相关来源为软件开发收集需求的过程。需求来源可以是

公司员工和外部人员(如供应商等)，或公司文件，包括手册、文书、表格和报表等，也

包括现有应用系统的文档。

4.需求收集的方法。需求收集方法可以有背景阅读、文档取样、面谈、调查问卷、问题

根本原因分析等5个方法。

1)在启动需求收集过程之前，充分了解委托公司及其业务流程非常重要。这可以通

过大量的背景阅读来完成，可供阅读的背景信息包括：公司报告、公司图表、策

略手册、岗位描述、报表、现有系统的文档。

2)文档取样指收集公司保存的各类文档。这些样本文档可用于决定软件系统的输入、

输出，在存在现有软件系统的情况下，这是个非常理想的方法。另外，为了理解

系统输入／输出，在存在现有软件系统的情况下，这是个非常理想的方法。另外，

为了理解系统输入／输出接口，还可以收集些屏幕快照。

3)面谈是使用最为广泛的一种需求收集方法。系统分析员可向管理层了解有关公司

目标，再从员工处收集与业务流程相关的信息。面谈的优点是面对面的沟通能使

系统分析员对需求更敏感，也更容易采纳被访者的意见。分析员能与被访者就他

的工作性质进行更为深入的探讨，这种效果是其他需求抽取技术所不能企及的。

面谈是一种耗时而且开销较高的需求抽取方法。如果被访者的意见有冲突，会使

确定需求变得更困难。在访谈中要注意不要记录与议题无关的信息，问的问题必

须与议题有关，问的问题必须与被访者的工作直接相关。

4)调查问卷是在项目开发中收集信息的手段之一。调查问卷包含一系列经过设计的

问题，通常被认为是广泛收集数据的最经济的一种手段。如果应用系统的用户是

一般大众，或者分析员觉得有必要了解系统的具体用法，那么调查问卷这种方式

是非常有效的。调查问卷一般包括是非题和问答题。调查问卷的优点：调查问卷

是一种最经济的广泛收集数据的方法，一个精心设计的调查问卷很容易进行需求

分析。调查问卷的缺点：调查问卷不容易设计得好。不能对特定问题进行深入的

探究，不象在电话调查或面对面的沟通中，必要的话，可对一个问题追根到底。

5)问题根本原因分析是分析系统存在的问题，并找出其根源及解决办法，以消除故

障因素。可进行原因分析的技术有：再看一遍需求，列出所有类似的线索，查找

错误发生的机会，鱼骨图排列分析。这些技术不一定能把原因马上找到，但能拓

宽分析人员的思路，利于更进一步的仔细检查，与根本原因很接近。

四、需求的风险

在应用软件开发过程巾，由于软件需求本身的隐含性、用户与开发者之问的沟通障碍，以及需求随着时间、用户的变化而变更等原因，可能使需求分析偏离实际需求而最终导致软件开发的失败，这种可能性称为需求风险。需求分析工作往往面临着一些潜在的风险，这些风险主要表现在：

1.用户不能正确表达自身的需求。用户对自己的真正需求不明确，只是简单说自己想干

什么，这种情况增加了需求分析难度。

2.用户配合力度不够。有的用户忙，不愿意付出足够时间和精力向开发人员讲解业务。

3.用户需求不断变更。由于业务变化或者需求本身错误原因，导致软件整个生命周期发

生变化。

4.需求的完整程度。需求没办法做到没有遗漏，导致开发项目过程不断完善需求，造成

返工，延误时间。

5.需求细化程度的影响。需求越细，周期越长，可能变化越多，相反，需求越粗，开发

人员在设计时不清楚的地方越多。

6.需求描述的多义性。不同人员对需求说明产生了不同理解，导致开发方向偏离。

7.需求开发时间的保障。为了确保需求的正确性和完整性，项目负责人在需求阶段花费

较多的时间，导致项目后续开发迟迟没有进行。

五、需求的标准

好的需求应该具有正确性、完整性、可行性、必要性、一致性、无二义性和可验证性。

1、正确性：每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的

来源。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，一定要有用户的积极参与。

2、完整性：需求的遗漏是经常发生的事情，多发生在用户方面。因此每一项需求都必须将

所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

3、可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避

免不可行的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

4、必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。

“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求

都能回溯至某项客户的输入，如使用实例或别的来源。

5、一致性：与其它软件需求或高层（系统，业务）需求不相矛盾。用户需求必须和业务需

求一致，功能需求必须和用户需求一致。在开发前必须解决所有需求间的不一致部分。

只有进行一番调查研究，才能知道某一项需求是否确实正确

6、无二义性。每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。

“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能

回溯至某项客户的输入，如使用实例或别的来源。

7、可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、

检测等来确定产品是否确实按需求实现了。只有系统的所有需求是可以被测试的，才能

保证软件始终围绕着用户的需求。如果需求不可验证，则确定其实施是否正确就成为主

观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。

六、需求分析的过程

需求分析是通过建模来整合各种信息，使得人们更好的理解问题，为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案，检查需求当中存在的错误、遗漏、不一致等各种缺陷，并加以修正，最终形成需求规格说明，整个活动构成软件开发生命周期的需求分析阶段。需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有承担风险者都明白其含义，能找出其的错误、遗漏等地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量的需求，这样才能做出实用的项目估算并可以进行设计、构造和测试。

需求分析阶段的工作，可以分为四个方面：问题识别，综合分析，制订规格说明书，评审。

1.问题识别。就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需

求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求，性能需求，环境需求，可靠性需求，安全保密需求，用户界面需求,，资源使用需求，软件成本消耗与开发进度需求，预先估计以后系统可能达到的目标。

2.综合分析。逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的

限制，分析他们是否满足需求，去除不合理部分，增加需要部分，综合成系统的解决方案，给出要开发的系统的详细逻辑模型。

3.制订规格说明书。编制描述需求的文档即软件需求规格说明书，需求分析阶段的成果是

需求规格说明书，向下一阶段提交。

4.评审。对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行

下一阶段的工作，否则需要进行需求分析。

通常，把需求中的一部分用多种形式来描述．如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些混淆，并明确哪些需求是更为重要的。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

1创建数据字典。数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段．数据字典至少应定义客户数据项以确保客户与开发小组使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

2确定需求的优先级别。应用分析方法来确定使用实例、产品特性或单项需求实现的优

先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更．并在那个版本计划中做出需要的变更。

3．分析需求可行性。在允许的威本、性能要求下。分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

4．使用质量功能调配。质量功能调配是一种高级系统技术，它将产品特性、属性与对用户价值联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。质量功能调配将需求分为三类：期望需求，即客户或许并未提及。但如若缺少会让他们感到不满意；普通需求和兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。

5．衡量需求稳定性。记录基本需求的数量和每周或每月的变更数量(添加、修改、删除)。过多的需求变更“是一个报警信号”意味着问题并未真正弄清楚，项目范围并未很好的确定下来或是政策变化较大。

6．绘制系统上下文示意图。这种示意图是用于定义系统与系统外部实体问的界限和接13的简单模型。同时它也明确了通过接口的信息流和物质流。

7．作为功能需求的补充。软件需求规格说明还应包括非功能需求．它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

七、需求变更管理

(一)需求变更概述

1.经验的问题。需求变更的出现主要是因为在项目早期，用户往往不能确切地定

义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据

当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式；或者

要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。

2.意识的问题。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系

统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前

提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不

可避免地一次又一次出现。

3.管理的问题。如果开发团队缺少明确的需求变更控制过程或采用的变更控制机

制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖

延、成本不足、人力紧缺，甚至导致整个项目失败。当然，即使按照需求变更

控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不

同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件

质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。

(二)需求变更管理的最大问题

知道需要做需求变更管理；不知道如何更有效的执行变更控制操作；受CMMI误导，强调文档，走向维护变更数据之路；形成“重记录、轻控制”的不良现象。

(三)解决问题

1.相互协作。开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解

决的问题尽量解决。

2.充分交流。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以

分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提

出需求变更会给整个开发工作带来什么样的冲击和不良后果。

3.安排专职人员负责需求变更管理。有时开发任务较重，开发人员容易陷入开

发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员

负责与用户及时交流。

4.合同约束。需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同

时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况

的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行

变更控制流程。

5.区别对待的原则。随着开发进展，有些用户会不断提出一些在项目组看来确实

无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开

发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如

果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的

新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户

将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，

还要注意控制新需求提出的频率。

6.选用适当的开发模型。采用建立原型的开发模型比较适合需求不明确的开发项

目。

7.加强前期的用户参与力度。诸如，用户参与需求评审。作为需求的提出者，

用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往

往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，

可以有效减少需求变更的发生。

(四)核心思想

1.变更管理是目标是控制变更，而非避免变更

2.控制变更的目标是减少变更的影响，而达成这一目标需要由所有团队协作

3.需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于“尽可能以弹性的设计

来减少变更的影响”

4.建立统一的渠道让客户意识到变更的成本，减少“来路不正”的变更，记录“变更的

工作”

5.采用统一的平台来捕获、管理、控制变更是重要的最佳实践

八、评审需求

1.评审的任务。由多方对软件需求规格说明书进行评审，发现其中的问题，并就其中

的软件需求达成一致

2.评审的目的。

1)软件需求规格说明正确描述了预期的系统行为和特征。

2)从系统需求或其它来源中得到软件需求。

3)需求是完整的和高质量的。

4)所有对需求的看法是一致的。

5)需求为继续进行产品设计、构造和测试提供了足够的基础。

3.需求评审的内容

1)发现软件需求规格说明书中的问题

2)共同认可软件需求

4.评审原则

1)正确性。软件需求是否是用户所需要的。

2)准确性。是否把软件需求描述清楚了。

3)无歧义性。软件需求描述是否会引起不必要的误解和认识上的偏差

4)完全性。是否所有的需求都已经包含了。

5)可验证性。是否有手段来验证需求已经实现了。

6)一致性。软件需求是否会相互矛度。

7)可理解和可修改性。软件需求描述是否简洁、直观，易于修改和维护。

8)可追踪性。软件需求是否易于追踪。

5.软件需求评审结果

软件需求评审应该要有记录有结论，并形成软件需求评审报告。

九、结论

需求工程是就是所有与需求直接相关的活动,它作为软件工程的基本和关键领域，通过需求开发和需求管理两个方面对需求工作进行全面的管理，其在整个项目中的重要性和决定性也越来越突出。需求分析作为整个项目管理中需要重点控制的几个关键节点之一，必须给予足够的重视。需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能，如果不能准确地把握用户的需求意图，必将导致项目的后续工作无法顺利进行。作为一个软件编写者，应该深刻的认识到需求的重要性，应该首先与用户在需求上达成共识，而不能只是盲目的按照用户的意思去编程，否则将会浪费大量的人力物力，还不能够打到项目要求。

参考文献：

1.李师贤;张路玲需求分析常见问题及对策研究[期刊论文]-计算机工程

2002(01)

2.浅谈软件工程中的需求分析.

3.[美]莱芬韦尔．Software requirements management use case approach[M]．

4.(澳)Leszek A.Maciaszek 著;Requirements analysis and system design.

5.梅宏;软件工程.