一、需求是什么？

需求之所以存在，要么因为该类型的产品要求某些功能和品质，要么因为客户希望该需求称为交付的产品的一部分。

1.功能需求是产品必须完成的那些事。

2.非功能需求是产品的属性和品质。产品要让拥有者和操作者接受，就必须具备这些属性或品质。非功能需求描述了诸如观感、可用性、安全性和法律限制等需求。

3.限制条件

限制条件是全局性的需求。它们可以是对项目本身的限制，或是对产品最终设计的限制。限制条件只是另一种类型的需求。

二、Volere需求过程

这个过程目的是成功地收集、验证需求，并编写需求文档。

Volere是意大利语，意思是“希望”、“想要”。

你通过该过程所做地工作是由相关的提交产物驱动的，并非流程。（不同的产品需求，该流程中的每一组任务细节程度不同）。

三、需求过程的基本框架

不论是构建用户定制的系统，还是构建组件集成的系统，或者使用商业上架销售的软件包，或者采用开源软件，或者将开发外包，或者对已有的软件进行改动，都需要发现、捕获和交流需求。

采用Volere需求过程的客户，开发产品时采用了RUP、增量、迭代、螺旋、Scrum，或其他类型的迭代式开发过程，也有的客户采用了更正式的瀑布式过程，或自己定制的开发过程。要构建正确的产品，就必须发现正确的需求。为了发现正确、完整的需求，需要某种有序的过程。

项目启动——网罗需求——快而不完美地建模——场景——编写需求——质量关——复用需求——复查需求——迭代和增量过程——需求反思——需求演进——模板——白雪卡——定制需求过程

①启动会议确定了业务问题的范围，争取让利益相关者达成一致意见。其中，利益相关者是所有对它有要求的人。

②项目启动也确立了项目的目标。

③在这个阶段可以对项目的需求部分所涉及的成本进行初步预估，是不错的项目管理实践。可以通过工作范围模型中包含的信息来完成；

④对项目可能面临的风险进行早期评估，也是不错的项目管理实践。

⑤最后，小组成员对项目是否值得进行和是否可行达成一致意见。这是“进行或终止”的决定。或者，此时如果还有许多未知的东西，启动小组可以决定开始需求调研，不久后再来复查需求，重新评估项目的价值。

2.网罗需求

启动会议结束后，需求分析师开始在工作中网罗，学习和理解它的功能性。将工作上下文图划分为一些业务用例。每个业务用例都是一部分功能。每个业务事件都指派一名需求分析师。

分析师可以采用一些技巧：如做学徒、场景分析和用例研讨会等，来发现工作的真正本质。

问题的实质是拥有这个产品的底层业务的理由，或者可以将它看成是工作的策略，或者想象在没有技术的情况下工作会是什么样子。

3.快而不完美的建模

一些正式的模型是用UML或BPMN做的，但许多时候业务分析师可以有效地利用快速地草图，对调研工作进行建模。

4.场景展示了业务过程地功能性。场景是需求地基础。

5.编写需求

分析师编写需求是为了确保参与开发地各方对需要做地事达成一致地理解。这是确保记录和沟通需求实质地最有效方式，也确保交付地产品可测试。

分析师使用了两种机制，使编写需求规格说明地工作更容易。第一种机制是需求规格说明模板，它是需求规格说明的一个提纲。

第二种机制是需求项框架，也称为“白雪卡”，确保每项需求都有正确的组成要素。

6.质量关

需求是所有后面工作的基础，必须保证正确性。质量关对需求进行检查。

通常由1-2个人组成，可能是首席需求分析师和一个测试人员。只有他们有权允许需求通过质量关。在允许需求加入需求规格说明之前，他们一起检查每项需求的完整性、相关性、可测试性、一致性、可追踪性和其他一些质量属性。

7.复用需求

在开始任何新需求项目之前，浏览一下以前项目的规格说明书，寻找潜在可复用的东西。有时会发现很多需求都是可以复用的。

8.复查需求

复查工作确保规格说明书是完整的、恰当的，这样可以转向下一个开发阶段。这个过程可以评估风险和计算成本来对需求进行合理的复查。

9.迭代和增量过程

在需求业界有一个常见误解，认为做需求就意味着采用传统的瀑布式过程，在某些情况下确实如此，在并不总是这样。

产品可以以小的增量的方式进行开发。这样做的优势是可以尽早实现一部分用例，取得利益相关者的反馈。

10.需求反思

需求反思过程是发现过程中的优缺点。该过程包括一系列风险承担者访谈，以及与开发者进行小组会谈。

反思可能采取非正式的方式：利用喝咖啡的时间和项目小组会谈，，或项目领导者通过E-mail向项目参与者收集信息。

11.需求演进

需求随产品的开发过程而演进，它们开始是相当模糊的想法，随着时间的推移，产品的想法出现了，需求变得精确、可测试。演进可前可后。（功能需求、非功能需求、限制条件）

12.模板

Volere需求规格说明模板，它是对产品功能和能力的完整蓝图。

模板目录：

项目驱动——描述了项目的理由和动机

1.项目的目标——投资构建产品的理由以及这样做我们希望取得的业务上的好处

2.客户、顾客和其他的利益相关者——产品涉及他们的利益或对他们的影响

3.产品的用户——预期的最终用户，以及他们对产品可用性的影响

项目限制条件——加在项目和产品上的约束条件

4.需求限制条件——项目的局限性和产品涉及的约束条件

5.命名标准和定义——项目的词汇表

6.相关事实和假定——对产品产生一定影响的外部因素，或开发者所作的假定。

功能需求———产品的功能

7.工作的范围——针对的业务领域

8.产品的范围——定义预期产品的边界，以及它与相邻系统的连接情况

9.功能与数据需求——产品必须做的事情以及功能所操作的数据

非功能需求——产品的品质

10.观感需求——预期的外观

11.易用性和人性化需求——如果产品要让预期用户成功地使用，它必须是怎么样的

12.执行需求——速度、大小、精度、人身安全性、可靠性、健壮性、可伸缩性、持久性和容量等需求

13.操作与环境需求——产品预期的操作环境

14.可维护性和支持需求——产品的可改动性必须达到什么水平，以及需要怎样的支持

15.安全性需求——产品的信息安全性、保密性和完整性

16.文化和政策需求——人和社会因素

17.法律需求——满足适用的法律 

项目问题——这些适用于构建产品的项目

18.开放式问题——那些尚未解决的问题，可能对项目的成功有影响

19.立即可用的解决方案——利用已有的组件而不是从头开发

20.新问题——引入新产品而带来的问题

21.任务——将产品投入使用必须要做的一些事情

22.迁移到新产品——从现存系统转换的任务

23.风险——项目最有可能面对的风险

24.费用——早期对构建产品的成本或工作量的估计

25.用户文档——创建用户指南和文档的计划

26.后续版本需求——可能在产品将来的发行版本中包括的需求

27.解决方案的想法——我们不想错失的设计想法

13.白雪卡

模板是写什么的指南，白雪卡是怎么写的指南。

有一些自动化工具可以用于记录，分析和追踪需求。

14.定制需求过程

15.正式性指南