Requirements Engineering

The requirements capture process essentially creates and maintains a set of cross references between carefully identified statements within source documents and requirements derived from them.

These requirements, however, must be further engineered to produce the set of formal requirements that are the basis for system development.

In effect, a transfer of ownership of the requirements needs to happen, from the customer's expression of what is required in the source documents into the supplier's expression of what will be built in the set of formal requirements.

This clear distinction is the primary reason for a systems engineering toolset to support the analysis of both source statements and requirements.

The first step in engineering the initial requirements set is to categorise them. This categorisation needs to occur for several reasons, including:

• To provide fundamental grouping of requirements To allow checks for inconsistency, omission, and duplication between requirements in the same categories To allow domain specialists within the project to focus quickly and easily on the requirements that they need to be concerned with To allow the allocation of requirements to physical subsystems that are already known To assign responsibility for the supplier acceptance and/or engineering and/or successful delivery of requirements

• To allow subdivision of the requirements set on the basis of team organisation

Depending on the nature of the project, different types of categorisation are needed. Each requirement may need to be simultaneously categorised on multiple bases. As such, the systems engineering toolset must allow multiple categorisations and allow an arbitrary number of alternative values for each categorisation type.

The accurate categorisation of requirements is fundamental to the apportionment of responsibility for their successful implementation and, as such, must be a basis for the production of specialist requirements-related documentation (including requirements with specific value(s) for specific categories).

Following this the requirements ought to be formalised.

Once requirements have been categorised, they can be formalised. The formalisation of requirements means the identification and removal of:

• Ambiguity Imprecision Inconsistency Duplication

• Omission

For small to medium sized projects a certain amount of duplication and inconsistency can be directly removed from the requirements at this stage. This is achieved by domain specialists arbitrarily looking through the requirements in particular categories and using searches and the Project Glossary to locate problems.

The process requires a level of subjective decision which can lead to misunderstanding, especially on larger projects, where the decisions will probably be made by several people, each of whom will apply their own criteria to the classification process.

For larger projects there is a process of formalising the requirements by removing ambiguity and defining engineering requirements. Duplication and inconsistencies in the formalised requirements set are focused and split, and finally the source statements are cross referenced to requirements throughout the entire development lifecycle, allowing tracing to be possible.

Focusing and splitting requirements

This is the approach often regarded as the only option for larger requirements sets. It mimics the manual approach towards requirements engineering by producing successive revisions of the requirements set in which each revision contains the results of focusing and splitting the previous revision.

In a split operation, the text within a requirement is subdivided into lower-level, more detailed parts, each part being used as the content of a new requirement. The original requirement is typically marked

superseded. The resulting child requirements are then used as the basis for subsequent operations, typically focusing.

In a focus operation, the text of several requirements is combined together into a single requirement. The original requirements are typically marked superseded.

By such a sequence of focus and split operations, the original requirements captured from the customer's source documents are successively transformed into a requirements set for the system. The process stops when a subjective decision made by suitable project personnel says that it is complete. There is not a more formal metric.

This approach does, however, suffer from a number of drawbacks:

• Too much time is spent engineering the requirements instead of the system The requirements which result have lost all their contextual information As the categorisation of requirements results in their combination (prior to possible redivision), reorganisation of the requirements set on a different basis is difficult if not impossible The successive refinement creates myriad intermediate requirements and cross reference links to be maintained thereafter

• The lack of any direct correspondence between the final requirements and the original requirements captured from the customer's source documents means that compliancy checks between them are at best difficult and typically nearly impossible to maintain with adequate precision

The preferred approach is to split captured requirements only so as to produce a consistent level of detail between them. Thereafter, requirements are categorised which means assigning distinct values from an enumerated set for each alternate categorisation attribute. Several separate categorisations can be used simultaneously. This categorisation can be changed immediately by a change in any such value. The resulting categorisations are used to divide requirements into groups.

Each requirement group that can be dealt with in the analysis is focused by cross referencing individual requirements to the element(s) of the analysis model that satisfy the requirement. By examining all requirements related to each analysis, or at the appropriate time, design element in turn, omissions and contradictions can be easily determined.

This approach minimises the complexity of the requirements set and therefore the maintenance overhead of this requirements set, potentially the most volatile aspect of a project's database, as it evolves throughout the life of the project.

The approach ensures minimal distortion of the customer's source documents and therefore ensures that compliancy between the system and the requirements can be easily demonstrated.

Requirements must be traceable in three distinct respects:

• Back to the customer source statements Forwards into later parts of the project

• Internally within the requirements set to a greater or lesser extent as determined by the project's requirements engineering approach

This traceability requires that cross references exist which can be used to trace either forwards through the project or backwards through it.

Such tracing must be transitive such that links between individual items A and B, and B and C, allows item C to be immediately traceable from A even though there is no direct link between them. Without this capability, the number of direct links that must be created grows enormously.

Using such techniques in the underlying systems engineering toolset allows all of the customer source statements to be traced to the requirements set. There should be a complete coverage of the requirements set, so that no requirements exist which are not related to a customer source statement (this would be over-engineering the system). Also, no source statements should exist which are not traceable from one or more requirements (this is under-engineering the system).

Similar arguments apply to the requirements set and the deliverables from subsequent phases in the project. Each phase deliverables must completely cover the needs of the previous phase.