POSTER 09
Section 3 · Business Analysis — Domains 3 & 4
Elicitation, Analysis & Requirements
The engine room of BA: draw out needs (elicitation), then classify, model, specify, validate & prioritise them (analysis). Elicitation is not passive note-taking — it actively surfaces latent needs. The two iterate as a tight loop until requirements are clear and agreed.
Elicitation — Draw It Out
Plan▸
Conduct▸
Confirm results↺
- Techniques: interviews · facilitated workshops (JAD) · focus groups · observation / job-shadowing · surveys · document analysis · prototyping · brainstorming.
- Always confirm elicitation results with stakeholders — capture, then play back.
Analysis — Make It Buildable
Model▸
Specify▸
Validate & Verify▸
Prioritise
- Validation = the right requirements (meet the need).
- Verification = requirements built right (quality, testable).
- Prioritise with MoSCoW — Must / Should / Could / Won't.
Requirement Types — The Classification Ladder
Business
why — goals & value ▸ Stakeholder
who needs what ▸ Solution — Functional
what it must do + Solution — Non-functional
how well (perf, security…) ▸ Transition
how we get there (training, migration)
why — goals & value ▸ Stakeholder
who needs what ▸ Solution — Functional
what it must do + Solution — Non-functional
how well (perf, security…) ▸ Transition
how we get there (training, migration)
Good requirements are: clear · concise · complete · consistent · feasible · unambiguous · testable · traceable. Transition requirements are temporary — they retire once the solution is live.
Modelling Toolkit — Show, Don't Just Tell
- Scope: context diagram · use-case · feature model.
- Process: flowchart · swimlane · BPMN.
- Rules: decision table · decision tree.
- Data: ERD · data dictionary · state diagram.
- Interface: wireframe · report table · prototype.
- Agile: user stories + acceptance criteria.
Exam Concepts
- Elicitation surfaces latent needs — it's active, not passive.
- Always confirm elicitation results.
- Functional = what it does; non-functional = how well.
- Validate vs verify — know the difference cold.
Executive View
- Prioritised, testable requirements = predictable delivery.
- Models give a shared picture across business & tech.
- MoSCoW makes trade-offs explicit when budgets tighten.
Industry Example
IT
- New SaaS module: workshops + prototypes elicit needs; a context diagram bounds scope; user stories + acceptance criteria specify; MoSCoW sets the MVP.
Memory Hooks
- Levels — B·S·S·T: Business → Stakeholder → Solution → Transition.
- "Validate = right thing · Verify = thing right."
- Elicit → Model → Specify → Confirm — then loop.
60-sec Review
Plan-Conduct-Confirm
List 4 elicitation techniques
B-S-S-T requirement levels
Functional vs non-functional
MoSCoW + validate/verify
PMI Visual Wall · Poster 09 · Business Analysis — Elicitation, Analysis & Requirements · original instructional design · A3 landscape