It masters short courses.

Week 1

The role and purpose of business analysis
Defining the nature of the problem or objective
The nature and importance of requirements
The elicitation of requirements

Lecture delivered by BAIQ: ICBA - Week 1 Webinar.mp4

They want to support the development of BA learning and certification
Examination will be through GCI
The qualifications will be recognised in Australia
BAIQ is not officially IIBA, but they are all members. Less BABoK specific. More practice specific.

The business of Business Analysis

BA began in the 1980s with the IT revolution. It was a role which aligned stakeholders on what was needed and how technology was to be used.
BAs enable companies to use technology as a competitive advantage. They do this by shaping both what is needed as well as how technology can do that.
BAs ensure companies get what they want.
BAs followed a Business Analysis Maturity Model, System improvement, process improvement, business improvement.
To use BA effectively we need to understand the Business Change Lifecycle which starts at Alignment, then definition, design, implementation and realisation. All of the above revolves around a core business case.
The business case is important to all aspects of the Business Change Lifecycle
Moving through the Business Change Lifecycle requires BA’s to use the Business analysis process model. Investigate (assessing the truth), consider (represent the business as a whole), analyse (figure out the business need), evaluate of the options, define
One tool is MOST Analysis Mission, objectives, strategy, tactics.
BA’s need to work on bridging the gap from technical and business
The Balanced Business Scorecard, financial internal business processes, learning and growth(innovation), customer. All these things need to be in balance but innovation is the important to keep things in balance for the long term.
Requirements are the specifics of what needs to be changed. requirements become measurable outcomes.
Elicitation is about asking questions and take notes.
- who knows and who can tell us
- what they know
- what information we need but they don’t have
- (know knowns, unknown knowns, known unknowns, unknown unknowns)
Tacit knolwede is the less obvious knowlegde which is harder to articulate
Explicit knowledge is the hard facts and information that is present and easy to retrieve
ways to do elicitation
- interviews
  - who why what when where
  - 10-80-10 percentages prepare qa and follow up
  - this is cooperative
  - get their buy in
  - take notes
- workshops
  - get buy in
  - make sure everyone knows why they are there
  - keep everyone focused
  - make sure to record all important information
- observation
- scenarios
- prototyping
- data analysis
requirements are different from expectation. This is mostly a communication situation.

Week 2

Understanding and categorising requirements
Defining and recording requirements to work with
The requirements catalogue
Use case modelling

Analysing requirements (what are we doing with them)

structure and organise them
- build a hierarchy
- categories them
Test the requirements (are they actually required?)
bad requirements will result in failure
business requirements
- general requirements
  - goals policy compliance and
- technical requirements
  - specifics that come from a business perspective.
Solution Requirements
- functional requirements
  - the things the solution must do
- non functional requirements
  - description of how the functionality much be presented
Requirements analysis traps
- scope creep
- being too rigid
- ambiguity
- communication failure
- too much information
  - or an inability to find information quickly
- isolated requirements
Requirements can happen a multiple levels, make sure you know what level you are on and specify the amount of detail that is needed.
Adequit consensis is how you can understand the difference between scope creep and adapability
MoSCoW prioritisation
- must have
  - essential requirements that must exist
- should have
  - highly important but not immediate
- could have
  - very valuable but not vital to success
- want to have
  - if wishes were fishes??? look this up
The filtering process
- duplicates and overlap
  - only present once
- merged requirements
  - separate the complex into clearer
- relevance and contribution
- feasibility and sensibility
- conflicting and contrasting
- predetermined solutions
- usefulness of the information
Smart Requirements
- specific
- measurable
- achievable
- relevant
- timed
A business rule is a requirement which may need more specific brake down
Business analyst is not a PM. They should be working together.
The requirements document
- Intro Background summary
  - contectual information needed
- Requirements catalogue
- business process models
  - UML diagrams
    - structural diagrams
    - behavioural diagrams
      - mostly the ones used by requirements
- functional models
- Some other model diagrams
  - swim lane
    - activity diagram based on there area of responibility
  - communications
    - show the flow of information
  - state machine diagram
  - activity
    - the original flow chart
  - sequence
    - the order of things
  - use case
    - the most important for BAs
    - actors use cases and relationships
    - used to gather the requirements of a system
    - provides an outside veiw of the system
    - uuse cases are functional events
      - they can have there own activity diagrams

Week 3

Confirming and sharing requirements
Getting stakeholders aligned
Requirements traceability
Changes to requirements

Making requirements stick

We are not jest writing the decument we need to make sure that they are good
What we want to get the business to approve the requirements
All relevant stakeholders need to have their say
Debate (confruntation) is better now then in developmet
validation - Check with the stakeholders (check the truth)
- checks the details of the requirements with stakeholders
- ensure that stakeholders needs are correctly interpreted
- focuses on functionality details and consequence
verification - Check with the business (will the solution add value)
- checks that combed requirements meet business goals
Iv&v is different and can be used in different ways
validation roles
- business sponsor
- requirement owners
- subject matter experts
- developers creator
- testers
- project office reviewers
Stakeholders
- need alignment
  - a shared understanding
  - a platform for debate
- would like agreement
  - confirmation of acceptance
  - beyin and investment in outcomes
- to get agreement
  - situation
    - get rid of the noise
  - problem
    - understand the actual problem/pain
  - implication
    - The cost of doing nothing
    - How much it actually hurts
  - vision
    - how the solution solves the problem (and the implications of the problem)
    - How things can be better
Managing requirements
- requirements ID
- software support
- origin and ownership
- change control
- cross referencing
- config management
Requirements taceability
- forward - helps see what the result must be
- backward - why the requirement exsists
- tracebility
Risks - begins with clarity ends with surety
- risks arise from the unpredictability
- clarity of detail, logic of relevance, holistic inclusion, certainty of outcome
More models
- V Model
  - similar to waterfall
- Incremental Model
- iterative model

Week 4

Overview of tools for analysis
Using tools to get results
Business analysis tools for non-analysts
Change/project management

Tools and techniques

techniqes are a way to do it
tools are what we do it with
- tools simplify the complex and contextualise the diverse
- Sools standardise information to improve collaboration
- Tools are used to remove mental clutter and create focus
- There are hundred toos that can be useful
- the BA must know the right tools and how best to use it in the current situation
99 essential tools
- this a book of tools
categories of tools
- business strategy
  - situation goals direction
- investigation
  - finding the facts and the truth
- stakeholders
  - who matter why they matter how they think
- analysis
  - modelling logic flow and cause and effect
- evaluation
  - assessing solutions and option
- definition
  - difining outcomes
- change management
  - seeing it bare fruit
Porters 5 forces
- External industry model - shows the forces influencing a particular industry
  - Bargaining power of supplies
  - bargaining power of customers
  - threat of new entrants
  - threat of substitute product
  - Competitive rivalry within an industry
PESTEL
- external industry model - shows the forces influencing a particular industry
- political
- econmic
- social
- technological
- environmental
- legal
SWOT
- strengths
- opportunities
- weaknesses
- threats
To evaluate the effectiveness of a tool, look at the results of the questions your asking and the value of the answers to succeed.
Question types
- open
- closed
- limiting
- leading
- probing
- linking
Surveys
- be clear on the objective, what you want to know
- understand who you are surveying and why
- choose the tupe of question that give you the best information
Cost Benefit analysis
other tools
- shortlisting
- benefits cat
- force field analysis
- feasibilty
  - business
  - technical
  - financial
- Storyboarding
- Rich picture
- SARAH change model
- Kotter’s approach
- Honey & Mumford
- Outcome frame
  - what do i want
  - why do I want this
  - when do I want it
  - How will I know
  - where am I now
  - what resources do I need
  - what steps need to be taken
  - are there alternati

Week 5

Final Exam

Week 1

observation

Week 2

Week 3

Week 4

Week 5