谈需求三要素,其实就是从需求是什么开始,理清几个最基本的概念,这个时候不得不提的就是需求的三个层次:业务需求用户需求软件需求,因此,我们这个时候谈的需求不是管理学中的概念,不是马斯洛五层次需求模型中的需求,而是基于产品来谈的需求,更准确的说是基于软件产品来谈的需求.
下面把相关概念分别描述:
业务需求:从非技术商业的角度来谈的目标,和计算机/软件没有关系,即从业务的角度,客户希望达到的目标或效果,比如客户希望HRM体系完整,HR流程运作高效畅通,人力成本控制在某个额度内等等.有效合理的目标可以用SMART原则来衡量,这里就不再累述,客户所谈的目标越符合SMART原则,代表业务需求越清晰.目标也往往意味着解决问题和创造机会.
用户需求:基于业务需求,同时结合计算机软件,分析和提炼需要用计算机来帮助人工完成的需求,毕竟不是所有的业务需求和目标都是能依赖计算机来完成,也有很多是必须要人来具体实施,在计算机中不能操作的,比如体检流程中的体检本身,是需要医生亲自去做的,但相关记录和整个流程可以在计算机中进行操作. 用户需求可分为功能需求和非功能需求(比如质量要求).
软件需求:简单理解,需求规格说明书的内容就是软件的需求,即在软件中如何实现用以解决用户需要解决的问题.这个时候才是软件开发人员需要关注的,到了他们可以直接进行开发操作的层面.
接下来我们看到底什么是需求的三要素?
三要素是指问题/业务背景/解决方案,正是这个解释,才让自己对需求的理解有了从实践上升到理论高度的感觉,一直有这个意识,但是之前都没有找到一个适合的表达方式,平时现场往往反馈都是解决方案层面的需求,不是最原本的需求,问题层面的信息才是真实的需求,正是因为经过多个环节的抽象加工和解决方案的思考,使得最终环节受前面环节的影响,容易忽视最开始的客户原本需求,导致没有得出正确的解决方案,或未得出相对最佳的解决方案.
因为业务驱动,以业务为中心,不是以产品或技术为中心,正确理解客户的需求,得出正确的解决方案,才是最有价值和作用的,才能做出符合用户需要的软件产品.
软件需求分析作为一个专业领域,也是计算机/软件/信息系统发展过程中不断细分发展出来的,和其他很多领域的产生是同样的道理,比如现在UI设计也逐步成为了一个专业领域,之前是不存在的,再比如物流管理等领域,也是社会发展过程中逐步成为一个庞大的专业领域.
需求分析的整体结构，逻辑树：应用系统－业务子系统－3个层面(行为/功能,数据,质量).其中应用系统/业务子系统,是高层关注的内容,把业务分块,需要用到层次图/构件图等方法,业务系统之间需要考虑到接口．
业务子系统对应的３个层面,也是逻辑关系的核心：
1) 行为／功能.对应到业务流程－活动－步骤,其中业务流程是中层关注的内容,流程体现分工和控制,活动和步骤是基层操作者关注的内容,业务流程层面的明晰可用活动图,操作层面的明晰可用用例图．
2) 数据.对应的是报表,体现数据约束功能,另外是要建立好领域模型,搞清楚其中的数据关系数据构成数据推演,都有对应的工具可以应用到,比如数据推演用状态图．
3) 质量.主要是一树一卡,卡即目标产品决策卡,树代表什么记得不是很清楚,估计就是整个逻辑关系树吧．
从逻辑树的思考角度,解析了需求分析全局,是专业需求分析工作者需要具备的整体观,而后再是去考虑细节
在系列之二中谈到了需求分析的逻辑树,这章节里介绍下基于信息系统来看企业的价值树.
企业的价值树可分为3个层面:
1.高层. 关注的是目标(商业价值),不太关注具体的内容和细节,希望通过信息系统解决现存问题,或发掘和把握潜在的机会.
2.中层. 关注的是关键核心需求(利于管理和控制),主要业务流程是否畅通,是否有利于分工和协作.
3.基层. 关注的是效率质量便利,从操作/执行层面对系统有很多细节的要求.
通过价值树的分析,很容易就明确了在一个企业中,不同层面的人对信息系统的关注点是不同的,原因就在于各层面的价值诉求不同,这也就要求需求分析必须是要从多层面去分析问题,而不是片面地站在某个层面,其中尤其要关注到中高层面的需求,信息系统的价值最大化才能更好地体现.
三个层面对应的分析工具是:
1)构件图层次图上下文关系图.
2)活动图跨职能流程图.
3)用例图.
事实上,价值树和逻辑树是有对应关系的,本质上是相通的,只是分解的角度差异,都为需求分析提供了全局思考的框架.
优先级是一个非常重要的思维理念和方式,不仅仅是在平时工作中可以用到,更不是只有在软件需求分析中可以应用,在更广泛的工作和生活中都可以借鉴这个思维,因此,当了解到确定优先级的3种模型时,有一种惊异和收获感,把平时知晓但笼统的概念一下子具体化和可操作了,这就是模型带给我们的帮助.我们虽然不能做模型的奴隶,但不能否认模型往往为分析问题提供了很清晰的维度和操作性.
模型1:业务模式决定优先级 (项目级)
|
优先级 |
业务类型 |
频率 |
|
关键 |
主营业务 |
高 |
|
重要 |
主营业务 |
一般 |
|
有用 |
非主营 |
高 |
|
一般 |
非主营 |
一般 |
模型2:满意/不满意模型 (项目级)
|
满意度 |
得分 |
×
|
满意度 |
得分 |
|
非常满意 |
5 |
非常不满意 |
5 |
|
|
比较满意 |
4 |
比较不满意 |
4 |
|
|
满意 |
3 |
不满意 |
3 |
|
|
一般 |
2 |
一般 |
2 |
|
|
无所谓 |
1 |
无所谓 |
1 |
如何应用该模型:不做会怎么样? 不做,一个时间周期内影响多少次?(频率)
模型3: 卡洛模型 (产品级)
1) 基本性需求. 必须满足和达到的.
2) 期望性需求. 实现了满意,没实现就不满意.比如手机的照相功能.
3) 兴奋性需求. 领先市场,客户都想不到的都实现了.
模型1和2是可以结合用的,都是项目级的模型,另外也可以把业务和技术结合起来排优先级,把业务上优先级高的和技术最容易实现的最优先考虑, 是实现价值最大化的有效方式.
事实上,引申一下不难发现,模型1和2也可以为我们的时间管理提供有效的分析帮助,为平时工作和生活中碰到的一些事情提供了一个很好的分析思路.
在对需求分析的逻辑树和价值树的解析过程中,已经谈到了在需求分析的整个过程或者说是整体结构中,可以应用到哪些分析工具,其实工具的背后往往也是一种思想的体现.
主要介绍用来理清行为(功能)脉络的两个工具:活动图和用例图.
1.活动图:事到事,体现业务流程,把业务从开始到结束整个过程串起来,包含了多少个活动,是中层管理者最为关注的,不一定所有的活动都会在系统中来实现.
2.用例图:人到事,体验用户意图,是用户思维,从业务视角看待系统的思维方式.用户通过系统完成特定的工作,实现特定的业务价值,是操作层最为关心的.
用例图的层次颗粒度的把握是实际中的难点,层次关系一定要搞清楚,颗粒度的把握要考虑操作对象.
画活动图和用例图一个普遍的应用的软件是Rational rose .
之前虽然了解到有这两种图,但对具体如何应用一直很模糊,平时也几乎也没应用,虽然不是必须要用到,但对这些图的本质有明确认识及了解其基本的操作方法,还是很有必要的.
需求分析师是一个职位,伴随信息化领域的专业化发展和分工,从事这个领域的人员越来越多,那么这个职位比较通行的能力模型是什么样的呢? 经过有关专家的总结和提炼,主要有如下5个方面的能力要求:
1.技术理解力. 包含两个方面:
1)技术价值.了解技术所带来的价值,了解基本的技术术语,不陌生,毕竟需求分析师也属于技术这个圈子了.
2)技术发展趋势和技术的相关约束.了解新技术带来的可能价值或影响,及技术对业务产生的约束作用,比如有些事物在技术上是可以实现了,但现实环境不能应用.
2.解决方案创新力.
这是合格需求分析师到优秀的跨越. 解决客户的问题,创造性地找出最佳的解决方案应是需求人员不断追求的自我提升.
3.沟通力.
在5种能力中处于中心地位,包含语言和文字沟通,语言沟通方面需要具备的技巧有沟通访谈谈判技巧体态语言修炼,这些都要基于心理学的基础,尤其是社会心理学,文字沟通方面要掌握金字塔原理. 通过沟通可以弥补自身的不足,放大个人的能力.
4.管理力.
熟悉基本的管理理论和管理技术,包含项目管理等职业管理技能.
5.业务分析力.
这是需求人员最基本的一项能力,至少熟悉乃至精通业务知识,熟悉应用流程的思想来分析和串联知识.
上述概括的5种能力,是比较通行的,不管是什么业务类型,什么企业环境中,应该都是可以适用的,可以用来衡量和评价需求分析师的能力.
从事这个行业的人员,可以参照上述能力模型(对应的也就是知识结构),对照自身,找到不足的地方来提高和完善自己.