Unit of competency Outline
Date retreived
22/07/2026 4:58 PM AWST
22/07/2026 4:58 PM AWST
Whilst all efforts are made to provide accurate and timely information from the relevant source/documentation, please be aware that the information supplied may not be the most current version. The accuracy of the detail has not been confirmed by the Department and therefore should not be relied upon without first confirming the contents.
Plan and monitor business analysis activities in an IT environment
Plan and monitor business analysis activities in an IT environment
Unit of competency
National Code
ICASAD603A
ICASAD603A
State Code
D8115
D8115
TGA Status
Replaced
Replaced
DTWD Status
Replaced
Replaced
State Implementation and Classification
Approved Date
26/03/2012
Field of Education
020305 - Systems Analysis And Design
Original Release Date
26/03/2012
Nominal Hours
40
Description
This unit describes the performance outcomes, skills and knowledge required to establish and manage IT business analysis activities in a medium to large organisation.
Notes
Elements and Performance Criteria
1. Plan business analysis approach
- 1.1 Establish organisational process needs and objectives that apply to the initiative and if necessary define the requirements that the process must meet
- 1.2 Review existing organisational standards, including standards, guidelines and processes relating to the current initiative
- 1.3 Tailor approach to the needs of a specific business analysis initiative, according to organisational standards if required
- 1.4 Engage with the appropriate stakeholders to determine how the work will be completed
- 1.5 Plan the execution of business activities
2. Conduct stakeholder analysis
- 2.1 Recognise stakeholders who may be affected by the business need or a new solution
- 2.2 Assess stakeholder attitudes toward and influence over the initiative
- 2.3 Decide which stakeholders will have authority over business analysis activities
- 2.4 Instigate regular reviews to identify new stakeholders or changed positions as clarity of business needs evolve
3. Plan business analysis activities
- 3.1 Decide the type of project or initiative and the business analysis deliverables
- 3.2 Determine the scope of work for business analysis activities
- 3.3 Approve which activities the business analyst will perform and when
- 3.4 Develop estimates for business analysis work
4. Plan business analysis communication
- 4.1 Determine how best to receive, distribute, access, update and escalate information from project stakeholders
- 4.2 Decide how best to communicate with each stakeholder according to stakeholder needs and constraints to communication
5. Plan requirements management process
- 5.1 Establish a requirements repository for storing requirements, including those under development, those under review, and approved requirements
- 5.2 Assess the need and process for requirements traceability based on relevant factors
- 5.3 Conclude which requirements attributes will be captured
- 5.4 Determine the process for requirements change management
6. Manage business analysis performance
- 6.1 Determine which metrics will be used to measure the work performed by the business analyst
- 6.2 Report performance in an appropriate format based on the needs of the project
- 6.3 Assess performance measures to determine where problems may be occurring in executing business analysis activities
- 6.4 Identify preventative or corrective actions as required
The range statement relates to the unit of competency as a whole. It allows for different work environments and situations that may affect performance. Bold italicised wording, if used in the performance criteria, is detailed below. Essential operating conditions that may be present with training and assessment (depending on the work situation, needs of the candidate, accessibility of the item, and local industry and regional contexts) may also be included.
Initiative may include:
feasibility studies
new software development (in-house)
organisational change
outsourced new software development
process improvement
software maintenance or enhancement
software package selection.
Approach defines:
approach will also determine how the planning process is performed
deliverables
life cycle
templates and tasks that should be included.
Appropriate stakeholders may include:
customer, domain SME, end user or supplier
implementation SME
regulator or other stakeholder with legal or governance authority over the solution or the process used to develop it
project manager
tester
sponsor.
Business activities may include:
analysis techniques
frequency of stakeholder interactions
project deliverables
project risk
project timeframe
team roles
other elements of the business-analysis process.
Influence may include:
influence on the project
influence in the organisation
influence needed to ensure success of the particular project
influence with other stakeholders.
Authority may relate to:
approving the deliverables
approving the requirements process that will be used
inspecting and approving the requirements
requesting and approving changes
reviewing and approving the traceability structure
vetoing proposed requirements or solutions (individually or in a group).
Stakeholder needs and constraints to communication may include:
communication approach for the stakeholder
how best to communicate requirements conclusions or packages, including authority level (sign-off authority, veto authority or review only)
physical location or time zone of the stakeholders
time and resource availability constraints
what types of communications will be required, such as status, anomalies, issues and their resolution, risks, meeting results and action items
what types of requirements will be elicited, such as business, stakeholder, solution, or transition; high level versus detailed and how best to elicit them.
Requirements repository may include:
diagrams and models
requirements management tools and applications
whiteboards
word-processing documents
wikis
any other method of recording information that allows requirements to be single-sourced and available to stakeholders for as long as they are needed.
Relevant factors may include:
complexity of the domain
number of views of requirements that will be produced
potential impacts from risk
costs and benefits involved.
Requirements attributes may include:
absolute reference via a unique numeric (preferred) or textual identifier
author of the requirement
cost
complexity
ownership
priority
risks associated with meeting or not meeting the requirements
source of the requirement
stability
status
urgency
resource assignment
revision number
traced-from and traced-to.
Appropriate format may include:
verbal
presentation
writing.
Initiative may include:
feasibility studies
new software development (in-house)
organisational change
outsourced new software development
process improvement
software maintenance or enhancement
software package selection.
Approach defines:
approach will also determine how the planning process is performed
deliverables
life cycle
templates and tasks that should be included.
Appropriate stakeholders may include:
customer, domain SME, end user or supplier
implementation SME
regulator or other stakeholder with legal or governance authority over the solution or the process used to develop it
project manager
tester
sponsor.
Business activities may include:
analysis techniques
frequency of stakeholder interactions
project deliverables
project risk
project timeframe
team roles
other elements of the business-analysis process.
Influence may include:
influence on the project
influence in the organisation
influence needed to ensure success of the particular project
influence with other stakeholders.
Authority may relate to:
approving the deliverables
approving the requirements process that will be used
inspecting and approving the requirements
requesting and approving changes
reviewing and approving the traceability structure
vetoing proposed requirements or solutions (individually or in a group).
Stakeholder needs and constraints to communication may include:
communication approach for the stakeholder
how best to communicate requirements conclusions or packages, including authority level (sign-off authority, veto authority or review only)
physical location or time zone of the stakeholders
time and resource availability constraints
what types of communications will be required, such as status, anomalies, issues and their resolution, risks, meeting results and action items
what types of requirements will be elicited, such as business, stakeholder, solution, or transition; high level versus detailed and how best to elicit them.
Requirements repository may include:
diagrams and models
requirements management tools and applications
whiteboards
word-processing documents
wikis
any other method of recording information that allows requirements to be single-sourced and available to stakeholders for as long as they are needed.
Relevant factors may include:
complexity of the domain
number of views of requirements that will be produced
potential impacts from risk
costs and benefits involved.
Requirements attributes may include:
absolute reference via a unique numeric (preferred) or textual identifier
author of the requirement
cost
complexity
ownership
priority
risks associated with meeting or not meeting the requirements
source of the requirement
stability
status
urgency
resource assignment
revision number
traced-from and traced-to.
Appropriate format may include:
verbal
presentation
writing.
The evidence guide provides advice on assessment and must be read in conjunction with the performance criteria, required skills and knowledge, range statement and the Assessment Guidelines for the Training Package.
Overview of assessment
Critical aspects for assessment and evidence required to demonstrate competency in this unit
Evidence of the ability to:
plan and monitor business analysis activities, including determining an approach and processes that are appropriate to the circumstances
determine business analysis deliverables, tasks and estimates
determine metrics that will be used for monitoring business analysis work.
Context of and specific resources for assessment
Assessment must ensure access to:
documentation, including appropriate policies, current business analysis practices, tools and legislation
appropriate learning and assessment support when required
modified equipment for people with special needs.
Method of assessment
A range of assessment methods should be used to assess practical skills and knowledge. The following examples are appropriate for this unit:
evaluation of a simulated or workplace project in a medium to large enterprise
direct observation of the candidate carrying out business analysis work
verbal or written questioning to assess required knowledge and skills
review of reports and plans prepared for the projects
evaluation of a portfolio of the project work undertaken.
Guidance information for assessment
Holistic assessment with other units relevant to the industry sector, workplace and job role is recommended, where appropriate.
Assessment processes and techniques must be culturally appropriate, and suitable to the communication skill level, language, literacy and numeracy capacity of the candidate and the work being performed.
Indigenous people and other people from a non-English speaking background may need additional support.
In cases where practical assessment is used it should be combined with targeted questioning to assess required knowledge.
Overview of assessment
Critical aspects for assessment and evidence required to demonstrate competency in this unit
Evidence of the ability to:
plan and monitor business analysis activities, including determining an approach and processes that are appropriate to the circumstances
determine business analysis deliverables, tasks and estimates
determine metrics that will be used for monitoring business analysis work.
Context of and specific resources for assessment
Assessment must ensure access to:
documentation, including appropriate policies, current business analysis practices, tools and legislation
appropriate learning and assessment support when required
modified equipment for people with special needs.
Method of assessment
A range of assessment methods should be used to assess practical skills and knowledge. The following examples are appropriate for this unit:
evaluation of a simulated or workplace project in a medium to large enterprise
direct observation of the candidate carrying out business analysis work
verbal or written questioning to assess required knowledge and skills
review of reports and plans prepared for the projects
evaluation of a portfolio of the project work undertaken.
Guidance information for assessment
Holistic assessment with other units relevant to the industry sector, workplace and job role is recommended, where appropriate.
Assessment processes and techniques must be culturally appropriate, and suitable to the communication skill level, language, literacy and numeracy capacity of the candidate and the work being performed.
Indigenous people and other people from a non-English speaking background may need additional support.
In cases where practical assessment is used it should be combined with targeted questioning to assess required knowledge.
Replaced By
| State Code | National Code | Title | Type |
|---|---|---|---|
| AUW07 | ICTSAD603 | Plan and monitor business analysis activities in an ICT environment | Unit of competency |
| State Code | National Code | Title | Type |
|---|---|---|---|
| D578 | ICA60311 | Advanced Diploma of Information Technology Business Analysis | Qualification |