今天我简单的了解了定制需求过程和迭代和增量过程

迭代和增量过程

在需求业界的一项常见误解就是必须收集所有的需求才能够进入到下一步的设计和构建工作。在某些环境下这样做是必须的，但并非总是这样。一方面如果打算外包，月佣文档构成了合同的基础，那么很显然需要完帐的需求规格说明。外方面儿要总体侧构知，构建工作就可以在全部需求收集完成之前开始。我们建议有自的需求项中考谢这让我们回来看IceBreaker项开发者已经准备好开始构建产品了,历以在用办会议名关键的风险承担者选出了几个(如3 个或4 个) 最高优先级的业务用例。

需求分析师收集这些业务用例的需求，暂时忽略其他业务用例。忽略其他业务用例是可行价因为业多例之间的功能关联较少，所以分析师之间的工作不会相儿f执。然后当第那分制K虎地通过质量关之后，开发者就可以工作了.这样做的1的是尽可能早地实现一小部分用例得风险承担者的反馈。如果他很吃惊，那么lceBreaker 团队也希里儿早知道。当俄批用发和交付时，需求分析师就在为优先级的川例收集需求。他们会很机建立起交付的奏，新的用例会几周交付一次。

定制需求过程

       到处兜售骗人药剂的Duleamara 医生吹暖说，他的万能药保证能治好牙痛，让人变得有力气，消除皱纹，拥有光滑美丽的皮肤，消灭老鼠和臭虫，让您喜欢的对象爱上您。Donizeti

的歌则“Lelisird'amore" 中相当富有想象力的歌词指出某些事尽管很明显，却常常被忽视:

这世间没有包治百病的药我们真的很愿意向您提供一个需求过程，它具备Dulcamara医生的万能药的所有特征个适合所有应用程序、所有项目和所有组织的过程。但是从经验中我们得知，每个项目都需要-↑不同的过程。同时我们又知道，一些基本的原则对所有项目都是有益的。因此我们不会向您提供- 一个“均码”的神奇药方，而是从各种不同项目中提炼出我们的经验，提供一组适了所有项目的基本活动和提交产物。我们从各种不同项目中提炼出我们的经验，提供一组适用于所有项目的基本活动和提交产物。我们使用了一个过程来描述成功地收集需求必须要完成的事情，也描述了作为所有需求活动的基础的提交产物。( 阅读本书时，考虑根据自己的文化、环境、组织结构和选择的产品开发力式米调整过程和提交产物。

我们从各种不同项目中提炼出我们的经验，提供一组适用于所有项目的基本活动和提交产物。我们使用了一个过程来描述成功地收集需求必须要完成的事情，也描述了作为所有需求

活动的基础的提交产物。在阅读本书时，要考虑根据自己的文化、环境、组织结构和选择的

产品开发方式米调整过程和提交产物。

例如，使用板限编程的项目没有打算提供一份需求规格说明，但仍然需要清楚地理解需求。这种理解不能通过编写代码来达到。花时间编写每一项需求，并补充它的验收标准，仍然是理解需求的最快方法(编写代码是构建满足需求的解决方案，它不能保证发现真正的需求)。在Volere 需求过程中，我们提供了场最作为用例功能建模的方式。这几乎总是发现需求的较快的方法，特别是当开始考虑用例的异常和可选途径时。对于非功能需求来说，写F需求，并补充它的验收标准，仍然是理解需求的最快方法。

       原来不一定收集所有的需求才能开始下一步的开发， 还可以迭代着去多次进行。