ISYS90049 Digital Business Analysis

How ISYS90049 is assessed

The reviewed Subject Description does not publish attendance as a separate pass condition for this subject. It publishes Assignment 1 at 15%, Assignment 2 at 35% and the final examination at 50%. The Subject Description requires a weighted average of at least 50% across the two assignments to pass. It also requires the final examination to be passed; the numeric or percentage examination pass threshold is not published. Failure to satisfy either condition means the subject cannot be passed. Check the Subject Description and current learning site.

What ISYS90049 covers

The guide moves from business need and value through planning, strategic context, stakeholder elicitation and root-cause analysis.

Planning establishes scope, work approach, stakeholders, governance, information management and risk before evidence is gathered. Context analysis moves from external PEST signals and internal capability to a SWOT synthesis that supports strategic choice rather than a list of adjectives. Stakeholder work identifies influence, attitude and impact, while elicitation is prepared, conducted, documented and confirmed.

Problem analysis then distinguishes symptoms from causes through evidence, Five Whys, fishbone and Pareto reasoning. The resulting recommendation should be traceable: each proposed feature or process change must answer a validated need, create an observable outcome and acknowledge constraints.

The subject has two independent pass requirements outside a simple total: the weighted average across Assignments 1 and 2 must reach 50%, and the examination must be passed even though the reviewed description does not publish its numeric pass threshold.

For Semester 2, 2026, Digital Business Analysis at The University of Melbourne publishes this assessment map: Assignment 1: Group Analysis Plan (15%); Assignment 2: Group Strategy Analysis and Solution Evaluation (35%); Final examination (50%). The reviewed Subject Description does not publish attendance as a separate pass condition for this subject.

It publishes Assignment 1 at 15%, Assignment 2 at 35% and the final examination at 50%. The Subject Description requires a weighted average of at least 50% across the two assignments to pass. It also requires the final examination to be passed; the numeric or percentage examination pass threshold is not published. Failure to satisfy either condition means the subject cannot be passed.

Check the Subject Description and current learning site. The guide moves from business need and value through planning, strategic context, stakeholder elicitation and root-cause analysis. Business analysis begins with a problem or opportunity expressed through stakeholder outcomes, performance evidence and context.

A proposed application may eventually be appropriate, but naming it as the need hides assumptions about why the current state fails. The analyst first describes what is happening, who experiences it and why change matters. Write the need without a product noun, then list evidence, affected actors and desired outcome. Preserve alternative causal accounts until elicitation and process evidence discriminate among them.

Predictive work defines substantial scope and outputs early when needs and constraints are stable. Adaptive work uses short cycles and frequent feedback when learning changes the problem or solution. A hybrid approach can stage governance while iterating uncertain content. Explain the uncertainty, stakeholder availability, risk and delivery dependency behind the approach.

Do not choose agile or waterfall by organisational fashion alone. PEST scanning identifies factors outside the focal organisation that can alter demand, cost, legitimacy, capability or constraint. The categories prompt coverage; they do not analyse the factor. Each observation needs a source, direction, time horizon and link to a decision. Date the evidence and distinguish trend from scenario.

Avoid placing an internal weakness in PEST simply because it responds to an external factor. Stakeholders differ in decision power, operational knowledge, exposure to change and willingness to participate. A map should explain why each perspective matters and how engagement will occur. Influence is not the same as impact: low-authority users can carry the greatest implementation burden.

Record the rationale and evidence behind each placement. Avoid using stakeholder categories to silence groups; choose engagement methods that fit access, power and information needs. A useful problem statement describes the current condition, affected stakeholder, measurable consequence and relevant boundary. It does not embed an untested explanation.

The difference between current and desired state guides investigation without deciding the intervention. Write at least two causal hypotheses and the observation that would distinguish them. State the period, population and baseline behind any reported magnitude.

Worked application: Root-cause tools organise inquiry rather than prove cause

Key terms

Business Need

Business Need — Business analysis begins with a problem or opportunity expressed through stakeholder outcomes, performance evidence and context. A proposed application may eventually be appropriate, but naming it as the need hides assumptions about why the current state fails. The analyst first describes what is happening, who experiences it and why change matters.

Outcome Gap

Outcome Gap — A slow transaction, repeated complaint or manual workaround is observable evidence; it may arise from policy, information, skill, process or technology. Treating the symptom as the cause can produce a technically elegant intervention that leaves the operating constraint intact.

Solution Bias

Solution Bias — Write the need without a product noun, then list evidence, affected actors and desired outcome. Preserve alternative causal accounts until elicitation and process evidence discriminate among them.

Solution

Solution — A solution can combine process, people, information, policy and technology changes. Value appears only when those elements create an outcome a stakeholder or organisation recognises. Delivery is therefore an input to value, not proof that value has been achieved.

Business Value

Business Value — A broad promise such as efficiency needs a baseline, unit, observation period and accountable owner. Cost, risk, adoption and displaced work can offset a nominal benefit. The analysis should show when the value signal will become visible and who can act if it does not.

Benefit Measure

Benefit Measure — Link each solution component to a capability change, expected behaviour and metric. Do not add unrelated benefits after selection merely to make the preferred option appear stronger.

Digital Transformation

Digital Transformation — Digitisation converts analogue information into digital form; digitalisation uses digital tools to alter a process; digital transformation changes how the organisation creates value, coordinates work or relates to stakeholders. The labels imply different scope, governance and evidence requirements.

Operating Model

Operating Model — A new interface can improve one interaction without changing the operating model. Conversely, an apparently small data capability can reshape decisions across several units. Classify the change from its organisational consequences rather than the novelty of the technology.

Change Scope

Change Scope — State what changes in capability, process, role and value logic. Avoid using digital as a synonym for beneficial or transformation as a marketing adjective.

Analyst Role

Analyst Role — A business analyst frames questions, gathers and models evidence, surfaces assumptions, connects stakeholders and evaluates options. The role can influence decisions strongly without replacing the sponsor's authority or the expertise of operational participants. Neutral facilitation does not mean pretending all claims have equal support.

Decision Rights

Decision Rights — Useful analysis is iterative, context-sensitive and value-oriented. It communicates at the audience's level, seeks multiple perspectives and maintains traceability. The analyst also discloses constraints and conflicts rather than smoothing disagreement into artificial consensus.

Traceability

Traceability — Record who recommends, who decides and who supplies evidence. Separate facilitation notes from validated findings, and retain dissent when it changes risk or feasibility.

ISYS90049 FAQ

How to study for the exam

Keep one analysis trace from start to finish. Write the business need without a product name, add evidence of the current outcome, identify the affected stakeholder and define a measurable value signal. For each planning decision, record who owns it, what information is needed and what event would trigger revision.

Build PEST and capability notes as implications rather than inventories; every factor should alter a risk, opportunity, constraint or priority. Prepare elicitation with an objective and participant rationale, then separate what a participant said from the analyst's interpretation. Confirm notes before turning them into requirements.

For a problem statement, test at least two rival causal paths and use Five Whys or fishbone categories to expose assumptions; use Pareto only when the counts and categories are comparable. Maintain a separate assessment checklist: the assignment pair needs a 50% weighted average and the final examination must be passed, while its numeric pass threshold remains unpublished in the reviewed Subject Description.

ISYS90026 Information Systems Analysis and Design · ISYS90050 IT Project and Change Management · MGMT90141 Business Analysis and Decision Making