1. 需求方定义

需求方是软件产品/项目需求的发起者与最终确认方，核心角色根据业务场景分为两类：

• 内部项目：核心需求方为公司决策层（如老板、业务负责人），需代表内部业务场景的真实诉求；
• 外包项目：核心需求方为甲方（如甲方公司的产品负责人、业务对接人），需对最终交付结果的功能、效果负责。

2. 需求方与项目组对接规则

为避免需求传递偏差、提高协作效率，需遵循以下对接原则：

2.1 需求对接：仅对接产品岗（唯一接口）

• 常规要求：所有功能需求、优化需求（如新增功能、流程调整、逻辑变更），必须且只能通过产品岗对接，禁止直接向开发、设计岗提需求；
• 特殊例外：仅当产品岗无法及时响应（如临时出差、突发疾病）且需求属于“紧急故障修复”“影响核心业务的紧急调整”时，可临时联系项目负责人（或测试岗）同步，后续需补全与产品岗的正式对接流程（如需求文档确认）。

2.2 需求描述：“说问题+讲目标”，而非“定方案”

• 正确方式：需清晰描述“当前业务场景遇到的问题”（如“用户下单后，无法实时收到短信通知，导致多次咨询客服”）、“期望达成的效果”（如“下单后1分钟内发送短信，包含订单号和预计发货时间”）；
• 辅助沟通：若有参考案例（如竞品功能、同类产品界面），可提供截图、链接或文字描述，帮助产品岗更精准理解需求，但无需强制要求项目组“按参考案例实现”；
• 禁止行为：避免直接要求“必须加一个按钮在页面顶部”“用XX技术实现这个功能”，此类“方案型需求”可能忽略技术可行性或业务逻辑完整性，需由产品岗结合整体方案评估。

2.3 BUG对接：优先对接测试岗（专业确认）

• 常规要求：发现功能异常（如点击无响应、数据显示错误、流程卡住）时，需先反馈给测试岗，由测试岗复现BUG、确认影响范围（如仅部分用户受影响/全量用户受影响）、录入BUG管理工具（如Jira、禅道）；
• 特殊例外：仅当出现“系统崩溃”“核心业务中断”（如支付无法完成、后台数据无法访问）等紧急故障时，可直接联系开发岗临时修复，但后续需配合测试岗补全BUG提交流程（如描述复现步骤、异常现象）。

3. 原型评审：两次评审，分别确认“逻辑”与“体验”

所有需求需经过两次评审，确保功能逻辑符合需求、界面交互满足预期，评审通过后才能进入下一环节（如UI设计、开发）。

3.1 低保真原型评审（功能逻辑确认）

• 发起方：产品岗（需提前1-2天同步评审材料，如低保真原型、需求说明文档）；
• 评审核心：重点确认“功能逻辑是否符合需求”“流程是否完整”“边界场景是否覆盖”（如“用户未登录时，点击下单是否会跳转登录页”“订单取消后，已支付的金额是否会自动退款”）；
• 结果要求：需明确“通过”或“需修改”——若通过，后续开发需以本次确认的逻辑为准；若需修改，产品岗需根据评审意见调整原型，重新组织评审（小范围修改可仅同步需求方确认）。

3.2 高保真原型（UI/UE）评审（界面与交互确认）

• 发起方：UI岗（需提前同步高保真原型文件，如Figma链接、Axure原型）；
• 评审核心：重点确认“界面美观度是否符合预期”“交互逻辑是否流畅”“视觉重点是否匹配业务优先级”（如“‘提交订单’按钮是否足够醒目”“表单填写错误时，提示是否清晰”）；
• 结果要求：若有小范围调整（如颜色微调、按钮位置修改），可由UI岗直接修改后同步需求方确认；若需重大调整（如整体布局变更、交互逻辑修改），需重新组织评审。

4. 验收流程：两次验收，覆盖“测试环境”与“正式环境”

由于测试环境与正式环境的服务器配置、数据量、网络环境存在差异，需分两次验收，确保上线后功能稳定。

4.1 测试环境验收（核心验收环节）

• 发起方：测试岗（需提前同步“测试环境验收清单”，包含本次上线的需求点、测试通过标准）；
• 验收重点：需求方需对照“验收清单”，逐一验证“自己提出的需求是否已实现”“功能逻辑是否与评审时一致”“边界场景是否无异常”（如“新增的‘会员折扣’功能，不同会员等级的折扣是否正确”）；
• 结果要求：需明确“验收通过”或“存在问题”——若存在问题，需详细描述异常现象（附截图/录屏更佳），由测试岗反馈开发岗修复，修复后需重新验收；若通过，需在验收清单上签字/确认，作为进入正式环境部署的依据。

4.2 正式环境验收（最终验证环节）

• 发起方：测试岗（正式环境部署完成后，第一时间通知需求方）；
• 验收重点：需求方需快速验证“核心功能是否正常可用”“数据是否与测试环境一致”（如“用户下单、支付流程是否顺畅”“之前测试通过的功能是否无新增BUG”）；
• 注意事项：虽无需像测试环境那样逐点验证，但需重点关注“测试环境无法覆盖的场景”（如“正式环境的短信发送是否正常”“大流量下功能是否卡顿”）；若发现问题，需立即反馈测试岗，启动紧急修复流程。