看实习生需求文档有感

最近我呆的公司来了一批实习生,在公司培训了几个礼拜之后公司决定对他们进行一些测试。就是给他们出了一些可选的题目,比如《xxx租房网》、《xxx档案管理系统》、《xxx图书馆》...等一些公司缺少的系统。公司主要有以下几个目的:

  1. 检查实习生的培训效果

  2. 通过一个完整的应用来测试同学们,同时从里面帅选出比较优秀的学生

      3. 为公司编写一个目前缺少的系统。

我们以租房网那个题目为例,公司只是提了一些必须有的功能,比如登陆,比如发帖等基本的一些功能,其他的并没有详细的要求。需求文档也是由这些几个一组的实习生来编写的,然后在自己实现自己的需求文档,并自己担任QA测试和发布。也就是说整个过程都是自己来独立完成的。

今天有一组的同学们写完了需求,我一看名字是xxx需求V4.doc,我当时心里还挺高兴的,都知道先自己过几遍需求,并且有版本意识。但是当我通读完需求之后发现了非常多的问题。考虑到这些问题基本上刚出校园的同学们大都会遇到,所以有感而发写了这篇文章。希望对大家有所帮助。如果文章中的一些观点不正确的话,欢迎评论大家一起探讨。

首先我打开他们的需求文档,有20多页的样子,整个需求文档没有图,仅有的一个图还是截的别的网站的图。其余的全是文字,整个需求文档没有很明显的段落层次感。慢慢的文字有一种让人做语文阅读理解的感觉。然后我从头阅读完,一一在上面标出了自己的疑点和建议。现在总结如下:

1. 需求文档的内容首先必须要明确,明确要做什么,要解决什么问题。当然最好也能有为什么要做这个需求。

2. 需求文档需要明确定义系统有哪些主要功能模块,每个模块有哪些子模块,有哪些主要页面,页面上有哪些按钮,系统有哪些主要角色,大致的交互流程是什么样的。文档中需要对细节的地方定义清楚。最好使用图或者表格的方式来进行表现。先在需求的上方列出主要功能点,主要的交互流程,然后在详细的描述每个功能点。另外要定义清楚细节。比如我看的这个需求中有一段:“信息发布后,系统立刻自动将该条房源信息推送给符合条件的求租者。”从这段话中,我的关注点落在了【符合条件的求租者】,我的疑问是什么样的求租者才是符合条件的呢?如何判断某个求租者是否是满足条件的? 需求中没有对这个点定义清楚,这个就是细节没定义清楚。而开发实现的时候这个细节却是必须要清楚的。所以 这个地方是一个问题

3. 新人写需求文档的时候最容易犯的错误就是脱离实际情况,比如我看的这个需求中写的【利用图片识别技术过滤虚假信息】,说实话我真心觉的刚刚本科毕业在公司培训了几周的同学能做出来这个东西,当然不是看不起大家的意思。我只是觉的这些有点脱离实际情况。写需求的时候一定要结合需求的工期,看看有多少天时间,团队成员的水平如何,执行力如何?做到“量力而行”。要记住,即便你的需求写的天花乱坠各种NB的技术好像都用到了但是基本的功能不可用,结果一定会远远不如那些需求很明确简单,但是实现的很不错,系统功能正常运转的方案。另外也没有定义清楚什么是虚假信息,如何判定是否是虚假信息。

4. 需求中必须对功能进行优先级排序,明确什么功能是必须要做的,什么功能是必须要在这次需求中做的。什么可以放到下次需求。哪些功能是可选的。建议在一开始的时候,可以先简化需求,做一个需求第一版。可能就是实现一个登录和权限的功能。然后完成运行之后在做发帖之类的功能。通过这种迭代的方式来保证质量和工期。最后如果基本必须的功能实现好了,如果还有时间的话,可以在进行添砖加瓦,锦上添花。

5. 对于新人来说,尤其是几个组做同一个需求的时候,千万别比较【谁的需求文档写的多NB,什么时髦的技术都提到了,用到了】,即便要比,也要比谁的需求文档写的更切合实际情况,谁的需求文档更能描述和解决实际的问题。有些人的需求写的内容看起来确实很nb,但是往往最后都实现不出来。所以我觉的即便功能简单,但是正常可用就是很不错的东西。 尤其是互联网的产品,最初都是一个原型,通过不断试错,快速迭代的方式来小步快跑的增加功能。

好了,就先写到这边吧。

原文地址:https://www.cnblogs.com/rollenholt/p/3766558.html