CesarChv19/claude-skills_MC

요구사항 분석

요구사항(User Story + 비즈니스 규칙, 해당 시)을 분석하기 위해 접수할 때 적용하는 일반 지침입니다. 구축(이는 implementar-requerimiento 스킬 담당)을 위한 것이 아닙니다. 프로젝트/클라이언트에 관계없이 동일하게 적용 가능합니다.

1. 읽기 및 추출

• 전체 문서를 읽고 다음을 추출합니다: 목표, 범위, 액터, 흐름, 명시적 비즈니스 규칙.
• 문서 내부의 불일치 사항을 지적합니다 (예: 목표에서 언급되었지만 이후에 상세히 설명되지 않은 내용, 또는 텍스트의 다른 부분과 모순되는 규칙).
• 포함된 모든 이미지/증적(레이아웃, 화면, 대시보드)도 검토합니다. 명백한 것뿐만 아니라 텍스트에 없는 세부 정보를 포함하고 있어 텍스트가 남겨둔 공백을 해결할 수 있는 경우가 많습니다.

2. 기존 코드와의 비교 (해당 시)

• 요구사항이 이미 구축된 모듈/프로세스/기능과 관련되거나 유사한 경우, 현재 프로젝트의 실제 코드와 비교하여 무엇을 재사용할 수 있고 무엇을 새로 만들어야 하는지 파악합니다.
• 이미 사용 중인 다른 모듈, 다른 통합, 다른 공유 흐름 등을 수정해야 하는 경우, 기존 기능에 미치는 영향을 평가하고 요구사항이 해당 동작 변경을 명시적으로 요구하지 않는 한, 새로운 기능을 격리하는 것을 선호합니다.
• 발견 사항을 확정하기 전에 실제 DEV 데이터베이스와 대조하여 확인합니다. 스키마/데이터를 가정하지 말고 직접 조회합니다. 서버 및 자격 증명: 대화에 이미 없는 경우 사용자에게 요청합니다. 사용자의 명시적 허가 없이 주석/코드에서 찾은 자격 증명을 재사용하지 마십시오.

3. 미해결 질문

• 모호하거나, 명시되지 않았거나, 비즈니스/클라이언트 결정(예: 협상 조건, 금액, 기한, 임계값, 권한, 예외)에 의존하는 모든 지점을 명시적으로 나열합니다.
• 각각을 보류로 표시하고 답변을 받을 때까지 기다립니다. 클라이언트가 응답하면 답변을 문서화하고 해결됨으로 전환합니다.
• 아직 답변할 수 없는 질문에 의존하는 내용은 추정에 포함하지 않습니다.

4. 인벤토리

영향을 받거나 새로 생성되는 데이터베이스 객체, 화면, 비즈니스 규칙/유효성 검사, 보고서의 전체 목록으로, 각 항목에 (신규) 또는 (수정) 을 표시합니다.

5. 산출물

• Analisis_Impacto_[코드].docx — 클라이언트/공급업체의 개발팀에 보낼 영향 분석 문서.
• Estimacion_tiempos_[코드].xlsx — 객체/작업별 시간, 합계 포함.
• Plan_Implementacion_[코드].docx — 단계별 계획으로, 각 단계 간 의존 관계 포함 (모든 것을 한 단계에 넣지 않음).
• 기본적으로 요구사항을 분석할 때는 Estimacion_tiempos_[코드].xlsx 파일만 생성됩니다. Analisis_Impacto_[코드].docx 및 Plan_Implementacion_[코드].docx는 자동으로 파일 생성되지 않습니다 — 해당 내용(목표, 범위, 비즈니스 규칙, 불일치 사항, 기존 코드와의 비교, 미해결 질문, 인벤토리, 계획 단계)도 동일하게 개발되어 대화 내에서 유지되며, 사용자가 명시적으로 요청할 때(예: "영향 분석 문서를 생성해 줘" 또는 "Word로 내보내 줘") 문서로 작성할 준비가 되어 있습니다.
• Estimacion_tiempos_[코드].xlsx는 기존 템플릿을 기반으로 작성되어야 합니다 (요구사항 폴더에 이미 있는 경우 복사하고 처음부터 테이블을 다시 만들지 않음. 프로젝트에 아직 템플릿이 없는 경우 사용자에게 표준 템플릿이 있는지 먼저 물어본 후 형식을 결정합니다). 사용자가 다른 형식을 지정하지 않는 한 예상 형식: 제목 행 + 번호 | 활동 | 시간 (Hrs.) | 일 (Días) 열로 구성된 테이블 (활동 열은 넓게, 각 활동당 한 행, 마지막 합계 행에는 SUM 공식과 일 = 시간/8 공식 포함). 추가 열(유형, 메모, 분석/개발/테스트 별도 분류 등)을 임의로 만들지 마십시오. 유형(신규/수정)이나 메모를 상세히 표시하려면 "활동" 셀 텍스트 안에 포함시킵니다.
• 현실적인 시간 산정: 2단계에서 확인된 재사용을 인정합니다 (모든 것을 새로 개발하는 것처럼 추정하지 않음). 모든 작업에 동일한 경험 법칙을 사용하지 않으며, 시간을 날짜로 변환하는 데 필요한 경우 실제 팀의 역량을 문의합니다.

6. 상태 및 차단 요소

마지막으로 다음을 요약합니다: 확정된 사항, 계속 보류 중인 사항, 구축을 시작하기 위해 차단되는 사항 (누락된 문서, 클라이언트/비즈니스의 답변 보류, 승인 등).