参考Volere需求规格说明书的模板.docx

===== = 前言 ===== = 参照Suzanne Robertson,James Robertson著，王海鹏译的**《掌握需求过程（第3版）》**内容中的“附录A Volere需求规格说明书模板”进行编制。 此附录是编写严格和完整的需求规格说明书的指南。 === Volere需求分析 === Volere是在需求工程和业务分析领域，经过多年实践、咨询和研究得到的成果。 Volere需求规格说明书模板的第一个版本是1995年发布的，自那开始，成千上万的组织机构 将该模板作为发现、组织和沟通需求的基础，节省了工作量。 === 需求类型 === 为了易于使用，我们将需求划分为一些类型，这样比较方便。这种视角的好处有两点：有助于 发现需求，有助于对需求分组，将特定专业相关的需求放在一起。 “功能性需求”是产品的基础或本质主题事务。他们描述了产品必须做的事情，或必须采取的 处理动作。 “非功能性需求”是功能必须具备的一些属性，如性能和易用性等。不要被这个不幸的名称所 蒙蔽，对于产品的成功来说，这些需求与功能需求同样重要。 “项目限制条件”是由于构建产品的预算或时间而导致的对产品的约束。 “设计限制条件”限制了产品设计的方式。例如，产品可能必须实现在一个手持设备中，主要 顾客将使用这种手持设备；或者必须利用原有的服务器和桌面计算机，或其他硬件、软件和业务 方式。 “项目驱动”是与业务相关的动力。例如，项目目标是一种项目驱动，所有利益相关者也是， 每个人都有不同的理由。 “项目问题”定义了项目执行要面对的情况。我们将项目问题作为需求的一部分，目的是展示 一幅完整的图景，说明对项目的成功和失败产生影响的所有因素，并展示经理们如何利用需求作 为项目管理的收入信息。 === 测试需求 === Volere理念是开始编写需求时就立即开始测试需求。通过加入需求的“验收条件”使需求变得 可测试。验收条件用于对需求进行测量，这样就能确定给定的解决方案是否满足需求。 如果某项需求无法找到验收条件，那么这项需求要么有二义性，要么还没有被很好理解。所有 的需求都必须测量，都必须带验收条件。 === 需求项框架 === 需求项框架是编写每项原子需求的指南。该框架（也称为“白雪卡”）的组成部分在这里确定。 你可能决定添加更多的属性，以便你的环境提供必要的可追踪性。例如，实现该需求的产品， 实现该需求的软件版本，或对该需求感兴趣的部门。还可以添加其他属性，但添加时要有节制： 不要随意添加属性，除非它们确有帮助。每个属性你都需要维护。 这个需求项框架可以自动化，也应该自动化，通过Excel可以实现白雪卡。 {{:平台_模板库:图标:白雪卡.jpg?direct500|}} ===== = 项目驱动 ===== = ===== 1.项目的目标 ===== 关注客户要你构建新产品的根本理由。它描述了客户面对的业务问题，解释了产品将如何解决该问题。 ==== 1a.该项目工作的用户业务或背景 ==== === 内容 === 对开展的业务、它的上下文以及触发开发工作的情况的简短描述。 同时也应描述用户希望用交付的产品来完成怎样的工作。 === 动机 === 应该考虑用户的问题是否严重，是否应该解决和为什么应该解决。 也许没有问题，但是重要的商业机会，你的客户希望开拓。如果是这样，描述该机会。 或者，项目要探究或调查可能性。在这种情况下，项目的交付物不是新的产品， 而是一份文档，提供了产品能满足（或不能满足）的需求。 === 形式 === 简短的文字描述通常足以说明对项目的理解。你可以加入当前状况模型、业务过程模型、 当前文档的例子、当前状况的照片和视频、网站地址和组织机构图，来支持这段描述。 ==== 1b.项目的目标 ==== === 内容 === 描述我们希望该产品做什么，以及它将为工作的整体目标带来什么好处。本节不要太冗长，简短地解释项目目标，常常比长而杂乱的论述 更有价值。 简短准确的目标让利益相关者更清楚，更有机会就目标达成一致。 === 动机 === 在开发过程中可能会迷失这个目标，这样的危险是存在的。