简易化需求撰写

定位与适用

用尽可能简单的方式说明业务为什么要改、改什么、流程如何变化，供 IT 和业务同事阅办、调整或形成开发文档。适用于流程、规则、职责或系统操作的业务调整；纯分析报告、完整技术方案或开发文档不属于本技能的交付范围。用户同时需要这些内容时，只对其中的简明业务需求部分使用本技能。

开始前

开始撰写前，先询问用户希望“先看初稿再优化”，还是“先逐项确定关键点”；用户已明确选择时直接按其选择执行。再确认本次任务的目标、读者、交付形式和实际可用的材料。材料可能是几句话、录音、会议记录、数据、截图、分析报告或旧版需求，也可能只有其中一种。不要预设某种材料必有、必为最终口径。

以用户本次明确确认的口径为准；用户明确更新旧版规则时采用新口径。阅读材料时区分已确认规则、现状事实、讨论建议和待定事项；数据只支持其统计范围内的结论。其他冲突要核对来源、时间和口径，不自行选定一个版本。

提炼需求

围绕以下问题取舍内容，不必为了凑齐栏目而增加无关细节：

• 为什么需要调整：用短段落交代现状和问题。
• 需要调整什么：写明涉及的对象、环节和主要动作。
• 调整后如何流转：写清触发条件、处理人、关键判断和后续去向；涉及多方时简要写明交接条件、移交方、接收方和后续动作。
• 哪些仍需决定：只列会影响业务理解或后续配置的关键问题。

如果提供了相关数据，尽量选用少量能说明背景、问题规模或变更原因的关键数据，在背景中点到为止。核对统计时段和口径，不堆砌数字，不把分析结论或示例数字直接写成实施阈值。

缺失与冲突的处理

能依据现有材料写清的内容直接写。若材料无法读取，说明缺少哪一项，请用户重传或粘贴关键内容；先处理其余可用材料，不声称已核对缺失材料。若用户指定该材料为最终依据，依赖它的规则只能标为待核对，不能用其他材料定最终口径。若只有一句想法，先梳理可确认的目标和流程，再追问会改变流程结果的关键条件。若规则、阈值或责任方冲突且用户尚未明确替代关系，指出冲突及其影响，请用户定口径，不猜测填空。

用户要求逐项确认，就一次问一个关键问题，并在完全回答后再交付最终稿。用户要求先看初稿，就先写可确定部分，把关键空缺在对应位置标为“待明确”，不让待定项冒充已定规则。跨部门交接的关键责任或条件不明时也如此处理。收到新口径后更新正文，删除过时的待定表述。

写作与交付

用直接、简短的业务语言。通常采用标题、简短背景段落和一两张流程表；表格只写必要的“环节、条件、动作、责任方”。跨部门交接较多时才增加一张简短分工表。整体篇幅以简要说明为主，以读者能看明白为准，不为凑页数增加内容。

除非用户要求，不加入封面、复杂图示、验收条款、接口设计、数据库设计或技术实现方案。沿用现有流程的部分，说明衔接位置即可，不猜测系统内部实现。

最终交付一份完整、可供同事阅办的需求正文。用户要求 Word 时生成可编辑文档，并检查内容、表格和实际分页；修订时保留原稿，另存清楚命名的新版本。

简短示例

原话：“采购申请提交后，2 个工作日还没审批，系统自动提醒审批人；之后仍未处理，由部门负责人介入，介入时点还没定。”可写为：

这个例子只展示写法；其中的时限和角色不是其他需求的默认口径。

易错点

• 不把讨论中的建议、样本数据或示例数字直接写成实施规则。
• 不用接口、数据库、算法参数代替业务动作；确需技术方案时由后续开发文档细化。
• 不为显得完整而罗列全部数据、补造缺失条件，或把简单调整扩成完整项目方案。
• 不将已确认口径继续留在“待明确”中，也不在不同段落写出相互矛盾的条件。