G Model

COMIND-2586; No. of Pages 11

Computers in Industry xxx (2014) xxx–xxx

Contents lists available at ScienceDirect

Computers in Industry
journal homepage: www.elsevier.com/locate/compind

A methodology for supporting requirement management tools (RMt)

design in the PLM scenario: An user-based strategy
Maria Grazia Violante *, Enrico Vezzetti 1
Politecnico di Torino, DIGEP-Department of Management and Production Engineering, Corso Duca degli Abruzzi, 24, 10129 Torino, Italy

A R T I C L E I N F O A B S T R A C T

Article history: In the current ‘‘mass customization’’ scenario, product complexity is increasing significantly due to the
Received 24 May 2013 necessity to answer as quickly and effectively as possible to many different costumer needs but
Received in revised form 18 April 2014 maintaining costs under control. In this scenario, requirements management becomes a fundamental
Accepted 6 May 2014
features for the entire product lifecycle, as enterprises need to have a complete and clear idea of the
Available online xxx
market for succeeding in developing and supporting the right and innovative product. Moreover,
considering that product lifecycle is characterized by many ‘‘trade-off’’, so that product features are often
Keywords:
negotiated in order to fulfil to conflicting requirements, it is important to support the ‘‘traceability’’ of the
Requirements management
Customer requirements
entire lifecycle ‘‘negotiation’’ process. For this reason, PLM platform has to provide suitable
Product Lifecycle Management methodologies and tools able to efficiently support the design and management of large set of
Kano complex requirements. Requirements Management Tools (RMt) embedded in PLM solutions help
Satisfaction keeping specifications consistent, up-to-date, and accessible. At present, there are different possible
solutions, but a shared PLM integrated seems not to be available. In order to fill this gap, this paper has
developed an user-based strategy, based on Kano methodology, so on ‘‘user satisfaction’’, in order to
define a structured set of guidelines to support the design of the features of an integrated PLM
requirement management tool.
ß 2014 Elsevier B.V. All rights reserved.

1. Introduction quality of products and procedures. The PLM approach support the
connection between single processes and the whole product
Innovation and new product development are essential for lifecycle process management (Table 1).
most companies to sustain future revenue growth. Customers Among these processes, the Requirements Management one
demand more new products in shorter time intervals, often enables users in requirements-driven product development
customized to their own needs. They want more attractive designs, environments to define, develop, capture, and incorporate product
better performance, better quality, lower prices, and instant requirements of all kinds, customer, technical, regulatory, etc., in a
availability. To meet these needs, companies have to be able to single dynamic repository.
collaborate closely within their own organization and with Today, as the product projects are getting more and more
partners and suppliers located in various parts of the world. At complex, the management of their requirements is getting more
the same time companies have to manage increasing product and essential. In order to have right requirements, it is necessary to use
manufacturing complexities due to a quickly growing number of the right tools and methodology. To remain competitive in current
environmental and regulatory rules and requirements. Using a rapidly changing business climate, it is important to identify
Product Lifecycle Management (PLM) strategy to manage product customer needs and transform them into design of customer-
data, and to integrate and automate business processes generally oriented RM application. So it is imperative that customers play an
results in efficiency improvements, which consequently enable active part in the development process in order to deliver a high
companies to develop more new products, shorten time-to- quality application. Conversely, poor understanding of customer
market, reduce costs, increase productivity, and improve the needs and inaccurate assumptions made during the analysis of
customer needs may adversely influence design and manufactur-
ing of the products in terms of quality, lead time, and cost [1]. As
* Corresponding author. Tel.: +39 011 5647267; fax: +39 011 5647299. the competition for new markets increased, customer satisfaction
E-mail addresses: [email protected] (M.G. Violante), also became a key factor for business success and a major concern
[email protected] (E. Vezzetti). of the companies. Satisfaction ratings are being used as an
1
Tel.: +39 011 5647274; fax: +39 011 5647299.

http://dx.doi.org/10.1016/j.compind.2014.05.001
0166-3615/ß 2014 Elsevier B.V. All rights reserved.

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

2 M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx

Table 1 requirements catalogue to help: users to compare and select

Processes usually automated with PLM systems.
requirements management tools; tool providers to direct future
Process PLM systems tool developments. On the basis of specific industrial scenarios, the
 Portfolio Management Sales and Marketing paper of Beuche et al. [7] derives important requirements that have
 Proposal Response to be observed if requirements management tools are to be
usefully applied to product lines.
 Early Sourcing Sourcing
 Component and Supplier Management Most of these studies provide a list of features through which a
number of leading commercial and open-source tools can be
 Product Support Analysis and Planning Customer Service
compared, but they are strictly linked with the specific vendor
 Technical Information Creation and Delivery and Support
 Performance Analysis and Feedback solution rather than with the real needs of the Requirement
Management tasks and stakeholders (users or costumers who pay
 New Product Development and Management
for the system; developers who design, construct, and maintain the
Introduction (NPDI)
 Program Management system; users who interact with the system to get their work
 Project Management done).
 Requirements Management So, in order to support the definition of a complete set of
 Change Management (ECR/ECO)
features that the RM tools have to provide for supporting
 Concept Development Engineering efficiently the entire product lifecycle, this paper wants to propose
 System Design an objective methodology, disjoined by the specific vendors, that
 Detailed Design
focuses the attention on the real needs of RM process. For reaching
 Configuration Management
 Variant Design and Generation this aim it is necessary to involve in the study the RM stakeholders
 Verification and Validation and capturing their point of view as ‘‘users’’. Each user has a unique
 Design Outsourcing view on the ‘‘system’’, so users must be involved in the tool analysis
 Quality and Reliability Management Quality Assurance and and design. So users’ activities have to be linked, their needs and
 Regulatory Compliance Regulatory Affairs perspectives have to be considered from earlier design stages, and
their achieved degree of satisfaction has to be tracked [8]. The level
 Manufacturing Process Management Manufacturing
 Tooling Design and Manufacture of satisfaction is ultimately dependent on the fulfilment of user
 Manufacturing Outsourcing needs. The quality of a product or service is a key element in
creating user satisfaction. If we do not demand that the
requirements meet certain quality criteria, then it will be more
indicator of the performance of services and products and help to difficult to search for quality in later development phases [9]. Since
formulate strategies of the companies [1]. Hanan and Karp [2] have the impact on user satisfaction is different for each user
stated that ‘‘Customer satisfaction is the ultimate objective of requirement, it is important to determine which attributes of a
every business: not to supply, not to sell, not to service, but to product or service bring more satisfaction than others.
satisfy the customer needs that drive companies to do business.’’ For that reason a Kano model has been employed for designing
The objective of the product specification definition activity is to our strategy, for capturing the RM users voice and for identifying
turn customer needs into a product specification [3]. Customer which attributes drive them to real satisfaction. The paper is
needs represent the ‘‘problems’’ the product must solve, e.g. organized as follows: in Sections 2 and 3, we present a brief
functional features, durability, etc., while a product requirement introduction to Requirement Management and Kano model; in
specification is a formalized specification of customers’ require- Section 4, we explain our methodology and in Section 5 we present
ments, considering also performance and cost constraints. An the obtained results.
efficient requirements management comprehends the tracking of
evolving requirements over the entire product lifecycle and the 2. Requirement management
identification of impacts from changes [4]. It is necessary to
guarantee the agreement of the parties, recognize the deviations or Schwaber and Sterpe [10] provide a definition of requirements
changes in the project requirements, and renegotiate them. So the management: ‘‘The storage of requirements, the tracking of relation-
key point is gathering the right requirements and keeping them ships among requirements, and the control of changes to individual
updated in order to accomplish the project and to have the right requirements and groups of requirements’’. More in detail, require-
product. ment management could be stated with four different tasks. The
In order to reach this aim it is necessary to support the first one is requirements elicitation. This is the process through
Requirement Management with the right methodologies and which the product developers (designers) discover, review,
integrated PLM platform tools. articulate and understand the users’ (potential customers) needs
Focusing the attention on tools, it is possible to say that at and project constrains on development activities [11]. This phase is
present different solutions that help keeping specifications dedicated to convert tacit and subjective needs into explicit
consistent, up-to-date, and accessible are available. These have statement. Usually users are not good at describing what they
been growing steadily in recent years. There are so many tools and need; this is because in the first step users’ needs must be caught
correlated methodologies currently on the market that claim to and organized to prevent ambiguity or misunderstanding from
support the requirements management process (or part of it). In arising before significant work is done. Since there are many kind
the technical literature, a high number of evaluation frameworks (lead users, professional, etc.) involved, the ability of the analyst is
exists to assist practitioners in selecting requirements manage- to understand each need and to resolve the conflicts that may arise.
ment tools. For example Hoffman et al. [5] present a role-oriented The second task is the requirements analysis that supports the
perspective on the required features of a requirements manage- developers to arrive to a definition of users’ needs in order to define
ment tool and offer a comprehensive catalogue of requirements for product features. This phase requires analysing needs and
requirements management tools based upon this work. Gotel and understanding preferences; it involves a classification and
Mader [6] provide a mini-tutorial with a high-level guidance on prioritization of requirements, as these are not equally important.
designing a requirements management solution and selecting a The analysis involves the refinement of requirements through
requirements management tool. Hoffmann et al. [5] present a many stages in order to achieve a more detailed description of

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx 3

Fig. 1. Kano model of user satisfaction.

requirements. The third task is requirements specification that meeting the user basic quality needs, it provides the foundation for
consists in the creation of a structurally concrete and precise the elimination of dissatisfaction and complaints. By exceeding
specification of product requirements based on functional expectation it creates a competitive advantage and leads to
knowledge that has been elicited from users [12]. The last one innovation [25]. By the use of the theory of attractive quality for the
is requirements verification and validation that checks the quality analysis of improvement opportunities in products and services
of the requirements and whether requirements specification [14] and the model of excitement and basic quality [1,15], it is
reflects users’ needs. Validation is an evaluation process to possible to take into consideration the asymmetrical and non-
determine if it meets requirements or not; instead verification is linear relationship between performance and satisfaction (Fig. 1).
defined as a process used to establish if product reflects For this reason in the Kano model, positive (functional) and
specification requirements [12]. negative (dysfunctional) questionnaires are conducted to collect
For supporting an efficient Requirements Management process, the satisfaction difference per item from the interviewees, and to
firms need to have specific tools. These can assist organizations in judge the specific quality of each item represented according to the
defining and documenting requirements by allowing them to store ‘‘Kano evaluation form’’ (Table 2) [14].
requirements in a central location. Project teams can then access Table 3 shows Kano quality categories. According to them, it is
the requirements to determine what is to be developed, and possible to classify an item (or attribute, feature, etc.) of the
customers can access the requirements to ensure that their needs analysed product/service.
were correctly specified. To understand the working of a RM tool, From an operative point of view, in order to collect all the
CPDA cites the example of an Aerospace program[27]: ‘‘it starts necessary information for the analysis, it has been necessary to
with several thousand customer requirements at the system level, and employ a questionnaire. The questionnaire design has been
several hundred thousand at the lowest level defining components, implemented by the formulation of a pair of questions for each
with an equivalent number of verification and test items. In a perfect product feature for which you desire user feedback. The first
world, the cascading requirements and related information will be question in each pair of questions for a product feature refers to a
defined once, and relied on for the duration of the project. In reality, situation in which the feature is met, and it is worded in a format
requirements are always on the move. Users often change their mind, similar to the following: ‘‘If [the product] satisfied [feature x], how
or develop a better understanding of the targeted needs after looking would you feel?’’ This is the functional question. The second
at the initial design; market drivers change over the duration of the question in each pair refers to the case where the feature is not met.
development project; authorities keep adding new constraints related This is called the dysfunctional question and it is worded in a format
to environmental or safety concerns; and sometimes the project similar to the following: ‘‘If [the product] did not satisfy [feature x],
encounters difficulties that require a revision of the initial targets. All how do you feel?’’ For each question, the user can answer in one
those issues necessitate that the requirements management tool has out of five different ways: (1) I like it; (2) I expect it; (3) I am
the ability to deal with change management, change impact analysis, neutral; (4) I can tolerate it; (5) I dislike it. By combining the two
revisions, options, baselines and effectivities’’. answers in the Kano evaluation table, the items of the product/
service can be classified into one of six quality categories:
3. Introduction to Kano model attractive quality (A), one-dimensional quality (O), must-be
quality (M), indifferent quality (I), reverse quality (R), or
The Kano model of customer satisfaction is a useful tool to questionable result (Q). If the user answers, for example, ‘‘I like
categorize product attributes based on how they are perceived by it’’ as regards ‘‘If [the product] satisfied [feature x], how would you
the customers and their effect on customer satisfaction [13,14]. By feel?’’ in the functional form of the question, and answers ‘‘I dislike

Table 2
Kano evaluation form.

Dysfunctional

I like it I expect it I’m neutral I can tolerate it I dislike it

Functional I like it Questionable Attractive Attractive Attractive One-dimensional

I expect it Reverse Indifferent Indifferent Indifferent Must-be
I’m neutral Reverse Indifferent Indifferent Indifferent Must-be
I can tolerate it Reverse Indifferent Indifferent Indifferent Must-be
I dislike it Reverse Reverse Reverse Reverse Questionable

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

4 M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx

Table 3 In order to classify each feature in the Kano quality category, it

Quality category.
is necessary to process the results on the basis of the highest
Quality category Description response frequency obtained from the questionnaire. But if two or
Attractive Attractive quality features are the product criteria more Kano quality category had obtained the same frequency
which have the greatest influence on how satisfied a value, the authors have considered the following order
user will be with a given product. Attractive features M > O > A > I (that is the classification with the greatest impact
are neither explicitly expressed nor expected by the on the product) to decide the quality category.
user. Fulfilling these features leads to more than
In order to find out which feature can influence user
proportional satisfaction. If they are not met,
however, there is no feeling of dissatisfaction. satisfaction, the user satisfaction (CS) index is calculated [15].
One-dimensional These one-dimensional quality features are The CS index is indicative of how strongly a product feature may
positively and linearly related to user satisfaction. influence satisfaction or, in case of ‘‘non-fulfilment’’, user
The user satisfaction is proportional to the level of
dissatisfaction. The formulas to calculate the extents of satisfaction
fulfilment of these features: the higher the level of
fulfilment, the higher the user’s satisfaction, and vice
and of dissatisfaction are the following:
versa. One-dimensional features are usually
explicitly demanded by the user. AþO
extent of satisfaction : ;
Must-be This is the basic criteria of a product/service. If these AþOþMþI
features are not fulfilled, the user will be extremely OþM
extent of dissatisfaction : :
dissatisfied. On the other hand, as the user takes ðA þ O þ M þ IÞ  ð1Þ
these features for granted, their fulfilment will not
increase his satisfaction. The user regards the must- The extent of satisfaction (or positive CS index or Better value)
be features as prerequisites; he takes them for ranges from 0 to 1. If the value is close to 1, it means that the
granted and therefore does not explicitly demand
them. If they are not fulfilled, the user will not be
feature has a positive effect on increasing user satisfaction; when
interested in the product, service or process at all. the extent of dissatisfaction (or negative CS index or Worse value)
Indifferent An attribute whose presence or absence does not is close to 1, it means that the feature can decrease user
cause any user satisfaction or dissatisfaction. satisfaction.
Reverse An attribute whose presence causes user
dissatisfaction, and whose absence results in user
satisfaction. 4. Methodology

Our proposed methodology based on the Kano model follows

two steps. The first step is the identification of the RM tool features
it’’ as regards ‘‘If [the product] did not satisfy [feature x], how do and the last one is the development and administration of the
you feel?’’ in the dysfunctional form of the question, the ‘‘Kano-questionnaire’’.
combination of the questions in the Kano evaluation table finds
an ‘‘O’’, indicating that ‘‘feature x’’ is a one-dimensional quality 4.1. Step1: Identification of the RM tool features
item from the perspective of users (Fig. 2). If combining the
answers yields category I, this means that the user is indifferent to Starting from the International Council on Systems Engineering
this ‘‘feature x’’. The user does not care whether it is present or not. (INCOSE) survey of requirements modelling tools, it has been
The user is, moreover, not willing to spend more on this feature. possible to have a first idea about how software vendors assess
Category Q stands for a questionable result. Normally, the answers their product, working on 80 questions ranging from software
do not fall into this category. Questionable scores signify that the support to modelling capabilities [24]. Together with the INCOSE
question was phrased incorrectly, or that the person interviewed data, Vrinat’s survey has been taken into account too [26]. He
misunderstood the question or crossed out a wrong answer by conducted an analysis over eight requirements management tools
mistake. If looking up the answer in the evaluation table yields and evaluated them against one-hundred criteria. In order to
category R, this ‘‘feature x’’ is not only not wanted by the user but complete the questionnaire design, the authors have considered an
he/she even expects the reverse. evaluation work based on demonstrations and discussion with

Dysfunctional question:
“If [the product] did not satisfy [feature x], how do you feel?”

I can tolerate
I like it I expect it I’m neutral
it I dislike it

Functional
question:
If [the I like it One-dimensional
product]
satisfied I expect it Reverse Indifferent Indifferent Indifferent Must-be
[feature x], I’m neutral Reverse Indifferent Indifferent Indifferent Must-be
I can tolerate it Reverse Indifferent Indifferent Indifferent Must-be
how would
you feel?”
I dislike it Reverse Reverse Reverse Reverse Questionable

Fig. 2. Functionality of Kano evaluation table.

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx 5

Table 4
Features of RM tools and their description.

Feature of RM tool Feature Description

code

Easy to use and minimal training R1 The RM tool is user friendly when it is easy to use with minimal training.
Simple framework R2 A User interface that enables the inexperienced user to interact successfully with the tool.
Requirement identification and R3 A clear definition of requirements is necessary as the requirements drive cost, schedule, skills required,
Capture resources required, verification plans and schedules and operational procedures. The consequence of poor
requirements is that the user does not get what they want, when they want it and for the price that is
competitive.
 Input document enrichment/analysis: using existing document information (such as glossary, and index),
aid the user in requirements analysis, identification of requirements, etc.
 Input document change/comparison analysis: the ability to compare/contrast two different versions of a
source document.
 Automatic parsing of requirements: a mechanism for automatic identification of requirements by key
words, structure, unique identifiers, etc. to create requirements from the text.
 Interactive/semi-automatic requirement identification: the ability to identify requirements from a text file
via interactive means such as mouse highlighting of the requirement text or prompting by the system ‘‘is
this a requirement?’’
 Manual requirement identification: a manual means of identifying or creating requirements.
 Batch mode operation: a mechanism for inputting/identifying requirements from outside of the tool.
 Batch-mode document/source-link update: does the tool have the ability to update existing linked
documents from new/changed versions of the source documents without having to re-establish traceability
links.
 Requirement classification: does the tool have the ability to classify/categorize requirements during
identification.
Capturing system element structure R4 Once the requirements have been captured, the allocation of requirements to sub-system elements takes
place. The tool must capture these elements so links/allocations can be made to those sub-systems elements
 Graphically capture systems structure: Can the tool graphically capture system implementation (such as
architecture, functional decomposition, and WBS – Work Breakdown Structure) and display them
graphically such that requirements can be linked to them.
 Textural capture of systems structure: Can the tool textually capture system implementation (such as
architecture, functional decomposition, WBS) and display them textually such that requirements can be
linked to them.
Handle a large set of documents R5 The tool must be able to manage large of requirements. Increased numbers of users, end users, developers,
subcontractors, product features, external system interfaces, etc. come along with increased number of
requirements generated in the Requirements Engineering – RE process
Being able to support R6 The tool must be able to complex sets of requirements.
complex set of
documents
Customizable R7 The users must be able to customize the standard views without changing the template. The user interface
of the tool also must be customizable with a standard script language.
Extensibility R8 The RM Tool must be adaptable and extensible to the needs of the organization or project. The tool must
provide an open and well-documented object model and an API which makes all data and functions
accessible to extensions. The user interface of the tool must be extensible with a standard script language.
Linking and tracing R9 The tool must maintain traceability, as the ability to describe and follow the life of a requirement, in both a
forwards and backwards direction (i.e., from its origin, through its development and specification, to its
subsequent deployment and use, and through all periods of on-going refinement and iteration in any of
these phases). Tracing individual requirements to other system components helps ensure that your team
does not inadvertently overlook any requirements during implementation. You can define links between
different kinds of requirements and between requirements in different subsystems. When analysing the
impact of a change proposed in a specific requirement, the traceability links reveal the other system
elements that the change might affect.
Requirement hierarchies R10 Without the capability of identifying and managing dependencies among requirements, keeping track of
elaborate requirements hierarchies that include both parent/child relationships and arbitrary relationships
can be downright gruelling.
Identify inconsistence R11 The RM tool should allow the user to identify inconsistencies such as unlinked requirements or system
elements (orphans).
Storing R12 The RM tool must support baselines. A baseline is the state of a (specified subset of the) requirements
database fixed at a given point in time. Baselining requirements are like taking a snapshot of their state at a
point in time both individually and in aggregate and then applying a label to it. Requirements management
tools should store baselines in a secure repository accompanied by information about the act of creating the
baseline potentially in the form of electronic signatures.
Comparing R13 Because individual requirements and the collection of requirements that correspond to a development
effort will change over time, requirements management tools need to include baselining capabilities to
determine the differences between various baselines.
Reusability of Requirements R14 The reuse of requirements across projects permits to build up a repository of all of the requirements that
have ever been fulfilled – to make it easy to search across all of these requirements – and thus to raise
awareness of redundancy in software assets. So enterprise-level requirements can be linked to project-level
requirements. Copying and pasting requirements from project to project, parent/child relationships with
inheritance among enterprise- and project-level requirements are true support for reuse of requirements.
Workflow Capabilities R15 To automate the processes that surround requirements change, requirements management tools should
include workflow capabilities, including graphical utilities for workflow design and form design and
extensibility to support initiation of arbitrary internal and external events. Workflows can help to
implement a certain RE process and can improve consistency and standardization of the requirements.
Reporting and Analysis R16 The tool must generate freely configurable change reports. These reports should relate to views, baselines
and generated documents. The tool could analyse changes to provide information about the project status.
The tool should be able to analyse requirements. Examples are linguistic analysis, analysis of the link
structure, analysis of project progress and risk management.

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

6 M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx

Table 4 (Continued )

Feature of RM tool Feature Description

code

Change Management R17 The tool must offer the possibility to handle formal change requests. This function must be customizable to
the change process of the users. Especially in the late phases of a project, a restrictive change management is
important. The straightforward changes in earlier project phases must be possible as well.
Requirements Definition Features R18 To help elicit and specify requirements. While many requirements management tools offer support for
inputting requirements through bulk import or even customized forms, they do not help to elicit or to
specify requirements.
Decision Support Capabilities R19 To facilitate prioritization and selection of requirements. Once requirements have been defined, the task of
determining which will be fulfilled and in what order remains.
Requirements Validation Capabilities R20 To assess the quality of requirements. Many IT organizations expect their requirements management tools
to measure or even to improve the quality of their requirements. But requirements management tools are
agnostic about requirements contents: They store, associate, and version requirements without any respect
to their quality.
Integration with other life-cycle R21 Requirements management tools manage relationships among requirements, for example between
tools business requirements, functional requirements, and technical specifications. Integrations between
requirements management tools and tools for activities like software configuration management, build
management, and test management are required for this chain of traceability to extend through the lifecycle
without significant manual effort.
Security capabilities R22 Specification of who has authorized access to the system and under what circumstances that access is
granted. It is important to set access permissions for users. Web access lets you share requirements
information with all team members, even if they are geographically separated
Integration with Web R23 The tool should have a web interface or another browser-based client that makes it unnecessary to install a
client application for occasional users. Web interfaces offer a reliable and easily manageable possibility to
work with the requirements. They are interesting for collaboration with external partners (‘‘extranet’’) and
for internal users that use the tool only occasionally.
Collaborative Working R24 Many users should be able to work on the same data at the same time. Of the many users working on an
object, only one must be able to apply changes. If a user changes an object, it should refresh automatically in
the user interfaces of the other users.
Ms Word Support R25 The RM Tool should support Ms Word as an input mechanism, whether that’s through utilities that parse
Word documents to import requirements and associated metadata, plugins that expose requirements
management toolbars within Word, or a Word-like interface in the requirements management tool.

tools vendors [11], a critical evaluation of existing tools conducted processes must be facilitated with the automatic linking of related
by James [12] and Grady [16], a user cases scenarios analysis requirements and the inheritance of attributes [26]. So this phase
evaluated by Gabb et al. [17] and material coming from a work on may necessitate features such as R3 – Requirement identification and
tool selection criteria conducted by Daimler Chrysler [23] and Capture, R4 – Capturing system element structure, R5 – Handle a large
Jones et al. [18], Schwaber and Sterpe [10], and Regnell et al. [19]. set of documents, R6 – Being able to support complex set of document,
By the use of a cluster analysis approach [20], [21] on the R8 – Extensibility, R9 – Linking and tracing, R11 – Identify
information obtained by the previous surveys and evaluations, it inconsistence, R12 – Storing, R13 – Comparing, and R16 – Reporting
has been possible to provide a first features set of RM tools and Analysis. The feature R18 – Requirements definition features
(Table 4). In addition, starting from the four phases (elicitation, supports the ‘‘Requirement Specification’’ phase. Capabilities in
analysis, specification, verification and validation) in which RM is support of ‘‘verification and validation’’ phase are: (a) consistency
structured within a company, we have identified which features of checks for isolated items such as a requirement or a function, for any
Table 4 best support these tasks. lack of attributes, for un-allocated requirements, and for un-justified
Requirement elicitation involves seeking, uncovering, acquiring functions; (b) links between requirements and their associated
and elaborating requirements. So storing all source documents, documents covering tests or specifications; (c) creation and storage
notes, and observations from stakeholders interviews or work- of customizable views of requirements; (d) access for large numbers
shops in a database, and building a tracking list of those documents of stakeholders and users for reviewing and commenting on
permit a requirement identification and capture [26]. In this phase, requirements; (e) access rights for users and groups for each
the documents and requirements can be organized in tree requirement, including full access, read only, and read-write; (f)
structures or views, as well as the identification of stakeholders history of all changes for each requirement; (g) storage and
with their roles and responsibilities can be saved, and that data can management of the review and inspection of the results, including
be managed. The requirements can be imported from multiple information on how it was done and who was responsible; (h)
sources and formats – text in a Word file, parameters in an Excel traceability of verification and validation cases to requirements; (i)
spread sheet, etc. In addition it could be necessary to import of traceability of the validation cases to validation procedures; (j) and
requirements from another project for re-use. So features as, for storage and management of verification and validation plans and
example, R3 – Requirement identification and Capture, R4 – procedures [26]. So for this phase, it is important to provide some
Capturing system element structure, R9 – Linking and tracing, R10 features such as R4 – Customizable, R4 – Linking and tracing, R11 –
– Requirement hierarchies, R12 – Storing, R14 – Reusability of Identify inconsistence, R12 – Storing, R17 – Change Management, R20
Requirements, R15 – Workflow capabilities, R18 – Requirements – Requirement Validation Capabilities, R22 – Security capabilities, R23
Definition features, R21 – Integration with other life-cycle tools, and – Integration with Web, and R24 – Collaborative Working.
R25 – Ms Word Support could support this phase. Other features such as R1 – Easy to use and minimal training and
With regard to ‘‘Requirement analysis’’, it involves the R2 – Simple Framework cover aspects related to user interface of
refinement of requirement through the decomposition of high RM tools. In fact an easy-to-use interface must serve a broad range
level descriptions into more details which may entail building of occasional users who are not experts with the specific software
models, evaluating feasibility, analysing overlaps or conflicts to achieve the full payoff of requirements management. A simple
between requirements, and negotiating priorities. Refining or user interface represents a key aspect for the broad acceptance
deriving requirements through the flow-down and flow-across needed for a successful implementation.

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx 7

4.2. Step 2: Design and administering of the ‘‘Kano-questionnaire’’

To design the questionnaire, it is necessary to formulate a pair

of questions for each identified RM tool feature for which a
customer feedback is desired. The appendix A shows the
constructed questionnaire. Then, the Kano questionnaire was
distributed to RM tools users in the field of automotive, aircraft and
defence, who have experience in these tools indispensable to
gather, analyse, document and manage requirements of ‘‘complex
systems/products’’. The Kano questionnaire was administered via
e-mail with a letter of introduction, explaining the questionnaire
purpose, sent together with some operative instructions.

5. Results and discussion

Fig. 3. RM tools features fulfilment percentage.
The results obtained analysing the survey results, developed on
thirty feedback, have been quantified in Table 5.
The features of RM tools have the percentage of fulfilment
showed in Fig. 3 and classified in the following way: large set of documents, R6 – Being able to support complex set of
Dissatisfiers or Basic Needs or Must-be needs are expected documents, R15 – Workflow capabilities, R21 – Integration with other
features of a product or service (legible forms, correctly spelled life-cycle tools, R22 – Security capabilities, and R24 – Collaborative
name, basic functionality). These needs are typically ‘‘unspoken.’’ If working.
these needs are not fulfilled, the user will be extremely dissatisfied. Indifferent Features in RM tools are: R1 – Easy to use and minimal
For RM tools, examples of ‘‘unspoken’’ needs are: R3 – Requirement training, R2 – Simple framework, R19 – Decision support capabilities,
identification and Capture, R9 – Linking and tracing, R10 – R23 – Integration with web, and R25 – Ms Word support. In this case,
Requirement hierarchies, R12 – Storing, R14 – Reusability of user is indifferent to whether the feature is present or not.
requirements, R18 – Requirements definition features, and R20 – In Table 6 and Fig. 4, how each feature can influence user
Requirements validation capabilities. satisfaction is described. The extent of satisfaction (or positive CS
Satisfiers or Performance Needs or One-dimensional needs are index or Better value) ranges from 0 to 1; the closer the value is to
Standard features that increase or decrease satisfaction by their 1, the higher the influence on user satisfaction. In Table 5 these
degree (cost/price, ease of use, speed). These needs are typically values are highlighted. A positive CS index which approaches 0
‘‘spoken.’’ For RM tools, one-dimensional features are: R7 – signifies that there is very little influence. At the same time,
Customizable, R8 – Extensibility, R11 – Identify inconsistence, R13 – however, one must also take the negative CS coefficient into
Comparing, R16 – Reporting and analysis, and R17 – Change consideration. If it approaches 1, the influence on user
management. dissatisfaction is especially strong if the analysed feature is not
Delighters or Excitement Needs or Attractive needs are unexpected fulfilled (in Table 6 the values closer to 1 are highlighted). A
features that impress users and earn the company ‘‘extra credit.’’ minus sign is put in front of the CS index of user dissatisfaction in
These needs also are typically ‘‘unspoken.’’ For RM tools, Attractive order to emphasize its negative influence on user satisfaction if this
Features are: R4 – Capturing system element structure, R5 – Handle a feature is not fulfilled.

Table 5
Results.

Feature of RM tool Feature code A O M I Result

Easy to use and minimal training R1 20% 30% 7% 43% I

Simple framework R2 17% 23% 27% 33% I
Requirement identification and Capture R3 0% 30% 70% 0% M
Capturing system element structure R4 43% 23% 23% 10% A
Handle a large set of documents R5 77% 23% 0% 0% A
Being able to support complex set of documents R6 77% 13% 10% 0% A
Customizable R7 10% 47% 40% 3% O
Extensibility R8 10% 53% 33% 3% O
Linking and tracing R9 0% 23% 77% 0% M
Requirement hierarchies R10 0% 33% 80% 0% M
Identify inconsistence R11 30% 43% 27% 0% O
Storing R12 13% 40% 47% 0% M
Comparing R13 10% 57% 33% 0% O
Reusability of Requirements R14 0% 40% 60% 0% M
Workflow Capabilities R15 37% 30% 30% 3% A
Reporting and Analysis R16 10% 47% 30% 13% O
Change Management R17 3% 53% 43% 0% O
Requirements Definition Features R18 7% 40% 57% 0% M
Decision Support Capabilities R19 13% 13% 13% 57% I
Requirements Validation Capabilities R20 0% 33% 67% 0% M
Integration with other life-cycle tools R21 77% 23% 0% 0% A
Security capabilities R22 67% 17% 17% 0% A
Integration with Web R23 23% 10% 13% 53% I
Collaborative Working R24 43% 23% 33% 0% A
Ms Word Support R25 0% 23% 23% 53% I

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

8 M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx

Table 6 This study has computed the user satisfaction (CS) index that
User satisfaction coefficient.
states whether satisfaction can be increased by meeting a product
Feature code Feature name Better Worse feature or whether fulfilling this product feature merely prevents
value value the user from being dissatisfied. For instance (see highlighted
R1 Easy to use and minimal training 0.50 0.37 ‘‘Better’’ values of Table 6), the features of RM tools which have the
R2 Simple framework 0.40 0.50 higher influence on user satisfaction because its CS coefficient is
R3 Requirement identification and Capture 0.30 S1.00 closer or equal to 1 are: R5 – Handle a large set of documents, R6 –
R4 Capturing system element structure 0.67 0.47
Being able to support complex set of documents, R21 – Integration
R5 Handle a large set of documents 1.00 0.23
R6 Being able to support complex set 0.90 0.23 with other life-cycle tools, and R22 – Security capabilities.
of documents If improvements in the RM tools are provided in terms of R3 –
R7 Customizable 0.57 S0.87 Requirement identification and Capture, R9 – Linking and tracing, R10
R8 Extensibility 0.63 S0.87
– Requirement hierarchies, R14 – Reusability of requirements, and
R9 Linking and tracing 0.23 S1.00
R10 Requirement hierarchies 0.29 S1.00
R20 – Requirements validation capabilities (which are the highlight-
R11 Identify inconsistence 0.73 S0.70 ed ‘‘Worse’’ values of Table 6), they can decrease user dissatisfac-
R12 Storing 0.53 S0.87 tion markedly.
R13 Comparing 0.67 S0.90 While improvements in the features of RM tools such as R7 –
R14 Reusability of requirements 0.40 S1.00
Customizable, R8 – Extensibility, R11 – Identify inconsistence, R12 –
R15 Workflow capabilities 0.67 S0.60
R16 Reporting and analysis 0.57 S0.77 Storing, R13 – Comparing, R15 – Workflow capabilities, R16 –
R17 Change management 0.57 S0.97 Reporting and analysis, R17 – Change management, and R24 –
R18 Requirements definition features 0.45 0.94 Collaborative working (which are the highlighted ‘‘Worse’’ and
R19 Decision support capabilities 0.28 0.28
‘‘Better’’ values of Table 6) not only can increase users’ satisfaction
R20 Requirements validation capabilities 0.33 S1.00
R21 Integration with other life-cycle tools 1.00 0.23
but also can decrease users’ dissatisfaction.
R22 Security capabilities 0.83 0.33 Kano model and the Better/Worse value can help stakeholders
R23 Integration with web 0.33 0.23 to prioritize the features of RM tools. So it is possible to categorize
R24 Collaborative working 0.67 S0.57 user needs and provide appropriate actions or investments in user
R25 Ms Word support 0.23 0.47
satisfaction improvement in the context of RM products. RM tools
Notes: the highlighted Better values and worse values cause user satisfaction or stakeholders must fulfil all must-be or high Worse value elements
dissatisfaction.
to prevent user dissatisfaction, improve on one-dimensional and
high Better value of quality elements and provide attractive quality
elements.

Fig. 4. Influence of product features on satisfaction or dissatisfaction.

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx 9

6. Conclusion the most clear picture on RM scenario needs in order to provide the
appropriate correction action on their solution for increasing their
Customer satisfaction is related to the fulfilment of customer market quote. To deliver a high-quality application, it is imperative
needs. The fulfilment of those needs depends on the existence and that user play an active part in the development process. The
performance of certain customer requirements in the product or described methodology can be an effective means of communica-
service. Hence, there is a need to study and develop procedures tion essential to get the tool right the first time and avoid expensive
that can help a company or project team to gain knowledge of re-work later in the development cycle. The analysis result is also
customer requirements and satisfaction, and then develop useful for enterprises because they support the management in
products with innovative features. The Kano model provides an identifying which could be the real advantage of introducing in
effective approach to categorize user requirements and to their organization an integrated RM tool.
understand their nature. It is important to highlight that Kano The analysis results reflect the influence of the automotive,
model does not include a cost dimension but in our study this aircraft, defence background, as the considered voice of customer
factor is not relevant. Most of the traditional measures used in the comes from these sectors. However, the authors think that these
decision making process tend to be financial measures and outcomes could be useful to support the improvement of RM tools
business decisions and they are often taken in an attempt to for other domains. In fact, according to Schwaber and Sterpe [10],
maximize or reduce the impact of these financial indicators [22]. as business conditions change, requirements management tools
Our proposed methodology ranks features only according to their are essential to understand the impact of requirements change and
value to customers and users and not according to their estimated enforce the processes that surrounds it not only for the automotive,
cost of implementation. By including these customer-oriented aircraft, defence sectors (where the analysis was conducted) but
performance measures in the re-engineered process, the new also for other industrial contexts. So, considering that our study
business process will then have a customer orientation. was conducted using responses from segments portrayed by high
The proposed characterization offers a foundation to allow complexity products, many components, different disciplines, and
stakeholders (including customers, users, developers, researchers) configurations, in which requirement management is a key
to identify users’ needs and documenting these in a form that is element for the product development success, this result could
amenable to subsequent implementation. be employed also for other segments as naval, train, etc. where the
Drawing from the literature in the areas of Requirements same product complexity exists.
Management tools, many works have gave good overview of the The results obtained show that if features such as R5 – Handle a
main tools features and then have published evaluations and large set of documents, R6 – Being able to support complex set of
benchmarking reports on RM tools present on the market at that documents, R21 – Integration with other life-cycle tools, R22 –
time. In none of these works, the voice of the RM stakeholders is Security capabilities are included in enhanced RM tools, the user
considered, so in order to fill this gap this paper presents an satisfaction increases. Other features such as R3 – Requirement
evaluation methodology of RM tools features. The authors have identification and Capture, R9 – Linking and tracing, R10 –
identified a core set of features that a tool for requirements Requirement hierarchies, R14 – Reusability of requirements, R20 –
management must possess taking into account the previous Requirements validation capabilities decrease the user dissatisfac-
catalogues, surveys, researches conducted in this context. Then a tion. These results allow to know how to rank user needs; this can
Kano model has been designed to categorize the RM tools help developers plan releases by indicating which functions are
attributes relying on how they are perceived by the user and critical and which can be added (and in what order) over successive
their effect on user satisfaction. releases. Unambiguous knowledge about requirement priorities
The results of this methodology are helpful not only for RM tool help stakeholders to more effectively and efficiently manage
developers but also for enterprises that are looking for such a tool projects and allocate resources based on the requirement
for their core business. For SW developers, it is important to have importance to the project as a whole.

Appendix A. QUESTIONNAIRE

PART 1
Please answer the following questions by placing a check mark in the appropriate box corresponding your preference.

HOW DO YOU FEEL. . .? I like it I expected it I’m neutral I can tolerate it I dislike it

R1 If the RM tool is easy to use and requires a minimal training?

If the RM tool isn’t easy to use and doesn’t require a minimal training?
R2 If the RM tools has a simple framework?
If the RM tools hasn’t a simple framework?
R3 If the RM tool is able to identify and capture requirement?
If the RM tool isn’t able identify and capture requirement?
R4 If the RM tool is able to capture system element structure?
If the RM tool isn’t able to capture system element structure?
R5 If the RM tool is able to handle a large set of Documents?
If the RM tool isn’t able to handle a large set of documents?
R6 If the RM tool is able to support complex set of documents?
If the RM tool isn’t able to support complex set of documents?
R7 If the RM tool is customizable?
If the RM tool isn’t customizable?
R8 If the RM tool supports extensibility?
If the RM tool doesn’t support extensibility?
R9 If linking and tracing are supported by the RM tool?

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

10 M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx

Appendix A (Continued )

HOW DO YOU FEEL. . .? I like it I expected it I’m neutral I can tolerate it I dislike it

If linking and tracing aren’t supported by the RM tool?

R10 If the RM tool is able to do a requirement hierarchies?
If the RM tool isn’t able to do a requirement hierarchies?
R11 If the RM tool is able to identify inconsistence?
If the RM tool isn’t able to identify inconsistence?
R12 If the RM tool has a storing capabilities?
If the RM tool hasn’t a storing capabilities?
R13 If the RM tool has a comparing capabilities?
If the RM tool hasn’t a comparing capabilities?
R14 If the RM tool supports the reuse of requirements across projects?
If the RM tool doesn’t support the reuse of requirements across projects?
R15 If the RM tool includes workflow capabilities?
If the RM tool doesn’t include workflow capabilities?
R16 If the RM tool supports reporting and analysis?
If the RM tool doesn’t support reporting and analysis?
R17 If the RM tool supports change management?
If the RM tool doesn’t support change management?
R18 If the RM tool has requirements definition features?
If the RM tool hasn’t requirements definition features?
R19 If the RM tool has decision support capabilities?
If the RM tool hasn’t decision support capabilities?
R20 If the RM tool has requirements validation capabilities?
If the RM tool hasn’t requirements validation capabilities?
R21 If the RM tool supports integration with other life-cycle tools?
If the RM tool doesn’t support integration with other life-cycle tools?
R22 If the RM tool has security capabilities?
If the RM tool hasn’t security capabilities?
R23 If the RM tool has integration with web?
If the RM tool hasn’t integration with web?
R24 If the RM tool supports collaborative working?
If the RM tool doesn’t support collaborative working?
R25 If Ms Word is supported by the RM tool?
If Ms Word isn’t supported by the RM tool?

PART 2
Please answer the following questions.

1. What is your study degree?

–
2. Which RM tools did you use? Which one are you using now?
–
3. What is your expertise in requirement management?
–
4. Which company are you working at?
–
5. What is your role in the company?

References [14] N. Kano, et al., Attractive quality and must-be quality, Journal of the Japanese
Society for Quality Control 14 (2) (1984) 39–48.
[1] K. Matzler, H.H. Hinterhuber, How to make product development projects more [15] C. Berger, et al., Kano’s methods for understanding customer-defined quality,
successful by integrating Kano’s model of customer satisfaction into quality Center for Quality Management Journal 2 (4) (1993) 3–36.
function deployment, Technovation 18 (1) (1998) 25–38. [16] J. Grady, An open letter to the tool companies, in: Proceedings of 6th Intl
[2] M. Hanan, P. Karp, Customer Satisfaction How to Maximize, Measure, and Market Symposium of the National Council on Systems Engineering, 1996.
Your Company’s ultimate Product, American Management Association, 1989. [17] A.P. Gabb, N. Maheswaran, A.M. Allwright, Requirements Management Tools
[3] P. Nilsson, B. Fagerström, Managing stakeholder requirements in a product Evaluation User Needs and Evaluation Criteria, 1997 DTIC Document.
modelling system, Computers in Industry 57 (2) (2006) 167–177. [18] D.A. Jones, et al., Factors influencing requirement management toolset selection,
[4] G. Schuh, et al., Process oriented framework to support PLM implementation, in: Proceedings of the Fifth Annual Symposium of the National Council on
Computers in Industry 59 (2) (2008) 210–218. Systems Engineering, 1995.
[5] M. Hoffmann, et al., Requirements for requirements management tools, in: [19] B. Regnell, R.B. Svensson, K. Wnuk, Can we beat the complexity of very large-scale
Requirements Engineering Conference, 2004. Proceedings. 12th IEEE Internation- requirements engineering? in: Requirements Engineering: Foundation for Soft-
al, IEEE, 2004. ware Quality, Springer, 2008, pp. 123–128.
[6] O. Gotel, P. Mader, How to select a requirements management tool: initial steps, [20] G. Punj, D.W. Stewart, Cluster analysis in marketing research: review and sugges-
in: Requirements Engineering Conference, 2009. RE’09. 17th IEEE International, tions for application, Journal of Marketing Research (1983) 134–148.
IEEE, 2009. [21] C. Romesburg, Cluster Analysis for Researchers, Lulu.com, 2004.
[7] D. Beuche, et al., Using requirements management tools in software product line [22] H. Jagdev, P. Bradley, O. Molloy, A QFD based performance measurement tool,
engineering: the state of the practice, in: Software Product Line Conference, 2007. Computers in Industry 33 (2) (1997) 357–366.
SPLC 2007. 11th International, IEEE, 2007.
[8] L.C. Ballejos, J.M. Montagna, Modeling stakeholders for information systems Web references
design processes, Requirements Engineering 16 (4) (2011) 281–296.
[9] G. Génova, et al., A framework to measure and improve the quality of textual [23] DAIMLERCHRYSLER swt.cs.tu-berlin.de RM-Tool Evaluation, Requirements to RM
requirements, Requirements Engineering 18 (1) (2013) 25–41. Tools, 2004 (accessed April 2012).
[10] C. Schwaber, P. Sterpe, Selecting The Right Requirements Management Tool – Or [24] INCOSE, www.incose.org (accessed April 2012).
Maybe None Whatsoever, Forrester Research. Inc., 2007, 28th September. [25] ISIXSIGMA, http://www.isixsigma.com (accessed April 2012).
[11] I. Sommerville, P. Sawyer, Requirements Engineering: A Good Practice Guide, [26] Vrinat, M., 2006, Requirements Management: Solutions Review,’’ Stamford, Con-
John Willey & Son Ltd, England, 1997. necticut, http://www.nohau.se/file/cpda-analyst-report-report.pdf (accessed
[12] L. James, What’s wrong with requirements management tools? Requirements April 2012).
Engineering 1 (3) (1996) 190–194. [27] CPDA, www.cpd-associates.com.
[13] Q. Xu, et al., An analytical Kano model for customer need analysis, Design Studies
30 (1) (2009) 87–110.

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001
G Model
COMIND-2586; No. of Pages 11

M.G. Violante, E. Vezzetti / Computers in Industry xxx (2014) xxx–xxx 11

Maria Grazia Violante is currently Assistant Professor Enrico Vezzetti received the Master Degree in Industrial
of Technical Drawing and Design Tools for Industrial Engineering from the Politecnico di Torino in 1997, and the
Engineering at the Department of Management and PhD Degree in Manufacturing Engineering from the
Production Engineering of the Politecnico di Torino. University of Parma in 2001. In 1998 he was in the 3D
From the same Politecnico she received her Master Printing Laboratory of the Massachusetts Institute of
Degree in Industrial Engineering. In 2006 she was a Technology, USA. He is currently Associate Professor of
visiting researcher at Wolfson School of Mechanical Technical Drawing and Design Tools for Industrial
and Manufacturing Engineering – Loughborough Engineering at Department of Management and Produc-
University. She is author of technical papers on tion Engineering of the Politecnico di Torino. He is author
product design and development and interactive of more than 80 technical papers on product design and
learning environments. Her research interest is development with specific attention on reverse engineer-
focused on Product Lifecycle Management, Rapid ing, rapid prototyping, collaborative design and virtual
Prototyping, Computer Aided Design, Virtual Reality, reality. His research interests include Computer Aided
E-learning. Design, Computer Aided Inspection, 3D Scanners and
Virtual Reality.

Please cite this article in press as: M.G. Violante, E. Vezzetti, A methodology for supporting requirement management tools (RMt) design
in the PLM scenario: An user-based strategy, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.05.001