Business Analysis and Requirements Engineering is a course in the full business analysis cycle, from stakeholder analysis and elicitation to BPMN process models, testable requirements, user stories and use cases. It suits new business analysts, product owners and key users who communicate needs to development teams, and you leave with a complete requirements package for a sample system.
Many IT projects do not fail because of technology but because the team never shared the same understanding of what was needed. Users describe what they want in broad sentences, the development team reads it another way, and the delivered system goes through round after round of rework, budgets overrun and nobody can say where a given requirement came from. Business analysis is the skill that closes this gap, from understanding the real problem to writing requirements the team can build and test.
This course takes learners through the full business analysis cycle. It starts with the role of the BA in Waterfall and Agile projects, setting scope and analysing stakeholders, then practises elicitation through interviews, workshops, observation, document analysis and surveys. Learners model as-is and to-be processes with BPMN basics and separate out business rules, then write functional and non-functional requirements, user stories with Given/When/Then acceptance criteria and use cases. They prioritise with MoSCoW, produce a BRD, an SRS and a traceability matrix, run reviews and change control, and use AI assistants carefully to draft and check requirements. The course closes with a capstone that produces a requirements package for a sample system. (2 days, 6 hours per day, 12 hours in total, Beginner to Intermediate level.)
Course Details
The course runs for 2 days, 6 hours per day (12 hours in total, 09:00-16:00), mixing lectures with workshops and role-play on a single sample system that runs through the whole course. Beginner to Intermediate level, and no programming is needed. It covers the full business analysis cycle, from stakeholder analysis, elicitation and BPMN process modelling to writing requirements, user stories and use cases, prioritising, producing a BRD, an SRS and a traceability matrix, and managing change control. It draws on the BABOK Guide as a body of knowledge but is not a certification preparation course. Learners take home templates for every document type and the requirements package they built in the capstone to use as a model for real work.
Section 1: The Role of the Business Analyst
What a BA does, and how the role differs from system analyst, project manager and product owner
BA work in Waterfall projects compared with Agile and Scrum
The requirements life cycle, and the BABOK Guide as the profession's reference body of knowledge
Workshop: read the sample system brief and separate symptoms from the real problem
Section 2: Business Need, Scope and Stakeholders
Separate the problem, the business need and the proposed solution, and set success measures
Define scope with a context diagram and in-scope and out-of-scope lists
Analyse stakeholders with a power/interest grid and assign roles with RACI
Workshop: build a stakeholder map and context diagram for the sample system
Section 3: Elicitation Techniques
Interviews: prepare questions, ask open questions and probe for the reasons behind answers
Requirements workshops and the facilitator's role in reaching agreement
Observe real work, analyse existing documents and design surveys
Lab: role-play an interview and summarise it as meeting notes
Section 4: Analysing and Organising What You Gathered
Separate facts, opinions, assumptions and constraints
Group findings with an affinity diagram and find root causes with 5 Whys and a fishbone diagram
Handle disagreements between stakeholders
Workshop: write the problem statement and an initial requirements list
Section 5: Lab: As-Is and To-Be Process Modelling
BPMN basics: events, activities, gateways, pools and lanes
Model the as-is process and find bottlenecks, duplicated work and error-prone steps
Design the to-be process and summarise a gap analysis of what the new system must change
Lab: model the approval process of the sample system as-is and to-be
Section 6: Business Rules and the Data a System Needs
Separate business rules from processes and requirements
Write business rules that are clear and verifiable, and use decision tables
A glossary and a basic conceptual data model so everyone uses the same terms
Workshop: build a decision table for the approval conditions of the sample system
Section 7: Functional and Non-functional Requirements
Levels of requirements: business, stakeholder, solution and transition
Write functional requirements that are clear, unambiguous and testable
Non-functional requirements for performance, security, usability and availability
Lab: rewrite ambiguous requirements from a sample document
Section 8: Lab: User Stories and Acceptance Criteria
The As a, I want, So that format, INVEST, and splitting epics with story mapping
Write Given/When/Then acceptance criteria that QA can test against
Definition of Ready, Definition of Done and backlog refinement
Lab: write user stories with acceptance criteria for the sample system
Section 9: Use Cases and Confirming Screens
Use case diagrams: actors, use cases and the system boundary
Use case specifications: main flow, alternative flows and exception flows
Choosing between use cases and user stories for a given project
Lab: write a use case specification with every flow and sketch a wireframe to confirm with users
Section 10: Prioritisation and Requirements Documents
Prioritise with MoSCoW, weighing value, effort and risk
The structure of a BRD and an SRS, and choosing the right level of detail
A requirements traceability matrix linking requirements to design and test cases
Workshop: prioritise with MoSCoW and build a traceability matrix
Section 11: Validation, Change Control and Working with the Team
Reviews, walkthroughs and getting sign-off from stakeholders
Change requests: assess impact, approve and update the baseline
Hand requirements over to UX, developers and QA, and answer questions during development
Lab: use an AI assistant to review user stories without sharing confidential data, then filter its suggestions yourself
Section 12: Workshop: Capstone Requirements Package
Take a new system brief and plan the elicitation as a team
Summarise stakeholders, the as-is and to-be processes and the business rules
Produce user stories, use cases, NFRs and a traceability matrix as one package
Present, get feedback from the instructor and classmates, and wrap up with a BA checklist
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
Write the story as: As a (user), I want (something) so that (benefit), and check it against INVEST: independent, negotiable, valuable, estimable, small and testable. Write acceptance criteria in Given/When/Then form, describing the starting situation, the action and the expected result, so developers and QA share the same understanding and can test it.
The as-is process shows how work is done today and is used to find bottlenecks, duplicated effort and error-prone steps. The to-be process is the redesigned flow after improvement or a new system. Drawing both in BPMN, with events, activities, gateways and lanes, and comparing them gives a gap analysis of what the new system must change.
Functional requirements state what the system must do, for example that users can submit an approval request with an attachment. Non-functional requirements state how well it must do it, covering areas such as performance, security, usability and availability. Both should be clear, unambiguous and testable, for example giving a response time as a number rather than saying the system must be fast.
It suits people starting out as, or moving into, business or systems analysis, product owners and project managers who communicate needs to development teams, and key users representing their department on IT projects. You do not need to code, but you should have used or been involved with business systems and be comfortable with office software.
You will be able to analyse stakeholders and project scope, choose elicitation techniques to suit the situation, model as-is and to-be processes in BPMN, write testable requirements, user stories and use cases, prioritise with MoSCoW, and produce a BRD, SRS and traceability matrix. 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 using a system or process your organisation is about to develop as the practice case. You can request a quotation from this page, or contact us on LINE @itgenius or by phone on 02-570-8449.
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…
Most software that runs into trouble after delivery was not left untested; it was tested in the wrong places. Missing or conflicting requirements were not caught early, test cases were written so loosely that nobody else could follow them, and no one could…
Most QA time disappears into repetitive work: writing test cases one by one from incomplete documentation, preparing test data set by set, chasing scripts that broke because a screen changed slightly, and then summarizing results for the team. When time runs…
