|
引言
需求工程是当前软件工程中的关键问题，需求错误是系统开发中最常见的一类错误，也是导致项目失败最多的原因。在项目的需求阶段发现错误所花费的成本与维护阶段发现错误的成本比例可以达到200∶1。
因此，探寻一套合理的需求管理方法，可以降低软件成本，改善软件的质量，提高软件的生产效率。
1 敏捷需求管理的研究与改进
Karl E. Wieners将需求工程分为需求开发和需求管理。需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动：变更控制、版本控制、需求跟踪和需求状态跟踪。由于项目在特性、进度、人员、预算和质量各个方面的要求不同，所以不存在一个放之四海皆准的模式。
为了适应软件改进过程中的需求管理，解决需求危机，取得更好的经济效益，本文根据敏捷方法与原则，对需求管理的定义做适应性变化。这种适应性变化将需求管理定义为：需求管理包括需求获取、需求组织、需求质量管理、需求变更和需求复用。
其中需求组织又包括需求分析和需求规格说明（SoftwareRequirementsSpecification，SRS），需求质量管理包括需求检验和需求确认，需求变更包括需求变更控制、需求跟踪和版本控制。获取、组织需求也包含于需求管理的范围中，原因在于先预防，然后再根据需求的变更进行控制。
2 需求获取
好的开始是成功的一半。成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作，这便是敏捷需求建模的价值观。敏捷需求管理要求做到以下几个方面。
2.1 明确权利与义务
敏捷思想不将开发人员和客户视为对立关系，而是看成一种良好的合作伙伴关系。各涉众之间相互理解、相互尊重，共同遵守软件客户权利法案与软件客户义务法案。每个人员都清楚各自的职责，了解并承担自己的义务，如有疑惑协商解决。这样能够减少以后因一方不愿意或不提供对方所需而产生的矛盾。
2.2 了解需求层次和重要性
让客户对需求的层次概念、需求的重要性以及忽视需求的危害性有所了解，保证需求分析员与客户建立良好的合作关系，促使他们积极友善地参加需求阶段中的各项活动，让客户清楚为达到系统的高效，整个项目计划中须为需求阶段安排一段充足的时间。
让客户了解需求层次概念的原因在于只有如此，才能避免他们认为分析人员总是“围绕”在其周围是浪费双方的时间而不乐意合作，导致双方受到挫折，以致需求草草了结，导致需求问题扩散到整个软件开发过程，产生后患。
2.3 结对学习
除了解客户的需求以外，还必须做到把客户不知道的也让他们学习到，也就是需求的其他层次。同时分析人员也必须向客户学习，学习他们的业务，深入客户的工作环境，学习了解客户的需求。不能凭空想像，否则开发的产品可能很有创意，但客户却不一定满意。
在敏捷需求管理中这个阶段引用“极限编程（XP）”思想中的“结对”策略让客户和分析人员结对，两者共同努力，达成信赖的组合体。这样不仅有利于项目的成功，也能为下期项目铺垫，建立长期的友好合作关系。
3 需求组织
3.1 需求分析
需求分析是在需求问题及其最终解决方案之间架设桥梁的第一步。需求分析的关键目标是以关系的形式描述需求，提供设计基础，在软件完成之后提供验证基础。具体来说，敏捷需求建模结合UML和敏捷方法采用用户故事、用例、原型等方法进行需求分析。
3.1.1 用例
将用例应用于需求分析和导出的主要好处来自于以用户为中心的方法。用例帮助用户更好地理解他们想从目标系统中得到什么以及如何与目标系统交互。在这个过程中，用户可以澄清他们的需求。
用例还有助于产生测试案例，特别是功能测试案例。用例将系统开发和用户目标联系起来，并且还可以更直接地被转化为对象模型。一旦用例和角色确定后，分析师可以提出下列问题以搜索与用例有关的细节：
（1）角色要在这里完成什么？
（2）角色有什么要提供给系统的信息？
（3）系统有什么要提供给角色的信息？随着用例细节的收集，每个用例都要被编制成文档。
3.1.2 敏捷需求建模推荐的用例文档模板
3.2 需求文档化
将需求形成文档是必需的，因为这是需求导出和分析过程随着系统进入到软件生命周期的后期阶段对于开发团队、客户和最终用户的唯一持久性的影响。需求文档通常称为软件需求规格说明，构成了开发和测试活动的基础。敏捷需求管理较少采用文档，直到迫切需要和意义重大时才采用。
4 需求质量管理
4.1 需求检验
需求检验的目的是为了确保需求说明准确、完整，表达必要的质量特点。在敏捷需求建模中，这个实践活动需要完成以下几个任务：
（1）审查需求文档，对需求文档进行正式审查是保证软件质量的有效方法。组织一个由不同代表（如用户、分析人员、设计人员和测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。
（2）依据需求编写对应的测试用例，根据用户需求所要求的产品特性写出系统的功能测试用例作为系统测试依据。
（3）编写用户手册，在需求开发早期即起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。
（4）确定合格的标准，需求说明中描述什么样的产品才算满足用户的要求和适合他们使用。需求检验的标准包括：完整性、正确性、可行性、必要性、无二义性、一致性和可跟踪性。
4.2 需求确认
需求确认是需求管理过程中的一种常用手段。需求确认有两个层面的意思：一方面是指系统需求调查与分析人员和客户之间的一种沟通，通过沟通对需求不一致的内容进行剔除；另一方面需求确认活动可以确保需求符合优秀需求陈述的特征。
敏捷需求管理包含两项重要的工作：需求评审和制定验收标准。
5 需求变更
5.1 需求变更控制
进行变更管理，首先要建立变更控制委员会（CCB），CCB是—个由软件项目需求承担者组成的小组，负责需求变更管理的工作，需求变更的一切最终裁决由其完成。所有项目参与人员必须遵从该流程。
（1）申请需求变更：项目组所有成员在开发过程中发现需求规格说明的需求与实际情况有差别，或者有新需求时，应及时提出变更申请，填写需求变更申请表。
（2）受理评估变更申请表：CCB收到提交的需求变更申请后，需求文档管理人员将变更申请记录在案，并把变更编号发回给申请人，然后由CCB对需求变更影响进行分析，以确定它对项目计划和其他需求等因素的影响。同时明确完成与变更相关任务所需的工作量，这有助于做出信息量充分的变更决策。
（3）修改或增补需求文档和设计文档：当决定采纳变更后，各方项目经理和CCB必须按照决定的方案落实该变更，修改或增补需求文档或设计文档，必要时调整开发计划和进度表。
（4）发布变更：当文档修改完后，必须尽快发布修改后的文档和变更内容，要求通知到项目的所有人员，以便及时做出正确的调整。
（5）修改代码和测试用例：受需求变更影响的编码和测试工作必须及时做出正确的调整。比如：开发组修改和增加代码，测试组修改或增加测试用例和测试数据等。
5.2 需求跟踪
5.2.1 需求跟踪链
通过跟踪链，可以向前或向后跟踪从需求起源到需求实现这一需求生存期。演示四种类型的需求跟踪链。第一种跟踪链“客户需求”可向前跟踪到“需求”，这样就可以断定在开发过程中或开发结束后，如果客户需求发生了变更会影响到哪些需求。
同样，第二种跟踪链也可以从“需求”回溯到“客户需求”，以确认每个软件需求的源头。如果以用例的形式来表示客户需求，那么上半部分就说明了用例和功能性需求之间的跟踪情况。下半部分表明，在开发过程中当需求流入下游的可交付产品时，
可以通过定义单个需求和特定的产品元素之间的跟踪链（第三种），从需求向前跟踪到下游工作产品。这种跟踪链可以确保每一条需求都得到了满足，因为可以确保每一条需求都有相应的组件来处理它。
第四种跟踪链从特定的产品元素向后回溯到需求，这样就可以了解每个元素被创建的原因。通过跟踪链，可以了解各个需求之间的父子关系、相互连接和依赖的关系，这些信息揭示出删除或修改某一特定的需求会波及到的范围。
5.2.2 需求跟踪矩阵
表示需求和其他系统元素之间跟踪链的最普通的方式是需求跟踪能力矩阵，也称为需求跟踪矩阵或可跟踪性表。需求跟踪的主要意义在于获得需求目前的实现状态，确保用户所有的需求都得到满足。
可靠的跟踪能力信息可为用户在需求变更、系统维护、关键成员离开、系统再设计和类似系统设计等很多方面提供参考和指导，并可以减少风险和提高项目成功的可能性。
5.3 需求版本控制
版本控制是管理需求规格说明和其他项目文档必不可少的一个方面。需求文档的每一个版本都必须唯一地标识出来，使得每个团队人员都能够访问最新版本的需求。敏捷需求管理实践要求对需求所做的变更必须明确地写入文档中，并传达给受此影响的每一个人。
为了减少混乱、冲突和误传，可以指派一个人专门负责更新需求，并确保只要需求有所变更就相应地改变其版本标识号。
6 需求复用
复用是在软件开发中避免重复劳动的解决方案，将己有的软件成分用于构造新的软件系统。其出发点是应用系统的开发不再采用一切“从零开始”的模式，而是以已有的工作为基础，充分利用过去应用系统开发中积累的知识和经验，消除许多重复劳动，提高软件开发的效率，
同时重用高质量的已开发成果，避免了重新开发可能引入的错误，提高了软件的质量。敏捷需求管理强调敏捷性和灵活性，反对呆板地一味从零开始，强调经验与复用，提出了需求复用这个实践，可以有效地提高软件的复用能力，提高产品质量，节约开发成本。
7 敏捷需求管理与传统需求管理的比较
传统的需求管理企图制订长远的计划，对过程进行严格的控制，以此减少需求的不确定性，对需求变化呈现排斥态度。这种方法是通过大量的前期工作来减少变化对软件工程带来的影响，一旦前期工作完成，当需求又发生变化时，这样的方法就会带来很大的问题，无法适应实际项目开发中频繁变化的需求。
敏捷需求管理是一种适应型，而并非可预测型的方法。敏捷需求管理采用敏捷需求建模的价值观、原则和实践方法，以人为本、以用户为中心，主张简单，沟通合作，拥抱变化，强调根据实际情况，采取甚至创造最适合具体环境的管理方法来适应需求不断变化的环境。
按照敏捷管理的实践方法来设计系统，能够正确地看待用户需求的变动，从而较好地适应需求的变更。
8 结语
本文在敏捷需求建模的基础上提出改进的软件需求管理定义模式，该模式适应性地将需求管理分为需求获取、需求组织、需求质量管理、需求变更和需求复用五个阶段。在改进的需求管理定义的基础上，设计了基于敏捷思想的敏捷需求管理模型，
接着对敏捷需求管理模型在需求管理域的九个具体实践：需求获取、需求分析、需求规格说明、需求检验、需求确认、需求变更、需求版本控制、需求跟踪和需求复用，进行了详细的分析；并对敏捷需求管理与传统的需求管理进行了对比分析。
如果项目管理者和程序开发人员真正地理解并贯彻这种方法，用这种思想去管理项目，那么就能有效地避免出现项目后期软件架构混乱、补丁加补丁、系统性能大大减低的情况，可以缩短软件开发周期，降低项目成本，改善软件质量，提高软件的生产效率。
| 
