Stage 5
Specification

Description of lifecycle stage

The functional requirements and detailed requirements need developing at this stage for the solution to be procured. The detailed requirements should clearly, accurately, and completely describe in detail what the Authority wants the successful bidder to supply. This stage is usually conducted in collaboration between the problem owner and the Authority’s procurement team.

In the case of technology-driven procurement exercises, the requirements should take into consideration the industry standards being utilised in devising the solution, again using the appropriate use-case as guidance on the key standards to apply. Deploying standardised technologies bring a wide range of benefits including:

A. Economies of scale which potentially drives down costs;
B. Interoperability at the technology system/components levels and ease of interchangeability of products;
C. Mitigation against vendor lock-in; and
D. Interoperability at the data level.

This manual will continue to develop over time to incorporate knowledge and lessons learnt from previous Authority projects. The use-cases will help authorities understand the standards adopted in relevant solutions procured by other authorities and draw upon their body of knowledge. This will also help the Authority’s procurement team to ensure a common approach throughout the Authority in relation to aspects such as data standards and formats, interoperability with existing systems and services, and issues related to vendor lock-in.

 

Considerations for Stage 5

  • Understand inputs, outputs, and any operational requirements such as speed of response. The Use-case Guides should help here, but remember that the interfaces to Authority’s existing components of a service are being retained, using the ‘as-is’.
  • Do not address design of the system/service. Make it clear that is the responsibility of the service provider to provide the outputs you define.
  • Address the essential non-functional requirements including accessibility (for example, refer to the GDS service design manual), security and data governance.
  • Document any service transition requirements, if existing services are to be taken over or decommissioned.
  • Consider the whole life operation and end of life requirements including data ownership and how data should be transferred back to the Authority from the service provider or on to a subsequent service provider at the end of the contract.