How to turn legislation into implementable business requirements

Legislation is authoritative, but it is not a requirements specification

An Act may define a duty, power, prohibition, right, time limit or condition. It rarely describes the complete service, process, information, control and technology needed to apply that provision.

The work between legislation and implementation is not clerical translation. It requires authorised interpretation, shared terminology and decisions about how the organisation will carry out its mandate.

Start with an authoritative source and a clear question

Agree the legislation, amendments, regulations, policy and authorised interpretations that are in scope. Record versions, effective dates, unresolved questions and the people responsible for interpretation. The New Zealand Legislation website explains the official source and status of legislation.

Also agree what the analysis must support: a capability assessment, policy change, service redesign, business case, procurement or implementation. Without that boundary, the work can expand indefinitely.

Use four layers to keep the mandate visible

1. Legislation: the relevant duty, power, rule or condition
2. Statutory function: the responsibility the organisation must perform
3. Organisational function: how the organisation carries out that responsibility
4. Capability: what people, information, process, control and technology must make possible

As an illustration, a duty to decide eligibility may require the organisation to receive an application, confirm identity, obtain facts, apply approved decision rules, record reasons, notify the person and handle review. Each capability can then be expanded into requirements.

Separate rules, process and judgement

Some provisions create clear conditions. Others give an authorised decision-maker discretion. Record the source, owner and version of each business rule, but do not turn professional or statutory judgement into an automatic rule without authority.

Keep the process sequence separate from the decision logic and from adaptive casework. The Better Rules discovery work provides useful context for turning policy and legislation into understandable rules while preserving accountability.

Write requirements that can be checked

A useful requirement identifies the required behaviour, the conditions in which it applies, its source, owner, priority and acceptance criteria. Cover more than software features: information, records, privacy, security, accessibility, integration, continuity, assurance and transition may all be necessary.

For example, “the system must support eligibility decisions” is too vague. A testable set would identify the facts required, the rule version, authorised overrides, reasons recorded, notifications, review rights, access and the expected behaviour when information is missing.

Maintain the chain through implementation

Trace each material requirement back to the obligation or authority and forward to design, controls and tests. Record assumptions and gaps rather than hiding them in prose. When legislation or policy changes, use that chain to identify the affected process, rule, information, integration and test.

The Legislation Guidelines and New Zealand Digital Service Design Standard can provide additional context, depending on the work.

Experience from a government engagement

Hot Desk produced a Legislative Capability Alignment Framework for a New Zealand government organisation. It mapped legislation through statutory and organisational functions to required capabilities and included governance, ownership, assurance and review considerations.

We can describe the framework and the work delivered, but the material we retain does not show what the organisation adopted or implemented later. We therefore make no claim about those later outcomes.

Explore our government advisory work, read about business-process design or discuss your requirements challenge.

A note about this article

This is general information from Hot Desk Consultancy Services Limited. It does not interpret legislation, establish compliance or provide legal, policy, procurement, architecture or implementation advice. Confirm the current sources and authorised interpretation that apply to your organisation.