瀑布模型项目中的需求分析之道(一)
在瀑布模型项目中,需求分析的质量直接决定了整个项目的完成质量。需求人员需要尽早的将项目需求和客户及内部开发团队达成一致,并做到对问题早发现,早解决。
一、能力模型
说需求分析,不得不先提当下比较流行的2种软件开发架构:瀑布模型和敏捷开发模型。在不同的开发架构中,需求分析角色者的能力模型和方法论也会有较大的差异。
瀑布模型是经典的周期模型,社会认可度高,通常适合招投标类的客户解决方案项目。它将一个项目的软件生命周期分为可研、需求分析、概要设计、详细设计、实现、系统测试、验收测试和维护等阶段,各个阶段呈线性推进,即一个阶段完成通过后才可进行下一阶段的工作。
而敏捷开发模型则以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。它强调适应性而非预设性,将项目分解成不同的“MVP”周期执行。敏捷开发模型是面向人而不是过程,它更强调团队间的充分沟通,更适合那些自主运营的互联网产品。
需求分析角色在瀑布模型中的能力模型偏向项目经理,在实际需求调研和需求设计中需要结合项目管理的黄金三角(时间、资源、质量)进行统筹规划;而在敏捷开发模型中则更偏向于产品经理,在产品策划和交互设计中则对自身商业感和规划能力有更高的要求。项目经理和产品经理的能力模型本身有一定的区别,产品新人在加入公司后可根据实际情况制定符合自身的能力提升计划。以下主要以瀑布模型类的项目为例。
二、需求的生命周期
一个需求的完整生命周期,通常包括产品策划(问题识别)、需求分析(分析与综合)、制定规格说明和评审。
(一)产品策划(问题识别)
在解决方案项目中,问题识别通常在可研阶段就已经开始,项目经理(这个阶段也可能是售前工程师)通过高层交流、问题报告、访谈纪要、标杆对比和准入标准等方式,初步形成一份“正式需求”,该过程可分解如下:
- 以业主的角度,帮助客户将项目从BRD梳理成MRD的过程,形成基本方案
- 以承建方的角度,初步了解项目的功能边界和实现成本
不同企业的团队构建可能会有不同,需求角色在该阶段最好能够在该阶段便参与可研的过程,而非等项目招投标完成后,才参与到项目建设,这样往往会加大项目的不可控性。
问题识别时,分类原始需求通常有上述几种方法,包括#APPEALS分类、四象限分类和BSA法分类,通过#APPEALS的八个维度来定位整个项目,为后续管理中使用黄金三角提供依据;四象限和BSA法通常结合使用,以判断项目的功能边界和项目的里程碑梯度。
(二)需求分析
需求分析的过程,是将用户需求转化为产品需求的过程,本质上也是信息系统的建模过程,包括结构化方法,面向对象方法和原型法等。在实际需求分析中,这几种方法通常综合使用。
- 结构化方法:是相对最早和最传统的软件开发方法,它采用模块化技术、分而治之的方法,将系统按功能分解为若干模块;模块内部由顺序、分支和循环等基本控制结构组成,主要工具为数据流图,适用于一些不太复杂的、需求相对比较明确的中小型系统。目前该已经比较少用。
- 面向对象方法:是目前运用最为广泛的一类软件开发方法。通常使用UML建模工具,比较常用的有用例视图(Use-Case View)和逻辑视图(顺序图、状态图、泳道图等),用例视图可结合场景
- 原型法:随着以互联网产品用户思维的兴起,越来越多的需求分析采用原型法,使用Axure等工具进行设计。
(三)制定规格说明和评审
许多时候,制定规格说明在需求分析完成时也同步完成,这里推荐使用Volere需求说明模板。
需求评审是项目正式开发前的必经之路,通过需求评审,项目组成员针自将要开展的工作,进行检查并提出问题,并最终做出评审边界,形成项目开发的基线版本。
三、其他常见问题
(一)需求引导
许多客户有时并不知道自己想要什么?有时并不清楚自己缺少什么?所以就需要我们去引导客户的需求。造成这种现象的原因很多,主要体现在用户对软件信息系统并不是很了解,客户的语言表达,客户只关心自身的问题等。
引导客户需求通常从引导客户分析、向客户确认需求细节和回绝客户提出的不合理需求等几个维度出发,几种常见方法如下:
- 向客户讲述基本的软件信息系统
- 提示客户在全局的地位及作用
- 向客户演示将要实施的系统的原型
- 从软件开发中需求考虑的几个方面入手
总而言之,在瀑布模型项目中,需求分析的质量直接决定了整个项目的完成质量。需求人员需要尽早的将项目需求和客户及内部开发团队达成一致,并做到对问题早发现,早解决;另一方面,有时候客户的“需求”不一定是功能需求,需求人员只有从项目经理的维度分析问题,才能够筛选并最终推进项目的实施。
#专栏作家#
兰色拉面(微信:lanselamian),人人都是产品经理专栏作家。关注城市服务、互联网+和智能硬件,对市民融合服务、移动进销存、物联网和支付 POS有一定的浅见。欢迎互联网爱好者们一起交流探讨。
本文原创发布于人人都是产品经理,未经许可,不得转载。
需求的生命周期是否可以包含一个“验证”的阶段呢?在需求评审通过并实现后,对这个需求的带来的影响和变化进行评估。
都在研究道,道法自然~!