See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/221508362
Requirements Verification in the Industry
Conference Paper · January 2011
DOI: 10.1007/978-3-642-25203-7_10 · Source: DBLP
CITATIONS
READS
29
954
3 authors, including:
Anabel Fraga
Juan Llorens
University Carlos III de Madrid
University Carlos III de Madrid
54 PUBLICATIONS 319 CITATIONS
135 PUBLICATIONS 823 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Automatic Pattern Generation View project
All content following this page was uploaded by Juan Llorens on 10 February 2014.
The user has requested enhancement of the downloaded file.
SEE PROFILE
Requirements verification in the Industry
Gauthier Fanmuy
Juan Llorens
ADN
Informatics Dept.
http://www.adneurope.com
Universidad Carlos III de Madrid
17 rue Louise Michel
Avda Universidad 30
92300 Levallois Perret - France
28911 Leganes, Madrid – Spain
gauthier.fanmuy@adn.fr
juan.llorens@uc3m.es
Anabel Fraga
Informatics Dept.
Universidad Carlos III de Madrid
Avda Universidad 30
28911 Leganes, Madrid – Spain
afraga@ie.inf.uc3m.es
Abstract: Requirements Engineering is a discipline that has been promoted, implemented and deployed
for more than 20 years through the impulsion of standardization agencies (IEEE, ISO, ECSS,…) and
national / international organizations such as AFIS, GfSE, INCOSE. Ever since, despite an increasing
maturity, the Requirements Engineering discipline remains unequally understood and implemented, even
within one same organization. The challenges faced today by industry include: “How to explain and make
understandable the fundamentals of Requirements Engineering”, “How to be more effective in
Requirements authoring”, “How to reach a Lean Requirements Engineering, in particular with improved
knowledge management and the extensive use of modeling techniques”.
This paper focuses on requirements verification practices in the Industry. It gives some results of a study
made end of 2010 about Requirements Engineering practices in different industrial sectors. Twenty-two
companies worldwide were involved in this study through interviews and questionnaires. Current
requirements verification practices are presented. It gives also some feedbacks of the use of innovative
requirements authoring and verification techniques and tools in the industry. In particular, it addresses the
use of Natural Language Processing (NLP) at the lexical level for correctness verification (on the form,
not on the substance) of requirements, the use of Requirements boilerplates controlled by NLP for
guiding requirements writing and checking, the use of Ontologies with NLP to verify requirements
consistency, and the application of Information Retrieval techniques for requirements overlapping.
1.
Introduction
Several studies clearly underlined the importance of requirement management in Systems Engineering
[Brooks1987], [Chaos-Report2003], [SWEBOK2004]. Among these studies [NDIA2008], the SEI
(Software Engineering Institute) and the NDIA (National Defense Industrial Association) made a study
on the efficiency in Systems Engineering. The Systems Engineering Division (SED) of the National
Defense Industrial Association (NDIA) established the Systems Engineering Effectiveness Committee
(SEEC) to obtain quantitative evidence of the effect of Systems Engineering (SE) best practices on
Project Performance. The SEEC developed and executed a survey of contractors for the defense industry
(i.e., government suppliers) to identify the SE best practices utilized on defense projects, collect
performance data on these projects, and search for relationships between the application of these SE best
practices and Project Performance.
The SEEC surveyed a sample of the population of major government contractors and subcontractors
represented in the NDIA SED. The survey data was collected by the Carnegie Mellon2 ® Software
Engineering Institute (SEI). Project Performance was then assessed based on satisfaction of project cost,
schedule, and scope goals. This study showed a strong correlation between project performances and
requirements engineering capabilities:
 Organizations with low capabilities in Requirements Engineering are likely to have poor performance projects
 At the opposite, organizations with high capabilities in Requirements Engineering are likely to
have good performance projects: over half of the Higher Performing Projects exhibited a higher
capability in Requirements Engineering.
2
Figure 1 - Relationship between Requirements Capabilities and Project Performance
Thus, it can be understood that Requirements Engineering is a key success factor for current and future
development of complex products. As highlighted in [GAO2004], [SGI2001] the existence of poor
requirements, or lack of them, is one of the main causes to project failures. Even more, although there is
no complete agreement on the effort and cost distribution of activities for the development process (the
requirements phase of software projects estimates between 5% and 16% of total effort, with too much
variance), empirical studies show that rework for identifying and correcting defects found during testing
is very significant (around 40-50%); therefore, more quality control upfront will lead to less rework
[Sadraei2007].
Another study [Honour2011] showed that an effective System Engineering is obtained at a level of
approximately 15% of a project cost optimizes cost, schedule, and stakeholder success measures.
All the previously mentioned studies suggest a more complex reality: the mere production of huge sets of
detailed requirements does not assure effective and quality project performance. To ask for Requirements
engineering higher capabilities inside an organization implies much more that strategies for mass
production of requirements.
A requirement is “An identifiable element of a function specification that can be validated and against
which an implementation can be verified” [ARP4754].
In the Systems Engineering community, requirements verification and validation are very well described
as “Do the right thing” (Validation) together with “Do the thing right” (Verification) [Bohem1981]. To do
“the right thing right” becomes the essential activity in the Requirements Engineering process. Therefore,
the quality factor becomes essential at all levels: the quality of single requirements must be measured, as
well as the quality of sets of requirements. The quality assessment task becomes really relevant, and
perhaps the main reason to provide this field with a specific engineering discipline.
This issue has raised new needs for improving Requirements quality of complex development products,
especially in terms of tools to assist engineers in their Requirements verification or requirements
authoring activities.
The first part of this paper describes some results of a study on Requirements Engineering industrial
practices, in the framework of the RAMP project (Requirement Analysis and Modeling Process) - a joint
initiative undertaken in France between major industrial companies, universities / research labs and Small
& Medium Enterprises. Current requirements verification practices and gaps are presented.
The second part of this paper describes how Natural Language Processing (NLP) can help into more
efficient requirements verification and Lean requirements authoring.
3
The third part of the paper gives an overview of existing academic or commercial tools that support
Requirements verification and authoring.
2.
RAMP Project
The RAMP Project (Requirement Analysis and Modeling Process) started in September 2009 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 solutions proposed by SME
(ADN, CORTIM) [Fanmuy2010].
In particular, some of the common needs are:
 Requirements are often written in natural language, which is a source of defects in the product
development process.
 Obtaining consistency and completeness of requirements remains difficult by the only humanvisual review since several thousands of requirements are managed in most of cases.
The objective of the RAMP project is to improve the efficiency and quality of requirements expressed in
natural language throughout the life cycle of the system, and thus the performance of projects in design,
renovation and operation.
The axes of the Project are:
 Improvement of the practice of Requirements definition written in natural language: assistance in
requirements authoring (lexical and syntactical analysis, models…).
 Improvement of Requirements analysis: assistance in the detection of inconsistencies, overlaps,
incompleteness (modeling, compliance to an ontology…).
 Assistance in the context analysis: assistance in the identification of data in scenarios enabling
requirements elicitation and definition in their context, assistance in identifying impacts in a context of evolution of a legacy system.
3.
Industrial practices in Requirements Engineering
At the initiative of the RAMP project, ADN created and developed a study on industrial Requirements
Engineering practices in 2010.
This study was based on:
 Interviews of major companies in different industrial sectors (Aviation, Aerospace, Energy,
Automotive…)
 Survey in the Requirements Working Group (RWG) of INCOSE (International Council On
Systems Engineering)
Different topics were addressed:
 Needs, requirements: Definition of needs & requirements, Identification and versioning of
requirements, Number of requirements, Prioritization of needs & requirements, Elucidation
techniques for needs, roles of Stakeholders, Efficiency of the elicitation of needs, Requirements
management, Quality rules for Requirements, Specification templates, Formatting of specification
documents, Capitalization of the justification towards needs & requirements, Requirement Engineering tools.
 Design of the solution: Derivation of requirements, Systems hierarchy, Requirements allocation,
System Analysis.
 Verification and validation of requirements: Most common defects, Verification/validation of
requirements by inspections, Verification/validation of requirements by use of models, Traceability of requirements and tests, Integration / verification / validation / qualification improvements.
 Management of changes to requirements: Change management, Change management improvements.
 Configuration management: Configuration management process, Configuration management
tools, Improvement of configuration management.
 Risks management
4


Customers/suppliers coordination: Maturity of suppliers in requirements engineering, Exchanges/Communication between Customers/Suppliers.
Inter-project capitalization: Re-use of requirements, Improvement in the reuse of previous
requirements.
The results of the Requirements verification and validation section were the following:
 Most common defects in Requirements:
The most common defects encountered within requirements were the 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.
Figure 2 - Most common defects in Requirements

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, QA inspections with pre-defined criteria etc.
Most organizations have requirements quality rules at corporate or project level. But most of the time
these rules are not correctly applied:
Correctly applied: 15%
Not applied : 35%
Variably applied: 50%
The review process is burdensome 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.
5
Figure 3 - Verification/validation of requirements by inspections

Verification/validation of requirements by the use of models
The use of models for verification/validation of requirements is a practice which is not 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:
o Support in analyzing for consistency and completeness
o Evaluation of the impact of requirements and their feasibility level
o Evaluation of the system behavior within a given architecture
Figure 4 - Verification/validation of requirements by the use of models

The different types of models most often used are, in decreasing order (results from RWG survey):
o UML
o BPMN
o Simulink
o SysML
o Performance models
o Costs models
o CAD Models
Tools assistance for requirements verification
Only few organizations use tools to assist engineers or quality assurance in verifying requirements.
The following practices are encountered from the most to the less frequent:
o Requirement verification within the RMS1 tool: requirements are reviewed directly in the RMS tool
(e.g. DOORS®, IRQA®). Some attributes or discussions facilities are used to collect review com-
1
RMS: Requirements Management System
6
o
o
4.
ments. Traceability is checked in the tool for incompleteness, inconsistencies between requirements,
for tests coverage.
This practice is often limited to the RMS tool because not all tools are always supporting traceability
and thus it is difficult to have a global view of requirements connected with other engineering
artifacts (e.g. tests, change requests…).
Very often the RMS tool is not deployed in the organization and it is difficult to verify traceability or
to make impact studies in case of changes.
In better cases, some add-ons to RMS tools have been developed for identifying semantically-weak
words (e.g. detection of words such as fast, quick, at least…).
Typical use cases: compliance to regulation, correctness of requirements, correctness of traceability
in design, impact analysis in a change process.
Requirements verification with specialized tools which perform traceability and impact analysis:
traceability is defined in dedicated tools (e.g. Requirements in one or several RMS tools –
DOORS®, MS Word®, MS Excel®; Tests in QMS 2 tool; Change Requests in CM3 tool). Tools are
not connected, but specialized tools (e.g. Reqtify® with Reviewer®) capture requirements and other
engineering artifacts from any source and generate traceability matrices with rules checker (e.g.
reference to missing requirement, requirement not covered with tests…).
Traceability is checked in the tool and traceability matrices are generated for prove issues.
In some cases, some scripts have been developed for weak words identification purposes, or for
documents verification properties (e.g. a column of a table has/or not content).
Typical use cases: compliance to regulation, correctness of requirements, correctness of traceability
in design to code and tests, impact analysis in a change process.
Requirements verification with specialized tools which perform lexical and syntactical analysis of
requirements
As requirements in natural languages are imprecise, ambiguous, etc. the use of tools (e.g. Requirements Quality Analyzer®, Lexior®,...) to check requirements regarding SMART (Specific, Measurable, Attainable, Realizable, Traceable) quality rules enable to correct defects in the form before
business or project reviews.
Such tools enable to detects the use of wrong words (e.g. weak words,…), bad grammatical sentences (e.g. passive voice, use of pronouns as a subject,…) and multiple requirements (e.g. sentence
length,…)
This enables to identify critical requirements and correct them before reviews.
Typical use cases: Analysis of Requests for Proposals (Bid), Requirements verification before a
business or project review.
Towards a Lean Requirements Engineering
One of the conclusions of the survey is that the problems still found, despite the use of a Requirements
Engineering approach, concern about the difficulty of understanding the fundamentals of Requirements
Engineering.
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
One of the identified Industry challenges is to reach a Lean Requirements Engineering: be more efficient
in Requirements authoring. This leads to assist practitioners in writing quality (SMART) requirements
from the very first attempt and to improve reuse of knowledge.
2
3
QMS: Quality Management System
CM: Change Management
7
5.
Advanced requirements verification practices
Obtaining the “right-requirements-right” is a complex, difficult and iterative process, in which engineers
must respond to the double challenge of discovering and formalizing the needs and expectations that the
clients usually are able to describe using different understanding and representation schemes. This
different ways of understanding & representing requirements between clients and engineers leads to real
problems at the time of clearly formalizing requirements. To add more complexity to the problem, the
clients can several times provide confusing, incomplete and messy information.
The success of this requirements process requires continuous and enhanced collaboration & communication between clients and system engineers: the more complete and unambiguous the requirements
specification is, the higher performances will the project have [Kiyavitskaya2008]. We are sure that this
need of communication among all stakeholders has been the reason why requirements are mainly
expressed in natural language for most industrial projects [Kasser2004], [Kasser2006], [Wilson1997]
instead of more formal methods. The market supports this idea by in almost all cases offering
requirements management tools based on natural language representation [Latimer-Livingston2003].
Due to the reason that industrial system projects can potentially handle thousands of requirements, the
human-based verification process becomes extremely expensive for the organizations. Therefore,
industrial corporations apply tool-based, semi-automated techniques that reduce the human resources
needs of efforts. Usually these techniques are based on the application of transformations to the natural
language requirements to somehow represent them in a more formal way [TRC].
It is clearly understood in the market [TRC], that a strong correlation exists between the complexity level
of requirement representations and what one can extract out of them. The more semantic knowledge we
are interested to validate from requirements the more complex the formal representation must be. The
Natural Language Processing discipline organizes the different techniques to be applied to natural text
according to the level of semantics [De-Pablo2010]. They are summarized in figure 5.
Figure 5 – Natural Language Processing summary of techniques
Morpho (lexical)-syntactic techniques can be applied to correctness verification of requirements, as they
can somehow produce a grammatical analysis of the sentence. Well-formed sentences will statistically
translate into better written requirements. Figure 6 presents an example of syntactical techniques [DePablo2010].
8
Figure 6 – Application of syntactical techniques to Natural Language
An evolution of the syntactical techniques, in the form of identifying sentence patterns (or requirements
patterns), is what the industry calls “boilerplates” [Hull2010], [Withall2007]. The identification and
application of boilerplates in requirements engineering leads to quality writing and checking and
improves authoring.
For example:
UR044: The Radar shall be able to detect hits at a minimum rate of 10 units per second
THE <OBJECT DETECTION> SHALL <DETECT> <ITEMS> AT <MINIMUM> <RATE VALUE>
Other possibilities:
Identify
Recognize
Other possibilities:
Doppler Radar
Sonar
Other possibilities:
Targets
Echoes
Figure 7 – Requirements modeling with boilerplates and NLP techniques
The application of ontology engineering in requirements engineering and in model-based systems
engineering, in general, seems to be a very promising trend [TRC], [Chale2011]. We call it requirements
verification based on Knowledge Management, and it deals with assisting System Engineers to get a
complete and consistent set of requirements (e.g. compliance to regulation, business rules, nonredundancy of requirements…) by using Ontologies, which represent the domains of knowledge of an
organization.
In its application to requirements verification, extending NLP with inference rules capabilities,
taxonomies, thesaurus and semantic groups enable computer tools to enhance requirements consistency.
The Reuse Company [TRC] offers a particular vision of ontologies in their application to Requirements
Engineering (figure 8).
9
Figure 8 – Ontologies in Requirements Engineering according to The Reuse Company
Ontologies, together with boilerplates, assist System Engineers to write from the beginning well-formed
requirements with controlled vocabulary, rather than verifying requirements afterwards. Their relational
structure offers multiple possibilities for semantic expansion of requirements.
Finally, the combination of Requirements Engineering with Knowledge Management, by information
retrieval from existing sources (business rules, feed-back,…), allows the verification process to measure
quality of a set of requirements: traceability, consistency/redundancy, completeness and noise.
Information retrieval enables also to verify the completeness and of the ontology.
6.
Tooling
Different tools are available on the market, from research to commercial tools.
In the scope of its Lean Systems Engineering research, EADS IW, one of the partners of the RAMP
Project made in 2010 an assessment of 15 tools [EADSIW2010].
The assessment was made over 3 pilot cases: 2 test cases on AIRBUS (A320NG & A350) and 1 Test case
on ASTRIUM (ATV).
8 tools were selected in the short list.
The assessment was based on 74 criteria.
The results are the following:
 One is promising: Requirements Quality Analyzer from The Reuse Company
 One is an important challenger : Lexior® from Cortim
 One is interesting but out of scope: DESIRe (more like a support for requirement authoring)
 The remaining tools are not compliant with industrial expectation: ARM / Requirements Assistant /
DXL / QuARS.
Tool
RQA
Company
Country
The Reuse Company
Spain
Use
Industrial
Kind
Commercial
LEXIOR
CORTIM
France
Industrial
Commercial
Holland
USA
Germany
Industrial
Industrial
Industrial
Commercial
Open Source
Open Source
Requirements Assistant
Sunny Hills
ARM
NASA
DESIRe
HOOD
Result
Most promising as
assessed so far
Most important challenger
Not integrated with
DOORS
Authoring Support
10
QuARS
TigerPro
University of PisaItaly
University of South
Australia
Australia
DOORS / DXL IBM
USA
Academic
Academic
Commercial
Open Source
Industrial
Commercial
Application
Academic Tool
Service Oriented
Business Model
Too complex
Compliance with
COTS Policy
Cost of Maintenance
Requirements Quality Analyzer (RQA)
RQA allows defining, measuring, improving and managing the quality of requirements. It is integrated in
DOORS®, IRQA® and MS Excel®. It is based on evaluating metrics. These metrics will help the
engineers to sort, classify and prioritize the review of their requirements from the most to the least critical
defects.
There are non-text-based metrics such as Text length, Readability, Number of punctuation marks,
Dependencies …
There are other metrics computed by processing the requirement text with natural languages processing
techniques: lack of shall, use of opinions; use of negative sentences, use of implicit and weak words, use
of connectors… It enables also to detect the use of design terms in higher-level requirements.
Finally, there are other metrics not based on a single requirement but in sets of requirements:
 Incompatible metric units: inside the same set of requirements it could be a mistake use two
different metric units belonging to different metric systems
 Overlapping requirements: this metric computes how similar in meaning are two different
requirements.. This allows to delete duplicate requirements or trace them if they belong to a different level in the requirement hierarchy
RQA uses of ontologies and requirements boilerplates for both:
 Analyzing and storing conceptual information that makes it easier for a machine to understand the
real meaning of a requirement
 Storing inference rules that allows the tool implement ‘artificial intelligence’ algorithms to emulate
a human reasoning
Lexior
Lexior is a lexical analysis tool based on requirements rules. It is integrated with DOORS®. An XML
interface is also available.
It is based on evaluating metrics per requirements writing rule such as: absence of shall, use of negative
sentences, use of verbal forms, use of passive voice, use of pronouns as subject, use of weak words…
Scoring of requirements enables to identify the most critical requirements.
It is also possible to generate some RID (Review Item Description) for a review.
7.
Conclusion
Assessments results have shown that about 25% of requirements are critical and can grammatically be
improved. Typical defects are the following:
 Absence of shall: 8 to 10%
 Forbidden words: 10 to 15%
 Subject, multiple objects, design: 15%
 Incorrect grammar: 50%
“Classical” review process is not performing as expected and is costly and time consuming. Support of
tools for lexical, syntactic analysis enables to correct bad requirements writing before business of project
reviews.
One of the next challenges in the Industry is to reach a Lean Requirements Engineering process: assist
systems engineers to write SMART requirements at a first shot.
11
The use of ontologies and boilerplates is a promising way of doing better requirements engineering and
reuse knowledge:
 Find missing requirements
 Find ambiguous requirements
 Find noise in requirements
 Find inconsistencies
8.
References
[ARP4754] Guidelines for Development of Civil Aircraft and Systems. Society of Automotive Engineers.
ARP4754A. http://standards.sae.org/arp4754a.
[Bohem 1981] Barry Boehm, Software Engineering Economics, Prentice-Hall, 1981, L/S 004.41 BOE, p.
37
[Brooks1987] Frederick P. Brooks. “No Silver Bullet. Essence and Accidents of Software Engineering”.
IEEE Computer 20(4):10-19, April 1987. Reprinted in: Frederick P. Brooks. The Mytical Man-Month,
Essays on Software Engineering. Addison-Wesley, 1995 (20th Anniversary Edition).
[Chale2011] H. Chale et al., Reducing the Gap between Formal and Informal Worlds in Automotive
Safety-Critical Systems, INCOSE Symposium 2011, Denver.
[Chaos-Report2003] The Standish Group, Chaos Report, 2003 (www.standishgroup.com/).
[De-Pablo2010] César de Pablo, “Boostrapping Named Entity resources for adaptive question answering
Systems”. PHD. Universidad Carlos III de Madrid. Informatics Department. Universidad Carlos III de
Madrid, 2010. http://hdl.handle.net/10016/9867
[EADSIW2010]. Requirements Quality Monitoring - Main results and outcomes, RAMP Workshop June 10th, 2010.
[Fanmuy2010] G. Fanmuy et al., Requirements Analysis and Modeling Process (RAMP) for the
Development of Complex Systems, INCOSE Symposium 2011, Chicago.
[GAO2004] United States General Accounting Office, Defense Acquisition: Stronger Management
practices are needed to improve DOD’s software-intensive weapon acquisitions, 2004
[Hull2010] Elizabeth Hull, Ken Jackson, Jeremy Dick. Requirements Engineering. Springer, 2010.
[Honour2010] Honour Eric, Systems Engineering return on investment (SE-ROI), INCOSE International
Symposium, Chicago, IL
[Kasser2004] Joseph E. Kasser. “The First Requirements Elucidator Demonstration (FRED) Tool”.
Systems Engineering 7(3):243-256, 2004.
[Kasser2006] Joseph E. Kasser, W. Scott, X.L. Tran, S. Nesterov. “A Proposed Research Programme for
Determining a Metric for a Good Requirement”. The Conference on Systems Engineering Research, Los
Angeles, California, USA, 2006.
[Kiyavitskaya2008] N. Kiyavitskaya, N. Zeni, L. Mich, D.M. Berry. “Requirements for tools for
ambiguity identification and measurement in natural language requirements specifications”. Requirements Engineering 13(3):207-239, 2008.
[Latimer-Livingston2003] Nicole S. Latimer-Livingston. Market Share: Requirements Management,
Worldwide,
2003
(Executive
Summary).
Gartner
Research,
1
July
2004
(www.gartner.com/DisplayDocument?ref=g_search&id=452522).
[NDIA2008] report CMU/SEI-2008-SR-034.
[Sadraei2007]
E. Sadraei, A. Aurum, G. Beydoun, B. Paech. “A field study of the requirements
engineering practice in Australian software industry”. Requirements Engineering 12(3):145-162, 2007.
[SGI2001] Standish Group International, Extreme Chaos, 2001
[SWEBOK2004]
SWEBOK Guide to the Software Engineering Body of Knowledge. IEEE Computer Society,
2004 (www.swebok.org/ironman/pdf/SWEBOK_Guide_2004.pdf).
[TRC] http://www.reusecompany.com. Website. Last visited 5th July 2011.
[Wilson1997] William M. Wilson, Linda H. Rosenberg, Lawrence E. Hyatt. “Automated Analysis of
Requirement Specifications”. Proceedings of the 19th International Conference on Software EngineeringICSE’97, May 17-23, 1997, Boston, Massachusetts, USA: 161-171.
[Withall2007] J. Withall. Software Requirement Patterns. Microsoft Press (2007).
12
9.
Biography
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 is the
Project leader of RAMP Project.
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 involved in AFIS (French Association on Systems Engineering, www.afis.fr) as Global
Processes Technical Committee. He was the chair for about 10 years of the Requirements Engineering
Working Group.
He is involved in INCOSE (International Council on Systems Engineering, www.incose.org) as Chair an
international WG: Systems Engineering for Very Small and Small Entities and small project (VSMEs),
and as an active member of Requirements WG, Bio-Medical WG.
He is co-founder of the SPECIEF association for the promotion of Requirements Engineering in French
(www.specief.org). He is a member of IREB (International Requirements Engineering Board,
www.certified-re.de) and is one of the authors of the French version of IREB syllabus.
Juan Llorens received his MS degree in Industrial Engineer from the ICAI Polytechnic
School at the UPC University in Madrid in 1986, Spain, and his PhD in Industrial Engineering and robotics at the Carlos III University of Madrid, Spain in 1996. In 1987
he started his own company dealing with Artificial Intelligence applied to Database
systems (Knowledge Engineering SL). Dr. Llorens worked for the industry as technical
director and Marketing Director in KE and Advanced Vision Technologies until 1992,
when he joined the Carlos III University in 1992. Since 2003 he is Professor of the Informatics
Department of the University. His main subject is Software Reuse, which he teaches in the Informatics
and Information Science graduate studies at the University. Dr. Llorens is the leader of the KR Group
(Knowledge Reuse Group) within the University. In 1998 he was invited to the Högskolan på Åland (HÅ)
(Mariehamn, Åland, Finland). From 1998 to 2008 he split his educational activities between Madrid’s
University and the HÅ, where he taught Object Oriented Software design.
Since 1999 he is in the board of CISET, a spin-off company of the Carlos III University of Madrid.
His current research involves the study of Knowledge technologies and Software Engineering techniques
integration towards Software and Information Reuse. He is member of INCOSE’s (International Council
on Systems Engineering, www.incose.org) Requirements Working Group.
Anabel Fraga is a Computer Engineering professional. Previous to set aside in the academic work, she committed her efforts in the industry as UNIX Administrator (HP-UX, Digital Unix,
and so forth), Application Administrator (SICAP, Comptel technology for Telecom companies),
Windows Administrator, Network Management and Project Management. She obtained the E-commerce
and Networking MSc, and her Computer Science PhD in the Carlos III of Madrid University. Her central
areas of research are: Software Architecture, Software Engineering, Information/Knowledge Engineering,
innovative ontology methodologies of development and Reuse; but she is also interested in ethics and
innovative learning methods for supporting new software architects. She is also interested in quality
improvements in the areas of IT and Requirements. She is certified in ITIL v2, ITIL v3, ISO20000 and
obtained the EXIN Trainer Certification. She is currently professor of Software Engineering, ITIL,
ISO20000, and Information Engineering in the Carlos III of Madrid University. She is member of ACM
CSTA, INCOSE and IASA.
View publication stats