requirement Business Overview

This document describes the UK Defence Business Data Exchange Specification which defines Requirement information, where a requirement is a need, formally defined by a person or an organisation.

General administrative information includes all the information to uniquely identify and describe the set of requirements for a specific project. This includes:

Identification of an individual revision of the requirement or set of requirements;
Status such as draft, issued etc;
Priorities and categories may be assigned to an individual requirement or set of requirements;
Identification of the project to which the requirement (set) relates;
Author or sponsor;
Dates (of creation, status changes, etc.);
Approval(s).

Detailed requirements will be created during the development of the product and its support solution and throughout the in service phase; some of these will be directly derived from the original requirements and will appear in a hierarchical fashion as a breakdown of formal requirements. The original requirement that requirements are derived from and to decompose them further.

Requirements will normally be expressed in a form that not only describes the capability required, but also specifies, or allows the generation of, appropriate metrics against which to measure the performance of the end product and its support solution. Requirements are normally written in such a way that they do not specify what the end solution will be, but what it is to be capable of doing or achieving.

The in service requirements are likely to have the same structure as, but will not necessarily be directly related to the original requirements. These requirements could, for example, appear in a contractual relationship for the performance of a maintenance or repair activity. The performance measuring aspects will normally take the form of some sort of acceptance criteria or the nomination of an accepting authority whose judgement will be sufficient.

Requirements are built upon existing capability and support environments and, whilst potentially requiring a completely new equipment solution, will almost certainly incorporate existing equipment and infrastructure within the end result, so they may be expressed in terms of changes to the existing items.

Requirements may also appear in the form of constraints on the scope of a project; for example by the application of certain design standards or statutory legislation.

Note: Care should be taken to differentiate between requirements and directives; where the latter dictates what the end results will be and the requiring organisation has the authority to make the demand. For example, a Design Authority may require maintenance organisations to implement a specific modification by a certain date and ask for an acknowledgement when complete, but this different to the specification of a need for a capability that could be met by the implementation of the same modification.

Requirements will express a reason or justification for the need that is being expressed; this may be a simple statement or may make reference to documents, such as business cases, or analyses that have been conducted of previous operational designs and support solutions.

Documentation for the Requirement will be prepared to ensure that the requirement is adequately understood, reference documents will be capable of being passed.

They will also explain the context within which the need arose or is to be satisfied; this may be by reference to the formal Support Context for the project or be a textual description.

Since this business DEX represents an information flow in a process model, by definition, it is a message between the people / organizations that implement the sending and receiving processes.
As such, the information that represents the sending and receiving of the message, as well as the content of the message and any other associated information, need to be included in this business DEX.