Rule 0: Questions for projects
Updated 16 October 2023
The rules are under review and subject to change.
Rule 0 is used to ensure requirements relating to ‘information’ and ‘use’ of a service or system are defined prior to any design work being undertaken.
There is a high risk of the design failing without these requirements being defined.
1. Rule Questions
The following questions are used by DAIS Assurance Officers to identify gaps in these requirements.
Not all questions will be applicable to every project, in which case it is the Assurance Officers role to determine applicability.
2. Outline
2.1 What business function(s) will the capability support?
ICT is required to support the business. If it is not clear what the ICT is there to support then it is either not required or the customer is not clear on what is required. This information can usually be extracted from a Project initiation document and Business case if these were created.
2.2 What is inside and outside the scope of the capability?
3. Information Exchange Overview
3.1 Are the business processes fully defined?
Information exchange requirements are there to support business processes. If business processes are not defined to a sufficient level to identify information needs then a Service cannot be designed to support it.
3.2 What information does the capability require from other systems, sources or users?
To support the business processes, information will be required from different sources. It is important that each source is identified and the information which is to be provided is defined. Failure to define the information requirements may result in the business processes not being successfully supported in the ICT design. This information should be defined in an Information exchange requirement.
3.3 What information will the capability provide to other systems?
Other systems may require information to be provided to support other business processes. It is important that each output is identified and the information which is to be provided is defined. Failure to define the information requirements may result in the other systems business processes not being successfully supported in the ICT design. This information should be defined in an Information exchange requirement.
3.4 What is the agreed classification of the information?
A key consideration to ICT design is the security requirements of the information. Before any system is designed it is important that the classification of the information which will be processed, stored and exchanged is defined. Failure to do so may result in the system not supporting the security requirements of the information resulting in design changes. This information should be recorded in an Information exchange requirement.
3.5 What is the frequency and size of information exchanges?
If a project team has defined business processes then quantifying the information exchanges in both frequency and size should be straightforward to estimate. Understanding the traffic requirements placed on the supporting networks, gateways etc is required in the design of the end to end service. This information should be defined in an Information exchange requirement.
3.6 How many users, their roles and locations?
Understanding where the service or system is used from and by how many people is key to providing an end-to-end service or system that is fit for use.
Connectivity through to each location should have appropriate consideration in the design phase to ensure any constraints are understood and mitigated.
4. Key Stakeholders
4.1 Who owns the information (IAO)?
All information must have an Information asset owner (IAO). The IAO is responsible for determining the level of protection afforded to the information. Understanding the IAOs requirements for is essential as it will influence an ICT design.
5. Usage Information
5.1 Does the capability require voice or video?
If voice or video is a requirement then IP Quality of Service will need to be applied in the design. This needs to be captured in an Information exchange requirement.
5.2 When will the service be used?
Any service or system design must consider when the demand for it will need to be met. This could vary from a flat profile in an office day to peaks at particular times of day, week, month or year. For deployed this could be to support different operational scenarios.
5.3 Will the service be used in the deployed environment? If so where?
Services provided to a deployed environment will have additional constraints which any ICT design must consider. For example, any Service will need to consider constrained bandwidth provision, latency and loss of connectivity in the design.
6. Service Continuity and Performance
6.1 What are the service continuity requirements?
Service continuity requirements should be appropriate to support the business need and should be defined by the customer.
6.2 What are the end user performance requirements?
To enable business functions to achieve their outputs, end user performance of any Service must be defined and considered within the design covering its end to end delivery. Any Service should be useable (fit for use) requiring User performance requirements to be understood and inherent to the design.