需求过程涉及到的一些对象及关系图:
其中:
1、工作
指完成业务的系统(包括人的任务、软件按系统、机器、科技设备),实际上包括了用于生产拥有者的产品、服务和信息的所有东西。
要构建的产品必须改进拥有者的工作。只有理解了这项工作和它的预期输出,才能知道怎样的产品对拥有者最有价值。
2、业务事件
它是发生的一些事情,这些事情让工作以某种方式做出反应。
业务事件可能发生在工作范围之外(外部事件),或者是因为到了做某事的时间而发生(时间触发的事件)。
3、业务用例(BUC)
针对每个业务事件,有一个预先计划的对它的响应。它包含一些可识别的过程,一些被存取的数据,产生一些输出,发送一些消息,或是这些事情的组合。它是一个功能单元,这种单元是编写功能/非功能需求的基础。
4、产品用例(PUC)
BUC中由自动化系统处理的部分就是PUC例,有时候PUC的功能就是BUC的功能(你决定自动化所有的东西),但通常功能的某部分不会成为PUC,你决定这个任务最好由人来完成。它不是在需求调研开始时假定的,而是分析了工作后小心得到的结论。
BUC包含响应业务事件的所有功能,而对应的PUC只包含实现在产品中的功能。
5、功能/非功能需求
功能需求:指明了产品必须做的事情,即产品为了满足它存在的根本理由而必须执行一些动作。
非功能需求:描述了产品必须具备的品质,这些需求让产品有吸引力、易于使用、快速、可靠,或安全。
6、验收标准和理由
需求的测量指标就是验收标准,它量化了需求的行为、执行方式以及一些其他品质。目的是为了保证需求本身是可测量的,从而达到测试方案满足和符合需求。它既不是测试,也不是对测试的设计,而是测试提交的产品必须采用的测试基准。它是构建测试用例的输入信息。
理由,是需求的原因,或存在的道理。加上理由,更容易理解真正的需求。是业务和提交的产品之间的认知纽带,知道了存在的理由,业务分析师就能够发现正确的需求表达,开发者就能够构建正确的产品。
7、场景
它是情节梗概,或一系列假设的步骤,它用自然语言讲故事,帮助需求分析师和利益相关者对业务用例、产品用例达成一致理解。
场景所展示的细节程度是针对业务利益相关者的。如果需要,你可以详细说明任何步骤,提供底层细节。同时,次要细节可能仍然需要确定,这些将通过开发者、需求分析师和利益相关者的对话完成。
posted on 2014-05-05 21:03
cheng 阅读(1074)
评论(0) 编辑 收藏 所属分类:
需求分析