Standard

Quality criteria for reviewing a functional standard

Updated 15 April 2024

The front sections

  • the purpose, readership and scope of the standard is clear (clauses 1.1 and 1.2)
  • references to other government functional standards, necessary for using this standard, are identified (clause 1.3)
  • the principles apply in all situations (clause 2)

The main content

The content of the standard:

  • supports the standard’s purpose and scope (clause 1)
  • supports the principles (clause 2)
  • does not breach current government policy, regulations or legislation
  • is written for long shelf life, and does not contain text which is likely to change, such as job titles (as opposed to role titles)
  • is agnostic to proprietary solutions and methods unless the government has adopted them
  • does not conflict with any referenced government functional standards

The standard encompasses activities and practices within the defined scope in terms of “why” and “what”.

The standard covers activities or practices for government as a whole, an organization (such as a department or arm’s length body) and for required individual practices, lifecycle activities and/or episodes.

Roles required to cover the breadth of the function are defined and state what the role is accountable for and who to - and align with GovS 001, Government functions clause 4.6: Roles and accountabilities.

Annexes

  • references to other government or external documentation are listed in Annex A and referred to from the appropriate places in the body of the standard using [square brackets]
  • definitions used in the standard and listed in Annex B are consistent with the government standards common glossary
  • additional annexes add value and are relevant to the content and use of the standard, such as underlying concepts, terminology or graphical representations

Writing style

GovS 001, Government functions specifies the use of the digital style guide.

You should also follow Annex E of GovS 001, Government functions which explains the writing style for standards. It is designed for precision and consistency, and based on best practice.

For example:

  • present tense, plain English, one idea per sentence, no unnecessary jargon

  • appropriate use of verbs such as “shall”, “should”, “may”, “might”, “can”
  • no abbreviations or acronyms - state something in full
  • use notes for ephemeral content that may change, to help the reader
  • no shall or should statements in annexes – if you are setting expectations, they need to be in the main body of your standard
  • The standard should be correctly labelled for status and version control as defined in this handbook
  • follow the style guide eg no full stops at the end of bullet points

The functional standard drafting template [4] is set up to ensure consistency, and includes content and styles to help with drafting (eg for different clause levels, annexes, headers and footers).

Hints and tips

Here are a few other shared conventions to be aware of:

  1. Avoid hanging paragraphs in your standard: all text needs to be attached to a clause. A hanging paragraph is a paragraph that, for example, sits between headings 5 and 5.1 and is not attached to separate clause. Instead, create a new clause (the usual heading used is ‘overview’).
  2. When referring to another standard that your reader needs to follow, use the format: “GovS 001, Government functions shall be followed”.
  3. For the title page of your standard, use a colon as a separator, like this: “GovS 001: Government functions”.
  4. The term ‘must’ means ‘it is the law’. Each functional standard has a boilerplate note that says: “It is assumed that legal and regulatory requirements are always met’. This means ‘must’ is not usually used in a standard. When you want to refer readers to existing legislation or regulations, you should add a note after the relevant content: “Note: attention is drawn to [XXX] and its equivalent in other jurisdictions”.
  5. When you cross-refer between clauses within the standard, always include the word see, for example: (see 3.2.1).