Elicitation, Analysis & Requirements

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)

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

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