What Does a Business Analyst Do, Really? (OutSystems User Group Netherlands, October 2025)

Ever wondered what a business analyst actually does?
During the October 2025 OutSystems User Group Netherlands meetup, Romijn Sanders (Product League) hosted an interactive business analysis workshop that explored how analysts shape strategy, align stakeholders, and drive value across projects.

This beginner-friendly session covered:
- The role and key responsibilities of a business analyst
- Best practices for elicitation, analysis, specification, and validation
- Tools, frameworks, and reference models like BABOK®, RACI, MoSCoW, Kano, and SWOT
-Advanced modeling techniques such as BPMN, DMN, and user story mapping
- Common pitfalls and how to avoid them

1. OutSystemsUser Group, October 2025
What does a business analyst
do, really?
[a beginner'sguide]

2. Understanding
the BA role

3. Key responsibilities

4. Key responsibilities
●Elicitation:Gathering needs via interviews, workshops, document analysis.
●Analysis: Decomposing complex themes into clear, coherent (functional) requirements.
●Specification: Structuring requirements into deliverables
(e.g., user stories, use cases, process models).
●Validation & verification: Ensuring requirements accurately reflect stakeholder intent and
are testable.
●Stakeholder management: Identifying roles, mapping influences, managing
expectations.

5. Ellicitation
●Come up withan elicitation plan:
oDefine scope
oSelect techniques
oIdentify participants
●Conduct various elicitation activities:
oInterviews
oWorkshops
oSurveys
oObservations / shadowing
oDocument analysis
●Confirm results with stakeholders and
update requirements repository.

6. Analysis
●Organize and model requirements:
1.group
2.decompose
3.prioritize
●Solution design sessions to evaluate
potential value and risks, together with
development and UX.
●Create gap analyses, process flows, data
models, decision models etc.

7. Specification
●Specify requirements in chosen format:
ouser stories
ouse cases
ofunctional specs
obusiness requirement documents
●Define acceptance criteria that are clear,
measurable, traceable.
●Maintain traceability by linking
requirements to design, test cases, and
releases.

8. Validation & verification
●Verify that requirements are complete,
consistent, and conform standards.
●Validate that requirements meet
stakeholder intent.
●Track defects and change requests
through version control.

9. Stakeholder management
●Identify and analyze stakeholders; e.g.,
power/interest grid, Mendelow’s matrix.
●Develop a communication plan:
ocommunicationchannels
ofrequency
ocontent for each stakeholder group
●Manage expectations and resolve
conflicts through negotiation and
facilitation.

10. The bain a team

11. Thebusiness analyst in a team
Business analyst Product owner UX designer
Focus Understanding and
specifying business
needs
Maximizing product
value
Designing intuitive,
user‐centered interfaces
Deliverables Process models,
requirements
documents
Product backlog,
roadmap, release plan
Wireframes, prototypes,
design system
Decision making Recommends solutions
and clarifies
requirements
Prioritizes backlog items
and features
Defines UX standards
and interaction patterns
Core skills Analytical thinking,
process modeling,
elicitation
Visioning, market
understanding,
stakeholder
management
User research,
interaction design,
usability
Collaboration Bridging gaps between
stakeholders and teams
Aligning development
with business goals
Iterating designs with
users and developers

12. Essential competencies

13. Essential competencies for a business analyst
●Critical thinking & problem-solving
skills
oBAs deal with ambiguous or conflicting
information
oIdentify root causes andpropose
solutions
oPrevent chasing symptoms, instead,solve
underlying problems
●Advanced communication skills
oClear, concise exchange of ideas avoids
misinterpretation of requirements
oBAs translates technical jargon for
business users
oBAs reframe business goals into
developer-friendly user stories
●Negotiation & conflict resolution
oRequirements often compete
•budget
•time
•technical constraints
oMediate between stakeholders with
opposing priorities
oSecure a consensus
●Domain knowledge & technical literacy
oBridge business and technical teams
oDeep understanding of the industry
domain and core technologies
oBe on the look out for innovation
opportunities

14. Essential competencies
●Modeling & documentation discipline
oHave accurate, well-structured
deliverables serve as the single source of
truth
oMaintain strict way-of-working and
discipline in…
•naming conventions
•version control
•traceability
o…to prevent misalignment and rework

15. Tools of
the trade

16. Frameworks and
reference models

17. Frameworks and reference models
In business analysis, frameworks and reference models give you repeatable, structured ways
to tackle complex problems; from strategic planning, down to detailed requirements. Some
examples:
●The BABOK® Guide knowledge areas
●Six Thinking Hats
●RACI matrix
●MoSCoW
●Kano model
●SWOT analysis

18. TheBABOK® Guide knowledge areas
What it entails
●A taxonomy of tasks and techniques for
end-to-end business analysis.
●Six “Knowledge Areas” (KAs):
oBusiness Analysis Planning and
Monitoring
oElicitation and Collaboration
oRequirements Life Cycle
Management
oStrategy Analysis
oRequirements Analysis and Design
Definition
oSolution Evaluation
●Under each KA are defined activities,
inputs/outputs, and key techniques.
How to apply
●Use the KAs as a checklist when scoping
your BA engagement.

19. Six Thinking Hats
What it entails
●A parallel-thinking tool to explore
perspectives in a workshop.
●Six hats/colors:
oWhite (data)
oRed (feelings)
oBlack (caution)
oYellow (optimism)
oBlue (process)
oGreen (creativity)
How to apply
●During a requirements workshop, assign
hats to sub-groups.
●Rotate every 10–15 minutes so every
voice is heard from the doomsday
prophet to the creative wizard.

20. RACI matrix
What it entails
●A responsibility-assignment chart
clarifying who’s…
oResponsible
(who is responsible for getting the task done)
oAccountable
(who oversees the task)
oConsulted
(who needs to assist/support in the task)
oInformed
(who needs to be kept up to date)
●…for each task or deliverable.
How to apply
●List all tasks/deliverables in rows.
●List all roles in columns.
●Mark each cell with R-A-C-I.

21. MoSCoW
What it entails
●Categorizes requirements into:
oMust have
oShould have
oCould have
oWon’t have
(for now)
●Helps align scope to time and budget
constraints.
How to apply
●In your requirements backlog, tag each
item M/S/C/W.
●Use these tags in sprint-planning and
stakeholder reviews to set realistic
delivery commitments.

22. Kano model
What it entails
●Segments features by how they impact
user satisfaction:
oBasic needs
(expected)
oPerformance needs
(linear satisfaction)
oDelighters
(unexpected pleasures)
oIndifferent
oReverse
How to apply
●Survey users: ask how they feel if a
feature exists vs. if it doesn’t.
●Map responses into the Kano categories.
●Prioritize backlog: lock in Basic, invest in
Performance, sprinkle in Delighters.

23. SWOT analysis
What it entails
●Assesses internal Strengths and
Weaknesses, and external Opportunities
and Threats.
●A strategic planning staple.
How to apply
●Facilitate a cross-functional workshop.
●Populate a four-quadrant matrix with
data
(e.g., market trends, internal metrics).
●Turn each quadrant into actionable
initiatives or tasks
(i.e., leverage strengths, mitigate threats).

24. Tooling and
techniques

25. Ellicitationtechniques
Pros Cons
Interviews In-depth insights; clarifies
misunderstandings
Time-consuming; potentially
biased answers
Surveys & questionnaires Efficient for large groups; easy
to analyze quantitatively
Limited follow-up; may miss
context
Observation & shadowing Uncovers real user behavior;
identifies hidden needs
Can be intrusive; limited insight
into motivations
Workshops Encourages collaboration; rapid
consensus-building
Requires scheduling; may
dominate by louder voices
Document analysis Provides historical data;
requires no direct user
interaction
Outdated, incomplete or no
existing documentation;
requires careful interpretation

26. Modeling &Documentation tools
Examples Purpose Key features
Process
Modeling
Visio, draw.io Document workflows and
handoffs
BPMN, swim lanes, version
control
Repository Confluence,
Sharepoint
Platforms for requirements
and knowledge bases
Rich text, templates, page
linking, comment threads
Backlog
management
JIRA, Azure DevOps Prioritize and track
development
Epics, stories, sprint
boards, reporting
Collaborative
boards
Figma, Miro Facilitate (remote) team
collaboration
Infinite canvas, sticky
notes, voting

27. Whento use what
Recommended tools Why you should consider it
Mapping end-to-end
processes
Visio Supports BPMN, swim lanes, easy
visualization
Prototyping user interfaces Figma, Axure RP Fast UI sketching; clickable
prototypes for feedback
Managing story backlog JIRA, Confluence Agile-friendly; links user stories to
tasks and tests
Decision modeling DMN, Excel decision tables Formal logic structures for
approvals, decision making, etc.
Requirements traceability Confluence, Excel trace matrix Links requirements to
designs/tests/releases
Lightweight visual
documentation
Draw.io Quick diagramming with low
setup overhead

28. Advanced modeling
techniques

29. Advanced modeling techniques
●User story mapping
oA visual framework that arranges user activities and tasks to reveal user journeys,
uncover gaps and prioritize releases.
oHow to use:
•Gather cross-functional stakeholders around a (digital) whiteboard
•Identify top-level user activities, such as “Browse Products,” “Add to Cart,”
“Checkout”
•Under each activity, list individual tasks or steps users perform
•Organize tasks by priority or sequence
(left-to-right for story order, top-to-bottom for release plans)
•Group tasks into an MVP and future releases to create a release roadmap

30. Advanced modeling techniques
●Business Process Model and Notation (BPMN)
oA standardized graphical notation for documenting end-to-end business processes,
using symbols like events, tasks, gateways and swim lanes to show flow, decision points
and handoffs.
oHow to use:
•Define the scope: identify start and end events
•List each activity or sub-process in sequence
•Use gateways to represent decisions and splits
•Use swim lanes to assign ownership across departments or systems
•Validate the diagram with process owners and refine for clarity

31. Advanced modeling techniques
●Decision Model and Notation (DMN)
oA formal method for modeling and automating decision logic via decision requirements
diagrams and decision tables, separating business rules from process flow.
oHow to use:
•Identify a decision to model
•List inputs and desired outputs
•Create a decision table: rows represent rule conditions, columns represent inputs
and outputs
•Link decision tables in a Decision Requirements Diagram to show dependencies

32. Examples of advanced modeling techniques
Example of a process flow using BPMN
Example of a decision table using DMN
Example of user story mapping

33. Best practices

34. Best practice: Frameworks
Frameworks give you repeatable patterns to shape requirements, ensuring clarity, consistency, and
testability.
●INVEST for user stories
oEnsures each story is a standalone, valuable piece of work
•Independent: minimize dependencies on other stories, stories should be self-contained
•Negotiable: allow for flexibility and adjustments as the team learns more about the
requirements
•Valuable: stories should deliver value and tied to a clear business outcome
•Estimable: stories should be clear enough to estimate confidently
•Small: stories should be small enough to be completed within a single iteration or sprint
•Testable: define acceptance criteria that can be (automated) tested
•Pro tips:
oDuring backlog grooming, run each story through the INVEST checklist.
oIf a story fails any “I-N-V,” split or rework it immediately.

35. Best practice: Frameworks
Frameworks give you repeatable patterns to shape requirements, ensuring clarity, consistency, and
testability.
●SMART for non-functional requirements
oTranslates abstract qualities into measurable goals
•Specific: “API latency”instead of “fast system”
•Measurable: define numeric targets
(e.g., <200 ms)
•Attainable: validate against platform capabilities
•Relevant: align with user, company or regulatory needs
•Time-bound: set deadlines or monitoring periods
●Pro tips:
oStore SMART NFRs alongside functional specs in your repository

36. Best practice: Governance
Governance structures ensure changes happen in a disciplined way, preventing scope creep and
maintaining quality.
●Review Gates (DoR& DoD)
oFormal checkpoints that deliverables must pass before progressing
•Definition of Ready: story has clear description, acceptance criteria, and mockups
•Definition of Done: code merged, tests passed, documentation updated, product owner sign -
off
•Pro tip:
oPublish simple checklists for DoRand DoD in your project handbook.

37. Bonus: Common pitfalls
Symptoms How you can mitigate
Vague requirements Frequent Q&A threads, ambiguous test
cases
Enforce INVEST and DoR, require
acceptance criteria for every story
Scope creep New work sneaks in mid-sprint Use strict change control, freeze scope one
sprint ahead
Analysis paralysis Endless modeling; missed deadlines Timebox analysis sessions, agree on
‘minimal viable documentation’
Overengineering Excessive diagrams, heavy specs, long user
stories
Apply “MVD” principle, review DoR
Stakeholder disengagement Low turnout at workshops, delayed
approvals, long feedback loops
Publish clear agendas, rotate meeting
times, follow up with summaries
Traceability breakdowns Missing links between requirements and
tests
Run weekly audit log checks
Conflicting stakeholder needs Multiple rework cycles, indecisiveness Use RACI and decision logs, mediate via
scoring
Poor change discipline Untracked tweaks, rework overload Implement CCB, log every change request,
maintain change dashboard

38. Thanks!
Now go out there and have
some fun!