当前位置: 首页 > 互联网, 历程 > 正文

从出差谈软件需求分析

这周,在局方领导的要求下,又出差去了一次台州,为的是项目二期功能开发的需求讨论。从工作沟通的角度上考虑,我十分赞成面对面的沟通与处理。且不说电话沟通或是即使通讯沟通能否把需求讨论彻底外,面对面的沟通更能体现需求方对项目的重视度,紧迫性和要求。反过来,能为项目经理在项目管控上提供支持。更大的好处对开发人员来讲,增进彼此之间的交流,方便后续开发过程中的沟通与交流,保持项目的平稳性都有很大的帮助。也许面对面的沟通会增加额外的成本,但反过来讲对增加项目进度,保持项目活跃性是个不错的办法。

需求免不了要开一番会议,需求方往往将密密麻麻的文字或是红头文件一堆扔给你先让你自己看。而我们在谈论需求的时候,还是要和客户一起将这些文字从头到尾先过一遍,先明白大体要实现什么样的功能,这更好是在会议之前就阅读完成。明白个大概之后,然后就有必要逐行逐条学习这些文字了。在这个学习的过程中,就不能简单的在文件上划线了,需要将重要的点,概念,处理逻辑等记录写下来。列出几个要点,一二三四,或是列出几个可能的模块功能点出来。这些就是在会议的过程中,我们需要第一时间收集和整理的。

客户不大可能一直陪着你做需求分析,他们有他们的工作。所以接下来的时间里,你就可以整理功能要点了,将之前列出的模块或是功能点进行细化,用软件或是程序的语言描述要实现的功能点,比如说:实现某某查询功能,导出功能,要计算某个值,这个计算逻辑的描述等等。除了功能列表的描述,更深入的就是画一些流程,表格或是框架结构了。这就是体现你软件开发功底,如何将需求转变成软件语言能力的时候。画个流程图,或是软件框架不仅能让你从全局掌握整个软件,也能很好将软件功能或是流程逻辑展示给客户的方式。是判断需求是否准确的重要方式。

在编写功能设计或流程图的时候,要时刻与用户或是需求方保持沟通,不清楚的地方要及时记录,可随时沟通或是一起提交给客户进行现场确认,及时改进我们的功能设计文档或是流程图。将之前的疑点或是不清楚点逐一解决。用户自身无法确认的,也要之后督促用户后续及时更进解答。这部分的工作在需求沟通环节也是相当重要的。

最后就是详细设计环节。当你了解整体的功能设计之后,在功能描述的前提下进行相关的结构设计包括数据库的设计就相当于给萝卜填坑了。这部分的数据设计只要将需求功能细化到具体的对象或是逻辑即可。这部分设计大体不必发给用户确认,但作为项目材料后续也是应该发给用户的。

需求分析一般不必附上项目的开发计划与进度,但如果需要做的细致,也可以按功能模块制定项目的开发进度和计划,从而可以预估出工作量。而这也常常是项目经理做的事情。项目的工作量可以从很多出发点考虑,但从功能点来说是最简单最直接的方式。软件本身就是为实现一个个功能而设计的,所以按功能来安排进度计划也就顺其自然了。

本文固定链接: http://www.byhard.com/?p=1658 | 海纳百川

该日志由 byhard 于2016年11月05日发表在 互联网, 历程 分类下,
原创文章转载请注明: 从出差谈软件需求分析 | 海纳百川
关键字:
【上一篇】
【下一篇】

从出差谈软件需求分析:目前有1 条留言

  1. 沙发
    增达网:

    你的博客就像冬天里的一把火!

    2016-11-17 09:25