The requirement for an efficient requirement!

Requirements are the backbone of engineering, particularly defence acquisition projects. The success or failure of a project hinges on satisfying a number of requirements established at the early stages of the project. You will often hear systems engineers warn of the consequences of not taking the time to properly define requirements, and with good reason! Research identifies there is a 60% time and cost premium to be paid on projects with poor quality requirements [1].

The time afforded to define requirements in the defence sector is already constrained by project schedules and capability milestones. This constraint will tighten further based on the recommendations of the House of Commons Committee Special Report on The UK’s defence procurement system, which include the following statements:

·         “The Ministry of Defence must develop a much greater sense of urgency in its procurement methodologies”.

·         “There must be a much greater emphasis and value on time”.

This has been further reinforced by the Strategic Defence Review 2025, with statements including:

·         “Innovation and procurement measured in months not years”.

·         “The MOD to set itself up for success internally”.

This is embodied within the acquisition reform of the Integrated Procurement Model, committing to deliver equipment programmes in a maximum of five years and digital programmes in three. The Integrated Procurement Model also focusses on prioritising requirements under a “joined-up approach” across a defence-wide portfolio.

Synoptix are experienced in dealing with challenging deadlines in both design and acquisition project across defence and wider industries. This is supported by identifying common requirements across systems to improve requirement and verification efficiency.

Why does our approach need to change?

It is becoming clear, that to meet the changes in delivery timelines associated with the Integrated Procurement Model, the UK must review and update our acquisition approach. Already with the rapid procurement of equipment such as the Archer artillery platform, we have seen how processes designed for peacetime have been revolutionised to enable delivery at speed.

At the core of procurement is how we define and manage requirements, so shouldn’t we also be looking at improving the efficiency of our requirements approach?

In large organisations, there is already a tendency for requirements to be reused across multiple projects in an attempt to make the requirement definition process more efficient. Research[2] covering various sectors from 19 countries around the world suggests that up to 76% of requirement sets include the reuse of requirements at some level. Within the same research, the following normalised distribution of re-use techniques can be observed.

Figure 1 - Requirement Re-use Techniques

Figure 1 shows that the relatively simple process of “Copy & Paste” (with textual modifications) accounts for 53% of cases, with more sophisticated methods such as templates and requirement catalogues only accounting for less than 25%.

There are cases where copy and pasting requirements can be used effectively, in particular helping to maintain uniformity in requirement style between projects. However, this requires significant input from Systems Engineers and carries several risks such as:

·         Lack of applicability and context between projects leading to unnecessary or incorrect requirements.

·         Requirement issues unintentionally carried over between projects.

·         Localised re-use depends on the experience of the individual requirements engineer.

·         The assumption that if a requirement has been accepted previously, it is still correct and cannot be modified for fear of rejection.

·         Formatting issues, especially when working across multiple source formats and tools.

All of the above can be extremely costly, constrain innovation and result in projects failing. These risks are exacerbated when dealing with the duplication of a full specification; this also adds the false impression of a mature requirement set based on quantity, rather than quality of the requirements in context. For a new capability, it is rare for a requirement set to exist with enough coverage to justify duplicating the whole set. If this is the case, it is likely there will be a duplication of capability itself. 

There are steps toward a more defined approach starting to appear, notably in the Human Factors area, where a library of technical guides provide sets of subject matter expert pre-defined requirements, that can be extracted and tailored to specific projects.

Modular requirement libraries

A requirement library, also referred to as a requirement catalogue, consists of a database of template requirements split into individual subject areas. These are authored, validated and managed through life by Subject Matter Experts. Library modules offer the benefit of being centrally managed by SMEs who are the most qualified in their specific area, allowing for updates to be controlled and agreed once.

Figure 2 - Requirement Pattern Syntax with Tailoring Example

When implemented correctly, notification of these central updates can be distributed across impacted projects efficiently, through traceability links between the library and the individual project requirement sets.

It is recommended that the library requirements are structured as a pattern syntax (multiple options are available) which facilitates tailoring to the specific context of the individual projects whilst maintaining good core requirement writing principles.

Not only do requirement libraries decrease the time spent on writing requirements, but they also provide a baseline in terms of acceptance evidence expectations. With a centrally managed requirement, the type and level of evidence required to demonstrate compliance can be standardised across projects, with previously accepted evidence showing an example of what good looks like, avoiding issues regarding acceptance expectations and unscheduled evidence activities later in the project.

Similar to your local book library, not all requirements will be relevant to a given project. The intent is that a projects requirement engineer uses the justification and SME knowledge for the requirements in the library, along with the project context provided by architectures, use cases or operational analysis to select the relevant requirements and tailor appropriately. An example implementation is shown in Figure 3.   

Figure 3 - Requirement Library Implementation Example

There are several areas where requirement libraries could offer significant efficiencies, due to mandated justification, high level policy or similar operating procedure regardless of system. The following areas are highlighted as potential early adopters; however, this will vary by organisation and requires individual investigation before a solution can be progressed:

·         Legislation: A degree of legislation and certification will apply to all projects with limited variation in terminology.

·         Safety: All projects consider safety, with similar core requirements derived from policy and standards.

·         Human Factors: Systems that interact with humans follow defined guidelines, which already include pre-defined requirements as part of the documentation set.

The wider move towards modularity

The Strategic Defence Review also consolidates the wider direction towards modularity, with market segmentation for smarter procurement focussing on Major modular platforms and modular upgrades.

In areas of defence, particularly the land domain, this approach and future proofing is already underway with the use of modular multi role solutions such as the AJAX and Boxer families. The use of common requirements, supported by variant and role specific requirements, are essential to prevent undue repetition and ensure uniformity across the family whilst meeting the vast needs of the stakeholder groups.

Figure 4 - Boxer Armoured Vehicle Variants

As can be seen in Figure 3, the modular requirement library approach allows for a sub library of common requirements which as an example could be used for a multi role vehicle to increase commonality across variants. Not only does this improve the efficiency of requirement derivation, but efficiencies can also be realised in V&V due to similarities in evidence, and also for in service support through commonality in integrated logistic support.

Synoptix, as leaders in the Model Based Systems Engineering space, have identified and are also developing the concept of a modular architecture library. This builds on the similar concept of requirement libraries and offer parallel benefits around efficiency in architecture development. This will be explored further in a separate paper. The successful implementation of these two approaches together offers significant efficiencies to organisations that have projects sharing elements of commonality.

Supporting international capability partnerships

The Strategic Defence Review also highlights the importance of developing international capability partnerships. An ongoing key barrier to any successful partnership is differing needs and priorities. A functionality that one partner considers key to integrate with its wider force, the other may not desire and will not be willing to pay or trade off other functionality for its inclusion. Similarly, both partners may cover similar topics in mandated regulations, but will differ slightly due to specific national details.

In addition to using requirement libraries to realise efficiencies across projects within an organisation as depicted in Figure 3, they can also be applied across different organisations and nations. This concept is expressed through Figure 5, where a requirement specification is split into 3 main categories:

·         Common Nation Requirements: Both nations agree requirement is applicable to meet their needs and can align details.

·         Nation Tailored Requirements: Both nations agree requirement is applicable to meet their needs, however detail differ so each have a tailored version within their specification.

·         Nation Specific Requirements: Only one nation has a need for the requirement, whilst the other nation may benefit from the resulting end solution, there is no trace to a stakeholder need.

Figure 5 - Modular requirement structure approach to international partnerships

The intent is that common requirements should be maximised, whilst minimising specific requirements. This increases the value of the partnership by enabling the sharing of existing evidence, along with splitting the cost and facilitation of any additional testing and analysis required.

Caution must be advised though not to fixate on common requirements and force commonality when there is none, as with requirement libraries discussed earlier. External pressures may also impose a rose-tinted view of commonality, only for nation specific needs to emerge later once implementation nears. Support from experienced Systems Engineers is imperative to a successful implementation.

A similar approach can also be applied to product families within an organisation, in both defence or commercial industry. For example, variants within commercial aircraft such as the Airbus A320 single aisle family. A large portion of requirements remain common across the family, with variant specific requirements where specific needs exist.

Barriers to implementation

Whilst there are several benefits of requirement libraries, these are only realised once implemented, which can be a challenge in itself. To fully benefit, endorsement from a large part of an organisation (ideally the whole organisation) including senior management is required; as the principle revolves around sharing requirements across multiple projects.  This can pose additional difficulties where a lack of Systems Engineering understanding is present, especially around the theory of deferred gratification, as an appreciable level of effort is required to set up the libraries before they value is realised. At Synoptix we recognise first-hand the impact that stakeholder understanding has on the successful implementation of new processes, and have experience in bringing stakeholders together along a change journey.

A second key barrier to implementation is the availability of resource with the required knowledge to initially identify the opportunity to implement a requirement library, set up the structure within requirement management tools and subsequently provide support during the initial transition period. The systems engineers with this knowledge are likely in demand already to support key deliverables.  

Rising to the challenge

It is important to acknowledge that there are no single answers to bespoke problems, and the reader should not surmise that requirement libraries are a silver bullet. Key is recognising the degree of commonality across multiple projects, which justifies establishing a library set. Equally important is acknowledging where individual project requirements are more appropriate, without forcing a pre-defined set.  

With vast experience in requirements management across several sectors and industries, Synoptix are well positioned to provide support; whether this be specialist advice and guidance to existing Systems Engineering teams, to undertaking full design, implementation and support of requirement structures. This is supported by our expertise in requirements tools such as DOORS, Jama and Dimensions, which have enabled us to introduce processes and frameworks to support clients in successfully managing complex requirement sets across a range of systems and their variations, in cases of up to 13,000 requirements.

An important enabler to support requirement libraries is understanding the project context, to allow the correct tailoring of individual requirements. Synoptix have extensive expertise in MBSE, particularly in maritime defence, modelling how complex systems integrate and operate in the wider environment. This ensures engineering work undertaken is backed by robust methodology and processes that adhere to systems engineering best practices.

[1] IAG Consulting. (2023). Assessing the Impact of Poor Requirements on Companies

[2] Palomares, Cristina & Franch, Xavier & Quer, Carme. (2014). Requirements Reuse and Patterns: A Survey.