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