敏捷过程中的软件需求分析
在日趋激烈的电信业竞争态势下，持续而快速地发掘和响应商机成为新的课题。作为响应机制中的关键环节，需求工程应用敏捷过程方法，以关注商业价值、快速响应、持续迭代的特征来应对变化和难测的未来，是尝试提高组织敏捷能力的核心。在这其中，作为沟通桥梁的需求分析同样可以应用敏捷的过程方法参与到生命周期的演进。敏捷需求分析将在需求时机与过程、文档要求、变更、参与者角色等方面展现其不同传统的特性。本文将结合电信业背景及企业实际情况，对敏捷需求分析作出初步的探索。1. 敏捷需求分析：电信行业背景与敏捷过程的需要从中国电信行业ITSP战略推出至今，数年中我们已经看到了明显的变化，作为其信息化体系落地的CTG-MBOSS，也已初具规模和成效。大规模实施的下一个阶段，将是在商业价值引领下的重构竞争模式、市场细分，以及作为支撑的需求深入研究。在项目实施过程中，各种挑战和困难纷至沓来，项目管理者不管是做时间、成本、质量的三角平衡，还是人与技术的双向选择，始终无法绕开的一个问题跟源是：如何快速响应环境的变化，使客户在优化的体验过程中满足其商业目标，从而实现企业本身的价值？
用失控的过程膨胀来形容近10年的许多软件公司的情形是很合适的。虽然有很多团队在工作中没有使用过程的方法，但是采用庞大、重型的过程方法的趋势却在快速增长，在大公司中尤为如此。但现实的发展确与此不相同步，竞争态势造成了更多的不确定性和快速调整的机会。从近年ERP上线的平均速度来看，项目的交付时间都比较长，这让用户产生了顾虑[1]。但实际上软件上线仅仅是一个软件生命周期早期的阶段，软件的价值是在使用中体现出来的，其投资回报也只能在后期的运营得到完成。未来的变化如同纳西姆?塔勒布的黑天鹅一般不可预测且重要，已知和过去琐碎的重复并不足以预测未来的重大影响[2]。以预测性度量为控制基础的过程模型，只能以经验涵盖一般性事件，所以与此同时，随机应变，保持快速集成和持续改进以应对商业环境的不确定性，延长软件的生命周期提高它的大价值，从而为获取更多投资回报提供保障，也成为软件工程发展的必然。敏捷过程（Agile Process）的主要优势是能够适应系统需求的不确定性，将客户作为需求团队中密不可分的成员，而在实现过程中尽量在短时间内实现对用户来说业务价值大的需求；同时，敏捷开发（Agile Development）是一种面临迅速变化的需求快速开发软件的能力[3] ，它帮助处理了未来不确定性的问题；但是对于过去，应该没有不确定的事。而敏捷需求分析，是面对迅速变化的商业状况，提高其响应和组织成可理解和接受的需求说明并对敏捷开发作出能力保证的方法论。
2. 敏捷与过程改进和度量模型从软件工程发展起，过程改进在全球日益得到重视，ISO 9000/SW-CMM/CMMI各级的评估也在业界得以推展，这种氛围下，以RUP等为代表的过程模型也得到了广泛的应用。但与此同时，敏捷的论调却异军突起，方兴未艾。软件过程的多样性，源于过程环境和层次的不同；而过程选择的多样性和CMMI目标的通用性决定了过程改进途径的多样化。运用一系列重方法，将在应对商机方面造成挑战；尤其是在企业的管理考核和过程模板仍更多的是一种瀑布式体系下，软件的实现过程将在不同模型下摇摆却显得不那么灵活。一个合适的生命周期模型选择是重要的，由于惯性的教育，瀑布在我们的工作环境中随处可见。但如果不去分析CMMI等的实质，将无助于改进这一点而提高响应。强调结构化方法与重型的管理策略，往往在内心中拒绝变更，把变更作为被管理甚至被“管制”的对象；而为了尽可能避免变更，常常要求开发之前的需求获取、分析与定义要完整无误且精确。这是一种理论上的理想状态，尽管我们可以采取诸如CMMI的一些理念及过程改进模板对其管理，但实际上往往会出现与用户商业价值要求的脱节；而为达成此目标，使得前期的需求开发工作变得小心翼翼，终有可能在压力与时间约束下难免简单化而草草了事，在后期又不能得到及时的修正，从而形成一个隐患。 但实质上，重型、轻型过程方法论之间并不存在根本性的矛盾冲突[4]，这体现于它们终理念和出发点的一致。把这些互补方法论拼在一起，“恰好可以发现整个软件过程体系全貌的一部分”[4]。CMM/CMMI 中不包括更为具体一点的如何写好需求，如何做好设计，如何写好测试等许多方面的软件工程技术、技能方面的指导，而这些恰好是敏捷的强项。敏捷方法整合了一套轻量的管理、过程和工程技术方法，这是它作为一种先进方法体系补充于CMMI 的地方。敏捷过程并不像业界所传的那样只适合小项目和新项目的研发，实际上它对于各种类型，包括企业所定义的A类、B类、C类在CMMI体系基础上都是可取舍适用的。这需要过程体系间的适当裁剪和调整组合。敏捷需求分析，将在全过程中扮演衔接、沟通和渗透的作用。3. 敏捷需求分析的过程特性IEEE对需求的定义是用户解决问题或达到目标所需的条件或性能；系统或系统部件要满足合同、标准或其他正式规定文档的条件或性能。 需求是设计、构造产品的前提，简单地说，是必须完成的事及其所必须具备的品质。需求存在的原因要么是该类型的产品要求一定的功能和品质，要么是客户希望需求成为提交的产品的一部分[5]。 软件需求包括三个不同的层次?业务需求、用户需求和功能需求?也包括非功能需求。业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（ s c e n a r i o）说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性( f e a t u r e )是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。[6]
图1. 需求的层次及组成（对于上段文字的部分描述及图1，参考资料[6]并对原文进行了部分改编，并非全部的引用，请注意鉴别）我们可以看到，不管是传统的还是敏捷的需求开发阶段，需求的层级及组成，其基本特性是一致的，这反映方法的差异并不改变需求的本身属性。一般的需求三个层次，忽略了一个问题，即每个层次所需的知识、技能、经验、背景等是不同的，不同的层次过程中，需要不同资源的整合。业界相关的论述中，只是给出了笼统的需求分析人员的统一角色，但并未对其作出区别。实际上，这很难映射到中小企业的现实操作层面。
