我们应当怎样做需求分析----软件需求与分析
阅读了《我们应该怎样做需求分析》一博,可以说这是我软件需求与分析这一课的敲门砖,给我指明了道路,让我明白应该怎样去走。
作者开始叙述了三件事:
- 东软:
a) 东软团队对一个项目进行10多次大变更,但是客户始终不满意,最终结果是团队里各成员都离开了东软,不再涉足软件行业。
b) 如果我们明白了这一点,深入地去理解客户的业务,进而想到客户的心坎儿上去,最后做出来的东西必然是客户满意的。记住,当客户提出业务变更的时候,我们一定不能被客户牵着走,客户说啥就是啥。我们要从业务角度深入的去分析,他为什么提出变更,提得合不合理,我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时,客户是乐于接受的,变更也变得可控了。
- 作者自己:
a) 客户给了许多正在使用的统计报表,报表都是手工报表,许多格式既不规范,又很难于被计算机实现,最终没有完成。
b) 客户提出的原始需求往往是不考虑技术实现,基于非计算机管理的操作模式提出来的。他们提出的很多需求常常比较理想而不切实际,毕竟人家是非技术的。但我们作为技术人员,需求分析必须实事求是的、基于技术可以实现的角度去考虑。那种“有条件要上,没有条件创造条件也要上”的鲁莽行事,结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。同时,计算机信息化管理就是一次改革,对以往手工管理模式的改革。如果我们上了信息化管理系统,采用的管理模式却依然是过去的手工模式,新系统的优势从何而来呢?因此,我们做需求就应当首先理解现有的管理模式,然后站在信息化管理的角度去审视他们的管理模式是否合理,最后一步一步地去引导他们按照更加合理的方式去操作与管理。
- 重大项目:
a) 作者在接到一个重大项目,面对一个十分复杂的场景的的时候,没有充分了解到每一个角色对项目的意见和需求,导致更加细节的业务没有分析到,以失败告终
b) 真正要完成需求分析,应该是一个一个的小会,1~3个业务专家,只讨论某个领域的业务需求,并且很多问题都不是能一蹴而就完成的,我们必须与专家建立联系,反复沟通后完成。需求分析必须遵从的是一定的科学方法,而不是盲目的大上快上。
最终得出一个结论:需求分析是做一个项目最重要的问题。
那么如何做好需求分析呢?
需求分析主要是调研:关于调研有如下环节:
- 初识
- 拜访
(这个是项目的开端,由于项目的开始是和人打交道,所以对不同层次的人沟通方式和内容都要因人而异,下面是作者的几个建议:1)树立良好的职业威信;2)进行详细角色分析,将与会各方代表对号入座;3)从宏观上制订目标与方案。随后的工作,就是与各方代码建立联系,逐一拜访他们,将需求调研工作一步一步进行下去。)
- 研讨会
- 需求研讨
5. 迭代
6. 需求捕获
(这一部分就是讲的就是项目的前期调研准备工作,我们想做一个项目,就要先知道客户想要什么样的东西,这些不是一下子就能领会到的,所以需要我们不断的领会,探讨。)
然后就是需求分析工作
1. 功能角色分析与用例图
2. 业务流程分析
3. 用例说明
4. 查询报表分析
5. 子用例与扩展用例
6. 行动图和状态图
7. 业务领域分析
8. 原文分析法
9. 领域驱动设计
10.非功能需求
为了完成项目,我们必须要做出分析。我们首先是调研,就是要了解到用户需要什么,而调研结果如何转化为我们程序员工作的需要,那就是我们进行分析的过程,我们要对我们调查到的结果整理,变成我们能看懂的,也是用户看见能理解的,这样既利于我们自己接下来的工作,也会让用户放心。
在用户分析中,最重要的一环就是需求确认:
1. 需求列表
2. 一个需求列表的实例
3. 快速原型法
4. 需求规格说明书
5. 评审与签字确认会。
接下来我将面临的是一个学期的软件需求课程,这个课程也许和上半年java+软工概论比起来要轻松一些,但是我认为涉及到的更精了。可以说我们之前接触的是如何编代码、如何处理自身问题,而现在我们的学习是如何完成一个项目,是关于和客户打交道,自己如果做的。
针对这半年的学习,我做了如下计划:
- 努力学习编程方面的知识,编程是程序员最低级的工作,但也是程序员最基本的工作,如果连编程都是问题的话,后续的工作都是空谈。
- 学习一下建模语言,上学期自己留下的恶果,现在要自己食了。
- 除此外,还要按照课本上的内容一部分一部分的吃透……
为此我做出了这半年的学习树: