A survey on Industrial Practices in Requirements Engineering

Gauthier Fanmuy
ADN
http://www.adneurope.com
17 rue Louise Michel
92300 Paris - France
gauthier.fanmuy@adn.fr

Ghassen Foughali
ENSTA ParisTech
32, Bvd Victor
75739 Paris - France
ghassen.foughali@ensta.fr

Copyright 2012 by Gauthier Fanmuy and other authors. Published and used by INCOSE with permission.

Abstract: Requirement Analysis and Modeling Process (RAMP) is a project born in

2009 in France from a joint initiative between 3 major industrial companies
belonging to different domains (Aerospace, Automotive, Energy), 2 SMEs (Service
consulting, Tool supplier) and 4 Research Lab & Universities in order to improve
the efficiency and quality of requirements expressed in natural language during the
development of complex systems.
Starting from a common view of the problem from industrial partners and the state
of art in Requirement Engineering and Modeling, this project intends to deliver short
& mid term solutions based on existing tool as well as promising research tracks in
this field though a singular partnership organisation under the umbrella of AFIS
(French Chapter of INCOSE).
This paper presents the results of a survey made in 2010 in the framework of the
RAMP project on industrial practices in requirements engineering. This survey was
made by interviews and on line questionnaires on over 22 industrials.

Introduction
Trends observed in the aerospace business highlight that the market is asking for more complex and innovative
products and services in a shorter time while keeping cost under control [Murman2000]. Our observation is that
the development of complex products is also more and more challenging, in other domains than aerospace such
as automotive industry, energy, bio-medical.
We are therefore convinced that Requirements Engineering is a key success factor for current and future
development of complex products, as highlighted in [GAO2004] [SGI2001] [NDIA2008] that shows that poor or
lack of requirements is one of the main causes to project failures.
This issue has raised new needs for improving Requirements quality of complex development products,
especially in terms of assistance to requirements authoring activities (form but also substance).
This common vision of the problem has created in 2009 the RAMP (Requirement Analysis and Modeling
Process) project from common needs expressed by 3 industrial companies (EADS, EDF, RENAULT), research
studies done in Requirements Engineering (University of Paris 1, ENSTA, INRIA, IRIT) and expertise and
solutions proposed by SME (ADN, CORTIM).

This paper describes the results of a survey made in 2010 in the framework of the RAMP project. The
first part of this paper deals with the methodology adopted to conduct the survey. The second part
presents the results of the survey.

[1]

Survey organization
As the objective was to get a representative set of responses from the Industry, the survey was organized in 3
steps.
The first step was conducted with a set of interviews of major companies in different industrial sectors
(Aviation, Aerospace, Energy, Automobile). The goal was to capture through the exchange the real
industrial issues.
The second step was conducted with an online survey within the Requirements Working Group (RWG)
of INCOSE (International Council On Systems Engineering). The goal was to confirm or complete the
issues raised in the first step.
The third step was the elaboration of a global report with the results of steps 1 and 2.
Step 1 Interviews
A panel of 8 major industrial companies was selected in various sectors: Aerospace, Space, Defense, Automotive
and Energy. 14 persons which are key actors in Systems Engineering were selected within these companies for
individual or group interviews. The interviews were targeted to fit within 4 hours. For the questionnaire,
different perspectives were considered as some industrials were Project Owners and others Project Contractors.
The high level following topics were considered:
Needs, requirements
Design of the solution
Verification and validation of requirements
Management of changes to requirements
Configuration management
Risks management
Requirements management
Customers/suppliers coordination
Inter-project capitalization
Benefits of a requirements engineering approach
Limits of a requirements engineering approach
Main areas of improvement of requirements engineering
Maturity in requirements engineering
Identification of needs
What are the stakeholders involved in defining needs?
How do you elicit the needs of different stakeholders? (scenarios, concepts
/ operational capabilities, interviews, business processes, simulations ...)
Are the needs of these stakeholders formalized as requirements?
If needs are not being elicited, what are the main reasons?
Are requirements prioritized? On what criteria?
How do you ensure the consistency of the needs of a stakeholder? among
stakeholders?
How do you resolve these differences?
Figure 1 - Extract from a Project Owner questionnaire
The interviews were conducted between May 2010 and September 2010. A report was made after each interview
and a first global synthesis of the interviews reports was made.
Step 2 Online survey
According to the results of the interviews, an on line questionnaire was set up on the Requirements Working
Group INCOSE website (connect.incose.org not available for non INCOSE members). The goal of this
questionnaire was to confirm or not the interviews results with a wider range of companies.
16 RWG members participated to the survey.
Step 3 Synthesis
The last step was the elaboration of a report which results are presented next.
[2]

Survey results: Industrial practices in Requirements Engineering

1.

NEEDS, REQUIREMENTS
1.1. Definition of needs, requirements

Requirements are mainly in natural language with defined rules.

One of the difficulties of implementation
concerns the level of precision which can vary
from one level of system to another. This
situation makes the establishment or the use of
traceability very difficult.
The use of models as a specification although
currently marginal, is however, judged as a
highly valuable practice. The use of models at a
system level is today not totally productive. The
models are mainly elaborated in the Aerospace
and Aviation domains.
The use of formal languages remains a problem
since the syntax makes it difficult to share the
information and to conduct validation activities

1.2. Identification and versioning of requirements

One of the basics of Requirements Engineering is
met, that is "every requirement has an identifier".
Most of the time, the requirements are not
versioned.
In a same enterprise, depending of the
departments or projects, the versioning of
requirements may or may not be in place.

1.3. Number of requirements

The large number of requirements is practically systematically cited as being a problem (more than 63% of
responses in RWG survey).
The passing from one development level to another produces a tenfold increase in the number of requirements.
Such an increase has an impact on different development activities.

Heavier management requirements,

Traceability more complex,
More complex definition of tests,
[3]

Fastidious reviews of requirements,

Difficulty in identifying within the company which requirements are impacted when the
stakeholders change their needs/specifications (including regulations and standardization)
etc

But also:

Loss of the synthetic vision of what the system is expected to do,

Scattering of the real objectives,
Requirements are too often scattered in different documents (e.g. ICD), when they should be
grouped in specifications,
Difficulty to identify and find the history
etc

An aggravating factor is that the allowed time for reviews is very often too short to enable to manage them
correctly.
Globally, the large number of requirements is difficult to manage.
The large number of requirements is not necessarily due to poor authoring practices/ definition of requirements,
but may be due to the fact that there are a lot of needs.
1.4. Prioritization of needs, requirements
In a single organization, one can find different practices, with for example, needs prioritized at a software level
but not prioritized at a global system level.
This prioritization is generally available for commercial products.
In other domains such as aerospace or energy, there are few unnecessary or optional needs, and these needs are
generally not prioritized.
Few criteria used alone or with combination to
prioritize the needs:

Requirements related to global

objectives of the project (12.5%)
Desirability (what it can bring,
customers
interest
for
a
requirement) (44%)
Impact on architecture (31%)
Impact of product costs, project,
delays (38%)
Risk / Technical choice (38%)
Key requirements (44%)

1.5. Elicitation techniques for needs

Functional Analysis and the definition of scenarios/business processes remain the most commonly used
techniques to identify needs. One of the expectations of Functional Analysis is to contribute to the obtaining all
of the necessary requirements.

[4]

Other
techniques
are
also
commonly used: Concept of
Operations (Aviation), Customer
Focus
Group,
simulations,
interviews, brainstorming.
More marginally other techniques
can
be
cited
such
as
questionnaires,
templates,
operational capacities, clinical tests
in automobile industry

1.6. Stakeholders implicated in the collection of needs

The stakeholders implicated in the identification of needs are, in decreasing order:

End users or their representatives

(62%)
Customers or their representatives
(62%)
Regulatory agencies (37%)
Manufacturing (37%)
Testers (37%)
Industry standards (31%)
Community of users (19%)

Maintenance (19%)
Logistics (19%)
Standardization agencies (12%)
Recycling/dismantling/taking out of
service (12%)
Executive board (6%)
Purchasing (6%)
Partners (6%)
Employees trade unions (6%)

1.7. Efficiency of the elicitation of needs

The efficiency of the methods of collecting needs is variable and dependent on the degree of maturity of the
customer, the other stakeholders, and the design team.
But the acceleration of development times, the pressure of milestones requires a continuous effort; in coengineering this can have an impact on the quality of deliverables.
The concept of completeness is difficult to evaluate
since it is only the identified needs which are specified.
Functional Analysis and modeling are means to help in
obtaining completeness, in particular to help identify
and specify those requirements related to cases on the
system limits and failure modes.
Moreover, on one hand there are the designers who do
not master the technology of the methods proposed,
and on the other hand the computer specialists who
recommend concepts.

[5]

1.8. Requirements management

Most of the time, the process of requirements management is based on a document based approach.
Requirements are approved through the approval of the requirements documents.
1.9. Quality rules for Requirements
The use of quality rules for requirements authoring is not systematic. Quality rules are established at a company
or project level in 50% of cases and their implementation on the ground is strongly variable.

Quality rules for requirements

1.10. Specification templates

All organizations have defined templates for requirements in their company database. Nevertheless, although
standardized, their application in projects remains variable. These templates are not always systematically
applied to all projects. Very often it is at a project level that this choice is made.
1.11. Formatting
documents

of

specification

The layout of requirements documents is

mainly unsatisfactory with regard to their
readability, their help in analyzing the
consistency / completeness etc.
This produces a delay during the performance
of reviews.
It is necessary to improve the current
situation. Some key points identified:

improvement of the structuring of the information in documents,

Pass from a documentary approach to an requirements approach,
Avoid duplication of information,
Be more efficient in requirement writing: too much time is spent to establish a specification

1.12. Capitalization of the justification towards needs, requirements

The formalization of justifications of "why" this requirement (design choice, feedback, system analysis), is an
identified key practice.
Even here, the practice on projects is variable. Globally this practice is standardized at a company level, but the
implementation is often at the initiative of projects or the actors in the projects.
The risks related to non-formalization of justifications are:
[6]

A loss of knowledge for the

organization

A wrong interpretation of the

context of requirements (we do
not always know why this
requirement,
why
this
requirement allocation or
why this choice etc.)

It is even more of a problem for systems

to be renewed, developed several tens
of years ago
The RWG survey shows that justifications are:

Systematically formalized and traced in 50% of cases

Variably formalized and traced in 31% of cases

Never formalized and traced in 19% of cases

1.13. Requirement Engineering tools

The main tools for Requirements engineering are Word/Excel (Pack MS Office) and DOORS/DOORS RMF.

2.

DESIGN OF THE SOLUTION

2.1 Derivation of requirements

The main points concern Functional Analysis, interfaces and requirements allocation.

Interface definition between the different sub-systems is essential in the form of requirements
Several years may be necessary to define all the requirements for big systems with many actors.
Interface definition should include the definition of the dynamic behavior.

[7]

In some cases, the importance of interfaces is undervalued. The risk of incorrectly specifying them at a
given level is that this can lead to the tests being performed at an upper system level: this complicates
the integration and automatically increases its duration.
Functional Analysis is a good way to help in deriving functional requirements.
System analysis enables to define complementary requirements (e.g. vibrations, temperature, EMC,
maintenance, etc)
Some solutions can also be imposed for reasons of system coherence (e.g. component for digital bus
coupling)

2.2 Systems hierarchy

The approaches of breaking down systems into sub-systems are practiced as follows:

A physical, organic or architectural breakdown (50% of cases)

A breakdown by function or by client service (25% of cases)
An organizationally based breakdown (13% of cases)
Variable (12% of cases)

One critical point is the mastering of coupling between systems and sub-systems.
One of the sources of complexity is related to the use of a standard structure breakdown linked more to an
organization than to a System Engineering point of view (interactions, couplings, dependence between systems,
etc.),
2.3 Requirements allocation
Requirements allocation is a key element to distribute without any ambiguity, the derived requirements amongst
the different sub-systems. It can be considered however, that the concept of requirement allocation to systems is
understood and implemented.
In 63% of cases, in a design process, the requirements of a system are systematically broken down and allocated
to sub-systems. This practice is variable in 37% of cases.
However, it is not a question of imposing requirements on the sub-systems but to ensure that the assigned
requirements are taken into account in the customer / supplier relationship.
This work requires that the business workflows needs to be defined and necessary tools produced.
The deployment remains complex because the maturity of actors/departments in the field of Engineering
Requirements remains variable.
In this context, the justification of the choices becomes a key element.
2.4 System Analysis
The identification of knots of the study or zones of complexity helps in defining the global optimum: list all the
concerned requirements, validate concepts of solutions, study the feasibility of the solutions, and identify
components (renewed, to develop) and their performances.
The comparative study of solutions passes by the definition of evaluation criteria (technical feasibility,
performance, cost, maintenance etc.) and by the implementation of simulations.
The use of models for the analyses of system is used variably according to sectors. Nevertheless it is an area
which is increasing in engineering activities.
In certain cases, models or data emanating from system modeling (stimuli) can be communicated to the suppliers
to ensure that the product is working well.
[8]

3.

VERIFICATION AND VALIDATION OF REQUIREMENTS

3.1 Most common defects

The most common defects encountered with requirements are ambiguity and expressing needs in the form of
solution.
Consistency and completeness of requirements repositories are also difficult points to address.
The input data (needs, scenarios, mission profiles) of a system are not always complete, precise etc.
particularly in the case of new or innovative systems.

3.2 Verification/validation of requirements by inspections

Inspections are the most commonly used means to verify/validate requirements. They can take several forms:
cross readings, peer reviews etc.
The review process is heavy but effective with the intervention of the good specialists / experts. Nevertheless the
analysis of needs remains difficult when the final customer does not participate in reviews but is only
represented.
Concerning
software,
a
requirements review process is
estimated to be present in about
10% of a global development
effort.
Other means could be used to
verify
or
validate
the
requirements. For example: the
use of executable models to
verify the requirements by
simulation, the proof of
properties (particularly in the
case of software).
From a general point of view, in a given context, a ratio time/efficiency could be defined for each method of
verification/validation of the requirements.
[9]

3.3 Verification/validation of requirements by the use of models

The use of models for verification/validation or requirements is
not a practice which is as common as requirement reviews.
Nevertheless, this practice is judged as providing real added
value in improving engineering projects.
Examples of the use of models:

Support in analyzing for consistency and

completeness
Evaluation of the impact of requirements and
their feasibility level
Evaluation of the system behavior within a given
architecture

The different types of models most often used are: (in decreasing order):

UML
BPMN
Simulink
SysML
Performance models
Costs models
CAD Models

3.4 Traceability of requirements and tests

Traceability between requirements and
IVVQ data (tests protocols, tests
results) is identified as a key element
for managing projects.
When elaborating requirements, IVVQ
plans are defined in order to perform
IVVQ at all levels. Thus, each IVVQ
action is identified with a definition of
means and traceability to requirements.
This practice is variably applied. It is
either done systematically in the best
cases, or used or not depending on the actors or projects in the worst cases.
Traceability is at a requirement level or document/chapter level (thus global).
The prerequisite is of course to have the repository of requirements of the project.
In 60% of cases, IVVQ activities are defined during specification activities.
These IVVQ activities are established in 50% of cases in the context of an IVVQ strategy.
3.5 IVVQ Improvements
On new or innovative systems, it is difficult
1/ to define (technically or contractually) all of the requirements,
2/ to estimate the complexity of tests at the beginning of the program/project.
[10]

It can be a combined problem: multiple modes

of operation can lead to a physically impossible
(million tests) to approach an exhaustive
validation.
This issue of combinations is also applicable to
complex systems with multiple variants.
One major axe of improvement is to set up an
IVVQ strategy enabling:

To implement IVVQ as earlier as

possible

To
anticipate
proofs
of
compliance
This strategy defines in particular:

The IVVQ objectives

The reference scenarios and acceptance criteria that will enable to validate/qualify the products
The implication of IVVQ actors in specification phases is judged as a practice needing to be reinforced.
4.

MANAGEMENT OF CHANGES TO REQUIREMENTS

Globally, changes are well managed within a change management process.

Nevertheless, this practice can be variable even within the same organization (for example: existence of a tooled
process at a software level, existence (or not) of a process to equip the system level). This is also variable
according to the clients.
One of the main axes for improvement concerns the traceability between requirements and change requests.
4.1 Change management
Change management is handled in similar
proportions either at a document level (31%)
or at a requirements level (38%) or mixed
(25%)
Changes in requirements are not managed in
6% of cases.
Traceability of changes with respect to the
requirements is achieved in 60% of cases.

4.2 Change management improvements

Identified improvements in change management are the following:

[11]

5.

CONFIGURATION MANAGEMENT
5.1 Configuration management

The situations encountered are very diverse. Good software configuration management is generally observed.
For systems perimeters, the situation is more contrasted: although configuration in downstream phases
(products) is quite well covered; upstream phases are either correctly covered or not covered at all.
Configuration management is ensured through requirements documents in 50% of cases, through requirements in
19% of cases, and variable in 19% of cases.
Configuration management in requirements phase is not implemented in 13% of cases.
Changes on requirements are traced to configuration baselines in 50% of cases.
5.2 Tools for configuration management
The tools used for configuration management cited during the interviews are the following:

5.3 Improvement of configuration management

One identified improvement is related to traceability between configuration management and requirements,
architecture and design elements.
6.

RISKS MANAGEMENT

Risks are managed at a program/project level.

In the domains of the interviewed organizations, there are no specificities related to requirements engineering.
Tools such as AMDEC are also used to manage risks at components/equipment level. Nevertheless this tool only
covers a part of the requirements repository.

[12]

7.

REQUIREMENTS MANAGEMENT

Complex systems are generally developed in simultaneous engineering projects. Reconciliation is needed for:
Definition of systems requirements and their cascading down to components
The timing constraints concerning supplier discussions related to bids, may, in some cases, lead to
discussions with suppliers early in the planning program / project
The schedule needs to have models or mockups of components to anticipate integration activities
Anticipation of compatibility with respect to future projects whose needs are not consolidated
etc.
It is therefore possible that the nominal sequence is not respected. In this case:
A risk analysis is done to assess the consequences of a later definitions / changes to requirements.
The derivation of requirements must be organized
The reviews positioned accordingly.
It is necessary to have more time during the preliminary phases to analyze, process requirements, validate the
assumptions. This is especially true in cases where there is no existing repository/ references for a new complex
system.
Mastering the knowledge of the status of the requirements is necessary.
In the case of a customer-supplier relationship, there is often a game with the accuracy of the requirements. In
fact, generally its in the customer's interest to keep certain requirements vague because he is not able to give
precisions either because he needs to obtain information or know-how, or because he wants to avoid too much
commitment.
This game involves a risk, but it may be acceptable if the type of requirement is clearly identified and managed,
and whether the contractual consequences are well accepted by both parties.
8.

CUSTOMERS/SUPPLIERS COORDINATION
8.1 Maturity of suppliers in requirements engineering

In those domains where suppliers are in the business from a long time ago (e.g. aerospace, aviation), suppliers
generally have a good understanding of the issues. Suppliers have maturity levels at least equivalent to their
customers.
In other domains (e.g. commercial), the maturity of suppliers in requirements engineering is more variable.
Nevertheless, the imposition by the clients of Good Requirement Engineering Practices (e.g. conformity
matrices) is making the global environment improve. .
8.2 Exchanges/Communication between Customers/Suppliers
One of the needs for improvement lies in the reinforcement of the interaction between Customers/Suppliers:
Traceability between system requirements (from customer) and sub-system requirements (from
supplier)
Exchange of justifications (synthesis notes, choices)
More generally, the implementation of automated exchanges between the different stakeholders (for example
through a common template) would greatly contribute to this aspect being improved.

[13]

9.

INTER-PROJECT CAPITALIZATION
9.1 Re-use of requirements

Many business rules or knowledge databases exist and may or may not be formalized as requirements.
These business rules / knowledge databases are in 35% of cases the basis of requirements.
In 25% of cases, these business rules / knowledge bases lead to generic requirements which are capitalized on in
a reusable domain model.
The issue concerning reuse is due to the adding-on of information to something which may not initially have
been well written.
The variability is then more or less
formalized depending on the
system layers.
In some cases we could probably
call this retrieval of requirements
(e.g. copy / paste) rather than reuse
as correctly termed.
Working with Product lines still
encounter many problems due generally to a natural resistance to change because this is a constraining process
(change management, impact analysis, traceability).

9.2 Improvement in the reuse of previous requirements

Standardization is a key word in the improvement of requirements reuse. This standardization goes through:
The definition of business rules as requirements,
The identification of specific / common components,
The characterization of their environment,
The availability of a suitable tool

[14]

10. BENEFITS OF A REQUIREMENTS ENGINEERING APPROACH

The benefits of a requirements engineering approach are:

Increased legibility of project information

Improved communication between stakeholders

Reduced costs and delays, including IVVQ optimization

(Note: it is still difficult to give proves based on measurements on projects in real size)

Regulatory compliance

Make good design from the start. This is particularly necessary in areas where it is not possible to
make updates prototypes, pre-series ... before commissioning.

Use data models using integrated processes and tools at Meta model and Project levels.
Standardization.

Requirements complete and correct

11. LIMITS OF A REQUIREMENTS ENGINEERING APPROACH

The problems still encountered, despite the use of a Requirements Engineering approach, concern the difficulty
of understanding the fundamentals of Requirements Engineering.
The teams still face difficulties in the transition from theory to practice. In particular:
formalization of requirements
consistency of textual requirements
requirements that describe solutions
definition of specification models
Managing the system complexity still remains a problem. This is due largely to differences in levels of
awareness of issues and Requirements Engineering practices of the various individuals in projects.
A multidisciplinary integration and a smoother flow of information would be very beneficial.
Requirements Engineering is sometimes regarded as a documentation activity. Decisions made in the design are
not in line with requirements. The changes are conducted once the change in design is effective.
[15]

One difficulty is the Concurrent Engineering: Everyone starts at the same time and the different aspects must be
related, and made consistent later on.
This gets more complex within a widespread enterprise.
Another difficulty is the taking into consideration of changing needs on projects having long development
cycles.
For new or highly innovative systems, a balance is to be found between the planning constraints (programming)
and the time needed to complete the definition of the requirements, system analysis, etc.
In order to make contracts robust, it is tempting to put a lot of demands on everything. This has impacts on the
monitoring of these requirements at the project level. Moreover, there is a risk of redundancy, contradiction of
requirements etc.

12. MAIN AREAS OF IMPROVEMENT OF REQUIREMENTS ENGINEERING

The main areas of improvement in Requirements Engineering are as follows:
Ensure cultural change, including understanding the fundamentals. The players usually think
"solution"
Standardize practices between departments or services of the enterprise (including widespread
companies)
Gradually improve its methods used (including modeling and simulation - MBSE, scenarios, and
reuse).
Use models to replace or complement textual requirements.
For completely new or innovative systems, we can only be partially based on feedback. It therefore
becomes complicated to identify so-called threshold effects (e.g. at what level of performance, the
architecture of a system will completely switch?).
The use of models should allow:
o To represent the product (through the requirements)
o To properly understand the relative weight of the different requirements.

Consolidate the various fundamental aspects of development of system architecture such as a cascade of
the functional and physical aspects. This will help achieve a more robust design, and even to allow the
reuse of aspects. The major challenge is the definition of methods that control the coupling.

Traceability between system requirements, system architecture and derived requirements

[16]

Fill the holes that exist in order to strengthen the completeness of the business processes.
It includes:
o A better control of the requirements repository with SMART requirements and a certain
completeness using well organized methodologies.
o A questioning of the achievements and better understanding of new issues related to emerging
needs.

Give more flexibility in the development processes: incremental development, concurrent engineering.

Improve visibility throughout the life cycle (give a dynamic aspect to requirements), developing in
particular the concepts of point of views.

Better specification of the scope and interfaces.

Improve the quality of requirements.

Limiting the volume of requirements

Avoid implicit requirements, such as formalizing, for example mandatory requirements i.e. regulatory,
safety.

Reaching a Lean Requirements Engineering including in particular:

o Harmonization of methods and tools
o Extensive use of modeling by incorporating the physical and functional areas
o Improved knowledge management
o Systematize the multidisciplinary processes
o Improve the design to cost approach, particularly to facilitate the integration problems

Increase the taking into account of aspects concerning safety, logistical support, maintenance: link with
failure trees, identification of information to monitor etc.

Standardize the specification templates with respect to application areas

Keep track of design choices.

Improve the way in which the desirability of a requirement is estimated: priority of a requirement
regarding its impact on business

A requirement has a cost and a value. We know the cost but not always the added value. We should
spend more time upstream on this aspect.

The question that remains relevant is "Have we specified enough?

[17]

13. MATURITY IN REQUIREMENTS ENGINEERING

Variable from one program / project to another, from one department / service to another: between 2 and 5, with
a majority around 2 or 3.

Conclusion
Requirements are mostly formalized using natural language. A common point between the different industries is
the significant volume of requirements.
The use of models in place of, or in addition to, requirements remains marginal but is seen to be a high added
value practice.
The Requirements Engineering practices vary from one company to another, within the same company.
The main benefits of Requirements Engineering are:
Increased legibility of project information
Improved communication between stakeholders
Understanding the fundamentals is still a major obstacle to requirements engineering deployment.
Mastering complexity is also a major problem to be solved.
The most frequently encountered faults with requirements are:
The expression of needs in the form of solution,
Ambiguity,
Consistency,
Completeness,
Several requirements in a single requirement,
Imprecision,
Non verifiable requirements.
[18]

Areas for improvement relate to all System Engineering processes.

The most significant are:
Improve understanding of the fundamentals
Improve the quality of requirements
Use models to substitute or complement the requirements
Be more effective in writing specifications
Avoid implicit requirements
Allow concurrent engineering
Improve visibility over the entire life cycle in a perspective of project management by the
requirements.
Capitalize on and trace business knowledge
Better specify the interfaces, particularly the links between systems
Strengthen traceability between requirements, design, tests, changes, configuration
Develop an IVVQ strategy
Standardize
This report presents a generic approach to enumerate and to analyze requirement engineering activities such that
they are implemented in different kinds of industries.
Facing a huge amount of qualitative variables and to a process characterized by a strong dispersal of the
practices, future work will concern the analysis of the data through an industry perspective in order to define
profiles and correlate practices of a profile among different sectors, and identify possible feed backs and
improvements from one sector to another.
Such work can end with the recommendation of a typical requirement engineering models for each type of
profiles detected on the study or for each type of industry.
Future work will concern also the focus on knowledge management activities and how this can respond to the
identified gaps and bring value to requirements engineering process.
Finally, in future, we hope that this kind of survey can benefit from a larger amount of participants that can
include more types of industries and countries, in a periodical way for maturity assessment and progress paths
identification.

References
[GAO2004] United States General Accounting Office, Defence Acquisition: Stronger Management practices are
needed to improve DODs software-intensive weapon acquisitions, 2004
[Murman2000] Murman, E.M., Walton, M. and Rebentisch, E., Challenges in the Better, Faster, Cheaper Era of
Aeronautical Design, Engineering and Manufacturing, The Aeronautical Journal, Oct 2000, pp 481-489.
[NDIA2008] NDIA & SEI, CMU/SEI-2008-SR-034, A Survey of Systems Engineering Effectiveness
[SGI2001] Standish Group International, Extreme Chaos, 2001

[19]

Biography
Gauthier Fanmuy
Gauthier Fanmuy is the Technical Director at ADN (http://www.adneurope.com), a Systems
Engineering consulting company specialized in Requirements Engineering, Model Based
Systems Engineering and Products Lines for complex and critical Systems.
He has worked in the past years in the Automotive Industry at PSA Peugeot Citroen where he
has deployed Requirements Engineering and DOORS in an engineering department.
He previously worked in the Aeronautic Industry at Dassault Aviation where he managed
several projects such as integration of electro-optics sensors on military aircrafts, development of complex
system functions and re-engineering of MMI in object oriented approaches. He is also Deputy Technical
Director of AFIS (French Association on Systems Engineering). He was previously chairman of Global
Processes Technical Committee and also managed during 10 years of the AFIS Requirements Engineering
Working Group. He is the chairman an international WG in INCOSE (http://www.incose.org): Systems
Engineering for Very Small and Small Entities and small project (VSMEs).
As member of the IREB, he is playing a key role in the translation of the IREB certification material to French,
and in the porting of the overall IREB certification scheme in French speaking regions.
He is co-founder of the SPECIEF association for the promotion of Requirements Engineering in French
(www.specief.org) and is porting within this association the overall IREB certification scheme in French
speaking regions (http://certified-re.de/en/).
Ghassen Foughali
Ghassen Foughali is currently a PhD student at the Ecole Nationale Suprieure des Techniques Avances
(ENSTA ParisTech) France under the supervision of Prof. Omar Hammami. He received a
Master degree in systems engineering and project management from ENSAM in 2011 and a
ME in industrial engineering from ENIT, Tunisia in 2010. Ghassen Foughali work experience
is mainly with the French automotive industry and includes supply chain with RENAULT and
requirements engineering studies within PSA. Besides, he has been involved in collaborative
tool design for the electronics industry in the Mediterranean region.
Currently, his main research activities are related to requirement engineering process
improvement, system design automation, formal verification and mechatronics system design and validation.
Ghassen Foughali is a student member of the IEEE, AFIS and ADENIT Tunisia.

[20]