system requirements and design specification guideline v2

8/8/2019 System Requirements and Design Specification Guideline v2

http://slidepdf.com/reader/full/system-requirements-and-design-specification-guideline-v2 1/16

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

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 designwith embedded electronics and software. The document also relates to systemsconsisting of application software on computer networks.

There is generally an inconsistent understanding about what a ‘RequirementSpecification’ and what a ‘Design Specification’ consist of and how they relate to the

development process. This guideline document seeks to be a basis for discussionand to establish a platform for a clearer understanding of the definitions andprinciples. This guideline considers real-world situations.

Requirement Specifications and Design Specifications are important elements of anyQuality System for product development. As such, it is felt that it is imperative tounderstand what the purpose of each of these styles of documents is and how theyrelate to each other and the design process. How the documents are generated andused also has a bearing on the economics of product development and more widelyon 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 Specand Design Spec for each product developed. It is suggested that this is not an idealsituation due to the complexity of systems being developed in many companies.Actually, there is an issue with complexity in general and the fact that systemsnormally consist of the following elements:

1. Mechanical design2. Electronic design3. Embedded software design4. Applications/systems software design

The partitioning of the system into different development disciplines tends to suggestthat 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 partitionthe systems into various sub-systems or equipment types, each of which could havea separate Requirement Specification and Design Specification.




2. SOME MAJOR QUESTIONS TO BE ADDRESSED

There are a few key questions, which should be addressed by this discussion. Theseinclude:

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 purposeand value of a document it becomes difficult to (i) develop an optimal solution interms of document structure and content, and (ii) judge whether the resultantdocument is adequate or not.

3. THE PURPOSE OF THE REQUIREMENT AND DESIGN SPECIFICATIONS

3.1 OverviewOne can think of the Requirements Specification as the first ‘view’ of the productdesign, since it describes what the product is required to do. A RequirementSpecification, in its purest sense, does not normally describe how the product willimplement the requirements. This is more the job of the Design Specification.

The purpose of the Requirements and Design Specifications is not to satisfy theneeds 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 simplyoverheads and are only reluctantly produced because the Quality System says so.

A Requirement Specification, again in its purest form, is a black box representation ofthe product. It tells what the product or system must do functionally, and what itsperformance and properties must be or should be. The document does not tell ushow the requirements are implemented by design, unless there is a very strong needto 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 bya customer, which we must satisfy to achieve ‘quality’ and fulfill our contractualobligations to that customer. This statement, in many situations is mainly correct. Ifwe were a company that only made bespoke products and no standard products thismay 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 RequirementSpecification from the particular customer.




So the two extremes are (i) purely new customer product unlike any other product wehave ever developed and (ii) standard product, developed for a more general marketor perhaps a market sector. In practice though, it is rare that we get these twoextremes. Often customers request a variation or customisation of an existingproduct. 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 trueRequirement Specification, if fully defined, would rarely originate exclusively fromeither a single customer or on the other hand exclusively from our own definition.

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

Requirements

Requirements

Requirements

Bespoke ProductSituation

Standard ProductDevelopment Situation

Hybrid Situation

Customerrequirements

definition

Customer

requirementsdefinition

Customerrequirements

definition

Our

requirementsdefinition

Ourrequirements

definition

Ourrequirements

definition

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 aproduct is heavily balanced towards the needs of a specific customer, that customerproduct could eventually become the basis of a future standard product. It is alsolikely for a new customer product, that sub-systems, such as mechanical parts, PCBdesigns and code may be used in other future designs.

These considerations tend to put the whole subject of requirements management in anew light, and emphasises the importance of having a clear and well-reviewed set of




requirements. To summarise, requirements definition should be a balance betweeninternal and external needs, and requirements documentation can have value longafter a product is shipped to a specific customer.

3.2.2 Requirements Capture

The requirements capture process is the process by which sources of requirementsare reviewed and requirements are articulated into a structured list. A convenientform for the list can be a table. Sources of requirements can include:

1. Requirements specification formally submitted by the customer2. Internal requirements review or augmentation3. Face to face discussion with the customer4. Telephone conversations5. E-mail on specific requirements issues6. Extraction from standards, which are referenced by the specification

It can be important in the requirements capture process to record or to reference thesource of the requirement.

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

It is good practice in a specification to differentiate the individual requirementsbetween an ‘absolute must’ and a ‘desire’. It is common practice to use, ‘Shall’ and‘Should’ to define the relative product needs. An alternative requirementsclassification 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 theinitial 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 identifiedby us and should be added

2. The customer realises midway through the development that requirementshave been missed

3. Feasibility checks of certain requirements might come up with a negative

result4. During the design process, whether at a high-level or intermediate level may

identify opportunities to improve or augment the requirements5. During the design process, whether at a high-level or intermediate level may

identify blocking problems, which means the requirements originally definedcannot be met, are impractical or would cost too much time and money. Thisnormally requires the approval of a waiver on requirements




6. The test definition process reveals that some aspects of performance orfunctionality 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 hasbeen 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 willsignificantly affect the delivery schedule. Negotiation with the customer may result inthe 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 resultsfrom the requirements capture process. If the requirements are already in tabularform then the table can have some columns added to state how the requirement hasbeen 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 finishedproduct complies with the target requirements. Each requirement should have aresponse to say whether it is verified, how and where. This is a requirement of anISO9001 based Quality Management System.

A Requirement Specification document can be either written as a readable andflowing document or in fact as a Requirements Matrix. Easy handling of the




requirements is facilitated if the matrix is implemented on a spreadsheet such as anExcel 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 entitycould be the entire system or a sub-system. However, a product’s system designcould be realised by several hierarchical layers or, alternatively, into sub-systemsrepresenting mechanical, electronic or software sub-systems. Thus a design entitycould exist at any level in that design hierarchy. If the design entity being described isthe whole system, then the term System Design Specification can be used. The mostcommon occurrence in most organisations is a two-layer design implementationbased on hierachy.

A design entity would normally be one of (i) mechanical (ii) electronic (iii) softwareelement 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 maynot be completed until the design was complete and tested. The Design Specificationshould complement the design data itself. Such design data may be drawings in thecase of mechanical systems, PCB design for electronics or code in the case ofsoftware.

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

1. Response to RequirementsThe design should have been done in response to requirements. That is, themeans of implementing the required function is described. This should beincluded in the description. One way of doing this is by numerical cross-

referencing. There should be traceability in the description. This shouldfacilitate the design review process. Design reviews are critical to achievingquality in product development and are an integral part of a QualityManagement System, such as defined by those defined by ISO9001.

2. Overview of What the Design Consists ofThe Design Specification should give the reader a rapid orientation to the entitybeing described. This should outline the key components used in the design.These may have been internally produced or bought in. The description shouldgive the reader a reasonable orientation to the design. The rationale behindkey design choices should be explained, if this is deemed helpful to themaintenance of the product or future adaptation of the design. A part or a

solution may be chosen because:1. It has low cost2. It has the desired performance characteristics3. Its size4. Its reliability5. Its availability6. Its features




7. Some other constraints

3. Size, Dimensional Definitions or CapacityThis is part of the specification of the design entity and should help itsintegration into a larger system. This information may be included in released

drawings, so only key dimensions may be needed. For a software element theprogramme memory capacity may be specified.

4. Important Characteristics, Properties and Capabilities.During the design process the design entity may have had some targetcharacteristics and properties. These may have been tested and verified duringthe final development stages. Ideally, these key attributes should be outlined.

5. Interface DefinitionsThere may be a number of interface signals or connections to the design entity.These should be described. Interfaces may also have mechanical definitions ifthe design entity is physical. The interface could also be software data

structures in the case of software, or electrical signal definitions in the case ofelectronics. These definitions facilitate verification that the interfaces are correctfrom a system perspective. The definitions are essential for maintainability andfuture adaptation of the design.

6. Outline of Key Design DecisionsIn conceiving the design solution the developer may have made key designdecisions as to how the design was implemented. Decisions may have beenbased on (i) stated or un-stated constraints, (ii) performance or functionalrequirements (iii) design for test (iv) design for manufacture (v) cost (vi)component availability or some other reason. The key design choices shouldbe documented. This should help design review product maintainability and

product design adaptation. It is naturally good practice for the design engineerto make design notes, which include such design decisions as the designprogresses.

7. Information, Which Makes the Design Easier to Debug, Upgrade, Fix orAdapt.Some of this will have been covered above, but supplementary information inthis area will almost certainly be beneficial. The developer should assume thatan engineer other than the original designer is performing these tasks.

8. Statement of Design IntentWhen designing the system there may have been important aims or intents in

his mind while designing the part of the system. Some intentions might includeconsiderations, such as:

Mechanical fit Leak tightness Operating power Operating speed Data bandwidth




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 orsub-system. Indeed attempting to maintain a design without this informationmay lead to significantly detrimental effects without the maintainer realising it.

3.3.2 The benefits of having a Design SpecificationThere 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 theDesign Review process and conversely the absence of a Design Specificationundermines the Design Review process).

2. It enables engineers other than the designer to get a rapid overview of thedesign

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 robustness5. It allows the design to be upgraded easily6. It allows the design entity to be designed into a related system with a higher

degree of confidence and with less time-consuming analysis7. 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 Specificationdocument? One can clearly either produce a minimalistic or an extensive version ofthe Design Specification. Perhaps the following questions can be posed whenmaking 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 potential4. What is the likely commercial importance of the product?

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




ValueGained

Level of detail

Fig 2. Diminishing value as specification detail progresses

In other words, even a brief overview of design documentation can be extremelyvaluable. In a situation where the time or resource level is constrained, it is sensibleto ‘time-box’ the effort allocated to the Design Specification document to ensure thatthe essential design information is covered first. This approach utilises Pareto’s 80:20principle. Another scenario or suggested approach is where a design specificationoutline 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 canbe enhanced by the presence and quality of notes and comments, which are addedto the design data itself:

1. Mechanical drawings – notes added to the drawing2. PCB design – comments added to schematics3. 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 RequirementSpecification and a Design Specification. One of the confusions that commonly ariseis that hybrid documents can be created, which integrate both requirements andsome design definition. This situation is often allowable and helpful for designdevelopment purposes, so long as the understanding of the differences ismaintained.

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

1. Functionality




2. Physical attributes3. Capability4. 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 aRequirement Specification in its purest form. The reality might be a little different. Forexample, some of the design implementation decisions may be entirely obvious. Inother cases, if the new product is a variant of an existing product then part of thedesign may already exist.

A Design Specification essentially defines how a system or an element in the systemwas designed and complements the design data itself. The Design Specificationidentifies key design elements, defines a structure and the inter-relationshipsbetween the design elements. Ideally the functionality of the key design elementsshould also be described. Additionally, design choices should be described as wellas 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 ofelaboration and design is conventionally done top-down. At an interim design stageoften the high-level design is defined, whereas the lower level design has yet to becarried out. This can often result in a high-level Design Specification, which can betermed a ‘System Design Specification’. Often this has to be completed before thelower level design takes place. As the design of the whole system progresses, theDesign Specification or suite of Design Specifications can evolve though time.

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

4. PARTIONING THE SYSTEM AND DEVELOPMENT FLOW

Often systems are large and complex and require several engineering disciplines torealise the product design. It is therefore natural to partition the system design in anythe following ways:

1. Hierarchically2. Distinct physical sub-systems3. Sub-systems relevant to engineering discipline – mechanical, electronic,

software

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




partitioned to facilitate and to allocate the development activity. If a group orindividual is assigned the development of a sub-system they obviously need to havea formal definition of what is required for that sub-system. This definition can take theform 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-levelDesign Specification document for that sub-system can be used. In many cases, itmay be sensible for the various disciplines to write the sub-system RequirementSpecification based on their interpretation and then get this document agreed. Thissub-system Requirement Specification should include a definition of the interfacebetween the sub-system and the rest of the system. This definition may incorporatephysical, electrical and logical (signal) definitions.

Note that it is likely and logical that interim Design Reviews should ideally take placeon the sub-systems, which are given out to the various development parties. In thereview process the actual design should be compared with the appropriateRequirement Specification and Design Specification documents. Part of the review

should include a review of the completeness and appropriateness of thedocumentation as well as the review of the design itself. When a PCB was definedand given to an engineer to develop there should be an accompanying RequirementsSpecification at the start of development, which may be a part of a System DesignSpecification 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-downfashion. As the high-level system design is split into sub-systems, the appropriatedocumentation for those sub-systems should be drawn up. Again, this documentation

can take the form of Requirement Specification or higher-level Design Specificationas appropriate. The structure of the specification documentation therefore tends tomirror 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 designdecisions are open. Fig. 4 shows the case where the higher-level design decisionsare already defined. In this second variation, the development team for the sub-system are required to elaborate the design implementation. When this design workis completed, the Design Specification documentation for the sub-system should beupgraded from the initial high-level description. This upgrade enables the sub-systemto be reviewed and makes it more maintainable and also re-usable in other systems.




(High-Level) SystemRequirement Specification

(High-Level) System DesignSpecification

Mechanical

Req Spec

Application SW

Req SpecEmbedded SW

Req Spec

Electronic

Req Spec

MechnicalDesign

MechanicalDesignSpec

ElectronicDesign

ElectronicDesignSpec

Embedded SWDesign

EmbeddedSW Spec

Application SWDesign

ApplicationSW Design

Spec

High Level

Intermediate Level

Detailed Level

Drawings OrCad Schematics,

layout, BOMs, MIF,

etc

Code Code

Variation 1

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

(High-Level) SystemRequirement Specification

(High-Level) System DesignSpecification

High-LevelMechanicalDesign Spec

High-LevelApplication SW

Design Spec

High-LevelEmbedded SWDesign Spec

High-LevelElectronic

Design Spec

MechnicalDesign

Mechanical

DesignSpec

ElectronicDesign

Electronic

DesignSpec

Embedded SWDesign

Embedded

SW Spec

Application SWDesign

Application

SW DesignSpec

High Level

Intermediate Level

Detailed Level

Drawings OrCad Schematics,layout, BOMs, MIF,

etc

Code Code

Variation 2

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

In conclusion, the structure of the Requirements and Design Specification suite willdepend 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 thedesign structure. It is also likely that the design review process should reflect thedesign structure. Sub-system Design Reviews should occur at the appropriate timeand should include both interim and final reviews for that sub-system. The sub-




system Design Review would naturally precede the Final Design Review for theoverall system.

6. SHOULD REQUIREMENTS AND DESIGN SPECIFICATIONS BE DONERETROSPECTIVELY?

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

We should revisit the fundamental reasons we use specification documentation:1. To help drive the development process2. To help partition the development work3. To enable Design Review and ultimately design certification

4. To enable the generation of test plans, test definitions and test data5. To enable the system or sub-systems to be maintained, debugged and

upgraded6. To enable design re-use in other systems

Clearly, it is preferable to do the Requirement Specification and if helpful a SystemDesign Specification prior to the development process itself. However, as is often thecase, resources may be in short supply and schedule pressures may necessitate ahasty or even a ‘crash’ development process. Obviously, in a highly pressurisedsituation it is better to do at least a skeleton specification definition than nospecification 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 processby skipping certain specification steps is normally very hazardous both in terms ofcreating an inefficient development flow and in terms of ending up with a productunsuitable for its intended purpose.

Let us consider the desire for design or product certification. A prerequisite of designcertification is the successful completion of Design Reviews for both the defined sub-systems and the overall system. Reviews require the existence of RequirementSpecifications and Design Specifications for the design entity being reviewed. If thedocumentation 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 systemhas been fully tested and debugged? This situation would be rare. Given that theRequirement Specification may be lacking, the test plan and test data is alsoprobably lacking. In any case, it will be difficult to isolate and eradicate problems,which are reported in the field.




What about design for reuse? Is it not the case that the bulk of development workcarried out in the organisation is based on the design of previous systems? If in anew product design we are importing mechanical, electronic or software sub-systemsfrom previously designed products the existence of appropriate requirements and

design specification documentation is invaluable. Without this we need to go intoreverse-engineering mode, which is difficult from the cost, resource and scheduleperspectives.

There may be some specialised cases where the product developed is a one-off, iswell 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, whencharged 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. Thework then becomes more difficult, hazardous and expensive.

Problem 2:There is lack of time to develop adequate specification documentation at thebeginning. In this case, steps should be taken to avoid jumping straight into thedevelopment 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 resourcesare re-assigned to new exciting or pressing projects. It is difficult or impossible toretrospectively fill the specification gaps.

Having ‘completed’ the product development, we move onto the next project andencounter Problems 1 to 3 once more. The cycle is in danger of repeating itself. Weshould of course fight against this situation. It helps a great deal if key stakeholders inthe development process such as Project Managers, Programme Managers, R&DManagement, Group Leaders, Design Engineers, Scientists and Quality personnel allunderstand the purpose and value of specification documentation to the overalleconomics 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 aspecific customer or a target market segment, then variants of the product aresubsequently required or requested. The customisation requirement could either bederived from the company themselves as a product push strategy or from a customeror group of customers who request particular features or product attributes. This maycause a product ‘branch’ to develop. The product variant may well be similar to the




core product and may use many of the same design elements and satisfy similarrequirements. 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 andvariants arise. Do we add the customisation features to the core product or allow abranch to develop? The decisions have implications for regression testing, overalltest strategy and field maintenance.

In the case that a branch is made due to a particular customer need, the customermay present a customisation requirement. This can be thought of as a ‘Difference

Specification’ or a ‘Delta Specification’. What should happen is the RequirementsMatrix for the Core Product is copied and modified, usually by adding featurerequirements to the matrix. The adapted matrix can be then be used to develop thetest plan and test cases ready for validation of the customised product. In the casethat the original Requirements Matrix has not been produced, then full qualification ofthe custom product is not feasible.

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

This scenario can be also cover the situation where an absolute need to fully validatethe 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 productquality. In either case effort is required to develop the full Requirements Matrixretrospectively.




In the situation shown in Fig.6, in order to fully validate and qualify the product, theabsent Requirements Matrix would need to be developed, then the feature in thethree Delta Specifications would need to be added.

Fig.6 Product propagation without full requirements management.

system requirements and design specification guideline v2

Documents