AI-Powered System Analysis & Design is a course in using AI across systems analysis work, from requirements, use cases, process flows and ER diagrams to API design, architecture and test scenarios, with diagrams written as code in Mermaid and PlantUML and a capstone design. It suits system and business analysts, developers, tech leads and project managers.
System analysis and design work burns more time on writing documents and drawing diagrams than on the design thinking itself. Getting the use cases complete, finishing the process flows, making the ER diagram match what was actually agreed, then writing the API spec and sketching the architecture on top of that. And when requirements shift mid-project the whole document set has to be reworked. The result is that many teams skip the design stage entirely and go straight to code, then hit the wall once the system grows. This course makes that time-consuming work several times faster with AI and gives the time
back to the decisions AI cannot make for you. Learners walk the same path as real work: gathering and sharpening requirements, breaking them into use cases, writing process flows, designing the ER diagram, specifying the API with OpenAPI, sketching the system architecture, and deriving test scenarios, producing every diagram as code with Mermaid and PlantUML so it can be edited and versioned in Git. It also covers how to review AI output so mistakes do not slip through into development, and closes with a capstone that designs one system end to end. (2 days, 6 hours per day, 12 hours in total, Beginner to Intermediate level.)
Course Details
A 2-day course, 6 hours per day (12 hours in total, 09:00-16:00), delivered as lectures with workshops on a real system of the learner choosing. Beginner to Intermediate level. Almost all tools used are open source or have a free tier; learners bring their own ChatGPT or Claude account. Learners take home a prompt template set covering every stage of system analysis, sample Mermaid and PlantUML diagram files, and a system design document template. The content focuses on the thinking and the process, so it transfers to other AI tools as the technology changes.
Section 1: AI in System Analysis and Design
The traditional SA workflow and the steps that consume the most time, which teams then skip
What AI does well versus what still requires human judgement
The full path: requirement, use case, process flow, ER diagram, API, architecture, test
Diagram as code and why design work belongs in Git
Preparing and configuring the tools for both days
Section 2: Gathering and Sharpening Requirements with AI
The difference between business, functional and non-functional requirements
Using AI to summarize meeting notes and extract requirements item by item
Writing requirements that are clear, measurable and unambiguous
Having AI find contradicting requirements and the gaps still missing
Prioritization and requirement traceability
Lab: turn raw meeting notes into a usable requirements document
Section 3: Use Cases and Actors
Identifying actors and system scope before writing any use case
Breaking requirements into use cases with main and alternate flows
Writing complete preconditions and postconditions
Producing use case diagrams with PlantUML and editing them as code
Common mistakes such as use cases that are too granular or too broad
Lab: build a use case diagram from your own requirements
Section 4: Process Flows and Sequence Diagrams
Writing business process flows that show the order of work and who owns each step
Using Mermaid for flowcharts and laying them out for readability
Writing sequence diagrams to explain how parts of the system talk to each other
Handling conditions, loops and exception cases in diagrams
Lab: write the process flow and sequence diagram for your core process in Mermaid
Section 5: ER Diagrams and Database Design
Extracting entities and relationships from requirements and use cases
Setting primary keys, foreign keys and cardinality correctly
Normalization principles and when denormalizing is the better trade
Producing the ER diagram in Mermaid and converting it into table scripts
Lab: design an ER diagram then create the real tables on PostgreSQL to test it
Section 6: Reviewing the Data Model Before Moving On
Using AI to check the data model actually supports every use case written
Testing with sample data and real queries to expose design mistakes
Considering data volume and the indexes needed from the design stage
Lab: review and adjust your data model until it supports every use case
Section 7: API Design with OpenAPI
Deriving the required API list from the use cases
REST design principles: resource naming, method selection and status codes
Writing the spec in OpenAPI with request, response and error models
Using AI to draft the spec and checking it covers every case
Using the spec so frontend and backend can work in parallel before the system exists
Lab: write the OpenAPI spec for your system and validate it
Section 8: System Architecture Design
Architecture components: interface, processing, database and external services
Choosing an architecture style that fits the team size and the complexity of the work
Writing architecture diagrams in Mermaid and refining them in Draw.io
Marking non-functional requirements on the diagram, such as security and load capacity
Lab: sketch your system architecture and justify every component
Section 9: Test Scenarios and Test Cases
Deriving test scenarios from use cases covering both normal and exception paths
Writing test cases with preconditions, steps and expected results
Using AI to surface the cases people usually miss, such as boundary values and malformed input
Linking test cases back to requirements so coverage can be verified
Lab: build a test scenario set from your own use cases
Section 10: Reviewing Design Quality
Where AI typically gets system design wrong and how to catch it
Checking consistency across requirements, use cases, data model and API
Using AI as a second reviewer by asking it to raise questions rather than give answers
Handling requirement changes that force a rework of the whole document set
Section 11: Delivering the Design Document
What a system design document needs to contain for a dev team to actually use it
Keeping diagram as code in Git and keeping documents in step with the code
Presenting the design to executives and users without going into technical detail
Lab: assemble a complete system design document from both days of work
Section 12: Capstone and Real-World Adoption
Capstone: design one system end to end from requirement through test scenario
Presenting the reasoning behind each design decision
How to bring this process into real work and adapt it to your team
Workshop: present your work and review the design together with the instructor
No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770
Diagrams as code means writing diagrams as text in a language such as Mermaid or PlantUML and letting a tool draw them. They can live in Git alongside the code, with change history and review through pull requests, they are easy to edit without moving boxes around, and because they are text, AI can draft or revise them. That makes it far easier to keep documentation in step with the real system.
Start by identifying the actors, both people and external systems, and setting a clear system boundary. Break the requirements into use cases that each deliver a meaningful result to an actor, write the main flow for the normal case, then add alternate flows and exceptions, with pre-conditions and post-conditions. Avoid use cases so detailed they become screen steps, or so broad they cover the whole system.
Normalisation organises tables to reduce duplicated data and prevent inconsistencies when data changes, by keeping each subject in its own table and linking tables with primary and foreign keys. The common levels are 1NF, where each field holds a single value, through 2NF and 3NF, where every column depends directly on the whole key. For heavily read reporting tables, denormalising can be worth it for faster queries.
It suits systems and business analysts who want to spend less time on documents and diagrams, developers who design systems before coding, tech leads and project managers who review designs, and people moving into systems analysis. You should understand the software development process and be able to read basic data structures; programming is not required, though some SQL helps with the ER diagram sessions.
You will be able to use AI to clarify requirements and spot conflicts, write use cases in PlantUML, create process flows and sequence diagrams in Mermaid, design ER diagrams and build the tables in PostgreSQL, write API specifications in OpenAPI, sketch system architecture, derive test scenarios from use cases, and review AI output before handing documents to developers. Participants who complete the training receive a Certificate of Completion with its own number, which can be verified online.
Yes. It can be run in-house for your team, with examples adapted to your own work, such as producing design documents for a system your team is currently analysing throughout the workshops. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.
Claude Code is not merely a tool for asking an AI to write code. It acts as an AI coding agent that understands project structure, reads files, edits source code, runs commands, tests the system and works alongside a real development workflow. Anyone still…
Plenty of people have an idea for a web tool they want in their own work but stall because they cannot code, and hiring it out costs both time and budget. AI coding assistants have changed that. Someone with no background can describe what they want in plain…
