什么是业务需求

在软件工程领域或软件开发生命周期中，业务需求是指在系统开发周期开始时获取并记录业务用户（如客户、员工和供应商 ¹）的业务需求，并将其用作未来系统设计的指南的概念。业务需求通常由业务分析师编写，他们研究业务活动和流程，并经常对其进行分析以确定组织的目标。

软件工程中的业务需求是什么？

在软件工程中，业务需求是软件系统为实现组织战略 ²目标所应具备的主要需求和期望。这些软件需求从业务角度描述了业务目标、业务运行和实现目标的方式，以及软件将如何使业务运作并实现目标。业务需求在开发周期的早期就已记录下来，以指导系统的设计。

业务需求通常包括

1. 业务背景、范围和背景

   • 本部分概述了软件将要使用的商业环境。该要素包括行业趋势、竞争格局和组织目标等。
   • 范围表明项目的局限性、解决方案的系统以及将包含的功能。

2. 有要求的关键业务利益相关者 ³

   • 它可以检测组织中对软件项目感兴趣的人员或团体，并将成为决定或受其结果影响的人或团体。
   • 这些利益相关者可能是高管、部门主管、最终用户或监管机构等。

3. 未来/目标状态的成功因素

   • 定义软件项目实施后成功的基础标准。
   • 这些因素与组织的战略目标相一致，因此可能包括提高效率、节省成本、提高客户满意度、遵守法规等。

4. 业务或其他系统施加的约束

   • 指出软件开发过程中应考虑的任何限制或局限性。
   • 这些条件可能由现有系统的预算、技术、监管和集成限制产生。

5. 概念数据模型和数据字典 ⁴参考

   • 概念数据模型是业务领域所需的数据实体、关系和属性的总体描述。
   • 数据字典是一种提供系统中使用的数据元素的复杂描述和定义的工具。

业务需求的好处

• 清晰的愿景和协调：业务需求是组织打算用软件做什么的具体知识的来源，因此，项目的所有利益相关者对项目目标都有相同的看法。
• 改善沟通：它们是业务利益相关者和技术团队的沟通媒介，因此它们可以改善沟通并减少错误。
• 增强项目规划：良好的需求概述使得制定精确的项目计划、时间表和预算成为可能，从而实现更好的项目管理。
• 降低项目失败的风险：通过一开始就发现并解决业务需求，产品不是利益相关者和业务目标所寻找的产品的可能性较小。
• 更高质量的软件：明确的业务需求是软件符合业务目标和用户需求的关键。因此，最终产品是有效的，并且对用户来说更好。
• 提高用户满意度：解决用户和利益相关者问题的软件总是更令人满意，采用率也更高。
• 有效的资源利用：存在精确的要求，进而有助于有效分配资源，因为时间、精力和预算都用在了最重要的特性和功能上。
• 促进变更管理：非常详细的业务需求是项目生命周期内变更管理的基础，因此更容易评估影响并相应地做出必要的调整。

谁定义业务需求？

• 业务分析师：他们是收集、审查和记录业务需求并确保其符合公司战略目标的主要参与者。
• 产品所有者：在敏捷实施中，产品所有者根据利益相关者的要求和市场的需求来定义软件必须提供的特性和功能的过程。
• 项目经理：他们是项目负责人，负责项目，业务需求清晰地表述、书写并传达给所有团队成员。
• 关键利益相关者：软件用户来自营销、销售、运营、财务和客户服务等不同部门，他们向软件提供有关他们需要什么以及他们对软件的期望的信息。
• 最终用户：软件消费者的反馈对于说明使产品变得用户友好和实用的需求非常重要。
• 执行发起人：高层管理人员或执行发起人给出战略方向并确保业务需求与业务目标和业务优先级 ⁵相匹配。
• 主题专家 (SMEs)：一些专家在某些领域拥有专业知识，他们可以为您提供与某些特定业务功能或法规遵从性相关的详细要求。

记录业务需求的格式

1. 标题页

   • 项目名称
   • 文档标题：业务需求文档 ⁶ (BRD)
   • 作者
   • 日期

2. 目录

   • 为方便导航而列出的章节和页码。

3. 执行摘要

   • 项目、目标和业务需求范围的简要概述。

4. 项目目标

   • 详细描述项目旨在实现的业务目标和目的。

5. 范围

   • 范围内：将要解决的特定功能、特性和领域。
   • 超出范围：为避免范围蔓延而未涵盖的项目。

6. 利益相关者

   • 参与项目的主要利益相关者列表，包括他们的角色 ⁷和职责。

7. 业务要求

   • 功能要求：软件必须提供的特定功能和特性。

   • 需求编号

   • 描述

   • 优先级（高、中、低）

   • 依赖项

   • 验收标准 ⁸

   • 非功能性要求：与性能、可用​​性、可靠性等相关的标准。

8. 监管和合规要求

   • 软件必须遵守的法律、法规和行业标准相关要求。

9. 用例/用户故事 ⁹

   • 详细的场景描述了用户如何与系统交互以实现特定目标。

   • 用例 ID/用户故事 ID

   • 描述

   • 演员

   • 先决条件

   • 后置条件

   • 步骤

10. 假设和约束

    • 需求收集过程中做出的假设。
    • 可能影响项目的限制（例如技术限制、预算、时间表）。

11. 验收标准

    • 必须满足某些条件才可视为要求已得到满足。

12. 可追溯性矩阵

    • 将每个需求映射到其对应的测试用例、设计元素和项目目标的表格。

13. 批准和签字

    • 文件的批准和签字部分供主要利益相关者和项目发起人签字，为他们表达对记录要求的同意提供了机会。

14. 附录

    • 附录提供额外的信息，如术语表、以前引用过的文件和其他支持材料。

采用这种结构将使得业务需求清晰，详细且有据可查，从而为软件开发过程奠定坚实的基础。

原型设计和业务需求

1. 明确要求

   • 可视化：原型设计 ¹⁰让利益相关者看到他们需求的真实情况，从而很容易理解和明确需求。
   • 反馈循环：任何原型的第一阶段和主要目标都是从原型利益相关者那里获得早期和频繁的反馈。这将使业务需求精确并与业务目标保持一致。

2. 改善沟通

   • 共同理解：原型充当业务团队和技术团队之间的桥梁，因此，减少误解的机会并确保各方对最终产品有共同的愿景。
   • 互动会议：原型设计可以成为一种工具，让参与者参与对话，交流他们的想法和观点，从而更好地了解需求。

3. 需求验证 ¹¹

   • 真实世界测试：原型可用于在受控环境中验证假设和要求，因此开发人员可以轻松地在开发过程开始时发现潜在问题。
   • 用户参与：用户直接参与原型设计阶段是确保系统符合他们的要求和期望的一种方法。

4. 范围管理

   • 功能优先级：通过使用重复原型设计，利益相关者可以确定最重要和最可行的功能，从而在项目工作时更好地对它们进行优先排序，使项目范围 ¹²更易于管理。
   • 减少范围蔓延：通过清晰地直观地表示需求，原型设计有助于确保所有更改都是经过深思熟虑并达成一致的，从而防止范围蔓延。

5. 成本和时间效率

   • 早期发现问题：在原型设计阶段查明并解决问题通常比在开发后期进行的更改更便宜、更省时。
   • 重点开发：清晰且经过验证的原型设计的要求是使开发以另一种方式更加明确和高效。

6. 增强用户体验

   • 可用性测试：原型有助于在早期阶段测试产品，因此最终产品易于使用并满足用户的要求。
   • 迭代改进：原型反馈后所做的更改对于最终产品尽可能接近用户的需求至关重要。

业务需求挑战

1. 要求不明确或模糊

   • 模糊性：利益相关者首先可能会给出不具体或不详细的要求，因此会出现误解的问题。
   • 信息不完整：主要细节可能会被省略，因此读者会要求不断澄清以避免混淆。

2. 需求变化

   • 范围蔓延：需求的不断变化和增加将导致范围蔓延，从而延迟项目时间表并增加成本。
   • 不断变化的业务需求：随着项目的进展，业务优先级可能会发生改变，因此需求也会随之改变。

3. 利益相关者参与有限

   • 参与不足：重要实体可能没有参与需求收集过程，因此无法获得见解和关键需求。
   • 缺乏可用性：利益相关者可能长时间无法联系，这将导致他们无法及时收集需求。

4. 复杂的业务流程

• 复杂性和相互依赖性：复杂的业务流程及其之间的相互联系可能是难以清楚、具体地表述需求的原因。
• 法规遵从性：所有要求的满足都符合监管和合规标准，这反过来可能会增加项目的复杂性。

5. 确定优先级的困难

• 优先级冲突：各个利益相关者可能有不同的目标，因此很难选择首先满足哪些要求。
• 资源限制：资源稀缺性会迫使人们选择能够切实满足哪些需求。

6. 技术限制

• 遗留系统：新需求与旧遗留系统的合并是主要的技术战场。
• 可行性问题：某些要求可能过于具有挑战性或由于技术障碍而无法满足。

7. 文件不足

• 缺乏正式流程：记录需求的正式流程和模板的必要性是显而易见的，因为它们可以保证文档的一致性和完整性。
• 可追溯性差：缺乏适当的文档意味着在项目生命周期中无法追溯需求，因此测试和验证工作受到阻碍。

8. 假设和误解

• 隐含的假设：利益相关者可能会走上错误的路并做出文档中未给出的错误结论。
• 文化差异：全球项目是跨越国界进行的项目，文化差异可能会导致对要求的误解和曲解。

9. 验证和确认挑战

• 测试复杂性：检查并确认最终产品符合所有业务要求是一项艰巨的任务，尤其是在复杂的项目中。
• 用户验收：需要检查用户是否喜欢成品并且它是否满足他们的需求，这证明验证任务非常重要。

结语

总之，确立业务需求是软件工程中至关重要的初步步骤，它确保最终交付的产品能够满足组织的战略目标和用户的期望。虽然在需求定义过程中可能会遇到需求变更、沟通障碍和技术限制等挑战，但通过灵活和协作的方法可以有效地应对这些问题。通过高效且准确地收集需求并进行适当的文档化，可以优化项目成果，减少风险，并提升用户满意度。

业务需求与技术需求的区别何在？

业务需求反映了组织在高层次上的需求和目标，而技术需求则是实现这些业务需求所必须遵循的技术规范和限制条件。

谁负责审查和批准业务需求？

业务利益相关者，包括业务分析师、产品所有者、项目经理和执行发起人等，应当细致地审查并批准业务需求，以确保它们与组织的业务目标保持一致。

如何应对项目期间业务需求的变化？

应采用正式的变更管理流程，对任何符合项目目标和资源限制的变更进行实施、记录和批准。

最终用户在定义业务需求中扮演何种角色？

用户是表达自身需求和期望的关键角色。他们提供的反馈对于软件的实用性和易用性至关重要。

业务需求应多久审查和更新一次？

业务需求应在项目的整个生命周期内定期审查和更新，特别是在关键里程碑时刻，以适应不断演变的业务目标和市场条件。

本文同步发表在 软件需求探索的https://srs.pub/theory/business-req.html