登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 行业 > IT > 辨析业务需求与软件需求

辨析业务需求与软件需求

返回>

2019年01月25日    作者:乔东    来源:微信公众号“IT管理工匠”

A-A+

  在很多机构的应用系统开发的过程中,业务部门提出具体的软件功能的开发需求,信息技术部门按照要求实现具体的软件功能,这是很多人印象中的业务部门与技术部门的配合方式。随着信息技术部门的工作定位,从原来这种包工队式的“支持”到“融合”再到“引领”,信息技术部门所面对的“需求”其实也悄悄的发生了一些变化,从“信息技术部门是利用信息系统来做业务的”这种定位来说,信息技术部门需要更向前走一步,参与到新产品/新服务的设计当中,参与到更早的业务需求当中。这样就更加凸显了业务需求与软件需求这样两个不同层次的需求概念的差别:


  业务需求反映的是业务层面针对各种经营管理问题的解决方案,其中既可能包括信息技术手段的实现,也包括人工处理的方式,在一个完整的业务处理流程中,往往是“人-机”交替进行的,而且往往可能会涉及多个不同的信息系统,会涉及多个系统之间的交互衔接问题,所以一项业务的完整流程只有在描述整体业务流程的业务需求中才能体现出来。


  软件需求则是在整体业务需求当中,对于那些需要通过信息技术手段实现的业务处理环节,针对所涉及的每个信息系统要实现的具体功能的需求,是软件功能开发的依据,是对业务需求的分解与细化。软件需求的形成是受所采用的技术实现方式影响的。在许多企业当中,一项完整的业务流程需要多个应用系统共同配合才能实现,所以常常会同时形成对应不同应用系统的多个软件需求。


  可以看出,业务需求是因,软件需求是果。只有在保证业务处理流程的完整性和一致性的前提下,落实到各个软件系统的软件需求才是可靠的,才能保证按照各自软件需求所交付的各项功能,与人工处理的环节配合起来,能够共同实现所需要的完整的业务流程,满足业务需求的要求。业务需求关注完整的业务解决方案,而不只是关注其中需要信息技术实现的部分。业务需求不等于软件需求,它是软件需求的前提。当然,在科技手段越来越重要的今天,技术手段的实现方式直接关系到不同业务场景下的业务特点和客户体验,所以业务需求中有时也会将采用哪种技术手段作为假设前提,必须以技术可行为前提。但是软件需求常常不能完全反映业务需求的全貌。不以业务需求为前提的软件需求,由于缺乏可靠的前提依据,往往有着“只见树木不见森林”的风险。


  在产品管理当中,大家基本都知道有BRD、MRD、PRD,这三者之间是有内在因果关系的,一个新产品,基于BRD进行决策后,利用MRD设计市场策略,再通过PRD定义产品,然后才是产品的实现与交付。前面提到的业务需求应该就是PRD的主要内容。经过这样的产品管理过程,才能保证开发出的产品是能够为企业创造价值的,这样的业务需求才是高质量的。因此,企业中的信息技术部门,在谈到需求交付时,不仅要做好传统的软件需求的交付,更要做好面向业务需求的交付,如果有条件的话,还应该进一步参与到产品需求当中,使信息技术手段更好的发挥作用。


  对于业务需求和软件需求这两类不同层次的需求来说,在企业的新产品开发过程中需要加以区分,特别是在产品管理体系不够明确的情况下,否则会出现偏差。这种偏差主要会存在两个方面:


  一种情况是,用业务需求代替软件需求。业务部门/产品部门针对要解决的业务问题,形成了业务方案,从逻辑上形成了业务的处理流程和处理规则,但是并没有进一步在此基础上,去识别、确定哪些业务处理过程需要通过信息系统来实现,更没有从操作层面上对软件功能提出具体的软件需求,如果简单要求技术开发人员通过理解业务需求而自行决定软件需求,这样很容易带来两方面的问题,一是用户操作体验可能比较差,虽然最终能够符合业务需求中各种流程、规则的要求,但在操作细节上自由发挥、考虑不细,结果是用户体验很差,二是在将业务需求细化为软件需求过程中,由于业务需求本身不够具体,加之技术人员对一些业务规则的理解时常会出现偏差,导致开发的功能不正确。这种用业务需求代替软件需求的情况,对于软件研发来说,通常会被说成是没有需求,使软件的设计、开发、测试都缺少具体的依据。


  另一种情况是,不重视业务需求而过度强调软件需求。在业务方案还没有考虑清楚的情况下,直接提出软件需求,要求尽快完成软件研发推出相应的软件功能。由于缺少了对业务方案本身的研究,就难免出现方向性、结构性的偏差,导致在软件研发过程中,随着业务方向的摇摆而不断进行需求变更,甚至是软件功能开发出来后的推倒重来。这种情况的出现,往往反映了企业中存在市场目标不够明确、产品管理不够成熟、业务与技术的管理层次不清晰等问题,是业务创新能力不足的表现。


  在实际工作中,对于业务需求和软件需求,往往分成多个步骤来处理。首先确定整体业务需求,明确整体的业务流程和相关规则。然后由技术部门和业务部门共同确定业务需求中哪些过程需要采用信息技术手段来实现,基于业务需求形成技术解决方案,在技术解决方案中,根据应用架构的要求和各个应用系统的功能划分,进一步确定各应用系统要实现的业务处理功能,形成各应用系统要实现的软件需求范围。第三步才是结合各应用系统的技术实现方式,针对各应用系统的软件需求范围中,进一步细化形成软件需求,作为具体应用系统技术开发的依据。


  在技术部门开发应用系统的业务处理功能的同时,相关的业务操作部门也要同步开发需要人工处理的各个环节的操作规程,制定相应的操作步骤、规则,对各种可能出现的异常情况的例外处理等。这也是新产品开发/实现业务需求过程中必须要完成的工作。只有当业务部门和技术部门按照整体的业务需求分别完成了人工处理和系统处理的所有处理过程后,整体的业务流程才算得以实现,具备交付使用提供服务的条件。所以,业务需求实际上是需要相关业务部门和技术部门共同实现的。


  业务需求反映业务全貌,是针对要解决的业务问题的,而软件需求仅针对业务需求中需要由某个具体信息系统进行处理的功能的进一步细化,不一定能反映业务全貌,是结合软件具体技术实现方式对业务需求的细化。业务需求的整体交付主要由产品部门统筹负责,软件需求的交付主要由信息技术部门负责,人工处理部分的操作规程由相应业务部门负责。无论是产品部门,还是信息技术部门和业务操作部门,都要能够清醒的区分业务需求与软件需求这两者的不同作用,能够分层次的、有序的组织好企业的新产品开发工作。

责任编辑:王兴钊

标签:软件
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3

京公网安备 11010202007990号


PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设