需求分析
接收需求（用户故事 + 业务规则，如适用）时应用的通用指导原则，用于分析 — 而非用于构建（那是 implementar-requerimiento 技能）。
可移植：无论项目/客户，应用方式一致。
1. 阅读与提取
- 完整阅读文档，提取：目标、范围、角色、流程、显式业务规则。
- 指出文档内部的任何不一致（例如，目标中提及但后来从未详述的内容，或一条规则与文本另一部分相矛盾）。
- 同时审查所有嵌入的图片/证据（布局、屏幕、仪表板）——而不仅仅是明显的那些。它们通常包含文本中未提及的细节，可能解决文本遗留的空白。
2. 与已有内容的比较（如适用）
- 如果需求涉及或类似于已构建的模块/流程/功能，将其与项目当前的实际代码进行比较，以确定哪些可以重用，哪些必须新建。
- 如果需求涉及修改已在使用的内容（其他模块、其他集成、其他共享流程），评估该修改对现有内容的风险，并优先隔离新内容而不是改变当前行为，除非需求明确要求更改该行为。
- 在给出最终结论前，对照实际的开发数据库验证发现 — 不要假设模式/数据，要查询。服务器和凭据：如果对话中尚未提供，向用户询问；未经用户明确授权，不得重复使用在评论/代码中找到的凭据。
3. 待澄清问题
- 明确列出每个模糊点、未指定点或依赖业务/客户决策的点（例如，谈判条件、金额、期限、阈值、权限、例外）。
- 将每个标记为待解决，直到获得回复；当客户回复时，记录回复并改为已解决。
- 在估算中不包含任何依赖尚未回答的问题的内容。
4. 清单
受影响的或新建的数据库对象、屏幕、业务规则/验证和报告的完整清单，每个注明**（新建）或（修改）**。
5. 交付物
Analisis_Impacto_[CÓDIGO].docx— 发送给客户/供应商开发团队的影响分析文档。Estimacion_tiempos_[CÓDIGO].xlsx— 每个对象/任务的小时数，含总计。Plan_Implementacion_[CÓDIGO].docx— 分阶段计划，包含阶段间的依赖关系（不都在同一阶段）。- 默认情况下，分析需求时仅生成
Estimacion_tiempos_[CÓDIGO].xlsx文件。Analisis_Impacto_[CÓDIGO].docx和Plan_Implementacion_[CÓDIGO].docx不会自动生成为文件——它们的内容（目标、范围、业务规则、不一致、与现有内容的比较、待澄清问题、清单、计划阶段）同样展开并保留在对话中，随时可在用户明确要求时导出为文档（例如，“生成影响分析”或“导出为Word”）。 Estimacion_tiempos_[CÓDIGO].xlsx必须基于现有模板构建（如果需求文件夹中已有模板，则复制它，不要重新创建表格；如果项目中尚无模板，询问用户是否有标准模板后再创建格式）。预期格式（除非用户另有说明）：标题栏 + 包含序号 | 活动 | 小时 | 天数列的表格（活动列宽，每行一项活动，末尾一行总计，包含求和公式和天数 = 小时/8）。不要添加额外列（类型、备注、单独的分析/开发/测试细分等）——如果想详述类型（新建/修改）或备注，将其包含在“活动”单元格文本中。- 实际的小时数： 确认步骤2中已确认的可重用性（不要估算为全部新建），不要对所有任务使用统一启发式，如果需要将小时数转换为日期，询问团队的实际容量。
6. 状态与阻塞因素
最后，总结：哪些已确认，哪些仍待解决，以及哪些阻止开始构建（缺少文档、待客户/业务回复、待审批等）。