Registered Research Field · ANZSRC 4612
Software engineering research for systems standard practice cannot resolve
Most software work is difficult engineering, not research. Research may begin where established architecture, testing and optimisation methods cannot determine whether a required behaviour is achievable within the system’s actual constraints.
How this field connects
A project can draw on more than one registered field. The links below make those technical intersections visible without forcing a business problem into a single industry label.
Built Environment and Design
Engineering
Environmental Sciences
Information and Computing Sciences
01
Where implementation ends and research may begin
A project is not research merely because it is difficult, new to the team or commercially important. We first examine standards, published knowledge, supplier evidence and comparable work. Research begins only where the required technical outcome still cannot be determined with confidence.
Usually implementation
- applying a known migration pattern
- building ordinary integration tests
- optimising a well-understood bottleneck
May require research
- inferring behavioural equivalence from incomplete traces
- testing consistency-performance trade-offs under a novel transaction pattern
- exposing rare interacting failure states
02
Open questions in this field
Can a replacement preserve undocumented behaviours users depend on?
Evidence may combine behavioural contracts, production-trace sampling and differential testing.
Can consistency, availability and latency requirements coexist under the actual failure model?
Controlled fault injection tests the conditions rather than the happy path.
Can a bottleneck be isolated when the environment cannot be reproduced?
Instrumentation, controlled replay and competing causal hypotheses may be required.
Can automated testing expose rare state combinations?
Generative, model-based or property-based methods can be compared against a fixed detection criterion.
03
Taking a question from this field forward
We start from the operating decision rather than a preferred technology: isolate what is already known, define the outcome that remains unresolved, set thresholds before the work begins, and stage it so the highest-consequence assumption is tested first.
The Ignition research value chain
One methodology, six steps — each with a named output
- 01FrameA testable research question
- 02DesignExperiment plan & controls
- 03ExecuteRuns & recorded findings
- 04IntegrateSpecialists, coordinated
- 05GovernEvidence log & audit trail
- 06ReturnValidated, claim-ready records
General information only. This page does not determine R&D Tax Incentive eligibility and is not tax, legal, financial or grant advice. Whether any government support pathway may be relevant depends on the project's specific activities, structure, evidence and the current program rules.
Next step
A researcher reads your description — not a salesperson.
Bring the operating problem, the result you cannot explain or the decision your team cannot make with confidence. You will get a reply within two business days — including when the honest answer is that a research pathway is not the right tool.