A business analyst helps people clarify a problem, understand a process and define requirements for a proposed change. For an ICT role, the work may connect user needs with system and software requirements.
Read the actual vacancy before choosing application evidence. Gathering a requirement or recommending an option does not automatically authorise scope, expenditure or a release decision.
Identify which business-analysis role is advertised
The ABS ICT business-analyst description concerns requirements for ICT solutions and distinguishes this scope from non-ICT business analysis.
Check the subject matter, methods, qualifications and experience required. Establish whether the role focuses on discovery, process analysis, system requirements, delivery support or a combination of responsibilities.
The existing IT roles guide gives wider career context. Select an example that demonstrates analysis in the advertised setting rather than assuming every business-analyst role is interchangeable.
Separate the problem from a preferred solution
Ask what people need to achieve, where the current process causes difficulty and which evidence supports that account. A stakeholder’s suggested feature may be useful, but it is not the same as a confirmed requirement.
Identify affected people, dependencies and decision owners. Record conflicting needs openly so the appropriate person can consider the trade-off instead of quietly choosing whichever request arrived first.
Keep the requirement, acceptance evidence and approval status traceable. A discussion note should not look like an approved scope baseline when the required decision has not happened.
A fictional requirements exercise
In this invented example, one team requests automatic approval of every submitted form, while another needs some submissions reviewed before processing. The analyst records both needs and clarifies the underlying risk and service questions.
They map the proposed decision point, identify information still missing and ask the authorised owner to determine the rule. They do not invent a compromise or describe either request as approved.
The practice case study demonstrates requirements clarification without claiming a real system change, budget approval or operational result.
Prepare a business-analysis case study
For an authorised or fictional example, explain:
- Business problem and relevant work context.
- Your actual role and stakeholder involvement.
- Evidence gathered and assumptions tested.
- Current and proposed process understanding.
- Conflicting requirements, options and dependencies.
- Acceptance evidence and decision responsibilities.
- Actual outcome, status and remaining questions.
Show permitted extracts rather than exposing sensitive process maps or customer information. Distinguish your analysis from implementation performed by developers or decisions made by a sponsor.
Ask about authority and collaboration
Clarify how requirements are prioritised, approved and changed. Ask how analysts work with subject specialists, designers, developers and testers, and who resolves unresolved requirements questions.
A credible application shows that you can turn an unclear request into a decision that the right people can assess. It demonstrates listening, structured analysis and clear records while preserving the difference between an analysed option and an authorised commitment to deliver it.
