GUIDELINE & DISCUSSION DOCUMENT

SYSTEM REQUIREMENT AND DESIGN SPECIFICATIONS

FOR THE DEVELOPMENT OF SYSTEMS

1. PURPOSE OF GUIDELINE/ DISCUSSION DOCUMENT

This is a discussion document aimed at companies developing complex systems,
which are software driven. Typically the systems would have a mechanical design
with embedded electronics and software. The document also relates to systems
consisting of application software on computer networks.

There is generally an inconsistent understanding about what a ‘Requirement

Specification’ and what a ‘Design Specification’ consist of and how they relate to the
development process. This guideline document seeks to be a basis for discussion
and to establish a platform for a clearer understanding of the definitions and
principles. This guideline considers real-world situations.

Requirement Specifications and Design Specifications are important elements of any

Quality System for product development. As such, it is felt that it is imperative to
understand what the purpose of each of these styles of documents is and how they
relate to each other and the design process. How the documents are generated and
used also has a bearing on the economics of product development and more widely
on product development environments. This discussion area is therefore important.

In many Quality Systems there is reference to Requirement Specifications and

Design Specification. The implication is that there is a singular Requirement Spec
and Design Spec for each product developed. It is suggested that this is not an ideal
situation due to the complexity of systems being developed in many companies.
Actually, there is an issue with complexity in general and the fact that systems
normally consist of the following elements:
1. Mechanical design
2. Electronic design
3. Embedded software design
4. Applications/systems software design

The partitioning of the system into different development disciplines tends to suggest
that Requirements and Design Specifications should be partitioned in the same way.
Thus, the two specification documents might be partitioned not just by design level,
but also by the engineering discipline used. Furthermore, it can be useful to partition
the systems into various sub-systems or equipment types, each of which could have
a separate Requirement Specification and Design Specification.

ISSUE v2 Page 1 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
2. SOME MAJOR QUESTIONS TO BE ADDRESSED
There are a few key questions, which should be addressed by this discussion. These
include:
1. What is a Requirement Specification, exactly?
2. What is a Design Specification, and how does it differ from a Requirement
Specification?
3. Are the specifications really necessary or are they an overhead we could do
without?
4. What value do the documents have?
5. How do specifications fit in with the design process and design reviews?
6. What is the purpose of the specifications, or do they have multiple purposes?

The last question is quite important, because unless we understand the true purpose
and value of a document it becomes difficult to (i) develop an optimal solution in
terms of document structure and content, and (ii) judge whether the resultant
document is adequate or not.

3. THE PURPOSE OF THE REQUIREMENT AND DESIGN SPECIFICATIONS

3.1 Overview
One can think of the Requirements Specification as the first ‘view’ of the product
design, since it describes what the product is required to do. A Requirement
Specification, in its purest sense, does not normally describe how the product will
implement the requirements. This is more the job of the Design Specification.

The purpose of the Requirements and Design Specifications is not to satisfy the
needs of the Quality System. The Quality System is our slave and not vice versa!
Many engineers and scientists may hold the view that such specifications are simply
overheads and are only reluctantly produced because the Quality System says so.

A Requirement Specification, again in its purest form, is a black box representation of

the product. It tells what the product or system must do functionally, and what its
performance and properties must be or should be. The document does not tell us
how the requirements are implemented by design, unless there is a very strong need
to do so,

3.2 Purposes of a Requirement Specification

3.2.1 Does the Requirement Specification originate purely from the customer?
A simplified view of a Requirements Specification is that it is a document prepared by
a customer, which we must satisfy to achieve ‘quality’ and fulfill our contractual
obligations to that customer. This statement, in many situations is mainly correct. If
we were a company that only made bespoke products and no standard products this
may to a large extent hold true. On the other hand, we can have standard products,
which are often termed, ‘COTS’, or ‘Customer Off-The-Shelf’, products. In this case,
we supply an existing product without modification and there may be no Requirement
Specification from the particular customer.

ISSUE v2 Page 2 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
So the two extremes are (i) purely new customer product unlike any other product we
have ever developed and (ii) standard product, developed for a more general market
or perhaps a market sector. In practice though, it is rare that we get these two
extremes. Often customers request a variation or customisation of an existing
product. Alternatively, we might accept a customer order for a new product, but to
use the opportunity to develop a more general, standard product. Thus, a true
Requirement Specification, if fully defined, would rarely originate exclusively from
either a single customer or on the other hand exclusively from our own definition.

The various situations can be depicted in Fig. 1, below.

Customer Our
requirements Requirements requirements
definition definition

Bespoke Product
Situation

Customer Our
requirements Requirements requirements
definition definition

Hybrid Situation

Our
Customer
requirements
requirements Requirements
definition
definition

Standard Product
Development Situation

Fig. 1 Defining the balance of requirements definition for different situations

In summary, in many cases the requirements for a product is some sort of balance
between internal and external needs. We should also bear in mind that even if a
product is heavily balanced towards the needs of a specific customer, that customer
product could eventually become the basis of a future standard product. It is also
likely for a new customer product, that sub-systems, such as mechanical parts, PCB
designs and code may be used in other future designs.

These considerations tend to put the whole subject of requirements management in a

new light, and emphasises the importance of having a clear and well-reviewed set of

ISSUE v2 Page 3 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
requirements. To summarise, requirements definition should be a balance between
internal and external needs, and requirements documentation can have value long
after a product is shipped to a specific customer.

3.2.2 Requirements Capture

The requirements capture process is the process by which sources of requirements
are reviewed and requirements are articulated into a structured list. A convenient
form for the list can be a table. Sources of requirements can include:
1. Requirements specification formally submitted by the customer
2. Internal requirements review or augmentation
3. Face to face discussion with the customer
4. Telephone conversations
5. E-mail on specific requirements issues
6. Extraction from standards, which are referenced by the specification

It can be important in the requirements capture process to record or to reference the

source of the requirement.

In the case of a bespoke product definition, we would hope to receive the customer
requirements in a well-structured and definitive list. This is not always the case, and
often the requirements might be vague and indefinite. There may be some work in
reading through the specification and transposing it into a definitive list, which can
then be assessed in terms of technical feasibility and implementation effort.

It is good practice in a specification to differentiate the individual requirements

between an ‘absolute must’ and a ‘desire’. It is common practice to use, ‘Shall’ and
‘Should’ to define the relative product needs. An alternative requirements
classification system is the ‘MoSCoW’ system. The letters refer to:

M: Must have

S: Should have

C: Could have

W: Would like to have

It should be appreciated that the definition of a product may not be complete at the
initial point of definition. It is not uncommon for the requirements to evolve over time,
based on a number of circumstances. Some examples might include:
1. Some key requirements are not identified by the customer, but are identified
by us and should be added
2. The customer realises midway through the development that requirements
have been missed
3. Feasibility checks of certain requirements might come up with a negative
result
4. During the design process, whether at a high-level or intermediate level may
identify opportunities to improve or augment the requirements
5. During the design process, whether at a high-level or intermediate level may
identify blocking problems, which means the requirements originally defined
cannot be met, are impractical or would cost too much time and money. This
normally requires the approval of a waiver on requirements

ISSUE v2 Page 4 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
 6. The test definition process reveals that some aspects of performance or
functionality have actually been missed in the original requirements.
7. Some requirements were found unnecessary and can be dropped

3.2.3 The Requirements Review Process

It is good practice to carry out a formal review of the requirements documents.
Initially, several questions should be asked:
1. Is the Requirement Specification understandable?
2. Do the requirements need to be elaborated into a definitive structured list?
3. Is the definition comprehensive or does it need to be expanded?
4. Are some requirements loosely defined?
5. Are some requirements an over-kill for the application?
6. Are any items not feasible from the outset?
7. Are there specific items which would cause:
a. Significant cost impact?
b. Significant schedule impact?
c. Resourcing problems?
d. A significant know-how challenge?
e. A supply chain risk?
f. A technical risk?
g. A health and safety risk?
8. Are feasibility studies required to verify that we can achieve it?
9. Are some requirements not needed for the application in mind?
10. Are performance requirements unreasonable in some areas?
11. Do some requirements create significant uncertainty because they necessitate
new technology or design solutions?

Some of these questions may only find answers if the high-level system design has
been complete! The trick is to identify the difficulty, risk or challenge as early as
possible, and if necessary negotiate with the customer. As indicated, further analysis,
high-level design or feasibility studies might be necessary for specific requirements.

Some of the requirements may be deemed too expensive, too risky or will
significantly affect the delivery schedule. Negotiation with the customer may result in
the requirement being left out or changed into something more achievable.

3.2.4 Requirements Compliance Matrix

The compliance matrix can be developed from the requirements list, which results
from the requirements capture process. If the requirements are already in tabular
form then the table can have some columns added to state how the requirement has
been verified, a reference to the test results, if applicable, and the current status of
verification. Such a table is a Compliance Matrix and testifies that the finished
product complies with the target requirements. Each requirement should have a
response to say whether it is verified, how and where. This is a requirement of an
ISO9001 based Quality Management System.

A Requirement Specification document can be either written as a readable and

flowing document or in fact as a Requirements Matrix. Easy handling of the

ISSUE v2 Page 5 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
requirements is facilitated if the matrix is implemented on a spreadsheet such as an
Excel document.

3.3 The Purpose of a Design Specification

3.3.1 Key Aspects of a Design Specification
A Design Specification describes how a ‘design entity’ is designed. A design entity
could be the entire system or a sub-system. However, a product’s system design
could be realised by several hierarchical layers or, alternatively, into sub-systems
representing mechanical, electronic or software sub-systems. Thus a design entity
could exist at any level in that design hierarchy. If the design entity being described is
the whole system, then the term System Design Specification can be used. The most
common occurrence in most organisations is a two-layer design implementation
based on hierachy.

A design entity would normally be one of (i) mechanical (ii) electronic (iii) software
element if below the system level, or possibly some combination of these. Design
Specifications in general could be initiated in the early stages of a design, but may
not be completed until the design was complete and tested. The Design Specification
should complement the design data itself. Such design data may be drawings in the
case of mechanical systems, PCB design for electronics or code in the case of
software.

The following areas should ideally be covered within a Design Specification:

1. Response to Requirements
The design should have been done in response to requirements. That is, the
means of implementing the required function is described. This should be
included in the description. One way of doing this is by numerical cross-
referencing. There should be traceability in the description. This should
facilitate the design review process. Design reviews are critical to achieving
quality in product development and are an integral part of a Quality
Management System, such as defined by those defined by ISO9001.

2. Overview of What the Design Consists of

The Design Specification should give the reader a rapid orientation to the entity
being described. This should outline the key components used in the design.
These may have been internally produced or bought in. The description should
give the reader a reasonable orientation to the design. The rationale behind
key design choices should be explained, if this is deemed helpful to the
maintenance of the product or future adaptation of the design. A part or a
solution may be chosen because:
1. It has low cost
2. It has the desired performance characteristics
3. Its size
4. Its reliability
5. Its availability
6. Its features

ISSUE v2 Page 6 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
 7. Some other constraints

3. Size, Dimensional Definitions or Capacity

This is part of the specification of the design entity and should help its
integration into a larger system. This information may be included in released
drawings, so only key dimensions may be needed. For a software element the
programme memory capacity may be specified.

4. Important Characteristics, Properties and Capabilities.

During the design process the design entity may have had some target
characteristics and properties. These may have been tested and verified during
the final development stages. Ideally, these key attributes should be outlined.

5. Interface Definitions
There may be a number of interface signals or connections to the design entity.
These should be described. Interfaces may also have mechanical definitions if
the design entity is physical. The interface could also be software data
structures in the case of software, or electrical signal definitions in the case of
electronics. These definitions facilitate verification that the interfaces are correct
from a system perspective. The definitions are essential for maintainability and
future adaptation of the design.

6. Outline of Key Design Decisions

In conceiving the design solution the developer may have made key design
decisions as to how the design was implemented. Decisions may have been
based on (i) stated or un-stated constraints, (ii) performance or functional
requirements (iii) design for test (iv) design for manufacture (v) cost (vi)
component availability or some other reason. The key design choices should
be documented. This should help design review product maintainability and
product design adaptation. It is naturally good practice for the design engineer
to make design notes, which include such design decisions as the design
progresses.

7. Information, Which Makes the Design Easier to Debug, Upgrade, Fix or

Adapt.
Some of this will have been covered above, but supplementary information in
this area will almost certainly be beneficial. The developer should assume that
an engineer other than the original designer is performing these tasks.

8. Statement of Design Intent

When designing the system there may have been important aims or intents in
his mind while designing the part of the system. Some intentions might include
considerations, such as:
 Mechanical fit
 Leak tightness
 Operating power
 Operating speed
 Data bandwidth

ISSUE v2 Page 7 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
  Upgradeability
 Design for EMC
 Design for easy assembly
 Design for test
 Mechanical hardness or robustness
Including such information can help with the maintainability of the product or
sub-system. Indeed attempting to maintain a design without this information
may lead to significantly detrimental effects without the maintainer realising it.

3.3.2 The benefits of having a Design Specification

There are several advantages to be gained from developing a Design Specification:
1. It describes how the product’s requirements are to be met (this facilitates the
Design Review process and conversely the absence of a Design Specification
undermines the Design Review process).
2. It enables engineers other than the designer to get a rapid overview of the
design
3. It can facilitate the definition of test cases and targets
4. It enables us to develop ‘stress-tests’ to test the design element’s robustness
5. It allows the design to be upgraded easily
6. It allows the design entity to be designed into a related system with a higher
degree of confidence and with less time-consuming analysis
7. It facilitates design adaptation and improves design re-use potential – this can
improve the general economics of a development environment.

To what extent should a design entity be described by a Design Specification

document? One can clearly either produce a minimalistic or an extensive version of
the Design Specification. Perhaps the following questions can be posed when
making the decision:
1. How easy is it for another engineer to understand the design without a Design
Specification?
2. If needing to upgrade or adapt the design, how easy would it be for another
engineer and what essential information would be useful in this process?
3. To what extent might the design entity be re-used in other products?
a. Often elements of a product design have substantial re-use potential
4. What is the likely commercial importance of the product?

The extent of the Design Spec generally has diminishing value as the level of
description becomes progressively more detailed. The diagram in Fig. 2 can illustrate
this situation

ISSUE v2 Page 8 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
 Value
Gained

Level of detail

Fig 2. Diminishing value as specification detail progresses

In other words, even a brief overview of design documentation can be extremely

valuable. In a situation where the time or resource level is constrained, it is sensible
to ‘time-box’ the effort allocated to the Design Specification document to ensure that
the essential design information is covered first. This approach utilises Pareto’s 80:20
principle. Another scenario or suggested approach is where a design specification
outline is started under a time-pressured situation, but fleshed out at some later date.

A point worth mentioning here is that the quality of overall design documentation can
be enhanced by the presence and quality of notes and comments, which are added
to the design data itself:
1. Mechanical drawings – notes added to the drawing
2. PCB design – comments added to schematics
3. Software – comment added to code lines, blocks of text for explanation and
code procedure and function headers

3.3.3 The Essential Difference between a Requirement Specification and a

Design Specification
It is quite important to understand the key differences between a Requirement
Specification and a Design Specification. One of the confusions that commonly arise
is that hybrid documents can be created, which integrate both requirements and
some design definition. This situation is often allowable and helpful for design
development purposes, so long as the understanding of the differences is
maintained.

Essentially, a Requirement Specification assumes the design is not yet done and
describes what the design should do and what attributes or performance levels it
should achieve. These requirements are often describes as:
1. Functionality

ISSUE v2 Page 9 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
 2. Physical attributes
3. Capability
4. Properties or attributes

Assuming the product is an entirely new design, the requirements assume that the
design is a ‘black box’, where few or no design decisions have been taken. This is a
Requirement Specification in its purest form. The reality might be a little different. For
example, some of the design implementation decisions may be entirely obvious. In
other cases, if the new product is a variant of an existing product then part of the
design may already exist.

A Design Specification essentially defines how a system or an element in the system

was designed and complements the design data itself. The Design Specification
identifies key design elements, defines a structure and the inter-relationships
between the design elements. Ideally the functionality of the key design elements
should also be described. Additionally, design choices should be described as well
as design intent. Examples of ‘design intent’ might be:

Speed of processing

Upgradability

Ease of assembly

Testability

The slight confusion here is that system design is often a progressive process of
elaboration and design is conventionally done top-down. At an interim design stage
often the high-level design is defined, whereas the lower level design has yet to be
carried out. This can often result in a high-level Design Specification, which can be
termed a ‘System Design Specification’. Often this has to be completed before the
lower level design takes place. As the design of the whole system progresses, the
Design Specification or suite of Design Specifications can evolve though time.

Often we might come across specifications, which integrate the system requirements
and the high-level design definition. Such a document can be very useful to drive
lower-level design, but the difference between the requirements and the design
definitions should be understood.

4. PARTIONING THE SYSTEM AND DEVELOPMENT FLOW

Often systems are large and complex and require several engineering disciplines to
realise the product design. It is therefore natural to partition the system design in any
the following ways:
1. Hierarchically
2. Distinct physical sub-systems
3. Sub-systems relevant to engineering discipline – mechanical, electronic,
software

A key reason for partitioning the system can be that the development effort is split or
carried out by different groups and different individuals. Thus, the system design is

ISSUE v2 Page 10 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
partitioned to facilitate and to allocate the development activity. If a group or
individual is assigned the development of a sub-system they obviously need to have
a formal definition of what is required for that sub-system. This definition can take the
form of a Requirement Specification for that sub-system in the case that the higher-
level design decisions are open. If the higher-level design of the sub-system can
already be elaborated at the point of sub-project allocation, then a higher-level
Design Specification document for that sub-system can be used. In many cases, it
may be sensible for the various disciplines to write the sub-system Requirement
Specification based on their interpretation and then get this document agreed. This
sub-system Requirement Specification should include a definition of the interface
between the sub-system and the rest of the system. This definition may incorporate
physical, electrical and logical (signal) definitions.

Note that it is likely and logical that interim Design Reviews should ideally take place
on the sub-systems, which are given out to the various development parties. In the
review process the actual design should be compared with the appropriate
Requirement Specification and Design Specification documents. Part of the review
should include a review of the completeness and appropriateness of the
documentation as well as the review of the design itself. When a PCB was defined
and given to an engineer to develop there should be an accompanying Requirements
Specification at the start of development, which may be a part of a System Design
Specification or a standalone document, plus a Design Specification document,
which is produced by the engineer towards completion of the design.

5. STRUCTURING OF THE SPECIFICATION DOCUMENTS

As discussed in Section 4, the development process tends to occur in a top-down
fashion. As the high-level system design is split into sub-systems, the appropriate
documentation for those sub-systems should be drawn up. Again, this documentation
can take the form of Requirement Specification or higher-level Design Specification
as appropriate. The structure of the specification documentation therefore tends to
mirror the natural development flow.

In the two diagrams below, two variations of design documentation are shown. In Fig.
3, the first variation shows the case, where the sub-system higher-level design
decisions are open. Fig. 4 shows the case where the higher-level design decisions
are already defined. In this second variation, the development team for the sub-
system are required to elaborate the design implementation. When this design work
is completed, the Design Specification documentation for the sub-system should be
upgraded from the initial high-level description. This upgrade enables the sub-system
to be reviewed and makes it more maintainable and also re-usable in other systems.

ISSUE v2 Page 11 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
 (High-Level) System
High Level
Requirement Specification

Variation 1

(High-Level) System Design

Specification
Intermediate Level
Mechanical Electronic Embedded SW Application SW
Req Spec Req Spec Req Spec Req Spec

Detailed Level

Mechanical Electronic Application

Mechnical Electronic Embedded SW Embedded Application SW
Design Design SW Design
Design Design Design SW Spec Design
Spec Spec Spec

Drawings OrCad Schematics, Code Code

layout, BOMs, MIF,
etc

Fig 3. Variation 1, where the sub-system design is open to definition by the sub-
system development team.

(High-Level) System
High Level
Requirement Specification

Variation 2

(High-Level) System Design

Specification
High-Level High-Level High-Level High-Level Intermediate Level
Mechanical Electronic Embedded SW Application SW
Design Spec Design Spec Design Spec Design Spec

Detailed Level

Mechanical Electronic Application

Mechnical Electronic Embedded SW Embedded Application SW
Design Design SW Design
Design Design Design SW Spec Design
Spec Spec Spec

Drawings OrCad Schematics, Code Code

layout, BOMs, MIF,
etc

Fig.4. Variation 2, where the sub-system design has already been defined at the
high-level.

In conclusion, the structure of the Requirements and Design Specification suite will
depend on the complexity of the overall system, and how that system is developed.
Thus, the documentation structure is project specific and to a large extent reflects the
design structure. It is also likely that the design review process should reflect the
design structure. Sub-system Design Reviews should occur at the appropriate time
and should include both interim and final reviews for that sub-system. The sub-

ISSUE v2 Page 12 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
system Design Review would naturally precede the Final Design Review for the
overall system.

6. SHOULD REQUIREMENTS AND DESIGN SPECIFICATIONS BE DONE

RETROSPECTIVELY?
It is sometimes the case that the commercial approval for a product development
start comes very late relative to the required delivery date. In such cases skipping
some proper development process steps is tempting. If the schedule pressure for the
deliverable is so intense that some aspects of specification are skipped during the
development process, once the product is shipped, should the specification gaps be
filled retrospectively?

We should revisit the fundamental reasons we use specification documentation:

1. To help drive the development process
2. To help partition the development work
3. To enable Design Review and ultimately design certification
4. To enable the generation of test plans, test definitions and test data
5. To enable the system or sub-systems to be maintained, debugged and
upgraded
6. To enable design re-use in other systems

Clearly, it is preferable to do the Requirement Specification and if helpful a System

Design Specification prior to the development process itself. However, as is often the
case, resources may be in short supply and schedule pressures may necessitate a
hasty or even a ‘crash’ development process. Obviously, in a highly pressurised
situation it is better to do at least a skeleton specification definition than no
specification documentation at all. If we take the case that the product design is
‘completed’ and the product appears to be ‘working’ and is shipped, do we complete
the Requirements Specification and Design Specification documents?

It is also worth commenting here that attempting to ‘crash’ the development process
by skipping certain specification steps is normally very hazardous both in terms of
creating an inefficient development flow and in terms of ending up with a product
unsuitable for its intended purpose.

Let us consider the desire for design or product certification. A prerequisite of design
certification is the successful completion of Design Reviews for both the defined sub-
systems and the overall system. Reviews require the existence of Requirement
Specifications and Design Specifications for the design entity being reviewed. If the
documentation is missing it is difficult to conduct the review. In fact the review should
also be checking that the specification documentation is appropriate and complete.

Next, let us consider maintainability of the system. Are we confident that the system
has been fully tested and debugged? This situation would be rare. Given that the
Requirement Specification may be lacking, the test plan and test data is also
probably lacking. In any case, it will be difficult to isolate and eradicate problems,
which are reported in the field.

ISSUE v2 Page 13 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
What about design for reuse? Is it not the case that the bulk of development work
carried out in the organisation is based on the design of previous systems? If in a
new product design we are importing mechanical, electronic or software sub-systems
from previously designed products the existence of appropriate requirements and
design specification documentation is invaluable. Without this we need to go into
reverse-engineering mode, which is difficult from the cost, resource and schedule
perspectives.

There may be some specialised cases where the product developed is a one-off, is
well tested and is never likely to be re-used for anything else. These cases are rare.

There are a few problems frequently encountered by project managers, when

charged with conducting a new development:

Problem 1:
The new design uses parts and sub-systems from previous systems. These existing
sub-systems are lacking in Requirements Specification and Design Specification. The
work then becomes more difficult, hazardous and expensive.

Problem 2:
There is lack of time to develop adequate specification documentation at the
beginning. In this case, steps should be taken to avoid jumping straight into the
development process. It takes a certain amount of discipline to do this.

Problem 3:
After shipping the product, the funding for the project is closed off and the resources
are re-assigned to new exciting or pressing projects. It is difficult or impossible to
retrospectively fill the specification gaps.

Having ‘completed’ the product development, we move onto the next project and
encounter Problems 1 to 3 once more. The cycle is in danger of repeating itself. We
should of course fight against this situation. It helps a great deal if key stakeholders in
the development process such as Project Managers, Programme Managers, R&D
Management, Group Leaders, Design Engineers, Scientists and Quality personnel all
understand the purpose and value of specification documentation to the overall
economics of developing new and leading-edge products.

7. PRODUCT PORTFOLIO STRATEGY

It is quite common in companies that an initial product is developed either for a

specific customer or a target market segment, then variants of the product are
subsequently required or requested. The customisation requirement could either be
derived from the company themselves as a product push strategy or from a customer
or group of customers who request particular features or product attributes. This may
cause a product ‘branch’ to develop. The product variant may well be similar to the

ISSUE v2 Page 14 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
core product and may use many of the same design elements and satisfy similar
requirements. The situation is depicted in Fig. 5 below.

Fig. 5 Branching of products due to customisation requirements

Product development decisions need to be taken as the need for customisations and
variants arise. Do we add the customisation features to the core product or allow a
branch to develop? The decisions have implications for regression testing, overall
test strategy and field maintenance.

In the case that a branch is made due to a particular customer need, the customer
may present a customisation requirement. This can be thought of as a ‘Difference
Specification’ or a ‘Delta Specification’. What should happen is the Requirements
Matrix for the Core Product is copied and modified, usually by adding feature
requirements to the matrix. The adapted matrix can be then be used to develop the
test plan and test cases ready for validation of the customised product. In the case
that the original Requirements Matrix has not been produced, then full qualification of
the custom product is not feasible.

In some cases products can evolve incrementally without the full requirements being
documented and managed. This naturally causes a problem when attempting to
validate and qualify new products and a certain amount of back-tracking may be
necessary. This scenario is shown in Fig.6 below.

This scenario can be also cover the situation where an absolute need to fully validate
the product arises because the new variant is needed for a large, strategic customer.
More generally, a company can make a stern commitment to upgrade overall product
quality. In either case effort is required to develop the full Requirements Matrix
retrospectively.

ISSUE v2 Page 15 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.
In the situation shown in Fig.6, in order to fully validate and qualify the product, the
absent Requirements Matrix would need to be developed, then the feature in the
three Delta Specifications would need to be added.

Fig.6 Product propagation without full requirements management.

ISSUE v2 Page 16 of 16
© Oxford Management Solutions Ltd 2010. All rights reserved.