软件需求工程学习笔记（四）

1. 需求基本概念

       IEEE 610.12-1990标准采用的Dorfman和Thayer的需求定义为：（1）用户解决某个问题或者达到某个目标所需要的条件或能力；（2）一个系统或系统组件为了实现某个契约、标准、规格说明或其他需要遵循的文件而必须满足的条件或拥有的能力；（3）前两项中所描述的条件或能力的文档化表示。

       Jones 1994年给出的定义是“用户所需要的并能触发一个程序或系统开发工作的说明”。Alan Davis 1993年给出的定义是：“从系统外部能发现系统所具有的满足于用户的特点、功能、属性等”。Sawyer 1997年给出的定义是“需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是开发过程中对系统的约束”。Suzanne和James给出的定义是：需求是产品支持其拥有者的业务所必需完成的事，或让拥有者接收并感兴趣所必须具备的品质。需求之所以存在，要么是因为该类型的产品要求某些功能或品质，要么因为客户希望该需求成为交付的产品的一部分。杨巨龙给出的定义是：（1）站在顶层和全局的角度从问题和目标开始全面细致地对业务进行分析和描述；（2）在业务分析的基础上将信息系统的宏观设计也纳入到分析中，并描述出业务与信息系统的关系；（3）用户解决问题或达到目标所需的条件或权能；（4）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能；（5）一种反映上面4部分所描述的条件或权能的文档说明。张维明等给出的定义是：需求是一个对用户意图不断进行揭示和判断的过程，其目的在于细化，精化产品的作用范围，确定拟开发系统的功能和性能、约束、环境等。需求应是问题信息和系统行为、特性、设计及制造约束的描述的集合。潘加宇对需求的描述是：需求聚焦于待开发系统的边界，详细描述系统要卖得出去必须具有的表现，即功能和性能。此外，还有这样的一些定义：需求是人的一种主观心理状态，是人们为了延续生命和发展自身，并以一定方式适应生存环境而产生的对客观事物的要求和欲望。需求是人们对事物的期望。需求是人们对系统的主观期望，真正的需求存在于人们的脑海中，任何文档形式的需求仅仅是一个模型、一种叙述或描述。涉众通过这种描述能够对系统取得一致的理解。

       IEEE公布的定义包括从用户角度（系统的外部行为）和开发者角度（一些内部特性）来阐述需求。从用户角度来说，需求就是“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。它强调的是产品和何种形式，而并非产品是怎样设计、构造的。从开发者角度来说，需求就是“指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束”。Jones 1994、Alan Davis 1993 和Sawyer 1997提出的需求定义是从系统角度来看的。这些不同形式的定义分别从用户或系统的角度对“需求”进行了描述，定义涵盖了系统的外部条件和内部特征，以及用户、系统、需求之间的联系。这些定义分别从不同领域分析需求，但是其核心内容是“系统应满足的外部条件或内部具备的功能”。实际上，没有一个清晰、毫无二义性的“需求”术语存在，所谓的“需求”，是人们对系统的一种主观期望，真正的“需求”存在于人们的脑海中。没有绝对的“需求”，需求总是从一定的视角描述。需求是用户（人或系统）为解决问题或达成目标所需要的特性或条件。

2.市场需求、产品需求和组件需求

       在具体的软件项目中，往往会从市场需求、产品需求和组件需求这三种视角观察软件需求。市场需求是从客户的视角描述的对一个产品的需求。它用客户或用户的语言描述产品的用途和体验。它描述为什么要实现这个项目。产品需求是从方案实现的角度描述对一个产品的需求。产品需求描述不同用户可以用这个产品做什么，市场需求和客户期望怎样在这个产品中实现。它以产品的语言描述特性，定义方案域和优先级。组件需求是从实现和后期方案的角度描述的对产品组件的需求，描述怎样通过组件实现产品需求。组件需求是产品需求或系统的递归式优化。这三种视角在方案优化和抽象过程中产生。市场需求是在需求规格说明书中描述的，许多项目是对现有产品的变更。市场需求也描述这些变更，而不总是描述从零开始的项目或产品的需求。确定变更首先要对目标用户群和目标细分市场进行分析，准确把握它们的需要和用途。我们经常实现一些看上去很有趣的功能或变更，但它们的市场太小。所以，要从经济的角度为它们设定合适的优先级。市场需求是从利益相关者的不同视角开发可行的业务需求，产品需求是从不同用户的角度看的。产品需求和组件需求是互为条件的，这两种视角不是互斥的，而是互相依赖的。这三种视角依赖于方案框架。

3.软件需求产品的特性

       软件需求的特性是说明软件需求内容和形式上应具有的属性。软件需求在内容上应具有完整性、正确性、可行性、第一性、前置性、必要性、无二义性、可靠验证性等特性；软件需求在形式上应具有规则性、一致性可修改性、可追踪性等特性。完整性是指每一个软件需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的定量信息。正确性是指软件需求中的每一项需求都必须准确地描述其开发的功能。第一性是指业务分析工作是软件需求第一重要的工作。前置性是说在软件需求中应将信息系统的体系架构设计、数据库设计、安全设计等设计工作前移到软件需求中，进行初步的宏观设计和顶层设计。这么做的目的是为了避免信息孤岛和重复建设的问题。可行性是说软件需求中的每一项需求都是要在已知系统和环境的月三种全部可以实现。必要性是说软件需求的每一项需求都应把客户的真正所需要的和最终系统所需遵从的标准记录下来。等级性是说要对软件需求进行优先级排序。无二义性是说对需求文档中重复出现的名称上相同的词汇只能有一个明确统一的解释。可验证性是说，对于每一条需求，都应该有可测量的验收标准。规则性是说软件需求内容应按照格式化文档进行填写。一致性是说一个需求和另一个需求、一个文档和另一个文档中不能存在同名不同义的矛盾。可修改性是指对需求分析文档进行修改时应对每一需求变更进行历史记录。可追踪性是指应该能在每项软件需求与它的根源、设计元素、源代码、测试用例之间建立链接关系。以上特性是良好需求所应有的必要属性。不良定义的需求会导致软件项目的延期或取消。

       第三方机构Standish Group发布的1994年度CHAOS Report报告中给出了软件项目成败因素分析的报表。从表中数据可以看出：在项目十大成功保证中有3个是直接与需求相关的，累计权重达到37.1%；而十大败因中与需求直接相关的有5个，累计权重高达51.6%，需求问题对项目影响程度之高可见一斑。Ebert等人的最新研究结果显示，大多数软件项目的取消是因为没有足够清楚的需求和没有很好的控制变更，在失败的项目中，和不良需求相关联的典型问题需求包括：（1）隐含的需求；（2）缺少的需求；（3）后期才明确的需求；（4）从一开始就有错误或不完整的需求基线；（5）肤浅和有歧义的需求；（6）不确定和不明确的需求；（7）不良的变更管理；（8）对于基线和变更缺少文档；（9）员工转向新领域等。

4.需求工程的产生与发展

       在20世纪60年代计算机发展的初期，相对于硬件的通用性来说，软件是为每个具体的应用而专门设计的。由于软件规模普遍较小，程序的编写者和使用者往往是相同的。在这种个体化的软件环境中，软件的设计通常是在人们的头脑中进行的一个隐含的过程，除了程序清单外，没有保留其他的文档资料。

       随着计算机系统的迅速发展，在20实际60年代中期到70年代中期，出现了制造软件的“软件作坊”，形成了广泛使用的软件产品。各种“软件作坊”沿用早期形成的个体化软件开发方法。随着计算机应用的普及，软件数量急剧膨胀，程序的个性化特征导致了一系列的问题，出现了所谓的“软件危机”。软件危机的出现推动了软件工程概念的形成，人们借鉴传统工业的成功做法，通过工程化的方法来开发软件。软件工程意味着在软件开发的过程中引入软件生命周期的思想和结构化的软件开发方法，增强软件开发过程中的管理机制，保障软件开发技术的严格落实。

       在软件开发的过程，最初要做的工作是问题定义，也就是确定要解决的问题是什么；然后进行可行性研究，决定该问题是否存在一个可行的解决办法；接下来进行需求分析，也就是深入、具体地了解用户的要求，在所要开发的系统必须做什么的问题上和用户取得完全一致。经过上述软件定义时期的准备工作才能进入软件开发时期。

       和“软件危机”出现的原因类似，由于缺乏需求开发经验的积累，需求开发的过程没有统一的、公认的方法论和规范指导，缺乏有力的工具支持，做好充分验证等原因，导致后续的软件开发阶段没有切实可行的依据，软件质量得不到保证。因此，人们借鉴软件危机的解决思路，提出了需求工程的设想，即按照工程化的原则和方法来开发、维护需求，提高需求质量和开发效率。在20世纪80年代中期形成了软件工程的子领域——需求工程。

       需求工程涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。此外，它还涉及这些因素和系统精确规格说明以及系统进化之间的关系，并提供现实需要和软件能力之间的桥梁。进入20世纪90年代以来，需求工程成为研究的热点之一。需求工程技术的应用范围不断扩大，一般的信息系统建设、复杂系统分析等都开始将需求分析作为系统开发的重要阶段。与此同时，关于需求工程技术的研究也逐渐发展起来。从1993年起每两年举办一次需求工程国际研讨会（ISRE），自1994年起每两年举办一次需求工程国际会议（ICRE），在1996年Springer-Verlag发行了一本新的刊物Requirements Engineering。与此同时，一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR等。

5.需求工程的定义

      德国学者Ebert对需求工程给出的定义是：需求工程是系统性地、规范地进行需求获取、编写、分析、协商、核实和管理，使期望和目标在一个产品中实现。

      这个定义的内涵是：（1）需求工程是一个工学学科，它是系统工程和软件工程的交叉学科，它的方法和技术来源于多个学科领域。（2）需求工程的生命周期伴随产品的生命周期。需求工程不仅发生在新产品的开发过程中，也发生在对已有产品的改造过程中。（3）需求工程与项目密切相关，需求只存在于开发这个需求的项目的上下文中。（4）需求工程作为规范也是项目管理规范的一部分，它优先遵循项目管理的规范。需求工程的目标不是编写完美的需求，而是作为功能在一个产品或方案中具体应用。（5）需求工程是提出问题并解答问题的过程。它提出并解答软件系统的目标和如何达标的问题。

       德国学者Phol提出了将需求工程划分为3个维度的观点。Phol认为需求工程具有3个维度，它们是内容维度、共识维度和文档化维度。内容维度被用来理解所获取的系统需求。在需求工程过程开始时，除了系统愿景，仅有少量系统需求是已知的，而需求工程过程结束时，需求工程师已理解了所有的需求。共识维度与相关涉众就已知需求的理解取得共识的程度有关。文档化维度采用各种文档化或规格说明的格式对系统需求进行文档化和规约描述。文档化维度意味着将需求活动中抽取的以非正式的方式记录的信息进行重新的整理和描述。由此导出的需求工程的基本目标定义为：需求工程是一个协作式的、不断迭代以及增量的过程，旨在确保：（1）所有相关的需求都在所需要的细节层次上得到了清晰的了解和理解；（2）在相关涉众间建立起对系统需求的充分共识；（3）所有需求都依照相关的文档化/规约格式和规范进行了文档化和规约描述。

6.需求工程的研究实例

       如上文所述，需求工程描述软件工程和系统工程范围内的规范，需求工程学科的准则是来自实践的规范性准则。同时，需求的不确定性也使需求工程作为规范受到强烈的不确定性的影响，许多常规的工作也充满了探索性的因素。正如Ebert所说，需求工程没有封闭的理论，它的法则是经验性质的。基于这个事实，有必要对现有的需求工程理论进行全面的学习和研究，为后续的研究提供符合实际的信息资源材料。

       下面将介绍德国学者Pho提出的需求工程框架，中国学者张维明等人的提出的军事信息系统需求框架，英国学者Robertson夫妇的Volere需求过程，以及中国学者徐峰提出的SERU需求过程框架和杨巨龙提出的基于信息资源规划的需求工程。

      6.1 Phol需求工程框架

       在Phol需求工程框架中，需求工程的问题域被划分为5类对象，它们分别是：系统上下文、需求工程的核心活动、需求制品、需求确认和需求管理。

       系统上下文是系统所处的环境中与定义、理解和解释系统需求相关的那些部分。系统上下文由4个上下文刻面组成：主体刻面、使用刻面、IT系统刻面、开发刻面。

       主体刻面包含了系统上下文中与系统相关的对象和事件。使用刻面包含了与人或其他系统对本系统使用相关的所有方面。IT系统刻面由运行与技术环境的所有方面组成，包括那些定义了如何使用各种技术与运行环境的约束或指南的仿真与策略。所有这些技术和运行环境以及由它们所导致的各种约束影响着系统的需求定义。开发刻面包含了与系统开发过程相关的上下文方面，包括过程准则与约束等确保软件系统质量的手段或技术。

       目标、场景和面向方案的需求是需求工程中的三种需求制品。

       目标是关于系统的目的、属性或者使用的意图。每一个需求工程都开始于一个致力于改变当前状态的目标。目标导向是需求工程成功的关键。系统愿景是系统高层目标的定义。其他所有目标都是对系统愿景的精化。目标模型适合用来显示记录不同涉众的期望及目标之间的依赖关系。

       场景记录了满足或不满足某些目标的一组系统交互序列。场景描述了一个目标（或者一组目标）被满足或者未被满足的一个具体实例。它提供了一个或多个目标的具体细节。一个场景通常定义了一系列为满足目标而执行的交互步骤，并将这些交互步骤与系统上下文相联系。场景是介于抽象模型和现实之间的中间层抽象。场景比目标以及功能、数据和行为的概念更加具体，同时，场景自身也覆盖了多个不同的抽象层次。涉众可以根据所预期的在需求工程过程中的场景使用方式，来选择合适的场景描述抽象层次。场景特别适用记录关于上下文的信息。场景中记录的典型上下文信息包括参与者、角色、目标、前置条件、后置条件、资源以及位置。在上下文的主体刻面中，场景可以用来描述系统中所表达的关于上下文对象的信息更新。在上下文的使用刻面中，场景被用于刻画使用工作流。在IT系统刻面中，场景可以被用来刻画如维护、备份之类的过程。在开发刻面中，场景可以被用来描述修改该系统的工程师与系统之间的交互序列。

      面向方案的需求定义了系统需要实现的属性和特征。面向方案的需求定义了系统的数据视图、功能视图和行为视图。数据视图描述了数据方面的实体以及实体关系和属性。功能视图通过使用功能性模型描述面向方案的需求。系统的功能模型按照功能以及功能与数据存储之间的数据流来描述系统需求。行为模型通常用来描述系统的反映性行为，主要通过（1）状态；（2）事件；（3）状态转换来定义系统的动态行为。

       需求工程的核心活动是文档化、抽取和协商。

       文档化活动旨在记录执行需求工程核心活动或横向活动时所抽取或开发的重要信息。

       需求抽取是需求工程的3个核心活动之一。需求抽取活动的目标是：（1）识别相关的需求来源；（2）从所识别的来源中抽取现有的需求；（3）开发新的创新性需求。

       需求协商是需求工程中3个核心活动之一。协商活动的目标是：（1）识别冲突；（2）分析每个冲突的原因；（3）通过适当的策略解决冲突；（4）记录冲突解决方案和原理。通过需求协商活动可以实现对于所有已知的系统需求在所有涉众之间达成充分的共识。

       确认活动的目标是：（1）确认对系统上下文的考虑；（2）确认需求工程活动的执行；（3）确认所创建的需求制品。当确认对系统上下文的考虑时，需要检查与所有4个上下文刻面相关的上下文是否已经被充分考虑到，同时被正确地文档化。当确认需求工程活动的执行时，应遵循过程标准、指导和活动描述来进行确认。当确认所创建的需求制品时，需要确（1）确认内容；（2）确认文档化；（3）确认共识。这三个确认方面与需求工程的内容维度、文档化维度和共识维度相关。

       管理活动必须考虑以下3个主要方面：（1）上下文变更的识别和管理；（2）需求工程活动的管理；（3）需求制品的管理。对于上下文变更的管理，主要通过观察的技术进行。对于需求工程过程及其活动的管理，主要通过顺序的基于阶段的管理方法或迭代的基于需求制品的管理方法。对于需求制品的管理，包括三种必不可少的管理活动：（1）建立需求的可追踪性；（2）需求的优先级排序；（3）管理需求制品的变更。

       这五类对象的内在联系是：需求工程师立足于系统上下文，从事需求工程的核心活动，得到需求制品。横切活动用来支撑核心活动，并确保需求工程的结果。

      6.2军事信息系统的需求工程

       军事信息系统需求工程框架由需求工程的内容模型、需求工程的过程模型、需求工程的方法模型和需求工程的工具这四类对象构成。

       内容模型定义了系统需求的范围、层次以及类型等方面的信息，对需求内容进行系统的、合理的分类。建立内容模型着眼于需求的理解和组织以及需求的获取、描述、验证及管理。

       过程模型主要定义信息系统需求论证人员在需求论证过程中所采取的步骤和程序，从过程上规范方法使用的顺序、要求交付的文档资料以及各个阶段完成的标识等。过程模型的定义与控制是为了保证需求论证活动的基本质量。方法模型主要定义信息系统需求论证的各个阶段所采用的各种技术手段或算法，方法模型是与过程相关联的方法体系。方法模型为各种需求内容的论证提供了基本思路和步骤。方法模型的定义是为了提高需求论证的质量和效率。

       辅助工具以计算机软件的方式实现了方法模型中所定义的各种方法，并且通过数据之间的约束关系体现了过程模型所定义的流程，为需求论证人员提供了自动或半自动的支撑手段，提高了需求论证的效率、科学性和正确性。需求工程的内容模型基于多视图的需求分类方法对需求进行了分类。图展示了基于Zachman多视图框架对需求内容的分类，一共包含15个需求产品。根据视图主体，需求的内容又分为四个层次，分别是：业务需求、信息需求、系统需求和技术需求。这四种需求之间的关系如图所示。

      过程是有组织地将输入转变为输出的一系列的活动集合。要开发高质量的需求模型与成果，必须按照一个系统化和严格化和严格有序的过程来管理和控制需求开发进程。需求工程过程框架如图所示。需求过程的每个阶段都有适合于当前阶段的方法。

      需求获取是一个确定和理解不同用户类的需要和限制的信息收集过程。在需求获取的过程中，常采用下列方法和技术：（1）会谈；（2）调查问卷；（3）观察记录；（4）组织文档；（5）使用用例；（6）快速原型法；（7）联合会议记录等。在这些传统的需求获取方法之外，军事信息系统需求工程方法的研究者还提出了（1）基于综合微观分析机制的需求获取方法；（2）基于场景的需求获取方法；（3）三维互动采掘方法等。

      需求建模的重要目的是要理解系统将处理的问题，准确地获取用户的需求；同时，也是为了让相关人员能理解和评审需求。需求建模包括结构建模、行为建模、数据和内容相关的需求建模和其他需求建模。行为建模方法包括：（1）IDEF0图；（2）基于事件模型；（3）数据流图；（4）IDEF0/UCM集成等。数据/内容建模方法包括（1）基于本体的需求建模方法（E-R）图；（2）IDEF1X方法；（3）面向对象的需求建模方法等。

       需求验证是通过对需求进行审查、确认、测试、建模、执行、分析和评价，确定需求文档中的需求在逻辑上是否一致，在性能上是否达到最优或满足用户要求。需求验证的过程如图所示。需求验证的方法包括结构化文本、决策表和决策树、数理逻辑和IDEF3方法等。对于业务时序需求的验证，亦可采用消息时序图和对象Petri网的方法。

       需求管理的着眼点在于管理策略和规则的制定以及需求管理工具的开发。在进行需求管理时，主要是借鉴现有的管理方法和技术。常用的参考模型包括ISO9000，CMMI，RUP统一过程和REPEAT模型等。需求变更可界定为信息系统需求描述文档被确定后，在执行过程中，在满足用户期望以及相关约束条件的前提下，对需求要素进行调整与修改。需求变更的主要原因分类如图所示。需求变更影响结果如图所示。

       从需求数据存储形式来划分，需求工程工具通常分为两类：一类是以数据库为核心；另一类是以文档为核心。以数据库为核心的需求工程工具把所有的需求、属性和跟踪能力信息存储在数据库中。以文档为核心的需求工程工具通常使用字处理程序制作和存储需求数据。

      6.3.Volere需求过程

       Volere需求过程是一种旨在指导需求工程师成功地发现正确完整的需求，收集、验证需求，并编写需求文档的过程，这是针对得到提交产物的一个指南，是一种提交产物驱动的工作集合。

       项目启动工作为需求发现工作奠定基础，并确保项目成功所需要的资源都已经到位。在项目启动的工作中，主要的涉众聚在一起，对关键的项目问题达成一致意见。项目启动工作确定项目业务问题的范围、涉众和项目目标，同时对项目需求部分所涉及的成本进行需求预估。

       如果项目启动工作达到了预期的目标，就可以开始网罗需求的活动。在网罗需求的过程中，需求工程师对业务问题范围内的工作进行研究，学习和理解业务的功能，并在此基础上划分业务用例。业务用例代表了响应业务事件所需要的功能。对系统本质的理解建立在对业务事件的理解和分析基础之上。系统存在的根本理由来自于拥有这个产品之后底层业务的改变。通过界定发生改变的业务的范围就可以界定产品的范围，从而确定合适的产品用例场景，并写下需求和用户故事。

       场景展示了业务过程的功能性，将业务过程分解为一系列容易识别的步骤，用自然语言写成，以便于所有的涉众都可以参与讨论。当涉众达成一致之后，场景就成为需求的基础。

       编写需求的目的是为了以一种无二义的、可测试的方式写下需求，以确保参与开发的各方面涉众对需要做的事达成一致理解。需求理由和验收标准使项目涉众更容易理解需求，而对需求的测量是为了判断构建的产品是否是涉众真正需要的。编写需求的活动是与网罗需求、制作原型和质量关等其他活动集成在一起的。

       质量关对需求的正确性进行检查，通过质量关的需求才能成为需求规格说明的一部分。质量关检查需求的完整性、相关性、可测试性、一致性、可追踪性和其他一些质量属性。当质量关是需求传递给开发者的唯一通道时，项目团队就能控制需求。

       复查需求检查是否存在遗漏的需求，保证所有的需求相互一致，需求与需求之间没有悬而未决的冲突。复查工作确保规格说明书是完整的和恰当的，这样就可以转向下一个开发阶段。需求过程是一个从愿景到系统规格说明书的演化过程。理解工作的过程伴随着从愿景到业务用例再到场景的演化过程，在此基础上理解产品的过程伴随着从从业务用例到功能需求、非功能需求和限制条件的过程，最后产出了代表着技术需求的软件规格说明书。在需求过程中，一份结构良好的需求模板既是一种强大的需求过程工具，也是一份完整需求过程的检查清单。

      6.4 SERU需求过程框架

       SERU需求工程过程框架覆盖了需求获取、需求分析、需求管理中的主要活动，明确定义了工作任务、介绍了工作方法、指出了工作产物，说明了产物之间的连接方法，可以帮助软件开发团队快速应用到工作中，有效提高需求工程的质量。

       在SERU需求过程框架中，S代表着子问题域，核心思想是根据业务区划来分解系统，使系统的各个部分在业务上保持相对独立，降低耦合性；U代表着用例，用例是封装需求的手段，是需求组织的最小单位，由一个业务活动（B类用例）、一个具体报表项（R类用例）和一个具体接口（I类用例）。E和R是联接业务和用例之间的线索。E表示事件，是流程的起点，通过业务事件的标识找到流程，通过流程将不同的场景串接在一起。R表示查询、分析、统计，通过寻找管控点确定报表类型，然后细化到具体的报表项。

       SERU需求过程框架将需求过程从逻辑上分为三个阶段。第1个阶段是需求定义阶段，这个阶段定义为项目的立项阶段。其核心工作是：（1）根据业务特点划分主题域；（2）确定每个主题域范围，用上下文关系图表示；（3）针对每个主题域，列出业务事件、报表类型列表。本阶段主要的产物是：（1）构件图，用来表示主题域之间的关系；（2）上下文关系图，用来表示主题域的范围；（3）业务事件列表，报表类型列表。第2个阶段是理清需求框架和脉络阶段。这个阶段对应于需求捕获、分析这一阶段，结束的标志是“标识出绝大多数的用例”。本阶段的核心工作是：（1）针对每个业务事件进行流程、业务实体、使用场景分析；（2）针对每类报表进行业务实体、使用场景分析；（3）将场景抽象，得到用例模型；（4）将业务实体分析获得的领域模型片段进行合并与抽象。（5）对设计约束与质量属性进行分析。本阶段的主要产物是：（1）活动图，用来表示业务流程；（2）领域类图片段，表示每个业务流程、报表类型涉及的业务实体；（3）用例模型片段，表示每个业务流程中的业务活动、具体报表项；（4）领域模型，按主题域对领域类图片段进行合并与抽象；（5）用例模型：按主题域对用例模型片段进行合并与抽象；（6）部署图：用来描述软、硬件环境方面的设计约束。第3个阶段是填充细节阶段。这个阶段对应于需求捕获和分析的深化阶段，结束标志是“已标识用例、领域类的细节均填充完毕”。本阶段的核心工作是：（1）针对每个用例类进行捕获和分析；（2）对流程图上标识的相关文档进行分析，完成领域类的细节填充；（3）在架构师的支持下，完成技术类用例的描述。本阶段主要产物是：（1）业务类用例描述，包括事件流、相关需求、UI原型、规则约束；（2）报表类用例描述，包括报表概述、报表内容和输入/输出格式；（3）接口类用例描述，包括使用者概述、内容与格式、实现约束；（4）领域类描述：包括数据窗口分析、组成与格式、计算规则等。

       需求工程师在项目中应用此过程框架时，可以根据需要对框架进行剪裁、定制和修改。

      6.5基于业务及信息化规划说明的需求工程

       基于业务及信息化规划说明的需求工程在需求开发和需求管理的过程之前增加了需求规划的阶段。需求规划阶段的核心工作由业务研究、应用建模、系统规划、分析计算、报告编制和规划评审组成。需求规划阶段的工作产物是业务及信息化规划说明。

       业务及信息化规划说明是业务和信息化规划工作的成果。业务及信息化规划工作由业务分析、系统分析等部分组成，业务分析反映的是组织机构或客户以问题和目标为核心的业务组织、业务域、业务过程、业务活动、业务规则、业务单证、业务量的物理世界的现状的不失真反映；系统分析反映的是系统域、系统过程、系统活动、系统规则、系统单证、系统数据、系统流程、系统架构等，是对组织机构或客户要建系统和待建系统站在总体角度的一种系统的宏观设计。

       业务及信息化规划说明的重点是站在组织角度依据客户的问题和目标来确定需求的范围和要达到的深度，范围包括业务组织、业务域、业务过程、业务活动、业务单证、业务数据、业务规则、业务流程等，而目标说的是关于时间的效率、空间上的覆盖程度、使用的简便性等。业务需求规划说明还包括系统分析和安全分析，是站在宏观角度对信息系统的期望描述，业务需求规划将指导软件开发的各个环节。在阐述了基于业务及信息化规划说明的内容之外，杨巨龙还介绍了需求工程的知识体系和方法体系。

7.小结

       本文介绍了软件需求和需求工程的基本概念，以及5个关于需求工程的研究实例，或者说是关于需求工程的知识体系。时至今日，需求工程的知识发展面貌日新月异，本文所介绍的内容亦是粗枝大叶，挂一漏万。但是，从整体上看，略可管窥需求工程作为一门学科的发展脉络，那就是：与系统工程全方位结合的需求工程。Paul在其专著《需求工程：原理、方法和实践》一书中问道：“真的还需要另外一本需求工程的教科书吗？”他的同胞Ebert就立刻以一本《需求工程实践者之路》回答了他。Paul的自信是有道理的，他在书中精辟的总结道：“需求工程就是在上下文中建立愿景。”按照系统方法论，上下文更多的呈现出硬系统问题的特性，这个系统是建立在人类科学技术尤其是电子信息技术发展的基础之上的，这也就意味着即使遇到了一时说不清楚的问题，只要回退到技术的层面，一定能够为对问题的认识寻找到一个相对坚实的立足点。那么，建立愿景呢？我们勉强可以把这个问题归结为一个软系统问题，因为“建立愿景”这四个字其内涵是弄明白人的愿望，把它们表达成可见的景，然后像栽花一样种在计算机系统中，还要能够确保其正常演化发展。Paul在知识工程和系统工程基础上发展起来的需求工程框架本身就是一个严密的系统，在他的手中需求工程的知识已经被整合形成了一个硬系统，从这一点出发加入合适的计算机技术应该立刻能够整合出一种用于处理软件需求的软件工具，但这种软件工具的自动化程度再高，也只能不断的提升软件需求知识对软件项目现实的转化率，而不能也不可能实现完全的知识自动化。在军事信息系统需求工程一书中，作者把基于系统的需求工程方法、基于企业应用框架的需求工程方法和基于能力的需求工程方法作为三种并列的需求工程方法。但是，张维明以及他周围的学术团队实际上用他们不断推陈出新的学术成果指明了需求工程发展的方向。要素、能力、结构，三者统一于体系，体系是什么？系统之系统。再看薛惠峰等人以航天工程实践为研究对象形成的现代信息化知识体系，开宗明义就提出要用现代系统工程支撑现代信息化建设。从知识系统发展的历程看，可以说张维明等人的研究是从实践出发自底向上的，薛惠峰等人的研究是自上而下的，显而易见，在需求工程的研究领域，这两种路线已经交会在一起，正经历着自组织的整合，即将或者已经体现出了涌现性，将要向更高的层次发展演化了。再想想钱学森等人提出的综合集成的系统方法！我们现在无法知道这分处南北东西的几个学术团队是否在按照某种方法的指导从事着研究，我们现在能够看到的事实是，出现了这么一种宏观现象，可以使用这种思想合乎实践的诠释。这还仅仅是从软件需求工程的角度出发自然而然的呈现出的一个现象。如果上升到软件工程这个系统层面，戴汝为院士等人在专著中提到的“社会智能与综合集成系统”与陆汝钤院士等人在文章中提到的“天马”系统以及“知件”的概念，这又是处于什么层次的待开发的信息资源呢？对比身边种种现象，我不禁产生这样一个疑惑：钱学森之问真的没有答案吗？桃李不言，下自成蹊。这也从侧面印证了上文介绍的另一个观点，那就是“系统工程建立的历史条件是：生产和技术大大发展了，已经发展到需要系统工程的阶段，而且也有可能体现系统工程的阶段。其深层次因素是人类的科学技术和生产能力已经到了重点要从解决硬技术转向重点解决软技术的阶段。”显而易见，需求工程及软件工程已经走在了这个点上。