标签：
需求过程把重点放在提交的产物上，我们需要得到这些产物，从而建立可测试和可跟踪的需求规格说明书。这些提交的产物为管理项目提供了早期的衡量标准。我们可以对收集、提取、编写和检查需求的过程进行剪裁，以便让这些过程能适合技术和文化环境。需求模板和需求项框架是提交产物的例子，我们可以根据自己的环境和术语来剪裁。一般的过程提供了理解需求概念的关键。
项目启动是一项突发性的活动，通过这个活动收集让我们的项目启动所需要的各种信息，并确定项目可行而且资金充足。启动阶段确定产品要做为起一部分的工作，并确定产品要实现的准确目标。启动阶段提供的其他产品对限定产品范围要有所帮助，并将作为后续需求收集活动的输入信息。启动阶段提交的产物为产品奠定了基础：产品的目的——关于产品应该达到的业务目标的一个简短的、可度量的陈述；客户——该产品是为谁构建的；顾客——对商业产品来说，谁将购买该产品；风险承担者——哪些人在产品中拥有既得的利益；用户——谁将操作该产品，他们的能力如何；限制条件——是否有些设计方案必须采用，对项目解决方案可以提供多少时间和经费；名称——该项目使用哪些术语；相关事实和假定——每个人都需要知道的是什么；工作的范围——什么是产品和项目的边界；估算的费用——实现产品需要花费多少工作量或资金；风险——揭示项目面临的主要风险的一份简短风险分析，这些提交产物放在一起，可以提供足够的信息，以得到启动阶段的最终产物；继续或终止的决定——该项目是否可行，考虑得到该项目的成本，是否值得！
通过引入业务事件的思想，我们可以合理的切出一部分工作，用于进一步的建模和研究。通过理解每个相邻系统对工作的影响，我们理解了产品范围的限制。通过对工作行为建模，我们得到了范围。我们不是通过预先假设会有一个用户和计算机，或者通过考虑现有的技术来得到这个结果的。通过使用业务事件来分割工作，我们有了一个指导方法，来发现所有的工作部分。这些工作部分处于相同业务上的原因而结合在一起。事件驱动的用况是事件响应（活动和数据）的一部分。这些事件响应应由产品来执行。参与者被挑选出来与用况进行交互，很大程度上基于他们对那部分工作的期望。用况成为了需求的“错”。也就是说，我们研究每个用况并确定他们的需求。通过把系统分解成这些小的、方便的单元，我们能理解期望产品完成的真正的工作，我们才能构建真正相关的、有用的产品。
在网中捕捉到的任何不恰当的需求将被质量关过滤。所以，如果在网罗过程中发现了一些无关的需求，不必太在意。质量关将减少需求的数量，只保留哪些最恰当的。在这个阶段应该注意发现所有的需求，不要遗漏任何需求。在实践上，这意味着收集过多的需求总要好过收集太少的需求。倾听是最重要的需求收集技巧。
功能性需求指明了产品必须要做的事情。为了实现存在的根本理由，产品必须执行一些动作，功能性需求与这些动作有关。他们应该做到能形成一份完整的、尽量避免二义性的产品功能描述。做到这一点最容易的方法是编写一个场景，把用况分解为一系列的步骤，检查每个步骤，导出它的功能性需求。
非功能性需求是产品必须具备的属性。非功能性需求并不改变产品的功能。非功能需求增加了产品的功能——他增加了一些处理，使产品更易于使用、更安全或者交互性更强。
编写需求规格说明书是指得到要构建的产品的完整描述的任务。这其实不是一项单独的活动，而是在网罗和做原型的活动中，当发现需求时就完成了编写需求的一部分工作：在质量中，确保每一项需求是有完整上网时候就完成了其余部分的工作。编写一个好的需求规格说明书能够得到数倍的回报——构建工作更为精确，维护使用费用更少，产品反应了顾客的需要和想法。
标签：
原文地址：http://www.cnblogs.com/xiangwo/p/5037644.html
