Business & System Analysts - Use Case & Requirements Documentation
Gain job-ready business analysis skills by applying BABOK® principles, eliciting and documenting requirements (BRD, FRD, SRS, use cases) and modeling processes—all without prior experience.
- 25 hours
- Stage: First job: projects, agile, product
- Language: English
- Voice: English ✔
What you will learn
- Apply BABOK® v3 core knowledge areas in real-world scenarios, selecting suitable tasks and techniques for each business analysis situation.
- Conduct stakeholder workshops, interviews and surveys to elicit needs; write clear user stories and use-case specifications, and confirm the results with stakeholders.
- Develop Business Requirements Documents (BRD), Functional Requirements Documents (FRD) and Software Requirements Specifications (SRS) with defined scope, goals and acceptance criteria, and show which document suits which audience and project approach.
- Maintain a Requirements Traceability Matrix linking requirements to design and tests, using it to check coverage and assess the impact of changes.
- Model business processes using BPMN and Data Flow Diagrams (DFDs), showing actors, decisions, exceptions and data stores at the right level of detail.
- Create Entity-Relationship Diagrams (ERDs) for data modeling and basic UML class diagrams, defining entities, attributes, keys and cardinality.
Syllabus
Module 1Foundations of Business Analysis3 hours
What requirements are · why unclear ones cost money · the four requirements activities · BABOK® knowledge areas · planning the analysis work
- Why requirements work exists
- The four activities in practice
- Case: the unclear request that led to a rebuild
- The BABOK® guide and its knowledge areas
- Picking tasks and techniques for a situation
- Case: applying the knowledge areas to a feature request
- Why plan the analysis work
- Stakeholder register and elicitation plan template
- Case: a timeline for requirements activities
Module 2Understanding the Problem and the People3 hours
Business problem and need · context diagram · in and out of scope · elicitation techniques · interviews, workshops and surveys · confirming results
- Problem, need and scope in plain words
- Drawing a context diagram
- Case: in scope and out of scope for a small request
- The elicitation toolbox
- Matching a technique to the stakeholder
- Case: the same need, three techniques
- How interviews, workshops and surveys draw out needs
- Interview guide, workshop agenda and survey templates
- Case: from interview notes to a confirmed user story
Module 3Modeling Processes and Data3 hours
As-is and to-be processes · gap analysis · BPMN · data flow diagrams · entity-relationship diagrams · UML class diagrams
- As-is and to-be: why compare
- Mapping the current process and its gaps
- Case: from a slow approval to a better one
- BPMN and DFD: two views of a process
- Drawing a BPMN diagram and a DFD
- Case: choosing the right level of detail
- Entities, attributes, keys and cardinality
- Building an ERD and a UML class diagram
- Case: modeling customers and orders
Module 4Use Cases and User Stories3 hours
Actors and use case diagrams · use case specifications · main, alternate and exception flows · stories and acceptance criteria · glossary · business rules catalog
- Actors, goals and use case diagrams
- Writing a full use case specification
- Case: a booking use case and its exceptions
- Stories, acceptance criteria and use cases
- Tracing stories to use cases
- Case: checking coverage both ways
- Why define terms and rules once
- Building a glossary and a business rules catalog
- Case: one word, two meanings
Module 5Writing and Prioritizing Requirements3 hours
Non-functional requirements · testable thresholds · BRD, FRD and SRS · scope, goals and acceptance criteria · MoSCoW · resolving conflicts
- Functional and non-functional requirements
- Writing testable thresholds
- Case: the system must be fast
- BRD, FRD and SRS: what each one is for
- Writing the documents from templates
- Case: the right document for the audience
- Why requirements must be ranked
- Ranking with MoSCoW and recording decisions
- Case: two stakeholders, one budget
Module 6Reviewing Requirements for Quality3 hours
Clarity, completeness, consistency and testability · walkthroughs and inspections · documented approval · common defects · reviewing a real example
- The four quality checks
- Running a walkthrough or inspection
- Case: a review meeting that finds a missing rule
- Ambiguity, assumptions and solution bias
- Finding and fixing defects with a checklist
- Case: one sentence, many defects
- Quality criteria for a requirements document
- Marking up a document step by step
- Case: reviewing a complete sample document
Module 7Traceability, Change and Tools3 hours
Requirements traceability matrix · coverage and impact · baselines · change requests · impact analysis · Jira, Confluence, Excel and diagramming tools
- What traceability is and why it matters
- Building a traceability matrix in Excel
- Case: using the matrix when a requirement changes
- Why change needs control
- The change request and impact analysis form
- Case: a late request from a senior stakeholder
- Which tool for which job
- Setting up a requirements workspace
- Case: one requirement from idea to tracked item
Module 8Responsible Practice and Final Project4 hours
Drafting assistants · checking against sources · handling confidential data · the requirements package · from requirements to design and testing
- What drafting assistants can and cannot do
- Drafting statements, then verifying them
- Case: a draft that invented a requirement
- Why confidential data needs care
- Handling data in notes, files and meetings
- Case: a spreadsheet with personal details
- What goes into a requirements package
- Building the package for a small case
- Case: presenting and defending the package
- From requirements to solution design
- From requirements to test cases
- What comes next: advanced modeling and governance