该帖子同步发自：(wcabt的博客  访问该博客)

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

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

　　三大症状

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

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

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

　　产品需求缺失——项目是片段，产品是总量，两者的关系在于项目其实就是一个不断完善产品的过程。由于国内PMP(ProjectManagementProfessional)和项目管理流行，更多IT需求都是以项目形式存在，而往往忽视了产品需求的积累，导致最后的结果多是项目(需求)很多，但产品需求缺失。

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

　　事实上，业务IT需求造成如今的混乱状况，CMMI(CapabilityMaturityModelIntegration，能力成熟度模型集成)和国内企业对CMMI的僵化理解可以说“功不可没”。在对“两份需求”的认识上，CMMI里有明确分项，用户需求和软件需求。但值得一提的是，其实里面并未明确要求是两份文档或由两部分人来写，而只是表示需求细化的两个阶段。遗憾的是，很多国内CMMI认证企业也并没有真正打算去了解它的内涵，只是僵化地表现出自己是否有这样的能力。

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

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

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

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

　　用例;

　　协作;

　　迭代，即需求不是一次最终确定，而是先完成主要框架，再通过迭代逐步精化;

　　整个过程中以分析为支撑，做需求同时也在做分析，分析模型的输出结果应跟需求分开;

　　把用例分解到用户故事，在整个软件生命周期过程中来驱动开发和测试。

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

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

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

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

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

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

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