#requirements

AI Prompt for Business Analysts: As-Is To-Be Gap Analysis

Turn workshop notes into a business analyst gap analysis: as-is steps, root causes, a to-be process, a gap table, traced requirements, and user stories.

Act as a senior business analyst who runs process improvement workshops and turns messy as-is notes into a gap analysis that sponsors can approve and delivery teams can build from. Inputs: - Process name, trigger, end point, and the business goal behind the change: [ProcessScope] - Current steps as described by the people who do them, including workarounds and spreadsheets: [AsIsNotes] - Pain points, complaints, and any measured numbers (cycle time, error counts, volumes) with their source: [PainPointsAndMetrics] - What good looks like according to the sponsor: [ToBeVision] - Systems, roles, and teams involved: [SystemsAndRoles] - Fixed limits such as budget, deadline, regulation, or systems we cannot replace: [Constraints] - Output format: [Format] Generate: 1. A scope statement for the process: trigger, end point, in scope, out of scope. 2. An as-is step table from AsIsNotes: step number, actor, action, system or tool, handoff, and a workaround flag. Quote the note a step came from when it is ambiguous. 3. A pain point to root cause map: each pain point, the step where it starts, and the likely cause type (process, people, technology, data, or policy). Label each cause as stated by stakeholders or as your hypothesis. 4. A to-be step table from ToBeVision and Constraints, with removed steps listed separately and new steps marked NEW. 5. A gap analysis table: as-is, to-be, gap, gap type, and the change needed to close it. 6. Numbered requirements derived from the gaps: business requirements (BR), functional requirements (FR) written as "The system shall...", and non-functional requirements (NFR), each traced to a gap row. 7. Two or three user stories with Given, When, Then acceptance criteria for the highest value functional requirements. 8. A RACI for the to-be process from SystemsAndRoles. 9. Measures of success: use only metrics from PainPointsAndMetrics as baselines; where none exists, write BASELINE NEEDED and say how to collect it. 10. Risks, assumptions, and open questions for the next workshop, each with an owner role. Constraints: - Do not invent volumes, durations, costs, or savings. - Keep requirements testable and free of product names unless the input names the system. - No em dashes.