功能特性
功能特性是系统期望功能的简要表述。功能特性的格式为：
copyright dedecms
2
一个示例功能特性可以是： copyright dedecms
2
本文来自织梦
在每个功能特性保持在最小状态时，基于功能特性的方法效果最好。一个小组能在两星期或更少时间内实现的功能特性就是理想的功能特性。 本文来自织梦
用名为 功能集(feature set)的组将功能特性组织起来。功能集包含描述给定目的或领域的功能特性。功能集和它的功能特性仅对需求进行了概述。作为描述需求的机制，功能特性必需和额外的环境相结合。
本文来自织梦
在“功能驱动开发”方法中，环境被精心设计成介于功能集和一个被称为“ 领域中立组件”(domain neutral component)的色彩标记类图表之间。 领域中立组件是个描述跨领域公共关系的语义模板。领域中立组件由瞬间间隔(moment-interval)、角色(role)、主题(subject)(当事人(party)、地点或事务)以及描述(description)组成。 瞬间间隔是那些领域的短时间要素，如处于订货执行系统的一个订单。 角色是个用户，系统和他交互并必须能识别出他。 主题是形成领域的要素。 描述是一种抽象，它集合了这些对象的元信息。图 1 是个录像带出租的领域中立组件。
本文来自织梦
图 1. 录像带出租方案的领域中立组件
织梦内容管理系统
作为一种需求收集过程，“功能驱动开发”非常灵活，它有助于在开发周期中更改管理。这一过程让您在项目进行过程中轻松检查并记录新的、更改的和已除去功能特性的数目。因为一般来说功能特性小， 更改现存功能特性或添加新功能特性不大可能要求在项目级上大量的返工。功能特性还有助于挑战软件不可见性，因为作为跟踪领域中立组件中的系统实体间交互结果的新功能特性可能被揭示。
copyright dedecms
功能特性可以用于熟悉给定领域的个体间的需求交流。以这种方式使用，基于功能特性的方法很可能是最节约的需求收集过程。但是，这些功能特性可能太依赖领域专业知识了，这是许多开发小组都没有的奢侈品。 织梦好，好织梦
用户情景
dedecms.com
用户情景是写在索引卡上的简短描述，如图 2 所示。
图 2. 销售用户情景的要点
copyright dedecms
用户情景包含的信息往往比功能特性包含的信息多，尽管这不是必要条件。“极端编程”方法中，用户情景要求一个现场的客户提供部分环境。现场客户向开发小组描述理想的系统。然后，这个小组一点一点建立系统，给客户充分的机会定期查看结果。客户“监督着”这个可交付使用过程，并且在新用户情景中提出对系统的修改建议。整个环境由现场客户的反馈和递增的过程及交付相结合。
用户情景对于处理软件不可见性风险最高的项目来说，是最佳的方法。像功能特性一样，它们都足够小，能被轻松更改。 因为它们的环境基于运作的系统和客户，一经实现或不再有效都会被丢弃。但是，并不是每个项目都可以引入现场客户，因此用户情景并不适用于每个项目。这种方法因其缺少客户交互而丧失了它的优势。
结论
内容来自dedecms
本文讨论的每种需求收集过程在恰当的环境中都有其优势所在。但是，正如这篇讨论所示，对于每种环境来说，不是每种需求收集过程都是理想的，它们自身甚至还不是必要的完整。子整体软件开发的中心在于认识到单个过程或活动本质上的不完整，并且尽可能扩大这些用于减少这种不完整的解决方案的范围。
织梦内容管理系统
模块性允许两种目的相同的活动可以互相代替。当用一种需求收集活动代替另一种时，重要的是把需求环境考虑在内。开发周期中途更改活动很可能会引入一组新的动力到项目。如果没有考虑到环境，这种行动可能会成为灾难。但是，仔细的计划和执行后，引入新活动就能帮助创建新的动力，从而促进了项目的成功。
dedecms.com
复制地址和好友共享
