Business Analysis Essentials

Curriculum

Every chapter is listed here. You enrol in the whole course, not one chapter.

1. Module 1

   The analyst in the room

   Why the role exists, what you own, and what you hand back.

   • Why effective analysis mattersA missed requirement becomes rework. You see where that cost starts.
   • Role of the business analystThe link between the business areas and the people who build.
   • A shared vocabulary, adapted to the teamThe body of knowledge gives the words. The team decides how strictly to use them.

2. Module 2

   Planning the requirements work

   Scope, stakeholders, and a plan for the analysis itself.

   • Your part in planningYou plan the analysis, not the whole project.
   • Vision and scopeWhat is in, what is out, and who agreed.
   • Types of requirementsBusiness, stakeholder, and solution. Keep them apart.
   • StakeholdersWho decides, who uses it, and who can block it.
   • The business analysis planActivities, techniques, and what "enough" means before you start.

3. Module 3

   Drawing out what people need

   Interviews, workshops, observation, and the other ways a room tells the truth.

   • Your part in elicitationAsk for a decision, not a tour of the current system.
   • Investigative and iterative approachesDig for the cause, then come back when the first answer was incomplete.
   • InterviewsOne person, a prepared question, and what you write down before you leave.
   • Focus groupsSeveral voices at once, and how you stop the loudest one owning the note.
   • Requirements workshopA working meeting with a result, not a status update.
   • Joint design sessionThe people who will use it and the people who will build it, in the same room.
   • BrainstormingVolume first. Judgement after. You keep the list.
   • ObservationWatch the work. People skip the step they no longer notice.
   • SurveyWhen you need many answers and cannot sit with each person.
   • PrototypeA rough version that gets a correction faster than a document does.
   • Document analysisThe rule that already exists in a policy, a form, or a contract.
   • Business rulesThe constraint that is true even when no screen shows it.
   • Reverse engineeringReading the current system when nobody can explain it.
   • Product trialsUsing a candidate product to learn the requirement, not to buy it yet.

4. Module 4

   Analysis and the pictures

   Models that get a reaction, and how you check a requirement before it hardens.

   • Why you analyseA stated need is not yet a requirement you can build.
   • Feedback, verification, and validationDid we hear it right, and is it the right thing.
   • Organisational modelWho does the work, and who it moves between.
   • Location modelWhere the work happens, including the places a diagram usually forgets.
   • Process and flowThe steps, the handoffs, and the wait.
   • Use casesA person, a goal, and the path that gets them there.
   • Data modelThe things the business cares about, and how they relate.
   • State modelHow one thing changes, and which changes are not allowed.
   • Prioritising requirementsWhat must be first, and what can wait without breaking the need.

5. Module 5

   Writing the requirement

   Detail, defects, and a document someone will actually read.

   • Formal and informal, and how much detailMatch the page to the audience. A sponsor and a developer do not need the same depth.
   • Writing for useShort sentences. One requirement per line. No hidden "and".
   • Common document defectsAmbiguity, a missing actor, a rule with no exception, a copy of the old screen.
   • What goes in the packThe parts of a formal requirements document, and what you can leave out.
   • Verification, validation, and sign-offChecked against the source, checked against the need, then signed by the person who can say no.

6. Module 6

   Change, traceability, and the conversation

   A baseline, a change path, and how the requirement stays alive.

   • From the first note to decommissionThe requirement does not end when the build starts.
   • A baselineThe line you measure change against.
   • A change processHow a change is asked for, assessed, and accepted or refused.
   • Who may approve a changeName the authority before the first change arrives.
   • TraceabilityFrom the need to the requirement to the test, so a change shows what else moves.
   • Requirement attributesStatus, owner, source, priority. Enough that a stranger can find it.
   • Communicating the requirementThe people who were not in the room still have to be able to use it.

7. Module 7

   Checking the solution

   What "done" means, and the analyst's part in acceptance.

   • Testing and the other checksNot every confirmation is a test script.
   • Find defects, and prove it meets the requirementTwo different purposes. Do not mix the report.
   • Test cases and suitesWhat you need from the requirement before anyone can write them.
   • Why testing gets hardLate requirements, a missing rule, and an environment that is not the real one.
   • Structured testing and the analyst's partWhere you sit when the build is checked against what was signed.
   • Acceptance and close-outWho says yes, on what evidence, and what you hand over.

8. Module 8

   Choosing work worth doing

   Need, gap, and a business case you do not pretend to own alone.

   • The business needThe problem, and a root cause, before a solution is named.
   • Capability gapsWhat the organisation cannot do today, including a simple strengths-and-gaps look.
   • Solution approach and scopeChange the process, buy, build, or stop. Then draw the edge.
   • Your part of the business caseYou bring the need and the scope. You do not invent the financial return.

9. Module 9

   The job under waterfall and agile

   What stays the same, and what you must change with the delivery cycle.

   • Analytical thinking and problem solvingTake the request apart before you write it down.
   • Behaviour, business knowledge, and communicationHow you hold a room, and what you must know about the business.
   • Working with other people, and with the systemsStakeholders, and enough of the current tools to ask a precise question.
   • Practices that keep the work honestIterate, improve the process, elaborate as you learn, check as you go, trace, and model so people can disagree in public.
   • Waterfall, incremental, and agileThe need stays. The moment you freeze the detail does not.

10. Module 10

    A case you can defend

    One problem, worked through, and said out loud.

    • Work one problem throughScope, elicit, analyse, write, and name the change path.
    • Exercises in the roomYou do the technique. You do not only hear it.
    • Say it as if the sponsor is hereA short telling. The certificate follows the case.