解读敏捷需求分析五大关键因素

大多数学计算机语言的人都会有过这样的感觉，过去一直认为编程和架构是整个软件生命周期里最了不得的部分，但实际工做后才会发如今商业产品里，需求分析才是一个商业软件成功与否的关键。

放 眼望去，在当今软件工程领域出现的许多问题，诸如缺陷及资源运用不当，都源于需求的不清晰，甚至有软件人戏称：“需求变动乃万恶之源”，一时也得到了颇多 响应。时至现在，业务IT间需求分析过程当中存在的问题主要有哪些？什么是敏捷需求分析？产品级和项目级需求有何异同？敏捷需求分析方法论中的五大关键点是 什么？就以上热点话题，雅各布森中国区总经理吴穹分享了他的见解。

 

三大症状

在吴穹看来，两份需求、合同式验证、产品需求缺失成为了当前需求沟通的三大症结。

两 份需求——用户（业务）需求和软件需求。用户需求由不熟悉IT的业务人员完成，大多归于天马行空的意识流，基本上是想起什么写什么。而软件需求由IT人员 编写，通过技术思惟的过滤、梳理、增删，包含进了算法、数据库设计、架构之类的技术专业词汇，业务人员每每已不知文档内所云。

合同式验证——业务人员和技术人员企图在沟通后以合同形式将需求固化而且肯定下来，而没有充分考虑到软件开发过程当中可能出现的需求变动。

产品需求缺失——项目是片断，产品是总量，二者的关系在于项目其实就是一个不断完善产品的过程。因为国内PMP（ProjectManagement Professional）和项目管理流行，更多IT需求都是以项目形式存在，而每每忽视了产品需求的积累，致使最后的结果可能是项目（需求）不少，但产品需求缺失。

项 目级和产品级需求的具体区别，若是放在几年或十多年前并不明显，对于全新产品而言，项目（需求）=产品（需求）。随着时间推移，二者的区分逐步明朗，因为 全新项目愈来愈少，更多的需求都是在维护和升级老的产品。以咖啡机为例，从基本型升级到1.1版，或许是加入一个按钮。此时和客户沟通的时候就须要引导客 户想清楚，须要的是项目级仍是产品级的需求，是作整个咖啡机的需求仍是仅仅只是新添按钮的需求。若是将来再作1.2版，继续添按钮，这时候的需求又该如何 写？新按钮的需求，而后和之前的按钮有些变化。若是不能明确两种需求的差别，随着项目需求的累积，到最后会发现全部的（需求）都是片断的，都是增量而缺少 一个总的全景。

事 实上，业务IT需求形成现在的混乱情况，CMMI（Capability Maturity Model Integration，能力成熟度模型集成） 和国内企业对CMMI的僵化理解能够说“功不可没”。在对“两份需求”的认识上，CMMI里有明确分项，用户需求和软件需求。但值得一提的是，其实里面并 未明确要求是两份文档或由两部分人来写，而只是表示需求细化的两个阶段。遗憾的是，不少国内CMMI认证企业也并无真正打算去了解它的内涵，只是僵化地 表现出本身是否有这样的能力。

最近接触到一些项目也出现了这样的情形，你们先作了一份用户需求，而后花费大量时间写软件需求，以知足认证的须要，但到头来软件需求根本没人看，你们都只是应付，CMMI成为了摆设。

 

需求贯穿于软件开发测试全过程

在 吴穹看来，敏捷的最大贡献在于它是对整个软件工程的一次再认识。具体到敏捷需求分析领域，其实涉及到一个核心问题：是否认可（软件）需求能够在一开始就搞 清楚并肯定下来？敏捷的答案是No！而在传统瀑布式开发中，更多的是合同式验证的情形，大多数客户的思想基础都是基于需求最初就能肯定下来的。但事实上， 这在当前阶段基本属于“不可能完成的任务”，不符合软件开发本质。在敏捷需求分析中，需求应是贯穿于整个软件生命周期全过程当中并在其中不断变动、迭代和完 善。

敏捷需求分析认为，需求应创建在以用例为中心的需求文档体系，采起协做式而非合同式的沟通方式之上。具体可分为五个关键点：

• 用例；
• 协做；
• 迭代，即需求不是一次最终肯定，而是先完成主要框架，再经过迭代逐步精化；
• 整个过程当中以分析为支撑，作需求同时也在作分析，分析模型的输出结果应跟需求分开；
• 把用例分解到用户故事，在整个软件生命周期过程当中来驱动开发和测试。

 

业务/技术沟通频现“两份需求”

同 时还要考虑到的是，将两份需求改成一份文档，而没必要死抠CMMI概念区分出用户和软件需求。首份需求稿将由SA（系统分析师）来牵头完成，负责各方协调和 沟通的工做。理想的状况下，整个团队在项目开始前就应搭建完毕，包括客户、开发测试人员都参与的写做和迭代，而不是以往的由技术人员对用户进行里程碑式的 教辅。一般来讲，一个项目里一名SA同时对应5~9名开发人员是比较合适的。

 

需求文档化与敏捷的平衡点

至 于用例和用户故事。按照敏捷大师Martin博客中的说法，二者都是组织需求的方式，只是目的不一样而已，用例的目的是为了把需求描述清楚，而用户故事的目 的是把需求分解成可用于迭代计划的单元。对应到产品级和项目级文档，用例是产品级，例如作咖啡机，无论有多少不一样版本，有些核心功能是不改变的，这些都是 产品级需求。而用户故事则是项目级，属于作完就扔的“抛弃型”。

进 一步理解的话，用户故事实际上是一个或多个完整的业务场景，而用例是场景的抽象，一个用例里能够包含成百上千个场景。用户故事是基于开发思想的，不光要考虑 业务，还要考虑如何实现包括工做量大小、任务分配、项目风险以及架构风险等多重因素。有人认为写用户故事是极简单的事，但在吴穹看来，如今有不少人都还在 用功能点套用用户故事，显得不三不四，而没有理解到用户故事的精髓。

以 ATM取款为例，正常流程是插卡、取钱、把钱拿走。这个看似简单的场景其实工做量很大，能够在整个流程中作一些必要的简化。有人认为既然用户故事是一个场 景，那就把它变成一个场景步骤吧，因而就成了功能点。其实他们忽略了一点，用户故事仍是一个简化了但还保证完整业务价值的场景。ATM取款创建用户故事会 涉及哪些因素呢？取款是否须要输入密码？小额取款时可否取消密码输入的步骤？取钱后打印帐单，查询余额等，在这里面哪些功能是风险级别高的，哪些须要与银 行核心数据通讯？这不只涉及（功能）优先级的问题，还能够根据原则简化用户故事。例如能够考虑作一个用户故事，储户用不需验密的卡，限额是一千块，取几百 块钱的时候，把去银行验证的过程取消掉。这种情形下不少时候都要考虑到帐户的风险状况，这些都须要多方沟通。相似的用户故事简化的情形有不少，但这时必定 基于黑盒方式来作简化。而在简化的过程当中，考虑如何实现如何合理调整工做量提升效率，这些都是找（用户）故事的过程，也是一个白盒的过程。

在 实现上，除了强调快速交付或生命周期很短、业务模式高度可变的互联网、网游等项目，能够采用纯用例的模式，现阶段让（大型）企业IT项目全面接纳需求彻底 无文档化仍是不现实的，更实际的解决办法是在文档化和敏捷需求分析之间找到一个平衡，一份需求用例加上用户故事，而后驱动开发这种方式，目前看来，这是现 阶段更适合大型企业的敏捷需求实践模式。

 

（本文来自《程序员》杂志10年07期）