【IT168 技术文章】

    需求术语的概览

    什么是需求？什么是需求分析？什么是需求跟踪？什么是需求获取？什么是需求规格？什么是需求验证？什么是需求变更？……一堆关于需求的问题，一堆关于需求和需求管理的恼人问题，需求真的很重要吗？那为什么如此难以把握？为什么在软件工程中如此难以应用呢？

    您作为从事项目开发，尤其是软件项目开发的负责人，需求分析师，系统架构师，程序员，测试人员，维护人员，项目的使用者，只要您是项目开发和应用中的一位成员，您一定思考过上述的问题，或许您曾为此问题曾经与人激烈讨论过，或许您已经疲于争论已经在实际的项目中应用您的认识和体会了。

    上述这些话，在 IBM 或者软件行业协会举办的需求管理讲座上，我以 IBM Rational 产品讲师的身份曾经多次询问过客户和听众，他们每每给予我的回应除了无奈的笑之，就是带着期许的眼光等待着我给出回答。

    什么是需求

    对于第一个问题：什么是需求？很多需求专家和权威机构已经给出了他们的描述，为什么是描述而不是定义呢？“因为软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的”需求“对于开发者似乎是一个较高层次的产品概念。而开发人员所说的”需求“对用户来说又象是详细设计了。实际上，软件需求包含着多个层次，不同层次需求从不同角度与不同程度反映着细节问题：——IEEE 软件工程标准词汇表（1997）中需求为：

    （1）用户解决问题或达到目标所需的条件或能力

    （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力

    （3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。“

    ——Jones 认为“需求是用户所需要的并能触发一个程序或系统开发工作的说明 ——（Jones 1994）”

    ——Alan 认为“从系统外部能够发现系统所具有的满足于用户的特点、功能及属性等 ——（Alan Davis 1993）”

    ——S&S 认为“需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束 ——（Sommerville and Sawyer 1997）”

    所以引出上述这些描述，是因为我们仔细阅读上述权威机构和专家的描述，可以发现，他们分别从用户，从系统，从系统部件，从作用，从实现等不同方面对需求进行了阐述，至少通过上述的描述我们可以知道，需求基于不同的立场和角度是可以有不同的理解的，这也是为什么总是会有人针对什么是需求喋喋不休的争论，而最终谁也无法说服谁的场景在软件开发过程中层出不穷的原因。那么谁会对需求有不同的立场和角度呢？干系人，同项目或者系统有关的干系人（Stakeholder），前文我们提到的软件项目开发的负责人，需求分析师，系统架构师，程序员，测试人员，维护人员，项目的使用者等等，这些都是需求的干系人，因为有干系人的存在，就会有基于不同立场和角度的需求认识，这样就会形成不同类型的需求，因此当我们在探讨什么是需求时，我建议大家不要忘了思考我们正在针对何种类型的需求在进行探讨，探讨的目的是什么。

    至此如果我们接受了从需求分类的角度考虑什么是需求。那么什么是需求分析？什么是需求跟踪？什么是需求获取？什么是需求规格？什么是需求验证？什么是需求变更？……也就是我们该如何理解并组织这些需求活动和术语呢？

    需求术语的组织结构

    对于第二个问题，如何理解和组织众多需求术语和活动。本文借鉴需求管理专家 Wiegers 在《Software Requirements》一书中对于这些需求活动和概念的描述与分类，    需求工程：需求开发和管理的过程。它包括了需求开发和需求管理两个部分。

    需求开发：是指从问题获取、分析判断到编写规格说明文档、评审验证等一系列产生需求的活动。这些活动在需求开发中是相互独立和可以反复出现的。

    问题获取：需求的收集、分析、细化、核实并组织的步骤，该活动包括干系人分类，筛选典型客户代表，组建需求团队，召开会议，判断需求质量属性等多项具体内容。

    分析：根据需求获取中得到的需求文档，分析系统实现方案。具体的方法包括：鱼刺图，上下文关系图，用例图等分析方法。

    编写规格说明：需求开发的最终成果是客户和开发小组对将要开发的产品达成一致协议，这一协议就是通过文档化的需求规格说明书来体现。对于不同类型的需求可以有不同的规格说明相对应，例如所常见的用户需求，业务需求等。

    验证：确保需求说明准确、完整，表达必要的质量特点，需求将要作为系统设计和最终验证的依据，因此一定要保证它的正确性。需求验证务必确保符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性这些良好特征。

    需求管理：是计划、组织、指导和控制需求的系统方法，也是指软件项目开发过程中控制和维护需求约定的活动，通常包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

    版本控制：版本控制是需求管理的一个必要方面，需求文档的每个版本必须统一确定。以保证每个成员可以准确地得到需求的当前版本，并了解需求文档每个版本的修改原因和结果。

    需求跟踪：是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。

    需求状态跟踪：不同类型的需求都有不同的需求状态相对应作为需求优先级划分标准的补充说明，通过需求状态跟踪能够确保需求按照优先级先后实现的完整性。

    变更控制：变更控制给项目风险承担者提供了正式的建议需求变更处理机制，通过变更处理机制需求的决策人可以准确地分析需求变更所带了的影响和波动，从而决判断是否接受、拒绝或者延迟需求变更，最终准确控制项目开发范围。

    至此，我们了解了应如何理解和组织众多需求术语和活动。但是也有许多人看到这里会认为这又是一篇堆砌了很多术语介绍的文章，晦涩而难以应用。其实不然，本文重点论述的就是 —— 通过数据和信息的关系理解需求管理在变更管理中的重要性。为什么有此想法和立意呢？

    我在拜访很多软件开发企业的时候发现大多数软件开发团队都已经有了成熟的变更管理概念和管理基础，已经能够将变更管理到位了，于是他们就想进一步管理需求，但是不久就会发现从很多书本或者权威的书籍中得到的需求管理的理论，往往向我上面介绍的术语那样大而全，但是确苦于无从下手，担心需求管理同变更管理结合使用的学习成本太高并且风险太大，最终不了了之，很多软件开发企业和团队只能继续忍耐由于需求变更所带来的项目延期或者利润下降的噩梦。

    那么我们可以怎样使用需求管理呢？我们首先从一个生活中的小例子介绍。