[1]

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.

[2]

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.

[3]

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,

[4]

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.

[5]

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 co-engineering 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.

[6]

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.

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 of specification documents

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:

Quality rules for requirements

[7]

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.

[8]

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.

[9]

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.

[10]

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.

[11]

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:

[12]

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.

[13]

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.

[14]

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

[15]

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.

[16]

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

[17]

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?

[18]

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.

[19]

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

[20]

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.

Close: First:

Prev:

Next: