Business Analysis Process
The BA lifecycle
Plan the BA approach, elicit, analyze, document, validate, support build and UAT, then evaluate the solution. In agile this repeats each iteration; it is not a single waterfall pass. Candidates should distinguish elicitation (gathering information) from analysis (structuring, prioritizing, confirming it).
Concepts
- AS-IS / TO-BE process maps and gap analysis - the gap is a measured delta, not a wish list.
- Root cause tools: 5 Whys, fishbone diagram.
- Impact analysis for change requests: scope, cost, schedule, risk, testing, training.
- Traceability from objective to requirement to design to test to UAT sign-off.
- UAT versus QA: QA proves the build works to spec; UAT proves it supports the business process.
Traps
- Calling a list of missing features "gap analysis" - a gap must be measured against a defined future state.
- Skipping validation walkthroughs and discovering misalignment at UAT.
- Treating UAT as regression testing, or as the administrator's job alone.
- Not re-baselining documents after an approved change.
- Forgetting solution evaluation - measuring whether the benefit was realized after go-live.
Rule of thumb
Any change request passes through impact analysis and updates traceability before entering a sprint. A requirement that cannot be traced to an objective and a test is not ready.
Worked example
AS-IS: discount approval takes three days by email. TO-BE: four hours. Gap analysis shows the delay is manual routing, not missing data. The requirement becomes an automated approval process with escalation, and the success metric is measured 60 days after go-live.