PRD中写用例的注意事项

产品需求文档(Product Requirement Document,PRD)在 WEB/软件项目中的作用不言而喻,一份好的 PRD  能够使整个项目事半功倍,因此花在 PRD 上的时间成本通常也是非常可观的。我见过几个内部需求项目,PRD 的 word 文档竟然也有几十M之巨,产品需求人员在其中所耗费得精力可见一斑。

chinapm 中汤圆将 PRD 的核心概括为

该文档中,侧重的是对产品产品功能和性能(即“产品需求”)的说明,相对于MRD中的同样内容,要更加详细,并进行量化。

而 PRD 中这个“详细”和“量化”究竟到什么程度,是产品管理者经常遇到的问题。一方面,如果 PRD 中的需求描述或用例说明没有具体到具体细节操作,一旦开发人员理解有误或不完整,则会对出现不断的变更或返工(通常,开发人员喜欢闷头开发);另一方面,如果将 PRD 内容描述得过分细致,则又会出现很高的成本,何况百密一疏的情况也是非常多见的。如何解决这个问题呢?

编写有效用例》一书中提到了描述事件流程的基本方法,不论具体的用例是由需求人员做,还是技术人员做,都是需要了解的。对于用例中的 include 部分一定要细致入微,而 refine 部分则可以分清优先级考虑。

include,表示你要在一个用例当中包含另一个用例,并且被包含的用例是必须的,如果缺少被包含用例,则主用例就不能完成。比方,在用户管理场景中,要删除一个用户,你必须先查询到该用户,然后再点击删除。那么查询用户用例就是删除用户用例的一个include用例。
refine,是指对一个用例更精细化的描述。精化过程不会改变原来用例要包含的内容,只是更加细致。比方,取钱是一个用例,在描述用例场景时,你会用核对帐号,效验密码等活动来描述取钱的场景。在概念分析时,你可以把核对帐号,效验密码等定义为用例来描述取钱的过程,这时核对帐号,效验密码这些用例就是取钱的一个精化。它们实际上描述的仍然是取钱这个过程,但是取钱在概念阶段被精化成了核对帐号,效验密码等粒度更小的用例,这此用例仍然需要描述用例场景,例如核对帐号的过程、效验密码的过程等。
这些精化出来的用例向上要能够满足取钱用例场景的需要,向下则要更进一步能接近系统分析所需要的粒度。
同样的道理,如果需要,核对帐号,效验密码等用例在系统分析阶段还可以再次精化。但是它们虽然改变了名字,所描述的内容也从业务描述精化到了系统交互,但描述的仍然是取钱这一个业务。

当然,最重要得依旧是团队合作。在项目运行中,可能发生任何事情,但只要大家做好沟通,没有什么问题是不能被解决的。coffeewoo 中有篇关于这方面的解答非常经典,我就不班门弄斧了。临近春节,快递都放假了,不然也想尽快拜读一下他的大作《大象–Thinking in UML》。

分享到:
  1. 如果产品的各个功能相互关联在一起,就是经常有一个设置影响很多功能但这样的设置又很多的情况下,UC应该怎么写呢?