Task 1 (Inconsistency) Task 2 (Change Management) Task 3 (Decision making) Mission 1 (Impact) Mission 2 (Issue Report) 📊 View Summary ← Classroom
Day 2 Task 06 Impact analysis

Task 06. Impact Analysis

We use Codex Workspace to infer and analyze screens, APIs, DBs, and document schemas that are sequentially affected by requests to add mobile phone authentication.

Task 01 Specification Inconsistency Detection Practice Guide

📥 Practice Input

  • • meeting-notes.md (meeting minutes)
  • • requirements.md (Requirements definition)
  • • screen-specification.md (Screen definition)

📤 Practice output (Output)

  • • Summary report table of inconsistencies and actions taken

🛠️Practical guide to follow along

  1. Acknowledgment of request: Identifies the customer's change request to "Add Mobile Phone Verification".
  2. Codex Impact Analysis: Build by sending an impact analysis prompt to the Codex Client prompt input window.
  3. report check: In the printed report, review whether the membership registration screen (high), login API (medium), user DB (high), and administrator screen (low) action mapping are accurately entered.

Practice method guidance

This mission is based on the context of the entire Codex Workspace project (UI plan, API specification, DB schema, etc.) Infer the ripple effect of new change requestsThis is a practice. Without downloading a separate practice file, simply copy the prompt below and enter it into the Codex Client window.

Codex request prompt

Mission 1 Prompt
If the mobile phone authentication function is added to membership registration, please find all affected screens, APIs, DBs, and documents and prepare an impact analysis report.

Expected results report

Category Findings and Contradictions Influence reference document Recommended Action
Policy/Function In the meeting minutes, the 10% fee refund policy for cancellation of reservations was confirmed, but the requirements definition (`requirements.md`) was completely missing related information. high meeting minutes Reservation cancellation and 10% penalty refund function requirements must be additionally reflected in the requirements definition document.
Policy/Screen When a member withdraws, the meeting minutes define 'automatic cancellation and full refund' for existing reservations, but the requirements document defines 'retention and maintenance', and the screen definition defines 'hidden processing without pop-up information', so all three documents are different. high meeting minutes After coordination with the planning team, it is necessary to unify the withdrawal logic of the requirements and screen definitions based on the meeting minutes.
Function/Screen In the meeting minutes and screen definitions, it was designed so that 'the user (Customer) evaluates the expert (Expert)', but in the requirements document (FR-004), the subjects were written in the opposite direction so that 'the expert (Expert) evaluates the user (Customer)'. high meeting minutes FR-004 evaluation subject in the requirements definition has been revised and reflected as Customer.
screen In the meeting minutes, it is stated that 'reservation request button is disabled' for non-members, but the screen definition (SCR-001) contradicts it by 'activating non-member reservation button' and entering the schedule without encouraging registration. middle meeting minutes Modified the non-member home screen reservation flow in the screen definition to ‘Induce deactivation or registration pop-up’

💡 AI utilization and learning points

AI is not a ‘correct answer writer’ ‘Reviewer’Verification productivity is maximized when training with . It is a practical methodology that saves about 100 times the cost of rework due to design omission by verifying inconsistencies between the three major documents in advance.