怎样形成一个实例化的需求说明？
一个实例化的需求说明，首先一定是各个利益相关方协作开发出来的。因为协作开发出来的需求说明才是让各方对需求达成一致理解，能够确保需求的准确性和可靠性。
需求说明中的实例并不是用户提供的业务报表等原始的例子，开发人员必须对这些原始的例子进行提炼才更具有价值。
这就像原石必须经过加工成钻石才能绽放出夺目的光彩。
要形成一个实例化的需求说明，就需要对需求以及原始的例子进行提炼——去掉不相干的细节，提取重要的特性，使得需求定义更加清晰、明确、完整。
一个经过提炼的、好的需求说明一般具有以下特点：
需求的实例必须精确可测
需求的实例必须包含可验证的信息，即要明确输入和预期的输出，以便进行验证。
需求的实例不是脚本
需求的实例能够解释业务功能是什么，而脚本只能说明某件事情是如何完成的。
需求的实例关注业务功能，而非软件设计
需求说明只应解释业务功能，不应对软件如何实现作出规定。这样的需求说明就像一个常量，它不会因为设计的改变而改变。
需求说明应该是不言自明的
需求的实例应当能够使得该项需求是不言自明的，这样即使编写需求说明的离开了，也不会造成需求理解的偏差。
不要过度定义实例
需求的实例不是越多越好，正相反，需求说明应该只列出具有代表性的实例，这有助于保持需求说明简单易懂的特性。
使用“Given-When-Then”描述需求
Given-When-Then是定义系统行为的常见格式，它用3个部分来编写系统行为的场景：
假定（Given）：一个前提；
当（When）：某个行为发生时；
那么（Then）：后置条件会得到满足。
使用这种格式描述需求，就是要明确需求的前置条件和后置条件。
需求说明要使用统一的领域语言描述
统一的语言有利于协作开发需求说明，也有利于实现需求的集体所有制。
一个好的实例化需求说明的例子。
某电商的免费送货服务需求描述如下：
当VIP客户购买5本或以上的书籍时，可享受免费送货服务。普通客户不享受免费送货服务，没有购买书籍的VIP客户也不享受免费送货服务。
实例如下：
| 客户类型 | 购物车中的物品 | 送货服务 |
|---|---|---|
| VIP客户 | 5本书 | 免费、标准 |
| VIP客户 | 4本书 | 标准 |
| 普通客户 | 10本书 | 标准 |
| VIP客户 | 1台洗衣机 | 标准 |
| VIP客户 | 5本书，1台洗衣机 | 标准 |
这正是：
需求实例需提炼，原始例子不能搬
提炼要求有几点，不言自明最关键
参考书目：实例化需求：团队如何交付正确的软件，作者：（塞尔维亚）Gojko Adzic，出版社：人民邮电出版社