收益：
- 能够区分功能性和非功能性需求，并在人工智能的支持下编写清晰、可衡量的需求表达
- 能够使用人工智能和结构化提示从访谈记录中提取用户故事、验收标准和范围限制
- 养成检查人工智能生成的需求是否含糊、矛盾和缺失规则的习惯，并与利益相关者确认它们
需求分析是以完整、清晰和可验证的方式定义系统应该做什么的任务。这是 MIS 专家创造最大价值的阶段之一；因为在项目结束时这里的错误呈指数级增长。需求分析有两种基本类型。功能需求描述了系统应该执行的工作：“系统在确认订单时应向客户发送电子邮件。”非功能性需求描述了系统应该如何：性能、安全性、可用性和可访问性等质量。 “报告屏幕在平均负载下应在 2 秒内打开”是一项非功能性要求。
一个好的需求具有三个特征：清晰（有单一的解释）、可衡量（有可测试的阈值）、可追溯（清楚来自什么业务需求）。 “系统必须快”都不满足这些； “快”是主观的，无法测量，无法测试。现阶段，人工智能在起草需求、捕捉歧义措辞方面是有力的辅助；但只有利益相关者才能决定哪条业务规则是真实的。
用户故事和接受标准
现代需求编写中的常见格式是用户故事：“作为[角色]，为了[目的]，我想要[功能]。”示例：“作为销售代表，我希望通过移动屏幕计算折扣，以便我可以在现场快速报价。”故事简短，商业导向；它不强加技术解决方案。
每个故事都应该有验收标准：故事必须满足的可测试条件才能被视为“ok”。经常使用的模式是“Given/When/Then”模式：“Given：客户属于 VIP 段。When：订单超过 10,000 TL。Then：系统应用 5% 的折扣。”这种模式消除了歧义，因为它清楚地将条件和预期结果联系起来。
提示：在为人工智能编写用户故事时，请务必说“为每个故事以给定/何时/那么格式生成至少 2 个验收标准”。当模型被迫产生基准时，需求中隐藏的差距就会变得可见。
一步一步：人工智能辅助需求提取
步骤 1 — 收集原始输入。通话记录、电子邮件、现有屏幕截图、投诉列表。输入越真实，捏造就越少。
第 2 步 — 提取第一组故事。向人工智能提供原始输入并让它生成用户故事草稿。此步骤不是完整列表，而是第一步。
第 3 步 — 添加验收标准。为每个故事生成给定/何时/那么标准。无法制定标准的故事实际上意味着它没有得到充分的定义。
第四步——扫描矛盾和差距。问 AI“这些要求之间是否存在矛盾、重复或未定义的情况？”询问并检查。以人的身份过滤结果。
第 5 步 — 确定优先级并确认。根据业务价值和紧迫性对利益相关者的故事进行优先级排序。优先决策属于业务部门，而不是人工智能。
不要忘记非功能性需求
大多数项目在现场遇到困难是因为他们在编写功能需求时忘记了非功能性需求。一份报告可能“正确”工作，但如果需要 45 秒才能打开，则没有人会使用它。下表显示了经常被忽视的非功能性需求类型和可衡量的写作示例。
流派
不好的表达
可测量的表达
性能
“一定要快”
“平均负载下查询响应 < 2 秒”
可达性
“每个人都应该能够使用它”
“符合 WCAG 2.1 AA 标准；全键盘导航”
安全性
“应该是安全的”
“个人数据静态加密；访问基于角色”
可用性
“应该很容易”
“新用户无需培训，3步完成订单”
可用性/连续性
“不应该崩溃”
“每月正常运行时间≥99.5%”
三个迷你案例：从数字来看
案例 1——无法衡量的需求的价格。该屏幕是在一家银行开发的，要求“报告屏幕要快速打开”，在现场负载下，打开时间为 22 秒。开发人员认为他在他的环境中提供了“快”这个词（2 秒）。如果需求被写成“高峰时段< 3秒，实际吞吐量”，那么问题就会在测试中被发现。重建工作需要 3 周时间以及可衡量的额外费用。
案例 2——验收标准捕获的差距。在编写电子商务项目中“系统应用折扣”故事的验收标准时，利益相关者注意到，根本没有讨论如果折扣与优惠券和VIP折扣冲突会发生什么。一个单一的“Given/When/Then”问题在上线前就避免了双重折扣错误；这个错误导致类似项目严重的收入损失。
案例 3——人工智能制定的规则。在一个HR项目中，AI在需求稿中添加了“请假申请24小时内自动批准”这句话。会议中没有讨论这种自动批准；该模型制定了一条看似“合理”的规则。在每项要求旁边，专家都会写下“来源：哪个采访/文件？”通过添加该列，他删除了 4 个无来源的句子。
弱提示/强提示
弱提示：
为该项目编写用户故事。
强力提示：
您的角色：您是一名 MIS 业务分析师。从下面的采访记录中提取用户故事。规则：- 格式：“作为一个 [角色]，出于 [目的]，我想要 [功能]。”- 以给定/何时/那么的格式为每个故事编写至少 2 个验收标准。- 在每个故事旁边添加一个“来源”列：它来自哪个句子？- 标记 [不确定] 注释中不清楚的任何规则；适合。- 在单独的部分中写下可衡量的非功能性需求（性能、安全性、可访问性）。采访笔记：[正文]
强大的提示同时强制执行故事格式、验收标准、来源可追溯性和非功能性需求；这使得更容易控制输出。
四个可复制模板
1）需求澄清：
查看下面的要求。标记每一个含糊、不可通约或有多种解释的陈述，并为每一个陈述写一个澄清问题。不要编造答案。要求：[文字]
2）矛盾扫描：
在下面的要求列表中，找到相互矛盾、重复或留下逻辑空白的项目。报告每一项发现，并附上项目编号和一句话理由。列表：[文本]
3) 生成验收标准：
以给定/何时/那么的格式为以下用户故事编写至少 4 个验收标准，包括限制和例外情况。还列出任何尚不清楚的点。故事：[正文]
4) 范围概要：
根据以下要求，将“范围内”和“范围外”项目起草为两栏表格。对于您不确定的任何项目，请标记[需要确认]。要求：[文字]
常见错误
- 思考解决方案是一种需要。 “添加下拉菜单”是一个解决方案，而不是一个要求。该要求规定“用户必须能够从定义的列表中选择国家/地区”； IT 团队设计解决方案。
- 跳过非功能性的。简单地写下“做什么”而忘记“如何做”（速度、安全性、可访问性）是最常见和最昂贵的漏洞。
- 使用不可量形容词。诸如“快速、简单、安全、人性化”之类的词语，如果没有门槛，都是无效的。
- 没有注意到AI制定的规则。该模型可能会添加“合理”但实际上并非口头的规则；请求满足各种需求的资源。
- 将优先事项留给人工智能。首先做什么是商业价值决策；业务部门给出了这一点。
注意：需求分析中最危险的一句话是“每个人都已经知道这一点”。不言而喻的假设不会出现在文档中，也不会出现在代码中，并且会出现在现场。询问 AI“此要求中假设但未写入的内容是什么？”使这些隐藏的假设变得可见。
总之
需求分析以清晰、可测量和可追踪的方式定义系统应该做什么。功能性需求描述了工作，非功能性需求描述了品质，而后者经常被遗忘。用户故事和给定/何时/那么验收标准是消除不确定性的强大工具。人工智能显着加速了故事板的制作、验收标准、冲突检测和澄清问题；然而，业务规则、范围和优先级决策的正确性以及每句话的来源都是人的责任。不要最终确定任何无源且无法衡量的需求。
应用任务
为虚构的“在线预约系统”编写一段业务请求（例如，“客户应该能够在线预约，员工应该能够查看日历”）。 (1) 创建至少 5 个用户故事，并为每个故事制定 2 个接受标准，并对此请求进行强烈提示。 (2) 在模型产生的标准中找到至少 2 个隐藏的差距（例如同时双重预约、取消规则）。 (3) 以可测量的形式包含至少 3 个非功能性需求。 (4) 将至少 3 项确定为“超出范围”。 (5) 标记模型可能制定的规则并写下您将如何确认它。
清单
- [ ] 我分别写了功能性和非功能性需求。
- [ ] 每个需求都是明确的、可衡量的和可测试的。
- [ ] 每个故事都有给定/何时/那么接受标准。
- [ ] 我可以追踪每个需求的来源（对话/文档）。
- [ ] 我把AI可能制定的规则标记出来，留待确认。
- [ ] 我与业务部门一起确定了优先级。