随着计算机科学发展,越来越多也的兄弟姐妹们从事需求分析的工作,这里我大概分为一类是专业技术人才也就是从在学校就接收过专业的系统培训和学习。另一类则属于我们这类起初是从事程序开发工作,经历了几年的程序开发工作后慢慢转入软件设计和需求分析阶段的工作。以下我来总结一些我在做需求分析的十几年过程中对软件需求分析中与人沟通的一些内容,希望对大家有所帮助。
一、需求分析的任务与目标
这个部分我就不在大费口舌了,大家都清楚需求分析任务就是为了搞清楚软件是要“做什么”。
目标呢就是深入的描述出软件功能和性能,说的简单点就是“在什么范围内做什么”。
二、面向人的需求
这个部分就是本文的重点了,为什么我把它起名字为“面向人的需求”,一般在需求分析的方法中主流的不是面向结构的和面向对象的吗?为啥就出来了各面向人的需求呢。人是获取需求的主体,百分之八十以上的需求入口都是来自人。那么问题来了如何能够高效的准确的高的获取从人那里获取到需求呢?请继续向下看。
1、由上至下逐层分解
面向人的需求分析的关键也是类似结构化分析的一样,要从上至下逐层分解 ,首先我们相信大多数的项目中需求目标是最上级的领导制定的(这个地方解释一下,切记不要纠结是不是最高领导其实可定义为项目负责人),那么首先我们先从和领导沟通,在和领导的沟通中呢我们要注意聆听这个期间我们要做好记录,这个记录要在今后的需求获取过程中得以验证。
2、需求采集
需求采集的过程就是与各业务岗位人员(相当于用例图中的软件使用者)进行沟通或是获取数据接口等的过程,首先我们要与岗位人员进行反复沟通大致我总结为三个阶段,第一阶段一般是需要岗位人员讲述一下目前主要工作,在我们要制作的软件中所处的角色,在他的讲述过程中我们要做好记录(建议用录音设备记录),这个地方说明下在与首次与岗位人员沟通前建议由项目的使用方负责人先和要沟通的岗位人员打个招呼(历史经验来看这样效果比较好)。
3、需求清洗
对采集的数据是需要进行清洗的,首先去除一些与项目无关的内容(每次沟通中的录音难免有一些客套话或跑题的),其次要对相同的业务的使用者的阐述数据进行比对,如发现在同一个问题中有不同表述的情况,那么就要把这些内容单独记录,然后在下次沟通中作为重点问题进行沟通,必要时根据实际情况进行业务参与(建议以查看为主即观看业务如何进行的),业务参与也是需求获取的一个重要组成部分。
4、数据分析
以上我们看到在需求的获取及清洗过程中确实会产生很多问题,诸如以上提出的同一个人在几次沟通中对相同业务有不同的表述的问题,我们亲身参与了业务(实际可能多次参与)在结合岗位人员的表述我们就能发现问题所在,以下举个简单的例子:
有一家水泥生产企业打算制作一个生产销售的一个全流程的一个管理系统,那么在对销售岗位业务人员进行需求获取的过程中便出现了以上问题,第一次沟通中她对我说销售的对象分为个体的还有国企的,个体的销售费用是一类价格,国企的销售是一类价格。第二次我们在沟通的时候当时的那个销售人员并不在现场我询问另外一位销售人员我说到为什么卖给国企的价格和卖给个体的价格不一致(其实后来我后悔了,这样问其实是有点冒失的)?,他说为什么不一样,价格是一样的。卖给国企的和卖给个体的价格就是一样的。我又追问你确定是这样吗?(这么问也是有点冒失),他狠肯定的回答我说是的。
其实当时我是刚刚接触需求分析工作不久,在这个问题上我就有点困惑了,如果这个确定不下来必然是影响了很多业务流程的。
那么我就要对这个需求进行分析,是第一位销售人员说了假话?还是第二位人员说了假话?还是?
没办法我第三次来到这个岗位这次我并没有询问,而是选择在销售部门静静的坐了一天,在一天里总共有40几位购货者,其中大多是个体人员,还有几位是企业人员。经过我的观察及与购买水泥的人沟通,他们执行的是同一类价格。这个时候我可以断定的是这些购买者并没有不一致的情况,刚好今天进行业务销售的是我第一次沟通的那位,我不解的问她为什么您当时跟我说个体和企业会执行两个价格,而我昨天和今天看到的是价格都一致呢。她说是的因为我前天沟通的时候那天是企业会员日所以企业购买的价格会低于个体购买的价格(蒙圈)。
以上的例子说明了,有一些特例并没有在两次沟通中所被发掘出来,而往往这种特殊的情况因素才是软件设计阶段的主要需要考虑的,如果一旦遗漏或产生偏差将对整个软件产生重大影响。