需求是什么?程序员的需求和我们口中的需求不一样,我们的需求是我们需要个什么东西,而程序员口中的“需求”,一般指“软件需求规格说明书”、“Software Requirement Specification (SRS)”。那么什么样的需求文档对于程序员来说是好的需求文档呢?
一般人认识的需求规格说明书,包含且仅包含用户需求,这应该算最基本的了。有了用户需求说明书,不能算好的需求文档,只能算基础。用户需求使用功能列表和用户用例来描述。而用户需求作为整个需求体系的第三层次,变化是相当剧烈的。当然,对于程序员最蛋疼的人机界面的变更等等,并不是用户需求的主体,属于用户需求的边角余料。
对于一篇好的需求文档,由需求工程师们或产品经理们开发,最终交付给开发团队。这样的一篇文档下来,其中的内容是很多的,而且很丰富。而我们的“程序员”们,到底看了其中的多少内容呢?他一般的是直接跳过背景、目的、范围,跳过业务描述等所有内容,直接找到跟自己相关的功能描述,开始干活。
所以,在程序员眼里,一本好的需求,一个好的需求文档其实就算你写的天花乱坠,那么估计也不会看太多,他会直接越过去,找到和自己相关的部分,然后开始工作。
能将纷乱的业务描绘清晰易懂,文档方式不限要能方便查阅。
原型图、流程图是少不了的,图形方便人明白。原型图不愿定全要有交互结果,但要害部分、易疏忽部分照旧需求的。流程图特殊能表现一个人的逻辑思想、系统思想以及严谨水平。
标准化的笔墨性文档。明晰精确的描绘题目,内容前后一致,种种关联阐明得逻辑严谨,种种业务术语,标准、一致且有备注。
从需求的视点来说,如果你觉得需求改变没完没了,诲人不倦,那么,你应当希望需求标准说明书包含愈加高层次的需求,这样,你就能把我用户需求的编制根据,这样,需求中的过错,遗漏,自相矛盾,你就能够第一时间发现;你也能够反思自己的编码是否契合事务意图,唯有契合事务意图的代码才干不朽。
所以,在我眼里,一本好的需求,必定也有必要包含尽可能完好的事务描绘和事务意图描绘。好的需求是从背景开始打开的,从职业谈起,到该项事务的规划,到用户需求的规划,层次明晰,条理清楚。这样才干帮助读者掌握整个文档的思路和头绪。
还有一点,案件的最后要把一些数据运用表格的形式汇总,这样愈加的一望而知,用到的时分也不需要再去从案件的正文里边去找出来了。比如说道具价格、奖赏的物品id和个数什么的,因为有一些表单需要开发来保护,这样就清晰便利多了~