Stakeholders & elicitation
Identify users, sponsors and decision owners. Practise interviews, workshops, observation and follow-up questions before proposing features.
AGENTIC INITIAL STUDIO
Software requirements analysis
Learn stakeholder communication, requirements elicitation, scope definition, specification and acceptance criteria, then practise handing a clear agreement to implementation and testing.
SOFTWARE REQUIREMENTS ANALYSIS
Understand the problem before choosing the implementation.
This pathway applies to websites, business applications, data systems and AI-enabled software. Coding experience is optional for the analysis work; the Python example below is one way to practise the handover from specification to implementation.
Scope & requirements
Separate the business problem from the proposed solution. Define scope, functional requirements, quality requirements, assumptions and constraints.
Specification & acceptance
Turn findings into user stories, use cases and measurable acceptance examples. Prioritise requirements and resolve conflicting expectations.
Validation & change
Review the specification with stakeholders, connect requirements to tests and manage changes through versioned decisions and impact analysis.
What you take away
A stakeholder map, scope statement, prioritised requirements, acceptance criteria and a traceable change log. You should be able to explain why each requirement matters and how it will be checked.
THE LEARNING PROCESS
Communication before implementation.
First decide what the software needs to achieve. Clarify assumptions, agree a specification and connect it to implementation and acceptance checks. AI-assisted coding is one possible next step.
Stakeholder communication first
Ask who uses the report, which decision it supports and who owns exceptions. Turn an ambiguous request into agreed business rules.
Deliverable: stakeholder notes and open questions.Specification
Define the input contract, transformation rules, exceptions, outputs and acceptance examples. Confirm the specification before asking AI to implement it.
Deliverable: a reviewable specification and test expectations.AI-assisted implementation
Use the confirmed specification to brief AI, inspect its code and run independent checks. Keep responsibility for decisions and the final handover.
Deliverable: working Python, test evidence and a runbook.EXAMPLE APPLICATION / SYNTHETIC DATA
“Can you automate our expense report?”
A manager wants a department summary from a CSV file. There are eight records, including a repeated ID, a missing amount and a refund. Work through the decisions before running the implementation.
Inspect the eight input records
| ID | Department | Amount (AUD) |
|---|---|---|
| TX001 | Sales | 120.00 |
| TX002 | Sales | 80.00 |
| TX003 | Operations | 45.00 |
| TX003 | Operations | 45.00 |
| TX004 | Operations | — |
| TX005 | Research | 35.00 |
| TX006 | Sales | -20.00 |
| TX007 | Operations | 90.00 |
Ask the questions code cannot decide.
These are role-play decisions, not a live chat. There is no single universal refund or duplicate rule; choose a policy and make it explicit.
Make the agreement testable.
A specification guides the code. Tests check it.
The example implementation is prepared in advance and instantiated from your decisions. This page makes no live AI calls. The prompt shows how to brief your own AI tool; actual Python execution happens in your browser.
Inspect the implementation prompt
Edit the implementation, then run it against the fixture expectations. Changing stakeholder decisions clears confirmation, regenerates the example and invalidates the previous result.
Python output & traceback
First execution loads about 14 MB of Python. Runs stop after 10 seconds. No files are uploaded, source data stays unchanged, and edits are not saved after refreshing.
REVIEW BEFORE HANDOVER
A passing script still needs an owner.
Review the totals and exception list with the stakeholder. Agree who handles rejected rows, how the input format may change and how to rerun the process. This learning demo generates a report only; it does not approve expenses or make payments.
Communication notes
→ confirmed specification
→ Python + independent checks
→ stakeholder review + runbookThink before accepting the shortcut
If AI replaces every missing amount with zero, the total might still look right. What else must the acceptance tests check?
Reveal the explanation
Check accepted-row and exception counts as well as totals. The missing row must remain traceable in the review queue, while a genuine zero amount must be allowed. The flawed version in the demo fails these checks.
ONE-TO-ONE ONLINE LEARNING
Practise elicitation, specification and review.
In individual online sessions, the tutor can role-play a stakeholder while you ask questions, resolve ambiguity and review a specification. Use prototypes and acceptance examples to check shared understanding; implementation exercises are optional.
- No coding prerequisite for the analysis exercises; basic Python helps with the optional implementation demo.
- Bring an anonymised workflow, or use the synthetic case here.
- Leave with stakeholder notes, a specification, acceptance criteria and an implementation handover checklist.
- Language, timing and fees are agreed individually. Model access is optional and discussed before exercises that need it.