1.3 仅有的几个原则
像其它艺术一样，推理学和分析是一个需要通过长期和持久研究才能获得的学科。终其一生，也不能达到最高完美境界。
――福尔摩斯：血色研究
Arthur Conan Doyle
本节主要讨论无论什么时候论述需求都需要仅有的几个原则。它们会帮助你交付出好的结果，帮助你决策需求包括什么东西。这不是系统化一套原则，仅是我希望引起你注意的几个原则。
1 论述问题，而不是解决方案。俗话说，需求定义“做什么，而不是如何做”，这意味着试图论述解决方案和它的一部分，都不是需求的角色。这是一个很明显的规则，不能被打破。
2 论述系统，而不是项目。需求定义系统需要做什么：它们是一批目标。项目是临时的一段时间内鼓动起来一个团队，来完成这些目标。需求没有地方说，这些目标是如何完成的。也就是说，需求没有说一个项目是如何实现解决方案的（包括里程碑日期、团队规模、团队成员全称、成本预算和方法论）。写的每一个需求也是无时间限制的，对于在不同时间用不同方法构建的多种系统是同等有效的：需求可能束之高阁，1年2年后才被取出，或者我们用数年时间构建一个替代系统。
3 分隔正式部分和非正式部分。需求规格像一个契约，定义了构建商和供应商之间需要交付的东西。但，大量的约束性契约声明并不能为读者带来足够的合理明细：它需要的背景、上下文环境、流程和结构。这些额外的材料没有一个会在约束中声明。把这些分解为正式部分（约束的）和非正式部分（非约束的）是无价的。需求规格自身建立了需求规格的正式部分：官方定义的系统必须做内容。任何一件事也都非正式的。
4 避免重复。仅信息中每一项至到实践中仅表达一次。重复创建了额外的工作且打开了矛盾的大门。
1.4 传统需求过程
我只所以选择这些事情来论述，不是因为它们容易，而是因为他们是难的。
――John F. Kennedy（如果他是业务分析师，他会说什么）
传统的论述需求方法，在开始进入设计和构建系统之前，交付一个明细的需求必须有截然不同的阶段。图1－3概括了传统需求过程的通常阶段。插图中的步骤最显著的特点是这里的大部分工作需要做。“采集信息”的有趣外形告诉我们，它不被隔离在早期单个步骤中，而是继续到最终的需求规格被交付（尽管给予它的时间越来越少，细端所指的是图形的底部）。
图1－3 传统需求过程的活动
图1－3的步骤是：
1 准备。在需求过程开始之前，通过面对面解释或者通过一个短的范围文档，分析师必须给出一个系统目标的声明轮廓。找出能独立开始的信息：熟悉环境（如果是新进入者，需要熟悉文化），识别出信息的所有的资源。
2 采集（或“抽取”）信息。信息的主体资源是人、文档和存在的系统。采集好信息的关键是关注细节。首先，在同人谈话之前，找出你能找到的。熟悉相关系统。而人是新建系统中最好资源。本章的全面描述中描述了从哪里采集信息的两个基本方法：个别会谈和集体会话。
3 写需求规格草稿。尽可能早早地写下草稿作为开始，而不是有了合理的主流后。这只需要花费很少的时间：一天或两天。首先写下“上下文环境”，然后识别出功能领域，从规格的顶层章节开始，按照你需要表达的内容组织。不要害怕后期可能修改它。
4 需求评审。要使需求经过严格详细地审查，检验你要告诉大家的每件事情是否正确地进行了解释和表达。评审需求规格的方法有多种。这些方法使正式手续和精确程度呈现出多样化。本章的全面描述中有两个评审方法：分别方式，把需求规格分发给详审成员，收集他们的反馈；集体方式，在同一时间内，把评审成员召集在一起，进行规格的细节和系统化详审。
5 评审后修改。系统化地做完所有接受到的每一个注释，适当地修改规格。任何一个注释都可能暗示被遗漏或需要改变的事情，要提防观察是否有其它的隐含意义。处理评审后的新需求版本，选择重新评审或是不再评审，可以完成。
其它活动同主需求活动平行执行。两个公共的活动是写用例和开发原型。
1.5 敏捷需求过程
“你老了，神父，威廉”，年轻人说
“你已生华发，但仍然坚持已见，以你这样的年龄，合适吗？”
――艾丽丝奇遇记
Lewis Carroll
本节讨论使用敏捷方法构建系统时需求扮演的角色。它的目标是开发者和架构师，它们一开始没有给予需求规格。采用敏捷的观点就不是全有或全无两个极端。在它的指导下，你可能使用了很少的步骤，或者你可能全神贯注。你可以灵活地只作了项目的一部分。你也可以用传统的方法论述需求，然后，用敏捷方法来做设计和开发。在这样的情况下，你可用传统方法来做需求，上节所说的，然后，在开发中使用敏捷。
敏捷宣言定义了敏捷的观点，在重视人的价值，不重视过程；重视软件，不重视文档；重视协作，不重视契约；重视责任，不重视计划。在灵活在捕获需求时，敏捷的“重视软件，不重视文档”是我们的主要指南：我们把制造很少的文档作为目标。随之而来的专注于有效果的文档的两个方法，同时也能认识到论述需求所带来的价值。让我们用一对原则开始指导任何的敏捷需求过程。
l 原则1：从解决方案来判别问题是有价值的。用某种方法或其它方法，必须决定新系统需要作什么。你也需要决定如何作它们。这个原则仅仅是说，认识到把从如何作，到首先去做分隔开，是很好的实践。它给您一些东西，让你可以在后期度量解决方案的质量和决定两个建议方案的长处。如果在一起的东西是模糊，它会给你目标的度。
l 原则2：如果你识别出了一个需求，就记录下别人也可能找出的方面。但是，这个原则没有说，需求应该记录在哪里，记录什么。
极端需求过程
在极端编程（XP）的环境中，讨论“需求过程”听起来很不协调，因为在极限编程中，需求根本不会出现在混合的模板中。但，没有人决定必须做什么，系统就不能构建，所以，需求无处不在。而且它们会改变一些过程的结果，还有其它的，且是快速而轻盈。这就是我们这里要讨论的一类需求过程――捕获和灌注它的结果。
用极限编程构建一个新系统是通过要求用户写下一批完整的“用户故事”。一个用户故事就是短暂描述用户想让系统做的事情。来自每个用户领域的某个人（叫做“参考者”），至少要提供到描述的用户故事中。最终的结果是用户故事提供了系统的主功能。任何一个写用户故事的人都会从本书的需求模式中找出对应的，这些需求模式可以提供有益的建议。
一旦产生了一批用户故事，就可以用来安排顺序，逐个实现。一个用户故事被分配给开发者，开发者找出如何去实现它（先定为一批测试，XP叫做“验收测试”）。即使每个开发者没有搞明白哪些事是他们正在做的事情，即使过程即刻结束和从来也没有明白头脑之外的事情，他们也必须明确表述清楚他们需要满足的需求。任何一个开发者的第一个要问的是：我正在做什么？我要解决什么问题？行动之前，回答这些问题，写下答案，作为测试任务定义的开始。如果存在相关的需求模式，让它来帮助你。需求模式引导你认别出的额外需求，它们中的一些可能会产生自己开发活动。
在需求模式中，有三个方法用于极限编程：
1 提出用户故事且描述它们（做的更精确、更像一个需求）。
2 用更系统化的风格来叙述故事，挖掘出他们暗含的实际需求，也要识别出支持实现用户故事的功能的额外功能。
3 指导应用到组织级别的一批“公共需求”的产物，特别是被所有开发者所遵守并经过很好实践的规则。
增量需求过程
增量需求过程的前提是：即时性。仅在需要时才做需求。在前期，逐步建立需要做的最小需求，开发者更早介入就成为了可能。这里要做两件事：需求需要做到什么样的明细程度和每一块的需求什么时候开始论述。在开发和设计之前，在这个范围的结束点，需求需要被完整地写下来。在另一个层面说，个别的需求可以作为开发的一部分来定义。这两个方法都在传统方法和敏捷方法中作过描述。增量方法夹在它们二者之间。
正像敏捷开发包括增量一样，敏捷需求也包括增量需求部分――这就是说，一批需求可以逐步完善。那么，每个人都应有全局认识，避免重复。像软件的需求规格，逐渐焕发生命之光。适合这样做的过程是什么？大家紧记，敏捷观点，让我们简单：
1 论述需求首先是要让客户足够明白我们是如何理解他们想从系统中获取的东西（确保我们正确捕获了业务目标），让客户认可，可以进下去。
2 当开发者开始准备构建一个特定领域时，展开应用到该领域的高层需求，为了满足高层需求，论述系统需要的每个事情的明细。
