在本章中，我们将继续探讨如何构建稳健的需求。在上一章中，我们创建了高层次需求。虽然这些需求有助于确定我们将要创建的产品方向，但它们仍然比较模糊。换句话说，它们没有讲完整的故事，缺乏足够的细节来让我们开始编写软件。如果在这个阶段就包含过多细节，那就做错了。
在本章中，我们将探讨以下主题：
- 给产品的不同功能命名
- 识别参与者、事件、生命周期、阶段、类型、层级和循环
- 创建用户旅程、用例和故事
- 构建最终的业务需求文档
- 哪些工件应该优先完成
- 通过长期业务需求实现成果扩展
如果高层次需求是系统开发过程的“骨架”，那么本章围绕的就是“肌肉”、“皮肤”和“器官”。我们将通过区分具体功能、生命周期、用例和角色，把高层次业务需求的愿景和构想落地。这些元素将帮助我们开始规划领域（domain），最终形成设计良好的 Spring 服务。现在，让我们开始吧。
给产品的不同功能命名
在本节中，我们将回到 HomeIt 初创公司的示例。但在此之前，需要明确一点：
上一章的重点是扩展我们的想法，我们处于头脑风暴模式。在头脑风暴过程中，我们不会过多关注结构或具体细节，而是专注于“做什么”。这种思维方式在软件开发中至关重要。你不应过早限制思路，比如问：“这个解决方案可行吗？它怎么实现？谁来开发？用哪种技术？”这些现实性问题应该在后续阶段提出。
经过上一章的脑力扩展练习之后，我们现在要为产品需求增加更多结构。首先回顾 HomeIt 初创公司系统的高层需求。为了保持清晰性，我们需要识别并命名不同的解决方案需求。通过命名，它们更易于引用。HomeIt 系统的功能包括：
- 房产经纪人质量评分（Realtor quality score）
- 调解功能（Mediation）
- 保险功能（Insurance）
接下来，我们进入下一步：识别系统结构。
识别参与者、事件、生命周期、阶段、类型、层级和循环
通过了解系统的冲突点和不同功能，我们可以明确客户的位置以及希望引导他们到达的目标。下一步是确保理解系统的真实结构，即哪些关键元素将支持用户到达未来解决方案的旅程。
系统中的行动执行者是谁？
回到 HomeIt 系统，我们有多种参与者（actors），每个参与者都可以执行一组明确的操作。参与者也可以称为系统中的角色（roles）。
一些关键角色包括：
- 租客（Tenants） ：使用网站搜索租赁房产的用户
- 房东（Landlords） ：将房产提供给租客的用户
- 经纪人（Realtors） ：促成租赁协议的用户，连接租客和房东
- 管理员（Admins） ：拥有高权限的内部用户，如阻止尝试欺诈的用户
系统不仅包括网站的最终用户，还包含多个流程和可能性，包括需要特殊权限的内部用户，例如：
- 法务（Legal） ：编辑房东可使用的合同模板
- 财务操作员（Finance operators） ：确保支付系统正常运作，如处理保险退款
- 调解员（Mediators） ：在用户之间解决冲突，确保达成一致
在系统分析中，识别关键角色至关重要。某些产品团队会明确定义这些角色，但有时角色可能不够清晰。识别缺失的角色将为公司带来巨大价值，也有助于系统开发和架构决策。
为每个角色定义关键事件
识别角色后，我们需要明确他们可以执行的关键操作，这些操作称为 关键事件（critical events） 。关键事件定义了每个角色可能的行为。
租客的关键事件
以 HomeIt 系统为例，租客关键事件包括：
- 注册：在网站创建租客账户
- 房产搜索：搜索房产、查看房产详情
- 人员搜索：搜索经纪人、查看经纪人资料
- 租赁房产：预约看房、提交租赁报价、签署租赁合同
- 支付：支付租赁款项
- 消息：向经纪人或房东发送消息
- 通知：查看最新更新，如消息或合同变更
- 取消：取消租赁合同
- 经纪人评分：对经纪人进行评价
关键事件提供了比高层需求更完整的操作列表，即使每个事件的具体实现细节尚未明确。
房东的关键事件
房东的关键事件包括：
- 注册：填写个人信息
- 房产注册：登记新房产、设置可看房时间、启用/禁用房产
- 经纪人合作：批准或拒绝经纪人
- 人员搜索：查看经纪人或租客资料
- 租赁操作：批准租赁报价
- 账户管理：查看账户余额、提取资金
关键事件有助于将抽象想法转化为具体功能，增强用户体验和系统设计。
经纪人的关键事件
经纪人的关键事件包括：
- 房产搜索：搜索房产、查看详情
- 经纪人合作：发送或取消合作提议、设置可接待看房时间
- 消息：阅读与房产相关的消息
- 账户管理：查看和提取账户余额
- 调解：处理租客/经纪人纠纷
接下来，你可以思考其他可能的关键事件，以及内部角色（调解员、财务、法务、管理员）如何为租客、房东和经纪人提供价值和支持。
列出系统的主要功能
到目前为止，通过本次练习，我们已经探索并识别出一些有趣的新功能，我希望你在自由思考的过程中也发现了一些新功能。
目前我们发现的功能包括：
- 房产搜索（Property search） ：用户能够搜索租赁房产并查看其详细信息
- 经纪人合作（Realtor partnership） ：经纪人与房东合作，将房产展示给新的租客
- 消息功能（Messaging） ：用户能够互相发送消息
- 账户管理（Account） ：用户可以管理系统中的账户余额
- 调解（Mediation） ：用户能够在平台内解决冲突
- 房产注册（Rental property registration） ：房东能够管理系统中的房产
- 支付（Payment） ：租客能够支付租金
- 人员搜索（People search） ：用户可以搜索系统中的其他用户
- 经纪人评分（Realtor quality score） ：经纪人的声誉系统
- 取消（Cancellation） ：租客能够取消租赁合同
在探索系统过程中，你还发现了哪些其他功能呢？接下来，让我们进入系统分析的下一步：创建功能时间线。
提取功能事件时间线
现在，我们已经为每个角色头脑风暴了多个事件，并识别出许多新的关键功能，接下来需要探索如何细化单个功能并将其置于时间线上。这意味着通过一系列有序的关键事件来描述每个功能。
此外，我们希望创建的功能时间线能够映射功能的依赖关系。换句话说，事件在时间上的正确顺序是什么？用户需要满足哪些条件才能使用该功能？
在本节中，我们不会对每个已发现的功能进行详尽说明，这将需要大量篇幅和时间，本书的重点是使用 Spring 框架创建系统。我们将通过几个关键示例演示，你可以用相同的方法应用到其他功能上。
是否可以用本章方法完全替代 UX/UI 工作？
你可能会想：作者是不是建议用这里的方法替代标准 UX/UI 研究？答案是否定的！本章内容不能替代市场调研或专业 UX/UI 方法论，它只是用一种“干练、直接”的方式来编写事件序列，帮助工程师更好地理解所构建的系统。在某些项目中，UX 工作可能存在缺口，这时可以借助事件时间线来优化产品和业务需求。
注册功能（Sign-up）时间线
此功能无前置条件，是 HomeIt 的第一步。步骤如下：
- 用户访问网站首页
- 系统验证用户提供的信息
- 如有必要，用户纠正无效或缺失的信息
- 用户提交信息
- 账户创建成功，用户自动登录
注意，我们在排列事件顺序，但此时不对具体信息做过多假设，仅从高层次理解事件的组织方式。
房产注册功能（Rental Property Registration）时间线
前提条件：房东已注册并登录系统。步骤如下：
- 房东选择添加新房产
- 提供房产注册所需信息
- 系统验证信息
- 房东纠正信息（如有必要）
- 提交所有信息（描述、地址、价格等）
- 房东进入新房产页面，状态为“未激活”
- 系统提供上传媒体文件（图片或视频）选项
- 房东选择上传媒体文件
- 提供媒体文件
- 房产状态变为“处理中”
- 系统处理媒体文件
- 处理完成后，房产状态变为“就绪”
- 房东可选择发布房产
- 房东选择发布房产
- 房产状态变为“已发布”，可通过房产搜索功能访问
此功能展示了对象生命周期：从“未激活” → “处理中” → “就绪” → “已发布”。
房产搜索功能（Property Search）时间线
前提条件：房东已注册并发布房产，可选：租客已注册。步骤如下：
- 用户访问 HomeIt 首页
- 输入搜索条件（邮编、街道、城市等）
- 可选择排序或筛选条件（价格、街道、距离等）
- 系统返回符合条件的房产列表及图片
- 用户查看房产图片
- 用户点击查看房产详情
此功能依赖其他功能完成，因此可以为功能开发优先级提供线索。
经纪人合作功能（Realtor Partnership）时间线
前提条件：注册经纪人、注册房东、注册房产并实现房产搜索功能，且经纪人和房东均已登录。步骤如下：
- 经纪人登录并搜索房产，进入房产详情页
- 选择“与房东合作”
- 指定每周可接待租客的日期
- 指定每天可接待租客的时间段
- 指定期望收入比例
- 提交合作提案
- 提案进入“待审批”状态
- 房东查看提案列表
- 房东查看某个提案详情
- 查看经纪人信息
- 房东选择接受合作提案
- 合作状态变为“已批准”
- 经纪人可在列表中看到已批准的合作
- 经纪人联系方式显示在房产页面
此功能定义了合作对象的生命周期，并揭示了其他必需功能（如合作列表功能）。
注意：此处仅描述“理想路径”，未处理合作提案被拒绝或未回应的情况。
房产租赁功能（Property Rental）时间线
前提条件：注册房东、已发布房产、注册租客、支付方式及 HomeIt 财务信息。步骤如下：
- 租客访问房产页面
- 租客发送租赁提案
- 审阅并签署租赁合同
- 租赁提案进入“待审批”状态
- 房东审阅租赁提案并查看租客信息
- 房东接受租赁提案
- 生成电子签名合同
- 租赁提案状态变为“已接受”
- 租客收到提案批准通知
- 租客选择支付方式并提交
- 支付成功
- HomeIt 收取公司份额
- 经纪人（如有）收取份额
- 房东收取剩余金额
- 每月重复支付，相关方收到各自份额
此功能特点：
- 涉及三个角色互动（租客、经纪人、房东）
- HomeIt 财务流程需到位
- 存在循环流程（每月支付）
- 需考虑异常情况，如支付失败、余额不足或转账失败
- 不同国家可能有多种支付方式，需要灵活接入
通过此类分析，可以明确系统所需的关键步骤和需求，尽管过程复杂，但这是软件工程的核心：尽可能清晰地制定需求，从而为未来架构设计提供便利。
简化需求
通过上述练习，你可能会觉得实现这些需求会花费大量时间，这种担忧是正确的。要求开发团队在网站上线前完美实现每一个功能，会使开发过程复杂且成本高昂。而在软件开发中，我们通常不会这样操作。完美需求往往无法完全实现。那么，在面对如此复杂的需求时，我们如何采取更实用的做法呢？
当需求过于复杂、成本高且耗时时，一种关键方法是缩小工作范围。为了以最低成本建立在线存在，我们可以重新设计 HomeIt 系统，通过更简单的功能实现类似效果。
这就是所谓的范围缩减（scope reduction） 。通过省略某些功能，我们可以在较短时间内成功发布产品。
一个简单示例：
- 初期开发一个基础网站，让房东注册账户并发布房产，不包含其他用户类型的注册功能。
- HomeIt 初期不处理每月租金支付。
- 通过省略其他许多功能，我们确保网站具备建立在线存在的核心组件，后续可以逐步增加新功能。这种方式称为产品路线图（roadmap） 。
接下来，我们将更深入探讨系统中的阶段（stages）和循环（loops） 。
理解阶段、等级、类型、生命周期和循环
每个系统都是由阶段、等级、类型、生命周期和循环的组合构建的。下面我们逐一定义这些概念。
阶段（Stages）
阶段指实体在用户使用过程中经历的一系列“状态”或“阶段”。在 HomeIt 系统中，我们已有以下对象的阶段：
- 房产（Rental Property） ：未激活 → 处理中 → 已发布
- 合作提案（Partnership Proposal） ：待审批 → 已接受 → 已拒绝
- 租赁提案（Rental Proposal） ：待审批 → 已接受 → 已拒绝
阶段可视为对象在系统中成熟的步骤，通常用对象的“状态（status）”属性表示，可监控对象在不同开发阶段的变化。
等级（Levels）
等级是一组独特的特征或属性，用于使对象在系统中区别于其他层次的对象。等级在对象生命周期中可以不断演化，赋予对象更多价值或权限。
在 HomeIt 示例中，等级可以设计如下：
-
经纪人（Realtors） ：
- 铜牌：新注册，经手最多 4 个房产
- 金牌：声誉 3 星，可合作最多 10 个房产
- 钻石：声誉 5 星，无合作上限
-
房东（Landlords） ：根据活跃租赁合同数量减少手续费，例如同时有 5 个合同可享 10% 折扣
-
租客（Tenants） ：基于房产历史提供保险折扣，长期无事故房产可降低保险费用
等级可视为对象在系统中的“上升层次”，用于区分有价值的行为，并授予更多权利、权限或奖励。
类型（Types）
对象在系统中可能具有不同类型。例如 HomeIt 中的各种角色都是用户，但因任务不同而具有不同特性。
其他类型示例：
- 房产类型：区分房屋和公寓，可为搜索功能提供更精准的筛选
- 租赁合同类型：提供不同保险覆盖和条款
类型用于区分对象的属性包和行为包，它们彼此独立但用途不同。
生命周期与循环（Life Cycles & Loops）
生命周期指对象随时间在不同阶段或等级中演化的过程。可通过可视化展示生命周期，以便理解和沟通系统中所有可能性。
生命周期允许我们创建状态图（State Diagram），成为开发者的重要工具，可用于高精度映射测试用例。
在 HomeIt 案例中，我们可以可视化多个对象的生命周期，首先是房产生命周期：
如图 2.1 所示，将房产生命周期的各个阶段进行可视化展示——在本例中从“未激活” → “处理中” → “已发布”——能够更直观地理解对象在系统中的整个历程。此外，在对象从一个阶段过渡到另一个阶段时，我们还能清晰地识别触发该过渡的条件。
接下来，让我们可视化经纪人等级的生命周期：
如图 2.2 所示，我们为系统设计的声誉等级允许经纪人在低等级和高等级之间流动，有时还会回到低等级。某些对象的生命周期可能会形成循环。实际上，我们可以认为用户在系统中始终会经历一个循环：他们可能从“外部世界”新注册成为用户，成为活跃客户，随后暂时不活跃，最终重新激活账户。
将用户生命周期理解为一个整体循环非常重要，因为这有助于我们在系统中制定用户留存策略。参见本例中的最后一张图：
最后，如图 2.3 所示，我们对形成生命周期循环的条件进行了更通用的描述——在本例中，用户从未注册状态变为注册租客，然后成为拥有活跃租赁合同的租客，依此类推。设计系统性循环或生命周期时，并不一定需要在对象中有特定的“状态”属性。关键是要意识到系统中存在的隐性循环，这种认知可以帮助我们识别杠杆点，确保随着时间推移持续为用户提供更多价值。
这里非常重要的一点是，如果忽视循环和生命周期，可能会错失宝贵的洞察和策略。创建这些结构的可视化表示是需求分析中最重要的任务之一。
⚠️ 警告
我曾遇到无数项目，其中系统的生命周期和循环完全未被记录。软件中定义的状态和等级，最终往往演变为松散设计的实体和功能。提供清晰的图表，展示所有现有状态、情境以及触发状态转换的条件，可以为产品团队提供一种强大而直接的方式，帮助他们获得洞察，从而丰富用户体验。
在许多情况下，在记录和可视化等级、阶段、循环和生命周期时，你可能会发现并非所有的状态转换触发条件都明确存在于软件或业务需求中。这些看似简单的可视化图表中往往隐藏着机会。实际上，我职业生涯中收到的很多最佳反馈，都源于我习惯于尽可能创建这些可视化图表。我建议即使在与他人合作的项目中，也要练习创建这些图表。
以这种逐步方式投射需求的价值在于，它为我们想象系统提供了很大的自由度。这也是一种非常强大的头脑风暴方法。我们并不从试图定义某个具体功能开始，而是先扩展我们能为所构建系统设想的各种可能性。
如果你是开发人员，理解软件需求的这些“维度”（问题、解决方案、高级需求、角色、关键事件、等级、阶段、生命周期和循环）将非常有帮助，因为你可以剖析那些通常包含大量假设和模糊信息的需求文档。这些工具可以确保具体的业务需求清晰地表达出系统中用户的连续旅程。
创建用户旅程、故事和用例
在本节中，我们将生成三类关键产物，这些产物将整合迄今为止看到的所有业务需求元素，并以业务需求视角下合理的方式呈现。
我们首先探讨如何将独立功能组合成更高层次的用户旅程，从而更好地展示我们希望通过软件实现的战略。
我们将学习如何撰写用户故事，从业务角度总结和阐述我们的功能。
我们还将撰写用例，以便清晰传达我们旨在提供的价值创造过程，用高度清晰且一致的方式表达业务需求。
⚠️ 注意
到目前为止，我们看到的需求构建模块就像 LEGO 积木，可以用于不同层次的说明。必须认识到，不同的积木用于与公司中不同层级的人沟通，从而了解谁会对哪类产物更感兴趣。本章后续部分将再次讨论这个概念。
下面让我们定义并示例说明每种产物，并探讨它们之间以及与迄今为止看到的其他模型之间的关系。
用户旅程
用户旅程可以提供用户如何使用软件体验的高层次概览，虽然它们不像第一章看到的高级业务需求那样模糊。
用户旅程让我们能够可视化用户在较长时间范围内的行为。从某种意义上说，用户旅程可以被视为一种将整个用户生命周期更明确地展示给系统内用户行为的方法。
用户旅程也可用于表达系统中不同用户在较长时间内的关系。虽然我们在功能中汇总的关键事件描述了更细致的行为层次，用户旅程则用少量模块呈现用户行为的较大块内容。
为单个用户创建用户旅程
让我们回到 HomeIt 创业案例。看看这个用户旅程：
在第一个示例中，如图 2.4 所示，我们可以通过一次性概述一个模块的方式来传达租户在 HomeIt 网站上的完整旅程。每个模块代表一个完整的功能，而该功能又可以以不同方式进行拆解。
现在让我们来看房东的用户旅程：
如图 2.5 所示，我们可以简明扼要地概括房东在网站上的完整用户旅程。
这种使用用户旅程的方法侧重于单个用户。在这两个示例中，我们省略了一些实际功能，例如调解功能和保险功能。当然，如果你自己练习过创建需求，我们也省略了你所发现的功能。但你可以理解其概念：用户旅程能够在有限的视觉空间中传达大量信息。
接下来，让我们探索另一种创建用户旅程的方法。
多用户的用户旅程
在这种情况下，我们将在同一个用户旅程中涉及多个用户。请看图 2.6：
由于篇幅限制，我只展示了涉及四个参与者的用户旅程的一部分：租户、房地产经纪人、房东和 HomeIt。用户旅程被划分为水平泳道，每条泳道代表一个用户。泳道中的动作显示在左侧，方框按照这些动作随时间发生的顺序排列。
这样可以很容易地跟踪每个用户的动作及其发生顺序。在实际应用中，你可以创建跨越多个部门、涉及各种用户类型的庞大用户旅程。
这种涉及多个不同用户的用户旅程既可用于非常高层次的流程，也可用于非常具体的详细流程，具体取决于你的需求。作为练习，可以为调解流程创建一个用户旅程。花一些时间思考，并创建各个泳道及其中涉及的所有用户，以及每个用户随时间发生的动作。
用户故事（User Stories）
因为团队成员常常会深入关注项目的技术细节，很难鼓励他们从最终用户的角度思考。当我们未能采用用户视角时，就可能开发出与用户需求不符的产品或功能，这在市场上是很常见的现象。
这时，用户故事显得非常有价值。用户故事旨在从用户视角传达需求，使团队成员能够更好地理解用户需求，并“带上用户的帽子”来思考问题。它们的目标是将团队关注点从软件的技术细节转向用户需求的理解与优先级。
用户故事模板
用户故事本质上是简短描述，遵循特定模板来表达用户需求。最常见的格式如下：
标题： 房地产经纪人发送租赁物业的合作提案
描述：
作为一名房地产经纪人，我希望能够发送租赁物业的合作提案，以帮助房东找到理想租户。这不仅能提高我的月收入，也能为房东带来收益，同时帮助租户找到理想住所。
验收标准：
- 房地产经纪人能够发送租赁物业的合作提案。
- 合作提案可供房东查看。
用户故事的关键在于聚焦用户动作，并在读者脑中形成清晰的视觉画面。它们应描述易于可视化的事件，以简明的方式呈现。
用户故事回答的问题
用户故事在软件开发过程中起着重要作用，能够回答关键问题，例如：
- 谁在尝试完成什么？
- 用户在这个故事中应该采取什么行动？
- 为什么允许用户执行该动作很重要？
- 哪些其他用户会受到影响？
- 为什么这个动作对这些用户也很重要？
通常，用户故事最初可能不会涵盖许多业务规则。可以将其视为工具，用于说明系统中的用户行为、用户关系及其产生的价值。
编写用户故事时，一般建议不要一次描述过多动作。如果故事过长，可能需要拆分成多个故事。
用户故事与技术的关系
有效的用户故事不涉及开发技术细节，而是帮助团队专注于用户、关系、动作及相关方动机。如果提到 JSON 格式或 HTTP 方法，就偏离了目标。用户故事关注的是“为什么”而非“如何实现”。
创建用户故事标题
标题应简洁描述用户在系统中需要执行的动作，而不涉及软件细节。换句话说，就是描述用户应做什么，而不提系统本身。用户故事本质上是过程的说明，可以在必要时包含重要业务规则，但无需过多强调技术细节。
验收标准（Acceptance Criteria）
每个用户故事的关键组成部分是验收标准。它确保我们已在软件中完成故事实现。优秀的验收标准提供完整的业务测试清单，以验证开发是否完成。它也是部署产品到生产环境的关键依据。
用户故事练习模板
标题： <<用户 X 执行简短描述的动作>>
描述：
作为 <<角色>>，我希望能够 <<执行的动作>>，以便我能够 <<期望结果>>。
这将使我能够 <<后果 1、后果 2、后果 3>>。
同时避免 <<负面后果 1、负面后果 2>>。
还会影响 <<其他用户或角色>>，具体如下：<<后果列表>>。
业务规则：
<<可以添加业务规则，不涉及技术细节、按钮、屏幕等>>
验收标准：
<<需要验证的动作是否正确发生>>
<<其他动作或结果是否正确>>
如果在网上查找用户故事模板，你会发现各种形式。我更倾向于这个自定义模板，因为它允许更深入地探索用户关系和价值，而不仅仅是基础描述。
练习编写一些用户故事后，可以进入下一节内容。
用例描述（Use Case Descriptions）
到目前为止，我们已经探索了多种工具，用于清晰表达业务需求。如果把你比作画家，这些需求工具就像不同的颜色，帮助你描绘软件的整体“画像”。
用例描述是我特别喜欢的另一种关键工具，用于确保开发者理解需要构建什么。它的作用类似于用户故事：通过用例描述，我们可以描绘用户与系统交互的过程。
注意事项
在深入讨论用例描述之前，我想澄清一个可能产生混淆的地方。在软件工程中，有一种广为人知的工具称为“用例图（Use Case Diagram）”。我在这里提到的用例描述 不是 用例图。鉴于用例图很常见，我在此不作讨论。同时，我更喜欢用用户旅程图来从高层次说明用户动作。
用户故事与用例描述的比较
如果用例描述与用户故事相似，那么两者的区别是什么？我的观点如下：
- 用户故事：保持简短，避免过多描述过程的细节；过程通常由其他工具呈现。
- 用例描述：提供更详细的说明，甚至可以结合用户故事及其他工具。
例如，用例描述可以以用户故事文本开头，然后详细列出组成过程的关键事件序列，也可以包含相关图表，让开发者更清楚系统的运作方式。
用例描述可作为完整的文档记录：
- 从用户故事出发，帮助理解动作、动机和关系。
- 通过关键事件序列为软件开发提供基础。
- 添加对象阶段或生命周期图，可以更直观地展示对象随时间的变化。
结合可视化、用户故事和关键事件，用例描述成为强大的工具，有助于传达软件目标。可进一步加入系统层级图等增强清晰度。
最终，应把用例描述看作画布，用来添加颜色和草图，表达软件的功能和目的。
触发条件（Triggers）
触发条件是用例描述中的另一个关键元素，我认为它是用户能够启动故事中动作的上下文。一个用户可能通过多种途径开始使用某个用例。例如，在 HomeIt 系统中，租户搜索租赁物业时，可能的触发条件有：
- 直接物业搜索：租户通过应用搜索功能查找符合条件的物业。
- 从手机端搜索：用户从手机开始搜索，可能利用地理定位查找附近物业，并可增加“搜索距离”功能。
- 从电脑端搜索：用户从电脑搜索时，可使用大屏布局显示高分辨率图片，甚至提供多物业图片对比功能。
- 推荐系统：基于搜索历史和偏好向租户推荐物业。
- 通知提醒：租户订阅通知，当有新物业满足条件时收到提醒。
- 经纪人联系：租户通过应用联系经纪人寻求帮助。
注意：在同一用例中，不同触发条件可能对应不同的关键事件序列。
用例描述模板
你可以自由使用以下模板来创建用例描述：
-
用例名称：遵循用户故事标题规则。
-
用户故事：说明动作、动机和系统中的关系，包括验收标准。
-
触发条件 #1 – 触发标题：标识用户执行动作的独特上下文。
- 触发描述
- 关键事件时间线
- 阶段、层级、类型、生命周期、循环（或其他有助于理解系统的图表）
用例示例：房东发布新租赁物业
标题：房东发布新租赁物业
描述：
作为房东，我希望能够在系统中发布新的租赁物业，使其可供出租。这样可以吸引潜在租户、挑选最佳租户、创造新的收入来源，同时吸引新的经纪人合作，从而接触更多租户。这也能避免物业空置，并为经纪人提供展示物业的机会，获得新的收入来源。
业务规则：
- 物业在提供所有媒体文件之前，仅可进行注册，不能接受租赁或合作提案。
- 房东必须提供物业完整地址、租金价格、条件和特征，以及媒体文件。
验收标准：
- 房东用户能够发布新租赁物业，并附带照片和视频。
触发条件 #1：物业在网站上发布
关键事件时间线：
- 房东在网站上选择添加新租赁物业。
- 房东提供注册物业所需信息。
- 系统验证信息。
- 如有必要，房东修正物业信息。
- 房东完成提交所有信息（描述、地址、价格等）。
- 房东进入新物业页面，此时状态为“未激活”。
- 系统提供上传媒体文件（照片或视频）选项。
- 房东选择上传媒体文件。
- 房东上传必要的媒体文件。
- 物业状态变为“处理中媒体文件”。
- 系统开始处理上传的媒体文件（结果待定义）。
- 媒体处理完成后，物业状态更新为“准备就绪”。
- 系统提供发布选项，使物业对租户和经纪人可用。
- 房东选择发布物业。
- 物业状态更新为“已发布”，并显示在物业搜索功能中。
简而言之，该用例描述了房东如何添加所需信息，以便物业在搜索功能中可用。
接下来，让我们再次可视化物业生命周期。
以完整业务需求文档结构化单个用例
这是在完整业务需求文档中构建单个用例的非常有效方法。接下来，我们来看最终业务需求文档是如何创建的。
构建最终业务需求文档
本节讨论优秀业务需求文档的特性。在创建或审核自己的文档时，请检查这些方面，以确保在几乎任何项目中都能顺利推进。
聚焦单一概念/功能，范围清晰
业务需求文档应专注于交付 “单一概念” 。这意味着文档通常包含一组用例，但这些用例都围绕软件要提供的 单一价值 构建。这个价值是自包含的，不依赖其他内容来增强用户价值，流程从头到尾完整构建。
例如，我们之前讨论过，HomeIt 网站的第一个简化版本仅允许房东注册。其他用户仅作为访客，可以从发布的物业中获取房东电话。为这个首次发布创建的业务需求文档（称为房东流程发布）可能包含以下用例：
- 房东在网站上注册
- 房东发布新租赁物业
- 未注册访客搜索租赁物业
- 未注册访客访问租赁物业页面
你可以看到，仅通过这四个用例就能为各方创造市场价值。这种方法比尝试实现所有已发现的用例/功能更快上市。
当已有系统存在时
你可能加入的公司已经有多个系统。在这种情况下，需求文档通常聚焦于为现有流程添加新功能。例如，假设你在房东流程发布后加入 HomeIt 作为程序员，下一个合理步骤可能是实现租户流程，包括以下功能：
- 租户在网站上注册
- 租户为纽约的物业发送租赁提案
- 房东接受租赁提案
- 租户提交支付信息
- 每月处理租金支付
对于第二次发布，我们在系统中增加五个新用例，用于管理支付功能。即便如此，该功能仅限于纽约物业。这种方法在财务团队较小、创业公司希望在有限区域内集中精力时非常实用。
明确输入与输出
我们将在后续章节更深入讨论输入与输出。但基本原则是：用例应尽可能准确描述流程的输入和输出。
输入示例（注册租赁物业）：
- HomeIt 系统中注册物业的具体属性是什么？
- 预计支持哪些类型的媒体文件？
- 物业描述的最大长度是多少？
输出示例（媒体处理结果）：
- 处理后预计生成哪些类型的媒体文件？
- 视频处理后允许的分辨率是多少？
如果需求文档未明确输入和输出，后续可能阻碍程序开发。
明确特殊用例
在接受和审核产品团队或部门提供的业务需求文档时，应注意以下事项：
-
用户的替代行为
- 阅读描述和关键事件后，识别用户在系统流程中可能偏离预期路径的节点。
- 对每个节点问：“如果用户行为不同于预期，系统应该如何响应？”
- 高流量系统中，用户会进行各种创造性操作，程序员必须清楚如何处理这些替代流程。
-
系统错误与故障
- 审核文档时，标注系统可能出错的每一步。
- 例如，如果某功能依赖可能离线的合作系统，需要明确产品团队打算如何应对：是否无缝恢复？或将客户引导至客服？
考虑可能的误用或出错场景是开发规划中非常重要的一步。
完整的签署流程，涵盖所有受影响区域
在产品需求文档中，应要求产品团队提供跨所有受影响领域的端到端流程图，详细说明各用户在流程中的操作直到流程结束。
如前章所述，让各部门知晓新版本对软件成功至关重要。因此，程序员应确保流程图由各部门签署确认。获得详细用户旅程图并由各部门管理层签署，可大大降低流程错误的风险。
避免文档阻塞
在编写或阅读需求文档时，常会遇到许多未定义的点。此时应该怎么做？
- 是否开始猜测接下来会发生什么？
- 是否等待下一次团队会议报告阻塞？
这种情况非常常见。程序员经常面对不够详细的需求，缺少许多细节。作为良好实践，建议在文档中创建 “开放问题” 区块：
- 继续编写你确定的信息
- 将需他人回答的问题单独列出
这样可以确保文档持续推进，同时清楚记录待解问题。
哪些产物应该先创建？
随着第 2 章接近尾声，你已经看到在编写详细业务需求时有许多有效工具。那么一个关键问题来了：在众多起点中，应该先创建哪些产物？
答案很直接：取决于软件开发生命周期的当前阶段。以下是一些优秀的起点选择：
- 精炼已定义的需求：流程已经清晰，只缺少输入/输出格式。
- 定义系统流程如何工作：需求可能较模糊，但如果对整个用户旅程有总体理解，就可以专注于关键事件。
- 识别团队中最大的知识空白：需求可能过于具体，如果不清楚它们在更大范围的用户旅程中的位置，则可能需要从高层次设计整个用户旅程。
确定要创建的最佳需求文档时，可以先回答这些问题。同时注意以下因素：
- 公司规模：在不同部门众多的组织中，为每种用户类型绘制通用用户旅程图能大大促进跨部门沟通。
- 现有系统成熟度：如果是为已有系统添加功能，需先审核现有文档，识别缺口。
- 小公司实践：程序员可能会在文档最少的情况下急于实现，这是关键错误。未来团队成员需要了解已实现的内容，仅依赖代码或程序员不可持续，也不可扩展。
文档对于流程和沟通的可扩展性至关重要。缺乏文档会使你成为解答基础问题的“必找人”，造成瓶颈和时间浪费。拥有清晰的文档集合，可以释放时间用于更高价值的工作，从而带来更大的未来回报。
用长期业务需求来扩展成果
本节旨在帮助你完成一项关键任务：发现并解决业务需求中的短期约束。这样做可以显著节省工程成本，并有助于长期有效扩展工程成果。
许多开发者忽略这一点，因为习惯于短期思维。若屈服于业务部门为快速发布以产生短期收入的压力，可能会在下一年产生指数级更高的工程成本。
示例：HomeIt 系统支付功能
- 先实现一个支付系统（如美国信用卡支付），若团队在下月完成，接下来呢？
- 美国租户可能希望通过银行电汇支付租金，这需要额外开发工作，流程与第一次类似。
- 如果继续增加 ACH 支付方式，类似工作会重复发生。
短期思维下，架构未考虑扩展，多国支付、不同州税务处理等问题会增加复杂性和开发成本。
长期业务需求推论
虽然这似乎与 YAGNI（You Aren’t Gonna Need It）原则相悖，但通过理解和对齐产品团队的长期目标，你可以从一开始就构建可扩展代码，避免未来大量返工，提高开发效率和盈利能力。
识别可扩展代码机会的关键问题：
- 未来 5–10 年将创建哪些新类型、新级别、新产品？
- 计划在新地区发布软件吗？
- 预计开发多少新用例？
然后评估：
- 架构是否便于添加新用例、级别和类型？
- 工程团队添加新功能的时间是否会显著增加？
- 是否能协调更多工程师开发更多用例？
- 新增用例是否会使开发成本呈指数增长？
- 架构是否会在一定数量的新用例发布后产生不可管理的复杂性？
- 如何优化架构以快速交付多用例？
- 如何减少交付一个用例所需的代码量，实现更高效的扩展？
回答这些问题有助于设计可随时间提供指数级价值的软件，为公司释放巨大潜力。
练习与回顾
本章中介绍了许多关键工具和方法，用于深入理解和细化业务需求：
- 命名功能：划分应用程序的正确模块。
- 关键事件：集思广益，确定系统必须发生的关键事件。
- 事件时间线：逐步理解功能的执行流程。
- 阶段、级别、类型、生命周期与循环：理解系统中价值流随时间的变化。
- 用户旅程：理解用户生命周期及其在系统中的交互路径。
- 多用户旅程：可视化用户间的互动。
- 用户故事：理解用户关键行为、动机、价值及对其他用户的影响。
- 用例描述：整合前述工具，明确功能工作流程及触发条件。
- 特殊用例：识别用户的非预期行为及系统故障处理。
- 明确输入与输出：识别业务期望的数据流。
- 长期业务需求：评估架构隐含成本，优化代码扩展性和工程效率。
总结
本章内容源自作者自身开发、技术负责人和管理经验，而非其他书籍。实践这些业务需求方法带来了丰厚回报：财务收益、良好反馈及职业发展机会。
在下一章，我们将讨论如何以模块化、可扩展方式实现业务需求，学习优先级管理、识别领域和服务，以及跨组件的活动排序，并利用 Spring 框架工具进行软件开发。
