业务用例、需求汇总文档、修改汇总文档、会议记录文档、聊天记录文档，所有由客户提出需求相关的汇总资料。
业务用例必须结合用户故事一起说明，本章介绍业务用例。
使用场景划分
客户提供需求资料文档
客户提供具体待研发系统的需求资料，项目负责人需要按照客户提供的需求问题进行响应，这种情况下，必须以【需求】为主导开展工作（项目）。应当将严格按照需求资料内容在SDP系统详细记录，具体要求如下：- 相关需求资料文档登记为一个【业务用例】，分类标记【需求】
- 进入研发阶段以后，客户再次提供任何资料或反馈建议，每次都必须登记为一个【业务用例】，分类标记【修改】
- 用户故事的标记中，【需求】和【修改】是针对资料文档每一项进行详细记录，主要目的有：响应用户需求和反馈（工作量评估）、衡量是否完成标准。
自主研发系统
业务用例和用户故事以【业务】为主，基于故事开展工作（SDP、基准地价）。应当将严格按照需求资料内容在SDP系统详细记录，具体要求如下：- 分析待研究组织、业务执行者和用例，则每个系统卖点登记为一个【业务用例】，分类标记【业务】，业务用例必须有具体执行者。
- 用户故事的【业务】是对业务用例的详细描述，必须结合现状和改进场景加以阐述。
- 用户故事主要目的是响应用户需求和反馈（工作量评估）、衡量是否完成标准。
协助客户共同编写需求
需求人员协助客户共同对待研发系统深入研究，可以【业务】和【需求】为主导开展工作，具体有双方协商（如准备开展的土地出让项目）。此类情况按应当结合上述1、2两点开展工作。
总结
业务用例和用户故事具体标记分为三类：需求、修改、业务，存在一一对应关系。需求和修改主要是为了面对客户，由系统自动生产相关响应文档《需求设计文档》，结合系统功能可另外生成《系统功能需求文档》《系统研发工作量评估》。业务主要便于研发人员从业务角度理解待研发系统在实际工作中具体起到的作用，通过现状和改进后得到体现。
需求汇总 - Requirement
| 项目 | 描述 |
|---|---|
| 标题 | 文档名称 |
| 名称 | 英文，【REQ】 – yyyyMMdd |
| 业务角色 | 以下所有都改为分类 |
| 附件 | 具体资料及文档，可上传多个 |
| 需求 | 介绍资料背景，如获取时间、谁提供、如何获取、 个人对于需求理解，以助于日后将场景还原， 例如需求会议记录概要。 |
| 引用 | 弱关系，展示应当按照引用顺序排序。 |
标题
- 展示：分类+标题。
- 分类：【需求】，标题的前缀，SDP系统提供选项。
- 文档：后缀添加年月日yyyyMMdd，也可添加版本号_v1.0。
引用
- 若A与业务用例存在关系，则表示A的下文；格式为“（下文）【需求】业务用例-标题”。
- 若A与用户故事存在关系，则表示A的下文；格式为“（下文）【需求】用户故事-标题”。
示例
- 标题：【需求】基准地价定级计算系统需求20171021
- 名称：【REQ】- 20171021
- 附件：《基准地价定级计算系统需求规格说明书》
- 描述：2017-10-21由提供，该需求文档经过双方两次远程视频会议及多次QQ沟通。
- 引用：无
修改汇总 - Change
进入编码阶段后，任何新需求和反馈问题全部统一视为【修改】
| 项目 | 描述 |
|---|---|
| 标题 | 文档名称，参照“业务用例【需求】，标题” |
| 名称 | 英文，【CHG】 – yyyyMMdd |
| 附件 | 资料文件 |
| 描述 | 参照“业务用例【需求】，描述” |
| 引用 | 参照“业务用例【需求】，引用” |
业务用例 - Use Case
| 项目 | 描述 |
|---|---|
| 标题 | 执行者+用例 |
| 执行者 | 与待研究组织打交道的人 |
| 待研究组织 | 本次系统使用的组织 |
| 用例 | 待研究组织的价值 |
| 名称 | 英文 |
| 附件 | 可不上传 |
| 描述 | 简述该用例现状。 |
| 引用 | 参照《业务用例【需求】》 |
示例
- 标题：【业务】评估部门获取网格点分值成果
- 名称：Appraisal dep get the grid point score result
- 附件：无
- 描述：因评估部门制作土地等级等价格成果图件，需要评估土地地价，现行是采用网格点价格方式，故需要从数据部门获取到网格点分值以便于计算网格点价格。
- 引用：无