Key takeaways
- A business analyst translates between business stakeholders and technical teams.
- Core outputs are requirements, user stories, process models and acceptance criteria.
- Elicitation techniques include interviews, workshops, observation and document review.
- Good requirements are clear, testable and prioritised.
- In Agile teams the analyst helps refine the backlog and clarify user stories.
What is business analyst notes?
What does a business analyst do?
A business analyst (BA) finds out what a business needs, writes it down clearly and helps the team deliver it. Typical tasks are meeting stakeholders, analysing current processes, documenting requirements, preparing user stories, supporting testing and communicating changes. A BA does not always code or manage the project, but works closely with both developers and managers.
How are requirements gathered?
Techniques include interviews with stakeholders, workshops with a group, observation of how work is done, document review of existing forms and reports, surveys for many users and prototypes to get feedback early. Use more than one technique, because people often describe what they think they need, not what they do.
What types of requirements exist?
| Type | Meaning | Example |
|---|---|---|
| Business | Goal of the organisation | Reduce order errors |
| Stakeholder | Needs of a group | Store staff need a quick stock view |
| Functional | What the system does | Show stock level by product |
| Non-functional | How well it works | Load in under three seconds |
| Transition | Needs to switch over | Migrate old records |
What is the difference between BRD, SRS and user stories?
A Business Requirements Document (BRD) describes the business need and objectives. A Software Requirements Specification (SRS) describes the detailed system behaviour. User stories are short descriptions from the user's view: "As a store manager, I want to see low-stock items so that I can reorder on time." Each story has acceptance criteria, which are testable conditions such as "Items below the reorder level are highlighted."
How do I model a process?
Draw the current process (as-is) and the proposed one (to-be) using a flowchart or BPMN-style diagram with start, steps, decisions and end. Look for delays, handoffs and repeated work. The comparison shows where the change adds value. Use simple symbols and label each step with an action verb.
What analysis tools are used?
SWOT lists strengths, weaknesses, opportunities and threats. Root cause analysis, such as the five whys, asks why repeatedly to find the real cause. MoSCoW prioritises requirements as Must, Should, Could and Won't. Stakeholder analysis maps influence and interest to decide how to communicate with each person. Gap analysis compares the current state with the desired state.
How does a BA work in Agile?
The BA helps the product owner refine the backlog, writes and clarifies user stories, joins sprint planning, answers team questions during the sprint, supports acceptance testing and updates documents when needed. Documentation is lighter than in waterfall, but clarity is still required.
Which data skills help a BA?
Reading reports, basic SQL, Excel for analysis, simple charts and knowing which metrics measure a goal. A BA who can check numbers can support requests with evidence, for example how many orders are affected by an error.
What are common mistakes?
Writing vague requirements ("system should be fast"), skipping stakeholders, mixing solution and need, ignoring non-functional needs and failing to confirm requirements in writing. Always ask "how will we know this is done?"
What does a sample user story with acceptance criteria look like?
Story: As a customer, I want to track my order so that I know when it will arrive. Acceptance criteria: 1) Given an order number, when I open tracking, then I see the current status. 2) The status updates within five minutes of a change. 3) If the number is wrong, a clear error is shown. 4) The page works on mobile. Criteria like these are specific enough for a tester to write test cases and for a developer to know when the work is done.
How do I run a good requirements workshop?
Share the goal and agenda in advance, invite people who decide and people who use the process, set time limits, capture decisions and open questions on a visible board and send a written summary the same day. Ask for examples of real cases, and confirm each requirement by reading it back. Rotate who speaks so quieter participants contribute.
How do I manage change requests?
Record each change with its reason and requester, assess the effect on scope, time, cost and risk, discuss with the decision maker and update documents and the backlog if approved. A simple change log prevents surprises and shows the team why decisions were made.
What are the key terms to remember?
Stakeholder: anyone affected by or influencing the solution. Scope: what is included and excluded. Baseline: the approved version of requirements. Assumption: something believed true but not confirmed. Constraint: a limit such as budget, time or regulation. Keeping a glossary in each project avoids confusion between teams.
Download Business Analyst Notes PDF
Business Analyst Notes PDF
The PDF carries the same content as this page in a clean, print-ready layout, so you can read it offline and keep it for revision.
4 pages · 93 KB · PDF · Updated 5 Nov 2026