How to turn legislation into implementable business requirements

Legislation is not a requirements specification

Legislation can define authority, duties, powers, prohibitions, rights, time limits and decision conditions. It does not usually describe the complete operating model, service, process, information, control or technology needed to apply those provisions in practice.

Implementation therefore requires a controlled translation. The aim is to preserve a visible line from an authoritative provision to organisational responsibility, business behaviour, information, controls, requirements and evidence. The translation must also keep legal interpretation separate from business analysis and solution design.

A list of quoted sections is not enough. A useful requirement set explains who must be able to do what, under which conditions, using which information, within what time, with what discretion, control and evidence.

Establish the authoritative source set

Begin with a source register. Depending on the scope, it may include Acts, secondary legislation, commencement and amendment instruments, incorporated material, applicable policy, delegated authorities, approved legal advice and relevant operational directives.

The New Zealand Legislation website is the official home for New Zealand Acts, Bills and secondary legislation. Its guidance also explains that the collection of agency-published secondary legislation is not yet complete and that agency-published material should be checked at its source. That makes source ownership and verification part of the analysis.

For every source, record:

• the title, type and responsible agency;
• the exact provision or instrument;
• its status, version date and commencement position;
• amendments, repeals, transitional provisions and related secondary legislation;
• the source location and date checked;
• the business and legal owner;
• approved interpretation or policy material; and
• the change-notification and review route.

Do not mix a Bill, an enacted provision, a consolidation and an old operational rule without identifying their different status. Requirements should remain traceable to the version that supports them.

Agree the decision and scope first

Clarify why the work is being done and which decision it must support. The output for a policy change, capability assessment, service redesign, procurement, system replacement or assurance review will not be identical.

Record:

• the legislation and organisational boundary;
• the statutory functions, services, people and channels in scope;
• the implementation or investment decision required;
• the accountable sponsor and interpretation authority;
• stakeholders who deliver, assure or are affected by the work;
• required depth, evidence and approval; and
• explicit exclusions and unresolved questions.

Keep the work proportionate. An organisation-wide capability view can establish direction without specifying every screen or field. A priority service or decision may need detailed rules, data, process, control and acceptance criteria.

Create the four-layer line of sight

A practical organisation-wide model can connect four layers:

1. Legislation: the provisions and instruments within the agreed scope.
2. Statutory functions: the duties, powers and responsibilities the organisation must perform.
3. Organisational functions: how the organisation delivers those responsibilities in practice.
4. Required organisational capabilities: what the organisation must be able to do consistently to support delivery.

This prevents a direct jump from a legislative section to a technology feature. A statutory responsibility may require people, governance, policy, information, service design, decision authority, records, security, assurance, suppliers and technology working together.

Once the organisation-wide view is stable, expand selected capability areas into processes, decisions, casework, information, controls, service requirements and technology enablement. Maintain references back to the source and the validated statutory function.

Structure each obligation or authority

For detailed analysis, convert relevant text into a structured statement without pretending that the analysis replaces legal interpretation. Capture:

• source: the exact provision and version;
• actor: the person, office, organisation or delegate;
• trigger: the event or condition that makes the provision relevant;
• authority or obligation: what may, must or must not occur;
• subject: the person, matter, information or decision affected;
• conditions: thresholds, prerequisites and dependencies;
• time: commencement, duration, deadline and calculation rules;
• exceptions: exclusions, exemptions and special cases;
• discretion: where judgement or choice remains; and
• evidence: what must show that the provision was applied.

Separate the source words from the analyst's statement. Record assumptions and questions. Ask the authorised legal or policy owner to validate interpretation before the statement drives implementation.

Distinguish duties, powers, rules and judgement

Different legislative elements lead to different implementation needs. A mandatory duty needs evidence of performance. A power needs a valid authority and decision route. A prohibition needs prevention or detection. An entitlement needs eligibility, access and review. A definition shapes the meaning of data and rules. Discretion needs criteria, authority, reasons and suitable review rather than an invented deterministic answer.

Identify what can become an explicit business rule and what still requires professional or delegated judgement. Do not encode ambiguity as if it were certainty. Escalate unclear, conflicting or high-impact interpretation to the accountable authority.

The Legislation Design and Advisory Committee's 2021 Guidelines cover policy purpose, existing law, constitutional issues, privacy, powers, compliance, enforcement, appeal and review. They are useful context for understanding the design questions that may sit behind a provision, but they do not replace analysis of the legislation and circumstances in scope.

Build a shared vocabulary and concept model

Legislation, policy, operations and technology may use the same word differently or use several words for the same concept. Create a controlled vocabulary that records the term, definition, source, context, owner, relationships and known alternatives.

A concept model can show relationships between people, roles, applications, decisions, services, events, records and statutory concepts. Use it to identify undefined terms, conflicting meanings and information dependencies before they are embedded in rules or data models.

Keep source definitions visible. A convenient system label should not silently change the legal or policy meaning. Where a term is interpreted for operational use, record the authority, scope and approval for that interpretation.

Model decisions and business rules

Start from the business decision, not a screen or code branch. Identify the question being decided, possible outcomes, required facts, dependencies, exceptions and the authority that owns the decision.

Connect explicit rules to the decision they support. Each rule should be understandable to business, policy, legal and delivery stakeholders. Record its source, effective dates, owner, version, approval and related test cases.

The 2018 Better Rules for Government Discovery Report examined the gap between policy intent and implementation and included case studies on eliciting business rules from legislation. It also stressed multidisciplinary work, shared concepts, decision models, traceability and legal and business sign-off. Treat it as a discovery report and source of practical lessons, not a current mandate or proof that every legislative rule should become software code.

Keep process, decisions and casework distinct

Requirements should reflect the form of work:

• Process: ordered and repeatable activities, hand-offs, time limits and outcomes.
• Decision: explicit questions, facts, rules, judgement and results.
• Casework: adaptive work where events, evidence and professional judgement determine the next action.

A legislative service may use all three. An application can start a process, a rule can determine a routine condition and an unusual case can require delegated judgement and additional evidence. Combining them into one undifferentiated flow makes requirements harder to validate and change.

For each activity or decision, record the responsible role, trigger, input, authority, completion condition, exception, record and next state. Include manual, assisted and non-digital channels where they remain necessary.

Define information and records requirements

Identify the information required to apply the provision and operate the service:

• facts needed to establish identity, status, eligibility or authority;
• source, ownership, accuracy and currency;
• collection, permitted use and disclosure;
• classification, access and segregation;
• correction, review and dispute handling;
• retention, disposal and archival requirements;
• records needed to explain a decision or action; and
• data exchanged with another organisation or system.

Separate a legal fact, an asserted fact, derived information and a decision. Define what evidence is acceptable, who can verify it and what happens when it is incomplete or conflicting.

Map information to the related rules, processes, controls and requirements. This avoids creating fields that have no authorised purpose or decisions that lack necessary evidence.

Turn obligations into controls and evidence

For every material requirement, ask how the organisation will prevent, detect, correct and demonstrate the required behaviour. Controls can include authority checks, segregation, validation, approvals, reconciliations, alerts, reviews, access restrictions, records and independent assurance.

Define the control owner, trigger, frequency, evidence, exception route and review point. A policy statement alone may not establish that a control is operating. A technology control may also be incomplete if the business has not defined the decision, authority or response.

Connect each control to the obligation or risk it addresses and to the evidence an accountable person will review. This creates a usable basis for assurance and change assessment without promising legal compliance.

Develop the requirement set by type

Organise requirements so that different delivery questions remain visible:

• business requirements: statutory and organisational outcomes and capabilities;
• stakeholder requirements: what authorised users, affected people, partners and assurance roles need;
• decision and rule requirements: questions, facts, logic, discretion, outcomes and review;
• process and case requirements: activities, states, hand-offs, time, exceptions and completion;
• information requirements: data, records, definitions, quality, access and lifecycle;
• control requirements: prevention, detection, evidence, exception and assurance;
• functional requirements: behaviour a service or system must provide;
• quality requirements: accessibility, security, privacy, performance, availability, recoverability and maintainability;
• integration requirements: exchanges, authority, validation, failure and reconciliation;
• transition requirements: migration, training, communication, cutover and legacy disposition; and
• operational requirements: ownership, support, monitoring, incidents, continuity and change.

Not every requirement belongs in software. Some belong in delegation, policy, service design, training, records, operating procedures, supplier arrangements or assurance.

Write requirements that can be verified

A useful requirement is clear about the condition, responsible actor, required behaviour, outcome and evidence. Avoid words such as appropriate, timely, easy or sufficient unless they are supported by an agreed measure or decision authority.

For example, replace “The system shall support statutory decisions” with a structured statement such as: “When an authorised decision-maker records outcome X, the service must capture the applicable authority, source facts, reasons, effective date and review route before the decision is issued.” The final wording and evidence fields must be validated for the actual provision and service.

For each requirement, record:

• a stable identifier and concise statement;
• source provisions and related interpretation;
• business owner and approval status;
• priority and implementation dependency;
• acceptance criteria and test evidence;
• linked process, decision, information and control artefacts;
• effective date and version; and
• open questions, assumptions and exceptions.

Keep technology in the right place

Technology can enable the capability, but it should not define the statutory responsibility. Start with the outcome, users, authority, work, information and controls. Then assess which parts need policy, organisational change, process improvement, a configurable platform, integration, automation or a new service.

The New Zealand Digital Service Design Standard includes current principles on user needs, purpose, security and privacy, service lifetime, multidisciplinary teams, data stewardship and public accountability. Its technology principle positions technology as an enabler for well-designed services rather than the purpose or driver.

Compare solution options against the traceable requirement set. Preserve configurability where legislation or policy is likely to change. Identify requirements that should remain outside automated decisions and provide accessible alternatives where a digital channel is not suitable for every user.

Manage gaps, conflicts and assumptions

Translation work will expose questions. Keep a visible register covering:

• unclear or conflicting provisions;
• missing secondary legislation or policy;
• different operational interpretations;
• legacy behaviour without a confirmed source;
• undefined terms and data gaps;
• delegation or authority questions;
• policy choices presented as legal requirements;
• solution assumptions presented as business needs; and
• decisions awaiting legal, policy, business or governance approval.

Do not resolve these gaps silently in requirements. Record the owner, decision needed, impact, due date and temporary treatment. A known uncertainty with an accountable route is safer than a false statement of certainty.

Validate with the people who own the work

Use a multidisciplinary review proportionate to the scope. Participants can include legal and policy advisers, statutory delegates, business owners, frontline practitioners, service and business designers, information and records specialists, privacy and security advisers, Māori and community stakeholders, architects, delivery teams and assurance roles.

Review the chain in both directions. Starting from the source, can stakeholders see how the provision reaches delivery and evidence? Starting from a requirement or system behaviour, can they identify the authority and business need?

Use examples and scenarios to test interpretation, exceptions, discretion, timing, access, communication and review. Present the findings to the stakeholders who will approve, deliver and operate the change.

Design for legislative and policy change

Maintain the mappings as controlled knowledge assets. When legislation changes, identify affected statutory functions, organisational capabilities, rules, processes, information, controls, systems, tests, training and public guidance.

Track proposals separately from enacted and commenced changes. Record effective dates, transitional arrangements, old and new versions, implementation decisions and the disposition of superseded requirements.

Assign owners and review frequency. Use change impact to plan policy, service, process, information, technology, supplier, communication and assurance work. Revalidate the complete line of sight after implementation.

The minimum traceability pack

A practical evidence pack can include:

• scope, decision, owners and interpretation authority;
• authoritative source and version register;
• legislation-to-function-to-capability mapping;
• controlled vocabulary and concept model;
• decision, rule, process and case models;
• information, record and control requirements;
• structured business, functional and quality requirements;
• acceptance criteria, scenarios and test results;
• gaps, assumptions, decisions and exceptions;
• solution options and implementation dependencies;
• approval, version and change records; and
• operating, assurance and maintenance responsibilities.

The depth should reflect the decision, risk and complexity. The purpose is a defensible line of sight and implementable work, not a large document with no clear owner.

Questions before implementation

• Are we using the correct in-force provisions and related secondary legislation?
• Can every material requirement be traced to a validated authority or business need?
• Have we separated source text, legal interpretation, policy choice, business knowledge and solution design?
• Do we understand the statutory and organisational functions before selecting technology?
• Are definitions, facts, decisions, discretion and exceptions explicit?
• Have we kept process, decision and adaptive casework distinct?
• Can the organisation demonstrate performance through suitable records and controls?
• Are requirements testable across normal, exceptional, manual and review paths?
• Can a future legislative change identify every affected capability and implementation asset?
• Who approves unresolved interpretation and accepts the remaining risk?

Evidence from an anonymous government engagement

For one New Zealand government organisation, Hot Desk produced a detailed Legislative Capability Alignment Framework and an executive stakeholder presentation. The work established a four-layer mapping from legislation to statutory functions, organisational functions and required organisational capabilities.

The engagement also connected capability groups to organisational structure, expanded Digital and Technology as one enabling capability area within the wider organisational model, and defined assurance, governance, ownership, maintenance and periodic-review considerations.

The retained deliverables provide a structured reference for capability assessment, prioritisation, transformation and investment planning. They are draft consultancy artefacts. This evidence does not claim formal adoption, implementation, legal advice, customer endorsement or measured outcomes, and the organisation and identifying details remain private.

Where Hot Desk fits

Hot Desk provides government legislation and implementation advisory that can connect legislative obligations to statutory functions, organisational capabilities, processes, information, controls, technology enablement and planning decisions.

The consultancy does not provide legal interpretation or legal advice. The client retains the relevant legal, policy and statutory decision authority. An engagement can produce analysis, mappings, requirements, decision material and implementation support within the agreed scope.

Advice remains product-neutral. It may support improvement of the client's current environment, procurement or implementation of another platform, or a conclusion that technology change is not the appropriate next step.

Continue the discussion

Explore business-process and transformation advisory, review regulatory compliance from obligation to operation, read what makes an AI workflow governed and operable, or discuss a legislative traceability and requirements engagement.

About this insight

This article is published by Hot Desk Consultancy Services Limited as general information. It does not interpret legislation, establish legal or regulatory compliance, determine an organisation's obligations or provide legal, policy, procurement, architecture or implementation advice. Confirm the current sources, authorised interpretation and requirements that apply to your organisation and circumstances.