January 16, 2012

Requirements Management Plan - M-11

Manage requirements there traceability and there validation and verification

A. Scope

The Requirement Management Plan details all activities scheduled to manage project requirements.

It describes the strategy implemented for the project to ensure the formalisation of information pertaining to the requirements that fall within its remit.

These activities will be defined in response to the requirements - if existing - formulated by the Customer about project requirement management. Otherwise, they are defined and approved by the Customer, based on a co-assessed "right amount of effort".

B. Fundamentals

The Requirement Management Plan is initiated at the start of phase A, prior to the drafting of the first specification. Its content is therefore discussed with the Customer to ensure the coherence of requirement management processes at both partners. It is finalised at the end of phase A.

The provisions included in the Requirement Management Plan must guarantee the correct execution of the objectives set out below.

1. Taking into account the Project Customer's requirements

The project team receives a certain number of specifications from the Customer describing its requirements with, in the simplest case, the Customer Need Specification (see E-2) ,a Product Assurance Specification and a Management Specification.

The requirements may be completed by Interface design requirements regarding the expected product.

2. Characterisation of the proposed solution

During project development, the project team will characterise the technical solution, in the form of a product, describing an architecture, components, component interfaces, characteristics, performance, etc.

The product design requirements are written in compliance with the recommendations of the Requirement Management Plan. They are associated with the Customer requirements.

In addition, the project team puts itself in the Customer's place if it needs to procure a given number of sub-assemblies. To do this, it issues requirement specifications (Customer Need Specification for sub-assemblies, PA specifications applicable to Suppliers, etc.) and Interface specifications between these sub-assemblies.

Note: tailoring a reference document

The best professional practices in the space sector have been specified in reference or "standard" documents (RNC, ECSS). The PA requirements, Management requirements and some technical requirements are produced by tailoring requirements contained in these reference documents.

The Requirement Management Plan must specify the provisions adopted to describe the links between the project requirements and requirements taken from the reference documentation used, notably when the project will give rise to specifications tailored to its Suppliers.

3. Presenting the status of conformity to requirements to the Customer

At the end of phase C/D and with the project team having performed all scheduled validation and verification activities at its level (analyses, simulations, tests, inspections, etc.), having retrieved the Qualification Files (see E-13) from its own Suppliers, and having consolidated all of this information at its level, the product is deemed qualified.

The project team is then required to determine the status of conformity of each Customer requirement.

C. Typical content

1. Subject

This chapter introduces the general objectives and scope of Project Requirement Management Plan activities.

In particular, it clearly describes the product in question and the project to which it is related.

Example

1. Subject

This document describes the organisation and activities introduced to ensure the management and traceability of requirements for the "XXXX instrument" project.

The XXX instrument comprises the following 2 sub-assemblies:

  • Sub-assembly 1...
  • Sub-assembly 2...

 

Laboratory YYY is the prime contractor for the XXX instrument. Sub-assembly 1 is produced by this Laboratory and the development of Sub-assembly 2 will be outsourced to company ZZZ.

 

2. Scope

This chapter introduces the activities proposed to manage project requirements, in addition to the people involved throughout every phase of the project.

Example

1. Scope

This document describes:

  • the conformity and requirements management objectives,
  • the information handled,
  • the tools implemented,
  • the interface with documentation management and configuration management,
  • the methods used to exchange information with partners.

 

The specifications are placed under the technical responsibility of various project technical managers, the system engineer guaranteeing the highest level requirements.

Their content is systematically approved by the project manager.

 

3. Documentation

3.1 Reference documents

These constitute the bibliography that is necessary in order to prepare the Requirement Management Plan.

Example

3.1 Reference documents

RNC-CNES-E-HB-10-504Contenu type de la STB
RNC-ECSS-E-ST-10Space engineering - General requirements
NASA/SP-2007-6105 Rev1Systems Engineering Handbook P. 279
INCOSE-TP-2110-006-01Guide for Writing Requirements

 

 

3.2 Applicable documents

These are all documents that apply to the drafting of the Requirement Management Plan

Example

3.2 Applicable documents

RNC-ECSS-E-ST-10-06Technical Requirements Specification
xxxxxxxFormat of the compliance matrix for the "XXX instrument" project
yyyyyyyWORD style sheet used to enter "XXX instrument" project specifications
zzzzzzzDocumentation management specification for the "XXX instrument" project
wwwwConfiguration management specification for the "XXX instrument" project

 

 

3.3 Definitions

This paragraph provides the terminology used in this document.

Example

3.3 Definitions

ComplianceStatus defining the level of satisfaction of a requirement
RequirementRequirement issued by the Customer that characterises the need
IF requirementRequirement issued by the Customer characterising the definition of the interface between 2 sub-assemblies of the product in question
Design requirementRequirement issued by the Supplier characterising the technical solution and the product
SpecificationOrganised collection of requirements

 

 

3.4 Glossary

This paragraph provides the acronyms used in this document.

Example

3.4 Glossary

C/NC/PCConforming/Non-Conforming/Partially Conforming
IFInterface
SBSSystem Breakdown Structure

 

 

4. Product tree and specifications tree

A specification refers to one or more (with regards to IF specifications) product tree (or System Breakdown Structure) elements.

Design requirements satisfy Customer Need requirement; both referring to the same element

In addition, the sub assemblies need requirements "refines" Customer Need requirement (see E-2) and interface specifications apply to some sub-assemblies.

In this way, any new specification produced during the project is clearly identified and can be located in the project specifications tree.

The project team must therefore assume responsibility for the product breakdown tree and develop the specifications tree at its level of responsibility.

Example

4. Product tree and specifications tree

The product tree relating to the project is described in document [Ref. XXXX].

The following specifications are managed by the project team:

  • XXX instrument Customer Need Specification,
  • XXX instrument Design Specification,
  • Customer Need Specification for XXX instrument sub-assembly 1,
  • Customer Need Specification for XXX instrument sub-assembly 2,
  • IF specification for sub-assembly 1 and sub-assembly 2 of the XXX instrument,
  • XXX instrument sub-assembly Design Specification,
  • PA specification applicable to suppliers of Sub-assemblies 1 and 2.

 

All specifications managed by the project are organised in accordance with the following chart:

GNS_UK_M11.jpg

 

 

5. Identification of requirements

5.1 Requirements and remarks

The requirements are differentiated from the remainder of the specification document text as they are subject to a final status of conformity. The description of each requirement content is therefore physically isolated from the rest of the text and in particular from information provided to introduce its context, specify a design, etc.

In addition, the drafting of requirements involves compliance with a certain number of rules outlined in the "good practice" guides (cf. reference documents and applicable documents).

5.2 Numbering and version of requirements

Each requirement will be given a number or unique identifier in the project reference documentation, for identification purposes only.

In theory, the project team selects a numbering rule for all requirements.

In addition, each requirement is accompanied by an indication of its version, which is incremented from 1 following each change.

Example

5. Identification of requirements

The requirements of version one of each project specification are numbered from 10 in 10s, starting from 10 and with a prefix used to identify the specification to which it refers.

Requirement identifier example: ZZZ-REQ-050

Requirements cannot be renumbered and newly introduced requirements will be assigned a number not yet used.

To draft project requirement descriptions, the "good practices" specified by ECCS (see applicable documents) and clarified by the INCOSE (see reference document) will be implemented.

 

6. Characterisation of requirements

The definition of the description of a requirement is accompanied by the definition of a certain number of characteristics or attributes which enable:

  • identification of the requirement,
  • understanding of the description or context of the requirement,
  • determination of the status of conformity.

 

It is advisable to define the attributes that will be determined by the project team.

Generally speaking, at least the following attributes are required: requirement identifier, requirement version, requirement description and status of conformity, in addition, for a requirement resulting from a tailoring of the RNC, the number, version and status of tailoring of the requirement of the RNC from which it resulted.

In practical terms, the project team defines a table giving the name and definition of each attribute selected.

Example

6. Characterisation of requirements

The following table defines the list of attributes implemented to manage the project requirements.

NameDefinition
IDContinuation of unique non-significant characters used to name the requirement
IssueNumber from 1 upwards identifying the version of the requirement
DescriptionTextual expression of the requirement
......

 

 

7. Tools

7.1 WORD and EXCEL office tools

The various attributes relating to the requirements may be directly input in WORD and, subject to the use of a specific style sheet, it is possible to automatically export the content of the document into a specific requirements management tool. This style sheet must be provided by the Customer.

The applicability of requirements, in particular for IF specifications may be indicated by the production of the applicability matrix providing the element(s) of the product tree to which the requirement applies for each requirement.

Requirement management tools

When using a dedicated tool, the project team must define the configuration activities for the tool that meet the Customer's requirement management requirements.

Example

7. Tools

Specifications are managed in WORD.
In order for the Customer to retrieve the requirements, all project specifications are input in WORD in the style sheet included in an applicable document.

 

8. Interface with documentation management and configuration management

8.1 Requirement and configuration management

At the start of the project, the management of requirement and specification versions is restricted to the management of different information support file versions. Backups are strongly advised.

The next step is to manage the project's specifications in configuration. In terms of requirements, at least their identifier, version and description are managed in configuration. The configuration management rules therefore commonly apply to this content (Change Request management, implementation of Change Review Boards, etc.).

Emphasise that in all cases, as required by the numbering of the requirements, the granularity of change management is at basic requirements level.

8.2 Requirement and documentation management

Regardless of the tool used to manage requirements, a specification in the sense of organised collection of requirements is always produced in a document.

The document management rules commonly apply to specification documents. It is simply a question of being consistent when managing the different specification version numbers and the different document issue numbers.

Example

8. Interface with documentation management and configuration management

The documentation management rules described in the applicable document "XXX instrument project documentation management specification" apply to specification documents.

Each specification version is identified by a pair (issue number, revision number) and a record of changes summarising previous versions and included in the document's cover pages.

As soon as it is announced that the first specifications will be managed in configuration, the project team introduces the organisation required to implement the configuration management mechanisms described in the applicable document "XXX instrument project configuration management specification".

 

9. Methods used to exchange information with partners

Generally speaking, it is necessary to exchange requirement-related information with partners (Customer and Suppliers) during a project.

In contractual terms, it is essential that this information is exchanged in document format. To ensure this, the project team uses specification documents managed by the project documentation management system.

With regards to partners using a special requirement management tool, it is useful to list the "standard" exchange formats in a table.

In practical terms, the project team will use an Excel format file, in particular to supply the compliance matrix (see MF-7) for the Customer Need Specification.

Example

9. Methods used to exchange information with partners

The project team will distribute its specifications in WORD format to all partners.

The project team will issue to its Customer the compliance matrix associated with the XXX instrument Customer Need Specification in the form of an EXCEL table defined in an applicable document.

 

Forms

Activities / documentation

Published in: