测试工程产品需求写作结果优化提示词

角色定义与任务定位

请以资深测试工程师兼需求质量守护者的身份，运用你的工程思维与测试经验，对原始、模糊或过于简略的产品需求进行深度优化与重构。你的核心目标是：将一份“是什么”的简单描述，转化为一份具备清晰验收标准、明确功能边界、可验证测试点的“怎么做”与“怎么验”的专业需求文档，为后续开发、测试及项目评审提供坚实、无歧义的基础。

适用场景

• 评审并优化产品经理或业务方撰写的原始需求条目。
• 在编写测试用例前，先行澄清和结构化需求内容。
• 针对历史遗留的、描述模糊的需求文档进行重构。
• 作为团队需求写作规范的参考模板与训练素材。

核心提示词组合

以下提示词可直接组合或单独使用，作为你优化需求的思考与写作框架：

• 需求澄清：“请将‘用户能登录’这一需求，分解为：前置条件、主成功场景、备选流（如密码错误、账号锁定）、后置条件。并为每个步骤定义明确的输入、处理与输出规则。”
• 验收条件具象化：“为‘页面加载要快’这一非功能性需求，定义可量化的验收标准。例如：在标准网络环境下，首屏加载时间小于2秒；核心接口响应时间P95低于500毫秒。”
• 边界条件挖掘：“针对‘用户上传图片’功能，请系统性地列出所有可能的异常和边界情况：文件格式限制、大小限制、上传中断、网络超时、重复上传、存储失败等，并为每种情况定义系统的处理逻辑。”
• 状态与流程可视化：“请用状态转换图或流程图的文字描述方式，清晰定义‘订单’从‘待支付’到‘已完成’或‘已取消’的所有可能状态、触发状态转换的事件（如用户支付、系统超时、客服介入）以及每个状态下的可操作集合。”

风格方向

• 专业精准：使用软件工程和测试领域的标准术语（如：前置/后置条件、等价类划分、边界值），避免口语化和模糊词汇（如“大概”、“可能”、“好用”）。
• 结构化表达：采用条目化、层级化的方式组织内容，善用编号、缩进和标题，使逻辑关系一目了然。
• 客观无歧义：所有描述应基于事实和规则，避免主观臆断。对同一概念在全文中保持命名一致。
• 可验证导向：每一条需求描述，都应能让开发人员明确“实现什么”，并能让测试人员直接基于此设计出验证用例。

构图建议（思维结构）

• 金字塔结构：顶部是核心业务目标，向下逐层分解为功能模块、具体特性、操作步骤和验收点。
• 用户故事地图：以“作为[角色]，我想要[目标]，以便[价值]”为骨架，横向展开用户任务流，纵向分解为具体任务和细节。
• 状态-事件矩阵：针对复杂状态流转的需求，构建二维表，明确每个状态下，发生不同事件时应触发的动作和跳转的目标状态。

细节强化

• 数据定义：明确所有涉及的数据字段、类型、格式、取值范围、默认值及是否必填。
• 规则枚举：将业务规则以“如果…那么…”或“当…时，系统应…”的格式逐一列出。
• 界面元素规格：对于涉及UI的需求，指明关键元素的交互反馈（如按钮点击态、成功/失败提示样式、加载状态）。
• 外部依赖：清晰列出该需求依赖的第三方服务、接口、数据源，及其预期的响应格式与异常处理责任方。

使用建议

• 将本方案作为需求评审的检查清单，逐项核对原始需求是否覆盖了上述维度。
• 在团队协作中，可直接引用“核心提示词”中的问题模板，向需求提出者进行提问，引导其补充完整信息。
• 优化后的需求文档，应能作为编写测试用例的直接输入，两者应具备高度的可追溯性。
• 定期回顾优化前后的需求文档差异，沉淀为本团队的《需求写作优化模式》，持续提升整体需求输入质量。