一个需求规格说明书的问题记录

1)  需求文档主要描述了各个数据项的新建,删除,修改,列出了相应的数据项。

但之间的关系没有进行描述;这举2个例子。

1

<礼品分类> <礼品管理>关联时,关键数据为<分类编号>

文档中没有描述,之间的的关系。

比如应该描述:删除,修改礼品分类时对礼品管理的影响。

 

例子2

<礼品管理>中关键数据我随便举几个:

礼品数量:实际使用意义?  业务流程不清晰

剩余数量:数据操作来源分两种:(文档中也没有描述,个人认为这是个需求分析过程,不算属于设计。而需求分析也是发现需求的一个重要手段。)

1)用户领取礼品是递减1    问题:领取礼品存在一个时间差的问题:是下了订单即减1,还是管理员审批发货后再减1.

2)移动管理员手动在礼品管理中修改剩余数量  问题:手动修改,存在边界数量问题。手动修改时如果本来有3个,手动修改为了一个。这时有2个人申请了该礼品。

就存在争议问题。是否可以通过锁定剩余数量来解决?允许手动修改这种关键数据时。必须记录操作日志。(对用户来说可能是隐藏需求

 

原需积分:只是展示用?

折后积分:和原积分的关系?

 

订单由消费者制定,  扣积分什么时候??

A)管理员审批发货后扣积分的话,在申请时需要对订单中可能扣的积分锁定??如果不锁定,可能10000的积分产生多个9999的订单。

又需要在审批时能查看订单者的积分信息。

B)下订单时即扣积分,能解决问题。审批时,如果未通过就需要归还积分。

 

2)文档共性问题:

完整性:为什么没有用户下订单的描述??

 

数据孤立:如果只从文档,我们无法清除的知道这个系统完整的样子是什么。只有一个一个独立没有联系的数据点。

如果我是一个开发人员,拿到这份文档,如果不问只能做出的一个一个没有关系的 form grid

 

系统需求的描述缺乏:作为需求规格说明书(不是需求说明书),还有系统需求(非业务需求)需要在文档中描述。

 

涉众似乎没有说明清楚。

 

建议:

首先:分析积分处理的整个业务流程:积分如何产生,如何消耗。

然后:就这个流程中,在现有的数据项中找出在流程处理中关键的数据。分析关键数据的处理方式。从中发现除数据外的需求点。主要为操作处理上面的需求。

发现用户操作习惯,和隐藏需求点。(在我看来,这是有条理的分析过程,算是方法学吧)。

最后:这个过程中可能发现很多需求,需要进行控制。

 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值