第一章：需求概述##

1.1 什么事需求####

至少我已经掌握了案件的基本事实。我将一一给你列举，因为没有比向另外一个人陈述情况更能理清一个案件的方式了。而且如果我不告诉你我们从哪里开始，也很难期望你的合作。
---阿瑟柯南道尔

• 什么是需求：需求就是定义系统需要做什么而不是怎么做。
  需求定义一定要解决：系统的目的是什么，以及为了达到目的系统需要的所有功能。需求不仅包括功能性需求，也不能忽略非功能性需求，包括性能，安全，标准等。

1.2 需求在总体方案中的位置####

我还没有数据。没有数据就进行理论化是极大的错误。人们开始不知不觉地扭曲事实以适应理论，而不是让理论适应事实。
---阿瑟柯南道尔

• 一个简单的开发生命周期：范围--需求--设计--开发--测试--安装

1.3 一些基本原则####

像其他技艺一样，演绎和分析科学只有经过长期和南信的研究才能掌握，普通人毕其一生也不能达到尽善尽美的地步。
---阿瑟柯南道尔

• 注意事项：定义问题，而不是解决方案；定义系统，而不是项目；区分正式和非正式部分；避免重复。

1.4 传统需求流程####

我们选择定义这些东西不是因为它们容易，而是因为它们困难。
---约翰肯尼迪

• 步骤：准备--收集（引出）信息--编辑需求规格草稿--评审规格--评审后修改

1.5 敏捷需求流程####

• 两个指导原则：区分问题和解决方案是重要的；定义需求后，一定要记录它以便别人可以找到。
• 用户故事：用户希望系统为他们完成的事情。
  与极限变成相关的使用需求模式的三种方法：
  1）为用户故事及其内容提供建议；
  2）以更系统化的方法解释用户故事，揭示隐藏在其中的真正的需求，同时识别出实现用户故事需要增加的额外功能；
  3）指导建立一整套“公共需求”，可以在开发组织中的所有系统使用，特别是建立一套所有开发人员应该遵循的良好实践的规则。
• 增量需求：前期充分地定义需求；后期扩展特定部分的高层需求。

第二章：需求规格的内容##

2.1 介绍部分####

• 系统目的
• 文档目的
• 需求格式
• 词汇表
• 参考书目
• 文档历史

2.2 上下文部分####

• 范围
• 主要假设
• 主要排除
• 关键业务实体：确定系统的核心业务，确定其主要特征，用状态迁移图等展示其可能状态。
• 基础构架：支持一个或多个需求所需的一组基础的能力。

2.3 功能域部分####

• 对每一个功能逻辑组编写一个高层描述，按照功能域命名，按照重要性排列。

2.4 主要非功能要求部分####

第三章：需求模式概念##

3.1 需求模式概述####

• 需求模式：定义一种特定类型需求的方法。需求模式应用于单个需求，一次帮助定义一个单一需求。

3.2 需求模式剖析####

需求模式包含的要素：

• 基本细节：模式声明，所属领域，相关模式，预期频率，模式分类，模式作者
• 适用性：一个明确的环境
• 讨论
• 内容：主要考虑效率，通常展示在一个表格中，包括摘要和定义
• 模板
• 实例
• 额外需求：跟随性需求；普遍性需求
• 开发考虑
• 测试考虑

3.3 领域####

• 避免需求模式之间的相互依赖
• 基础构架可以依赖于另一个基础构架
• 基础构架包括目的，调用需求和实现需求

3.4 需求模式组####

• 需求模式组用于描述多个需求模式每个的共同特性，而不必在每个模式中重复。需求模式组不是一个需求模式，但是可以包含需求模式定义中的任何部分。
• 需求模式组和领域的区别在于，需求模式组有共同的细节，而领域有共同的主题。

3.5 需求模式之间的关系####

• 引用：一个需求模式可以在定义中提到另一个模式。
• 扩展：一个需求模式以另一个需求模式为基础开发或者特殊化。也可以扩展为需求模式组。不允许扩展多个模式或组。

第四章：使用和编写需求模式##

4.1 何时以及如何使用需求模式####

• 需求模式最主要的目的是帮助定义一个新系统需要做什么。
• 需要使用需求模式的场合：
  1. 定义需求时，看是否存在一个模式可以知道如何定义这种需求。
     2） 考虑需求是否完全时，浏览主题覆盖的整套模式，看是否还有遗漏或者是否需要添加什么东西。
     3） 评审需求规格时，模式可以帮助检查需求的质量，确定还有哪些主题没有定义
     4） 评估系统额规模以及开发所需工作量时，基于需求，使用模式可以对实现的复杂性有更准确的感觉
     5） 实现需求的时候，模式可以使你更深刻地理解需求的意图
     6） 测试需求时，“测试考虑”一节用于建议测试这种需求的方法

4.3 编写新的需求模式####

• 步骤：
• 1.是否有足够的价值
• 2.建立模式的骨架
• 3.编写模式的“适用性”部分
• 4.收集需求实例
• 5.检查需求实例
• 6.描述需求可能包含的信息
• 7.编写需求模板
• 8.编写剩下的“讨论”和“内容”部分
• 9.开发潜在的额外需求实例的列表
• 10.确定额外需求的候选主题
• 11.编写“额外需求”部分
• 12.编写“开发考虑”部分
• 13.编写“测试考虑”部分
• 14.是否值得？
• 15.评审模式

第二部分：需求模式目录#

第五章：基础需求模式##

5.1 系统间接口需求模式####

基本细节

• 相关模式：系统间的交互，吞吐量，可用性，扩展性，遵从标准，文档，技术
• 预期频率：在小型或中型系统中，有4个或更少的需求；在复杂系统中可能 有一打或更多需求
• 模式分类：无
  适用性
  使用系统间接口需求模式定义被定义的系统和任何与之交互的外部系统组件之间的接口的基本细节。
  讨论
• 每个接口必须有一个唯一的标识的接口标识符。
• 每个接口必须确定是属于内部还是外部。
• 有多个相似的系统接口时，每一个必须单独对待。
  内容
• 接口名称
• 接口标识符
• 两端的系统
• 接口的目的
• 接口的所有者
• 定义接口的标准（如果有）
• 用于接口的技术（如果相关）
  模板
  实例
  额外需求
• 个别类型的交互
• 吞吐量
• 伸缩性
• 扩展性
• 弹性和可用性
• 流量验证和记录
• 升级
• 安全
• 文档和第三方接口开发

5.2 系统间交互需求模式####

基本细节

• 相关模式：系统间接口
• 预期频率：每个系统间接口有0-5个需求
• 模式分类：无
  适用性
  使用系统间交互需求模式定义穿越系统间接口的特定类型的交互
  讨论
• 我们拥有接口：尽可能完善接口
• 我们不拥有接口但能映像接口设计：完善需求
  内容
• 交互类型名称
• 接口名称和标识符
• 交互目的
• 传递的信息
  模板
  实例
  额外需求
  开发考虑
  测试考虑

5.3 技术需求模式####

基本细节

• 相关模式：遵从标准，系统间接口，易用性
• 预期频率：通常不超过6个需求
• 模式分类：普遍性
  适用性
  定义开发和运行系统所必须要或必须不要的技术，或系统必须能够与之交互或兼容。
  讨论
  所谓技术，是在卡法，安装，和运行系统时使用的外部生产的硬件或软件。这个需求不用于选择技术，只是以某种方式限制可以在系统中使用的技术。
• 在产品中使用：硬件，操作系统，数据库，网络服务器，防火墙，不间断电源以及任何提供给应用该软件支撑的附件
• 与产品配合使用：网络浏览器等
• 在开发中使用：如开发语言，文档，测试等
  内容
• 技术描述
• 接口名称和标识符
• 交互目的
• 传递的信息
  模板
  实例
  额外需求
  开发考虑
  测试考虑