A001-185-2508-黄奕琛

作业报告

课程名称	软件需求分析与建模	班级	18软5
作业名称	我对需求分析与建模的认识与应有内容建议	教导教师	董瑞生
姓名	黄奕琛	学号	1814080902525	日期	2020.10.04

1.需求问题是当前软件开发面临的主要问题

在 Standish Group的调查中将软件项目分为3种类别

1. 在预计的时间之内，在预算的成本之下完成预期的所有功能，则项目为成功项目(suecess)

2. 已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者实现的功能不全，则项目为问题项目(
   challenged or faulty)。

3. 因无法进行而被中途撤销，或者最终产品无法提交使用，则项目为失败项目(
   failedpaired)。

2.软件的模拟特性

在这些导致需求问题的原因当中，一个最为重要的原因是：未能很好地理解和掌握”应用”型软件的模拟特性以及由此而产生的一系列影响和要求。

软件的模拟特性来源于其知识载体的特性：软件在运行中表现出来的特性、行为应该和应用的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件”模拟”了现实。

例如，在图书管理软件中，如果在张三没有借书的情况下，软件系统产生了一条张三借书的记录，则该软件系统将会被认为是运行不正常和存在缺陷的，原因即在于借书情况的记录和现实中发生的借书事件没有保持一致。在软件和现实保持一致的情况下，人们不再需要为了査找本书而翻遍所有的书架，通过软件系统进行书目查询就可以得到准确的答案。软件的冗余功能问题也从另一个侧面很好地反映了它的模拟特性。在软件开发中，一方面只能完成预期功能的60%~70%，另一方面移交软件中却存在着大量的冗余功能，这些功能用户从来不会使用。人们在讨论冗余功能为软件开发带来额外负担时，却很少有开发人员能够意识到，这些冗余功能往往也是导致用户不满意和软件不被接受的原因之一。正是因为缺乏这种意识，所以软件开发人员才会在开发中持续不断地超出用户的需求添加”出色功能”，进行自我陶醉地为软件”镀金”。设想一个购买汽车的普通用户，如果发现汽车除了正常的功能之外，在方向盘边上还有一些用途不明的其他部件，虽然被告知那些部件可能水远不会被用到而可以置之不理，但作为一名普通的驾驶者，没有会有设计师的那份秦然，不小心触发那些部件可能产生的未知后果会一直紫绕心头，以至于恨能将之消除而后快。

3.软件分类

软件可以被分为3种类别：

1. 面向专业用户的纯工具型软件

专业用户通常以软件为中心开展工作，工具软件是他们的主要手段，因此面向专业用户的纯工具型软件的首要成功标准是要具有功能的复杂性和使用的高效性。功能的复杂可以让专业用户在执行任务时具有更大的发挥空间和回旋余地。使用的高效可以帮助专业用户更快、更好地完成任务。以上两点的实现都要以先进的技术为必要条件。该类软件以创新性为主要关注点技术创新是它们的生存之道。

1. 面向普通用户的纯工具型软件

普通用户利用软件的目的通常仅限于解决一些实际问题，软件仅仅是一种辅助性的手段，因此面向普通用户的纯工具型软件以功能的有用性为首要成功标准，一些过于复杂的功能反而会因其灵活性而丧失一定的实用性，进而受到用户的抵制。普通用户技术能力有限，所以对操作的要求以使用方便为主，在使用方便的前提下追求使用的高效性。实现功能的有用性和使用的方便性，利用常见的可行技术即可，先进技术并非必要条件。有效性是该类软件的主要关注点，能够有效使用即可占有一席之地。

1. 应用型软件

应用型软件在”模拟”现实的基础之上接收用户的请求，协助用户完成任务，它正确工作的

基础是具有”模拟”性。”模拟”性具体是指以下几点：

1. 目的性。软件的目标是直接或间接地满足用户的某些目的或者解决用户的某些问题，软件的功能是据此设立的。

2. 正确性。软件具备的功能能够保证目标的正确实现。

3. 现实可理解性。软件实现其功能的基础、手段和过程是在用户领域内现实可理解的，即软件系统是在理解其现实环境的基础上，通过影响现实的某些环节，或者改变现实各部分的通信方式，最终达成某些目的或者解决某些问题的。

4.需求问题具体原因分析

1. 非技术性和和社会性因素重视不足。

应用型软件的模拟特性使得需求处理具有很突出的特性。相对于软件开发的其他阶段而言，需求处理阶段涉及更多的非技术性和社会性因素，并且其所受的影响也远远高于其他阶段。20世纪90年代之前的需求处理往往更专注于技术处理，而对其中的非技术性和社会性因素重视不足。

1. 传统需求分析方法的缺陷。

传统的需求分析方法，如结构化分析和面向对象分析，都是从设计领域转入分析领域的。虽然它们在设计阶段取得了很大的成功，但它们并不非常适合于需求阶段的技术处理需要，因此它们在需求处理中的应用具有一定的先天缺陷。

1. 软件需求规模的日益扩大。

20世纪90年代之后大量出现的以”企业”为中心的软件反映了软件规模日益扩大的发展趋势，这一方面提高了需求处理中非技术性和社会性因素的影响比重，另一方面也进一步放大了传统技术在需求处理阶段的不适应性。

1. 需求问题的高代价性。

需求处理是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提。如果在需求处理过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错误修复代价较高，需求问题对软件成败的影响较大。统计表明，在需求阶段发生的错误如果到了维护阶段才发现，则在维护阶段进行修复的代价可能高达需求阶段修复代价的100~200倍，这种递增效应也说明了需求问题的高代价性。

5.需求工程的定义

简单来说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。从细节来看，可以定义如下：需求工程是软件工程的一个分支，它关注软件系统所应实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。

6.需求工程的任务

1. 需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制和约束，即要同时说明软件需要”做什么”和”为什么”需要做。

2. 需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试用户手册编写等很多后续软件开发阶段的工作基础。

3. 现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。

7.需求工程的复杂性

1.处理范围广泛

需求工程连接现实世界和计算机世界，所以它首先要理解现实世界，要描述现实世界的运行规律，既要描述物理的实体，又要反映人类活动的特点，而且并不存在一切内容都浮于表面的现实世界，需求工程师需要去研究、去发现，才能得到需要描述的内容；其次它也需要理解计算机系统，要清楚计算机与软件的构建方式，要能判断某一方法的可行性；最后它还需要将现实世界和计算机世界连接起来，让它们之间产生期望的互动效应，以满足用户的需求。

2.涉及诸多参与方

在需求处理的过程中柱往涉及很多参与者，他们来自不同的领域，具有不同的背景、技

层次、关注点、期望值和表达方式等，因此他们之间的交流是非常复杂的，而且他们之间还

产生利益冲突和观念冲突，这使得需求处理过程更为复杂。常见的参与方包括客户、用户

专家、需求工程师、软件开发者和系统维护者等。

3.处理内容多样

需求工程处理的知识内容多种多样，既有用户的功能需求和非功能需求，又有软件将来环境及其约束。

4.处理活动互相交织

需求工程包括需求获取、需求分析、需求规格说明和需求验证等4个需求开发活动，它

行接、顺序处理。

5，处理结果要求苛刻

作为需求处理结果的需求规格说明要满足正确性、完整性和一致性等苛刻要求。因为如求规格说明中含有某些不足或错误，就可能会为后续的开发活动或最终的软件产品质量带来灾难性的后果。

8.需求的定义

需求一直是软件工程中较为模糊的词汇之一。提起需求( requirement)，不同背景的人

(用户、开发者)会有不同的看法，因此需求是需求工程中一个非常难以准确定义和解释的

概念。

在各种不同的定义中，本书更倾向于使用IEEE的需求定义：

1. 用户为了解决问题或达到某些目标所需要的条件或能力；

2. 系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力；

3. 对①或②中的一个条件或一种能力的一种文档化表述。

IEEE的定义中同时包括了用户的观点(第一种条件和能力)和开发者的观点(第二种条件和能力)，它强调了”需求”的两个不可分割的方面：需求是以用户为中心的，是与问题相联系的需求要被清晰、明确地写在文档上。

9.满足需求就是解决问题

需求源于问题，要准确理解需求，就必须明确它与问题的关系。[ Jackson1995a， Jackson

1997]认为当现实的状况与人们期望的状况产生差距时，就产生了问题，问题中的差距要么是某些事件事物的状态不理想，要么是某些事情的发生过程不理想。要解决问题，就需要改变这些事件、事物的状态，或者改变其状态变化的演进顺序，使其达到期望的状态和理想的演进顺序。

人们开发软件系统的目的就是希望用它作为解决方案来软件解决方案解决问题，使得现实改善到期望的状况。解决问题、改善现实、满足用户期望的条件与能力就是需求。

例如，一个利润率仅为2%的企业希望通过开发和应用一个软件系统，能够将利润率提高到5%。那么2%的利润率就是现实，”利润率低”(低了3个百分点)就是企业面临的问题，利润率

为5%是期望的状况，将利润率提高3个百分点或者将利润率提高到5%就是需求。

1. 问题域

   问题在现实世界与软件系统的互动中得到解决。

   1. 解系统

      软件系统通过影响问題域帮助人们解决问题，所以[ Jackson199b]称之为解系统(
      solutionystem)。在解系统中软件起着主要的作用，它是软件解决方案在通用计算机上的实现。

   2. 问题域与需求

      虽然解决问题和满足需求的手段是引入解系统，但问題和需求都来自于用户，用户关注的是问题域，所以需求是用户对问题域中的实体状态或事件的期望描述，例如有需求描述R1、R2

      如下。

      R1：一且书籍被借出，则在归还之前，系统应该不允许它被再次借阅。

      R2：如果超过30天的归还期限，系统在书籍归还时应该进行超期处罚。

      需求并不针对解系统，它的描述应该尽可能使用问题域的语言，尽量不涉及解系统的专业名词。例如下述需求描述R3、R4中就含有”数据仓库技术”“客户关系管理系统”“按钮”“界面”等多个计算机词汇是不恰当的。相比之下，R5、R6的描述更能被用户所接受。

      R3：系统应该使用数据仓库技术建立客户关系管理系统CRM，以扩大5%的销售额。

      R4：如果用户在销售列表信息界面选中一个商品，点击”查看”按钮，系统将显示商品的详细信息界面。

      R5：应用系统12个月后，销售额应该扩大5%。

      R6：在用户请求查看具体商品时，系统应该显示该商品的详细信息，包括条码、名称、价格和需求开发的最原始出发点就是用户需求，或者需求的源头ー一问题。

   3. 解系统与需求规格说明

      解系统的核心是软件解决方案和解决方案在通用计算机上的实现。虽然解决方案及其实现都关注于软件系统本身，但相互间也有所不同。解决方案描述的是软件系统与问题域交互的过程，侧重于软件系统中与外界交互的部分。实现部分则主要是软件内部的组成元素、结构关系、物理实现等软件系统的构造要素。需求工程所关心的仅仅是解决方案，不涉及软件的实现细节。

问题解决的基础——模拟与共享现象

处于间题域之外的解系统之所以能解决问题域中的问题，是因为问題域与解系统之间存在有效的互动，并在互动中互相影响。而问题域与解系统能够形成互动的基础是解系统部分模拟了问题域，
Jackson1995b]将这种模拟性称为共享现象( share phenomenon)。

初看上去，问题域与解系统原本是两个相互独立的系统，相互独立性使得它们之间难以互相影响。但是一且认识到解系统对问题域的模拟性，它们就会变得紧密联系，互相影响也会自然形成。

简单地讲，模拟是指其中一方仿制另一方的信息。解系统对问题域的模拟则更加复杂一些，它们之间的模拟性带有交互性：一方面，解系统会在自身中保持一份与问题域现象一致的信息，并随着问题域现象的变化而变化；另一方面，问题域会期待在解系统中看到一致的信息，并据此展开自己的行为。

例如，一个图书馆中有图书、借书人、借书规则等现实信息，图书馆管理系统中就会建立相应的数据表(
Table-Book、 Table- Borrower、
Table-Rule)，这个是简单的仿制。如果图书馆中有一本书《软件需求工程》因为磨损而报废了，那么Book表中就需要删除”Name=《软件需求工程》”的数据行。如果在表
Borrower中有一个数据行是”Name=张三， Borrowed
Num=5”，那么管理员就会认为张三已经借走了5本书。如果张三实际上只借走了3本书，那么管理员就会认为管理系统出了错误，不能正常工作。这种带有交互性的模拟就是解系统与问題域能够互相影响的原因和途径。

解系统与问题域模拟的交互性其实是由人在意识中强制建立的。如果用户并未将现实发生的情况实时地输人到软件系统中，或者用户在工作时完全忽视软件系统提供的输出，那么软件系统就会失去影响和改变现实的能力，就不可能解决现实间题或者满足现实需求。这充分说明软件系统必须得到用户的认可，否则就会失去价值。

共享现象就是解系统所模拟的问题域部分，该部分在两个系统中同时存在。除了共享现象之外，问题域还有一些没有被解系统模拟的知识，因为现实世界非常复杂，不可能也没必要在解系统中完全重现。例如，一本图书的质地，每页纸是否损坏、是否被涂抹等信息不需要在软件系统中建模。解系统会从特定的角度对问题域知识进行抽象和简化，并模拟简化后的知识。

除了包含共享现象的知识模型之外，解系统也有一些并非来自于现实模拟的特征，例如数据库管理系统的选择、模型的范式化、索引的建立等，这些因素并不对应于任何问题域知识，却是解系统必不可少的部分。

问题解决的方法一一直接与间接

因为模拟后的知识一一共享现象，是解系统的一部分，所以解系统可以对其施加操作，适当改变这些知识。知识的改变会通过交互性传递给问题域，问题域在会接受改变的基础上继续规律性的运作，使问题得以解决。例如，要用软件跟踪记录用户在银行的存款情况，可以将用户在银行的账户建模为表
Account(ID，Name，
Balance)，如果用户张三在现实世界中存了1000元钱，那么软件系统就给”Name='张三”“的
Account记录的
Balance增加1000。当其他银行职员看到软件系统中的这条记录时，也会接受张三存了1000元这个现实。再如，仓储用户想降低库存成本，软件系统可以将出入库信息建模为表
Import和
Export，然后软件系统通过计算这两个表过去一段时间的值，给出将来一段时间会有多少仓储差额的预测值，仓储人员就会接受该预测值以保持最佳库存，由此自然能降低库存成本。

模拟并操纵共享现象是软件系统满足需求最直接的方法，但有些情况下软件系统也会使用间接的方法解决间题：软件系统操纵共享现象影响问题域的一部分，然后利用问题域内在的规律自动影响另一部分。例如，图书管理员希望能够督促那些超期的借书者尽快归还图书，直接的解决方式是软件系统将借书者的联系方式建模为表
Contaet，并自动使用
Contact的数据完成督促告知(如发送邮件)。但是如果软件系统中没有存儲借书者的联系方式，即软件系统的共享知识中没有解决问题所需要的信息，就只能通过间接的方式来满足需求了，这时软件系统可以将超期者的名单告知图书管理员，然后由图书管理员逐一打电话督促归还。

考虑问题解决和需求满足的方法时，成本是重要的因素。如果成本能够接受，就尽量使用直接的方式解决，如果成本太高，就可以折中使用间接方式解决。间接解决方式也提需求工程师，考虑到间题域内的规律性，在设计解决方案时要防止解系统的引人在问题域中引发未预见的连镜反应，这种反应可能会使解决方案无法达到预期目的，甚至造成不良的负面效应。防止未预见的连锁反应尤其要关注间接特性。间接特性不会与解系统直接交互，不会受到解系统的直接影响，但是却可能因为连反应面受到影响。例如在一个车辆调度系统中，由调度员根据用车的请求统一安排车辆的使用，安排过程中车辆的驾驶员并不和调度系统进行直接的交互，但在车辆和驾驶员固定配对的情况下，对车辆的调度就决定了驾驶员的工作安排，因此，车辆调度的方法自然会影响驾驶员的工作情况，如果他们的相关因素没有被认真对待，就可能导致不良后果，致使在驾驶员请假时进行了车辆分配或者驾驶员的工作量分配不均等。

问题解决方案一一需求规格说明

因为解系统解决问题的方法是改变共享知识，影响问题域的运行，进而满足用户的需求。所以需求规格说明主要包括两部分：对共享现象(模型)的描述和对系统对共享现象所施加的操作的描述。这也是软件系统中最为核心的两个部分：数据与功能。

问题解决的困难性

如果拥有描述明确的问题域特性E和定义良好的系统行为S，就可以很容易地发现将系统应用到问题域后会产生的效果。这种效果如果符合预期的需求R，那么系统就是满足人们需要的系统。所以需求工程的目的就是根据E，构建S，使得E和S的联合作用效果符合需求R：E，S|→R。

从这里可以发现需求工程的困难之处：

1. 不存在描述明确的E。

2. 不存在确定的针对S的评估标准R。

3. 根据问题域特性和系统行为推测系统应用效果是简单的推理过程，即E，S|→R是简单的，但根据问题域特性和期望的系统应用效果构建系统行为的过程是困难的，E，R=S是个创造性的过程。

这些困难也恰好说明了需求工程的主要工作：

1. 进行需求开发，确定用户的期望效果R

2. 研究问题背景，描述问题域特性E；

3. 构建解系统，描述解系统行为s，使得E，S|→R。

10.需求和问题有层次性

需求是问题解决的期望，问题是可大可小的，期望自然也是可大可小的。例如，一个超市收

员的间题可以是”“工作效率太低(大)”，也可以是”商品销售过程太繁琐(中)”，还可以是”销售时计算总价不方便(小)”。

问题和期望粒度不同的现象被称为需求的不同抽象层次。需求最为常见的抽象层次有3层：①业务需求(
business requirement)，针对整个业务的期望，如R7。2用户需求( user
requirement)，针对具体任务的期望，如R8。3③系统级需求( system
requirement)，针对用户与系统一次交互的期望，如R9。

R7：在系统使用3个月后，销售人员进行销售处理的工作效率应该提高20%。

R8：收银员可以使用系统完成销售处理。

R9：在收银员请求计算已输入商品的总价时，系统应根据规则 Rulel计算总价并显示。

11.需求的分类与表述

分类的目的是为了区别对待，否则分类就失去了意义。需求分类是为了将需求划分为需要区别对待的不同类型，每种类型会被文档化到不同的部分，服务于不同的读者，不同的目的。

人们在软件开发中谈论”需求”时，通常是指软件需求，本书中使用”需求”一词时也主要用来指称软件需求。但有时”需求”一词也会被用来指称其他类型的需求。为了能够更清晰地理解后面的需求分类，这里还是要区分一下不同类型的”需求”指称。

“需求”一词可能被用来指称针对项目的期望，如下述的R10、R11被称为项目需求。项目需求针对的对象是作为项日核心的计划，包括项目的成本、资源、时间和进度等。

R10：项目的成本要控制在60万元人民币以下

R11：项目要在6个月内完成

“需求”一词可能被用来指称针对开发过程的期望，如下述的2-8”求”一词的常见含义及其关系R12、R13被称为过程需求。过程需求针对的对象是软件开发过程，包括开发人员、工具和方法等。

R12：在开发中，开发者要提交软件需求规格说明文档、设计描述文档和测试报告。

R13：项目要使用持续集成方法进行开发。

要解决一个问题，人们需要将软件、硬件和人力资源联合起来，这种联合的形式被称为系统工程，包括软件工程、硬件工程和人力资源管理。虽然在系统工程中软件可能处于最为重要的地位，但是硬件与人力也不可忽视。因此，人们在表述需求时，除了会表达对软件的期望之外，也可能会表达对硬件、人力等因素的期望。这样，所有针对系统工程的需求都被称为系统级需求，其中与硬件相关的需求被称为硬件需求(如R14)，与软件相关的需求被称为软件需求，与人力资源相关的需求以及软件、硬件、人力之间协同的需求被称为其他需求(如R15)。

R14：系统要购买专用服务器，其规格不低于……

R15：系统投入使用时，需要对用户进行为期一周的集中培训。

在软件开发项目中还有一个不得不强调的”需求”形式是”不切实际的期望”。严格来说，不切实际的期望不属于需求，因为它虽然表达了一种期望，但却是根本无法实现的期望。常见的不切实际期望有3种类型：技术上不可行，如R16；在有限的资源条件下不可行，如R17(财务分析系统非常复杂，比整个销售系统都要复杂)；超出了软件所能影响的问题域范围，如R18(因为软件系统根本无法限制收银员的行为，正确的形式应该如R19所示)。

R16：系统要分析会员的购买记录，预测该会员将来一周和一个月内会购买的商品

R17：系统要能够对每月的出人库以及销售行为进行标准的财务分析

R18：在使用系统时，收银员必须要在2个小时内完成一个销售处理的所有操作。

R19：如果一个销售处理任务在2个小时内没有完成，系统要撤销该任务的所有已执行操作。

从严格的意义上来说，项目需求与过程需求都不能算是需求，因为它们并不是用户对问题解决的期望，而是用户对软件开发活动本身的要求。硬件需求与其他需求也不属于用户对问题解决的期望，而是为了让软件能够成功运营而需要适应的环境与活动。但是在文档化需求的材料中，经常会出现项目需求、过程需求、硬件需求和其他需求，因为它们对需求工程师及开发者正确理解软件需求甚至整个产品具有极其重要和不可缺少的作用，所以它们经常出现在需求文档中（一般位于非主体部分，如需求文档的开头或末尾部分），供项目管理者和系统工程师阅读。

严格意义上的软件需求分类

从严格意义上讲，软件需求是直接或间接关系到软件系统功能的期望。根据不同的分类标准，可以将需求分成不同的种类。在各种需求分类中最常见的是[IEE.1998]的分类，[IEEE

1998]将需求分成下列几个类别。

1. 功能需求( funetional
   requirement)：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。

2. 性能需求( performanee
   requirement)：系统整体或其组成部分应该拥有的性能特征，如CPU使用率和内存使用率等。

3. 质量属性( quality
   attribute)：系统完成工作的质量，即系统需要在一个”好的程度”上实现功能需求，如可靠性程度和可维护性程度等。

4. 对外接口( extemal
   interface)：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等。

5. 约東( constraint)：进行系统构造时需要遵守的约東，如编程语言和硬件设施等。

除了上述5种明确的软件需求类别之外，(IEE1998]还指出项目中也可能会出现逻辑数据需求等其他特殊类型的需求。

除功能需求之外的其他4种类别需求又被统称为非功能需求(non-funetional
requirement)。在非功能需求中质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指质量属性。

12.优秀需求的特性

①完备性

优秀的需求是完备(
complete)的，它不需要做更多的扩展就可以充分说明用户需要的系统功能。完备性的判断标准是：需求是否描述了开发人员设计和实现这项功能所需的所有信息。只有完备的需求在开发中才可能被独立出来，单独对待。在需求开发过程中，对于不清晰的信息可以标记为TBD(
To Be Determined，待确定)，但在需求开发结東之前，所有的TBD都必须被解决。

②正确性

每一项需求都必须正确描述所需要的系统功能，要真实反映用户的意图，所以需求的正确性又常被称为真实性(real)。需求的正确性只有提出需求的人才能加以判断，所以需求在传递给开发人员之前，必须请需求的提出者予以确认。

③可行性

需求必须能够在系统及其运行环境的已知条件和约東下实现。用户无法判断需求的技术可行性，所以需求的可行性是由开发人员进行检查的。在检查的过程中，开发人员可能需要进行一定的分析和研究，而不是单纯地凭借经验和直觉。对于难以判断的需求，必要时要通过开发原型来加以验证

④必需性

每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之后，系统仍然能够以同样的效果解决用户的问题，那么它就不值得在开发的过程中消耗额外的资源。

⑤无歧义

需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应该有而且只能有一种解释，即需求无歧义。为了让需求可理解，一般倾向于以用户的语言描述需求，而用户的语言往往含有大量容易导致歧义的因素，因此在保证需求描述的无歧义时要格外注意需求描述中的词汇选择，通常在需求开发中要定义一个可以共同理解的词汇表(
glossary)，然后再在其基础上进行需求的描述。

⑥可验证

需求应该是可验证的，也就是说通过分析、检查、模拟或测试等方法能够判断需求是否被满足。如果需求不可验证，就无法判断完成的系统是否满足了该需求，开发人员也无法去选择一个能够实现该需求的方法。通常，不可验证的需求往往是因为描述模桐或者过于抽象，所以在进行需求的描述时要让需求具体化，小心形容词和副词的使用，避免程度词的使用。

13.需求获取

需求获取是从人、文档或环境中获取需求的过程。获取过程并不是简单地将定义良好的需求从人、文档或环境中直接转移到获取的结果文档上，需求工程师必须要利用各种方法和技术来”发现”需求。需求开发的过程包含有学习和认知的过程，而学习和认知的过程是递进的，即学习一点，增加一些认知，然后在新的认知的基础上继续学习。因此需求获取和需求分析是交织在一起的需求工程师需要获取一些信息，随即进行分析和整理，理解、认知到一定程度后再确定要进一步获取的内容。

在需求获取中，需求工程师通常需要执行的任务包括以下几方面：

1. 收集背景资料。

2. 获取问题与目标，定义项目前景与范围。

3. 识别涉众，选择信息来源。

4. 选择获取方法，执行获取，获取功能与非功能需求。

5. 记录获取结果。

14.需求分析

需求分析的主要工作是通过建模来整合各种信息，以使人们更好地理解问题。同时，需求分析工作还会为问题定义一个需求集合，这个集合能够为问题界定一个有效的解决方案。需求分析还需要检查需求中存在的错误、遗漏和不一致等各种缺陷，并加以修正需求分析活动最后会产生一个需求的基线集，它指定了系统(或当前版本的系统)开发需要完成的任务。在资源受限的情况下，这个基线集往往只是用户所要求功能的一个子集，而且需求工程师和用户必须就该子集的取舍达成一致。需求基线集中的需求要具有优秀需求的特性，尤其是一些不一致和冲突的现象必须得到妥善的解决。

在需求分析阶段，需求工程师主要的任务包括以下几方面：

1. 背景分析

2. 问题分析，目标分析，业务分析，确定系统边界

3. 软件需求建模

4. 细化需求

5. 确定优先级

6. 需求协商

15.需求规格说明

获取的需求需要被编写成文档。业务需求被写入项目前景和范围文档，用户需求被写入用户需求文档(或用例文档)，系统级需求被写入需求规格说明。编写文档的主要目的是在系统涉众之间交流需求信息，因此编写的文档应该具有一定的质量。这些质量特性有些来自于文档内所有独立需求的质量之和，有些来自于编写者的写作技巧，最重要的质量要求是简洁、精确、一致和易于理解。

16.需求验证

为了尽可能地不给设计、实现、测试等后续开发活动带来不必要的影响，需求规格说明文档至少要满足下面几个标准：

• 文档内每条需求都正确、准确地反映了用户的意图。

• 文档记录的需求集在整体上具有完整性和一致性。

• 文档的组织方式和需求的书写方式具有可读性和可修改性。

为了保证以上标准的满足，需求规格说明文档(尤其是最终定稿的文档)在传递给相关人员之前要进行严格的验证。

17.需求管理

在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要围绕需求开展工作。需求的影响力贯穿于整个软件的产品生命周期，而不是单纯的需求开发阶段。所以，在需求开发结束之后，还需要有一种力量保证需求作用的持续、稳定和有效发挥，需求管理就是这样的一个管理活动。

而且，在需求开发建立需求基线之后，还需要在设计、实现等后续活动中处理来自客户、管理层、营销部门及其他涉众群体的变更请求。需求管理会进行变更控制，纳入和实现合理的变更请求，拒绝不合理的变更请求，控制变更的成本和影响范围。

在企业界的实践中，需求变更被认为是导致项目失败的两个主要原因之一。所以需求管理在项目的各项管理活动中具有非常重要的地位，CMM(
Capability Maturity Model
Integration，软件能力成熟度模型集成)就将其作为所有二级成熟度企业都应该具备的一个关健过程域。

目前，有很多的需求管理工具可以帮助进行需求管理工作，它们可以为每项需求定义属性，跟踪需求的状态，并在需求和其他系统开发产品间建立跟踪体系。

18.实践方法

通过分析需求工程过程可以了解需求工程活动粗略的组织形式和高层视图，但是要进行些具体的工作还需要更多的活动细节。这些括动细节是通过应用实践方法来实现的。

在工程领域中，如果能够建立比较完整的知识体系，那么就可以在知识体系的指导下进行规律性和系统化的生产。相反，在完全没有形成知识认知的全新工程领域中，就只能纯粹依鞭生产者的个人才智来进行工作。也有介于上述两种情况之间的工程领域：它们还没有形成完整的知识体系，所以无法实现大工业化的生产方式；同时这些工程领域又经过了相当时间的探索，从生产者大量的个人行为中总结出了一些有效的工作方式和行为方法。这些有效的工作方式和行为方法虽然比较琐碎和孤立，和知识体系的要求还有很大的距离，但是它们却能够很好地帮助人们更快更好地进行工程实践，所以被称为实践方法(
praetice；又被称为原则， principle)。

实践方法是人们能够从陌生的知识领域中得到的最早的知识片段和知识形式。在它们逐渐累积和丰富之后，人们就会从它们当中抽象出更加普遍的规律性知识，建立知识体系。

软件工程是一个”年轻”的工程领域，还没有形成一个完整的知识体系一一有些部分完整有些部分欠缺。在软件工程的各个子活动中，有些领域已经形成了比较完整的知识体系，如程序的编码和编译方法；也有一些领域还没有形成需要的知识体系，需要依赖大量的实践方法来指导工作的进行，如设计活动和需求工程活动。

因此，除了能够在宏观上指导需求工程过程进行的过程模型之外，需求工程的成功应用还需要掌握很多能够指导工作细节的实践方法。

19.需求开发过程与软件工程过程的相互影响

需求的好坏对后续软件开发有着极其重要的影响”这一观念已经是开发者的共识了，近些年的实践研究进一步发现：不仅仅是最终制品一一需求，整个需求开发过程都会对其后续的软件开发过程产生重要影响。

[Verner2005]发现，相比于需求方法本身的好坏，需求方法与软件开发方法的适配性更会影响项目的成败。这也就是说，需求开发方法与软件开发方法是否适配，比结果需求的好坏更能影响项目的成败。

需求开发过程之所以对后续软件开发过程有重要影响，并不仅仅是因为它的结果制品一一需求一一是后续开发过程的工作基础，更要认识到需求开发过程中还会产生很多正性信息(如前景与范围定义、涉众描述、分析模型、需求特征描述等)。如果单纯从产生软件需求规格这个任务来看，这些正性信息都是不必要的，但它们对后续软件开发过程的影响则是明显的。也就是说，为了让整个软件开发闭队的工作能够更加顺利，需求工程师需要完成很多看上去似乎不属于其本职工作的任务，这就是”团队”的含义。

应有内容建议

建议多上课时多实操。