“我们需要一个预约应用”只说明了产品类别，却留下了大多数决策问题：谁提供预约时段？客户能否取消？变更是否需要员工批准？当这些问题与企业的实际工作相联系时，需求概要才真正有用。可以先描述一个有代表性的工作流程，再补充实现它所需的角色、约束和评审决策。
本页内容
描述当前流程及其问题
写出从触发工作到完成结果的整个顺序，包括人员与系统之间的交接。以一家提供预约服务的企业为假设示例：客户提出时间要求，员工查看共享日历，再手动发送确认。问题可能是预约冲突，也可能是客户无法清楚查看情况。在列出需要哪些页面之前，应先明确哪种困难最重要。
- 哪些信息会发起请求？
- 由谁决定能否继续处理？
- 大家通过什么确认工作已经完成？
为每种用户角色明确职责
区分客户、员工和管理员的需求。例如，客户可以查看自己的预约，员工可以管理日程，管理员可以决定谁拥有相应权限。除了常规操作，也要描述纠错过程。如果员工调整了预约，谁能看到变更？原来的时段会如何处理？这些规则有助于设计与开发团队围绕同一个产品展开讨论。
划定首个版本的边界
在预约示例中，一个范围集中的版本可以让客户选择可用时段、收到确认，并在之后查到预约；同时让员工管理可用时段和处理取消。如果周期性预约或会员奖励可以稍后实现，就将它们列入单独的清单并说明原因。不要仅仅因为某个辅助步骤不如主界面显眼，就移除让已约定流程真正可用的必要环节。
- 包含从请求到结果的一条完整使用路径。
- 包含运行该流程所需的权限与纠错工具。
- 为推迟的想法设置重新考虑的条件。
列出依赖关系，标明未知项
识别应用可能需要的现有日历、支付服务、客户记录和其他系统，并记录语言、目标设备、迁移需求及业务约束。应区分已确认需求与待解答问题：“现有日历能否提供实时可用时段？”本身就是对需求概要有帮助的信息。直接假设它能够提供，可能掩盖必要的调研工作，并导致初始范围失真。
将需求转化为可以检查的例子
使用通俗语言描述验收检查。例如，在预约流程中：客户预订一个可用时段后，预约应出现在客户账户和员工日程中；如果另一位客户尝试预订同一个容量为一的时段，则不能得到第二份预约确认。同时，应约定取消后如何重新开放时段。这些例子能够暴露“预约管理”这一概念尚未定义的决策。还应明确由谁检查，以及由谁批准范围变更。
- 与有代表性的用户一起检查完整任务。
- 将待解答问题与已批准需求分开记录。
- 指定一位负责人处理相互冲突的优先事项。
纳入转向日常使用的安排
说明上线后谁负责管理应用、导入现有数据并支持用户。明确团队需要哪些培训或交接材料，并考虑如何报告问题、如何审核更新。这些细节能够让开发范围涵盖从可运行演示到企业能够实际运营的产品之间所需的工作。