Business Analysis: Functional & Non-Functional Requirements

学习需求分解/逐层细化技术，然后判断 AI 输出是否正确、错误或只是听起来不错

讲师:Tom and Angela Hathaway

您将学到什么

• 将需求说明和用户故事分解为功能要求、数据要求和非功能要求，采用经过实战检验的分步技术。
• 识别并记录在分解过程中出现的数据需求、性能限制和业务规则
• 识别非功能性需求（例如，易用性、可靠性、性能和合规性），这些需求通常被 AI 工具在生成的规范中遗漏。
• 编写可量化的解决方案需求，以支持终端用户验收测试和供应商评估
• 使用生成式 AI 工具大规模建议分解的功能性和非功能性需求，缩短时间而不降低标准
• 通过人工介入验证来捕捉生成的 AI 要求中的幻觉、遗漏和上下文错误，防止其进入开发阶段。
• 评估由 AI 生成的需求，以确保其达到解决方案提供商为您的组织做出明智技术决策所需的详细程度。
• 通过练习来展示每种技术，这些练习旨在在实际项目中需要判断力之前培养你的判断能力。

课程要求

• 无需技术背景要求
• 定义 IT 的非功能性需求的意愿
• 对商业分析领域的兴趣
• 支持 HTML5 的浏览器（用于练习和测验）
• 无需额外材料

课程描述

功能需求与非功能需求决定项目成败

Standish Group 已经追踪 IT 项目的成果超过三十年。数据几乎没有变化：只有 31% 的 IT 项目成功，而未完成或定义不明确的需求始终是失败的主要原因。

这不是一个技术问题。从来都不是技术问题。生成式 AI 并不能解决它。反而会放大这一问题。AI 工具可以快速自信地将您的业务需求分解为功能和非功能性规范。它们无法判断所产出的内容是否完整、正确，或者是否有某些关键要素缺失，而这些要素是构建解决方案不可或缺的。这种判断仍然属于人类。本课程就是教你如何培养这种判断力。

为什么章节顺序至关重要

第二章和第三章通过练习和实际案例教您我们经过验证的需求分解技术。您将学习如何将需求陈述和用户故事分解为功能需求（解决方案必须实现的功能）、数据需求（它必须处理的数据）以及非功能性需求（性能阈值、可用性标准、可靠性约束及管理行为的业务规则）。安吉拉和我在这四十年间，在全球多个地区数百个项目中开发和完善了这些技术。它们经过实践检验，而非理论上的，这一点在项目真实且风险实际存在时尤为重要。

新内容：为了支持您的非功能需求工作，本课程现在包括“完整的‘ilities’指南：121 个非功能性质量属性、测试标准和 AI 集成标准，简单明了！”作为可下载资源。它列出了具有简洁描述的 121 个非功能性质量属性、可测试接受标准以及 AI 集成标准。大多数团队仅使用八到十个属性列表工作。现在您将拥有 121 个。请妥善保存，因为您在第四章中的 AI 演示期间会用到它。

掌握基础知识后，第四章将展示如何将生成式 AI 引入工作流程。您可以使用自己选择的 AI 工具建议分解后的功能和非功能性需求（快速、大规模地），然后通过人工介入判断来评估返回的内容。实际上这意味着要对比 AI 建议与您的实际业务环境，并标记缺失或错误的部分。AI 工具会用同样的自信语气生成幻觉，就像它们对其他事情一样。您的任务是在这些内容进入开发之前将其识别出来。

为什么基础很重要

AI 工具无法了解您组织的具体限制、利益相关者的隐含假设以及解决方案必须遵守的监管环境。拥有扎实分解技能的专业人员可以在几分钟内评估 AI 输出并发现缺失的部分。如果没有这个基础，您实际上就是在批准工具决定的内容——而误解往往在最糟糕的时候出现（例如，在系统测试中，或者更糟的是，在生产环境中）。

注意：本课程与具体工具无关。特定的 AI 产品会来去匆匆。这里教授的提示词工程技能可以应用于我们组织正在使用的任何工具。

练习的目的

为了最大化学习效果，每个技术都包含作业。它们不是传统意义上的测试。其目的是在一个比单纯解释更接近现实的情境中展示每种技术。如果您完成这些作业，这些技术将更容易掌握。如果跳过它们，您仍然会理解这些技术——只是在工作中需要稍长一点时间才能变得得心应手。

本课程适合谁:

• 业务分析师和系统分析师
• 敏捷产品负责人和产品经理
• 负责需求的专题专家
• 项目领导者和项目经理
• 业务流程负责人和领域专家
• 敏捷团队成员参与故事细化
• 业务系统分析师
• 任何人收到解决方案需求草稿并被要求确认其是否正确。