1) 需求文档主要描述了各个数据项的新建,删除,修改,列出了相应的数据项。
但之间的关系没有进行描述;这举2个例子。
例1:
<礼品分类> 和<礼品管理>关联时,关键数据为<分类编号>。
文档中没有描述,之间的的关系。
比如应该描述:删除,修改礼品分类时对礼品管理的影响。
例子2:
<礼品管理>中关键数据我随便举几个:
礼品数量:实际使用意义? 业务流程不清晰
剩余数量:数据操作来源分两种:(文档中也没有描述,个人认为这是个需求分析过程,不算属于设计。而需求分析也是发现需求的一个重要手段。)
1)用户领取礼品是递减1 问题:领取礼品存在一个时间差的问题:是下了订单即减1,还是管理员审批发货后再减1.
2)移动管理员手动在礼品管理中修改剩余数量 问题:手动修改,存在边界数量问题。手动修改时如果本来有3个,手动修改为了一个。这时有2个人申请了该礼品。
就存在争议问题。是否可以通过锁定剩余数量来解决?允许手动修改这种关键数据时。必须记录操作日志。(对用户来说可能是隐藏需求)
原需积分:只是展示用?
折后积分:和原积分的关系?
订单由消费者制定, 扣积分什么时候??
A)管理员审批发货后扣积分的话,在申请时需要对订单中可能扣的积分锁定??如果不锁定,可能10000的积分产生多个9999的订单。
又需要在审批时能查看订单者的积分信息。
B)下订单时即扣积分,能解决问题。审批时,如果未通过就需要归还积分。
2)文档共性问题:
完整性:为什么没有用户下订单的描述??
数据孤立:如果只从文档,我们无法清除的知道这个系统完整的样子是什么。只有一个一个独立没有联系的数据点。
如果我是一个开发人员,拿到这份文档,如果不问只能做出的一个一个没有关系的 form 和grid。
系统需求的描述缺乏:作为需求规格说明书(不是需求说明书),还有系统需求(非业务需求)需要在文档中描述。
涉众似乎没有说明清楚。
建议:
首先:分析积分处理的整个业务流程:积分如何产生,如何消耗。
然后:就这个流程中,在现有的数据项中找出在流程处理中关键的数据。分析关键数据的处理方式。从中发现除数据外的需求点。主要为操作处理上面的需求。
发现用户操作习惯,和隐藏需求点。(在我看来,这是有条理的分析过程,算是方法学吧)。
最后:这个过程中可能发现很多需求,需要进行控制。