WIKI SLATEPrecision to Vision
← LibraryElicitation, Analysis & RequirementsProject Management · Principles of Project Management← PrevNext →
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

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