Regular Paper

Implementing
Requirements
Management: A Task for
Specialized Software Tools
or PDM Systems?
Johan Malmqvist
Chalmers University of Technology, Machine and Vehicle Design, SE-412 96 Gteborg, Sweden
IMPLEMENTING REQUIREMENTS MANAGEMENT

Received May 25, 2000; Accepted September 15, 2000

ABSTRACT
This article argues that product models that include the requirements posed on the product
have many potential benefits. For example, they facilitate managing the design process so
that its goals are met by enabling a continuous follow-up of the requirements satisfaction
status and by supporting the analysis of the consequences of design changes. The paper first
introduces a concept for a requirements-driven integrated product and process model. The
conditions for support for requirements management are discussed based on this model.
Finally, two different ways of implementing the concept: by using specialized Systems
Engineering/Requirements Management tools or by using PDM (Product Data Management)
systems are analyzed. 2001 John Wiley & Sons, Inc. Syst Eng 4:49-57, 2001

1. INTRODUCTION

be able to manage requirement information, function

structures, CAD models, drawings, NC programs,
analysis models, assembly instructions, and other data.
It is, however, well known that one of the most severe
limitations of current CAD/CAM/CAE/PDM systems
towards realizing such visions is the lack of functionality for requirements management (RM). This results in
limited support for the early phases of the design process where requirements are identified and conceptual
solutions are evaluated against the requirements, as well
as for later phases where requirement changes may
necessitate redesign.

Many firms have today formulated a vision where they

aim to develop products based on virtual product and
manufacturing process models that enable a total
digital representation of the future product and its
manufacturing process. This means that the model must

Contract grant sponsor: Swedish National Board of Technical Development (NUTEK)

Systems Engineering, Vol. 4, No. 1, 2001
2001 John Wiley & Sons, Inc.

49

50

MALMQVIST

In this paper, different technical solutions for implementing support for requirements management in
CAD/CAM/CAE/PDM systems are analyzed. The
starting point of the analysis is a classification of product models as requirement models, product and life-cycle system definition models, and property models.
Further, a number of aspects in which the RM support
can vary are discussed: requirements capture, content
and granularity of product model, system and organizational integration, and data management. The granularity of the information in the product model is given
special consideration since it determines what level of
traceability can be supported. Three variants of granularity and their traceability support are analyzed. This
is followed by an analysis of two classes of technical
solutions for the implementation. These are specialized
Systems Engineering/Requirements Management
(SE/RM) tools and PDM (Product Data Management)
systems. Here a PDM system solution is to be seen as
a simple solution based on software that most firms
already have (or are currently implementing).
The remainder of the paper is structured as follows.
Section 2 describes a concept for an integrated requirements-driven product and process model. Section 3
discusses various conditions for computer support for
requirements management. Section 4 analyses how dif-

ferent technical solutions meet these objectives. Sections 5 and 6 end the paper by discussion and conclusions.

2. REQUIREMENTS-DRIVEN INTEGRATED
PRODUCT AND PROCESS MODEL
This section introduces the concept of a requirementsdriven integrated product and process model. The concept is shown in Figure 1. In the next section, we will
discuss the functions of a requirements management
system with regard to this integrated product model.
The integrated model consists of four basic model
types: requirement models, product definition models,
life-cycle system models, and property models. The
model is based on the Chromosome model [Andreasen,
1992], although slightly simplified and rearranged to
suit the purpose of this paper. According to the Chromosome model, which is based on Hubkas technical
systems theory [Hubka and Eder, 1988], requirement
models are those that state the desired properties of the
product, thus including demands, wishes, and functions. Product definition models define the product, i.e.,
its structure, form, material, surface quality, software
code, etc. Life-cycle system models define the various
systems with which the product interacts during its life

Figure 1. Requirements-driven integrated product and process model.

IMPLEMENTING REQUIREMENTS MANAGEMENT

cycle, including parts manufacturing, assembly, and

others. Property models, finally, assess the actual properties of the product that have been realized in the
design process. It should be pointed out that this category includes virtual and well as physical models. The
Chromosome model emphasizes the need to work with
two views of the product definition: the organ structure
and the component (part) structure. The organ structure
is a design-oriented system decomposition while the
component structure is a manufacturing-oriented decomposition. The main benefit is that this enables the
decoupling of reasoning about how a product realizes
its function from reasoning concerning its manufacturing. In the following, the acronym IPP model will be
used to denote an integrated product and process model
that contains the said information.
An alternative to the Chromosome model that is used
in some SE/RM tools is an IPP model derived from the
systems engineering literature [Blanchard and Fabrycky, 1998]. Such an IPP model includes requirements,
functions/behaviors, systems (the product), manufacturing and support systems, and properties/effectiveness measures. In conclusion, the two product modeling
theories are similar although the concept of organs
(function carriers) is lacking in the SE literature.
There is a strong connection between an IPP model
and basic design process activities. Synthesis involves
the search for solutions (product definition models and
life-cycle system models) that satisfy the desired properties of the product stated as requirements and functions. Analysis is the use of product definition and
life-phase system models to derive the actual properties
of the product. Finally, evaluation is the comparison of
actual properties with the desired properties. Note that
the model also can be used with other starting points,
for example, for analyzing the consequences of a suggested design change on all requirements, not only
those most obviously affected. The model also supports
a higher degree of design re-use, by enabling the re-use
of requirementproduct definitionlife cycle system
property structures, rather than just parts.

3. COMPUTER SUPPORT FOR

REQUIREMENTS MANAGEMENT
This section discusses the basic functions of a system
for requirements management.

3.1. Requirements Capturing

The first step in the process of managing a set of
requirements on a product is to capture them from the
source and to organize them in some kind of structure,
while eliminating inconsistencies and redundancies and

51

assuring that the requirements are properly formulated.

This can be done by objectifying the contents of a
requirement document or by inputting data via a screen
form. The former is typically more efficient and especially attractive for firms which already have huge
masses of requirements information in document form.

3.2. Content of Product Model

To fully support requirements management, a product
model including all four parts of the IPP model described in Section 2 and their relations is needed.
Unfortunately, some requirements management
tools only manage requirements, without links to product-defining models. While getting control of various
requirements documents and integrating their contents
may be a step forward for some firms, this lends poor
support for requirements traceability and may lead to
improper decomposition of solution-dependent requirements. Therefore, we do not recommend this solution in the long term.

3.3. Granularity of Product Model

A key characteristic of any RM system is the granularity of information that it manages. This granularity
determines the level of traceability that can be supported. The granularity can for a given information type
be either object granularity or document granularity. In
an IPP model that consists of different information
types (requirements, product definition, and so on) the
use of object and document traceability granularity may
be combined in different ways. Three combinations are
described below. Section 5 analyses which combinations can be supported in SE/RM tools and PDM systems, respectively.
The simplest implementation of requirement traceability is here called document-to-document traceability (see Fig. 2). It supports some traceability, even
though the granularity is coarse. For instance, a requirement specifying document many contain many requirements and, therefore, needs to be linked to many
product-defining documents, making specific queries
more difficult and with imprecise results. Moreover,
there is a risk for inconsistencies in the requirement
structure when requirements are broken down and distributed to subsystem requirement documents. To avoid
this risk, a formally defined work process and good
discipline concerning adherence to this is necessary.
A higher degree of traceability is achieved if the
requirements are managed as individual objects while
product defining and property models are still documents (see Fig. 3). We call this object-to-document
traceability. This will, for instance, enable the identification of the CAD files that are directly related to a

52

MALMQVIST

Figure 2. Traceability type 1: document-to-document traceability.

specific requirement. In this type, function structures

can be managed in a similar fashion to requirement
structures. Moreover, the risk for inconsistencies in the
requirement structure is minimized.
Finally, traceability from requirement objects via
design parameters to property parameters constitutes
the most sophisticated and fine-grained granularity,
enabling object-to-object traceability (see Fig. 4). This
type supports quantitative tracing of the consequences
of a requirement change or design parameter modifica-

tion. In contexts where a crucial element of the design

decision-making is to trade various properties against
each other, this support is potentially very valuable. The
difficulty lies in defining the parameters that characterize a function carrier or a part. For simple parameters
(length, width, etc.) this may be straightforward, but it
will be more difficult for parts with complex geometry.
Moreover, this level of traceability will lead to higher
costs for data management. However, it may be worth
the extra effort when developing product families.

Figure 3. Traceability type 2: object-to-document traceability.

IMPLEMENTING REQUIREMENTS MANAGEMENT

3.4. Integration
Another dimension that differentiates implementations
of requirements management is how well they are integrated with other computer tools. They need to be
integrated with office software such as word processors
and spreadsheets, which are often used to define the
requirements, as well as with engineering tools such as
CAD, which will use the requirements, defined. Moreover, there is the issue of integration in the organization.
One extreme is to state that all employees should be able
to use the system; the other is to consider it an expert
tool.

3.5. Data Management

The requirements and relationship data that are added
to the product model also needs to be managed in an
administrative sense. The basic functionalities we need
are

53

Document management (including management

of metadata, files, file/model check-in/check-out
and access control)
Process management (a formal process for managing the life-cycle of an integrated product
model including its requirements, and automating routine parts of the process)
Requirement structure management including
the possibilities of creating variants and views of
requirements (structures) as well as efficient editing functionality.
These are similar to those offered by PDM systems,
but should be properly adapted as PDM systems typically have a document-level-focus while SE/RM tools
are object-level-focused. The granularity issue resurfaces here: Should requirements data be formally managed on the object level (individual requirement) or on

Figure 4. Traceability type 3: object-to-object traceability.

54

MALMQVIST

the document level (a file containing many requirements)?

4. TECHNICAL IMPLEMENTATION
SOLUTIONS
This section discusses alternative technical implementation solutions for implementing requirements management in a product modeling environment. It should
be pointed out that both alternatives require customization to meet the specific needs of a firm.

4.1. Systems Engineering/Requirements

Management Tools
In this paper, a SE/RM tool is defined as a system that
is specifically intended for managing requirements, or
intended to support the entire systems engineering
process. Examples of the former include Doors [Quality
Systems & Software, 2000] and RTM [Integrated Chipware Corp, 1999]. Examples of the latter are Core
[Vitech Corp, 2000], RDD.COM [Ascent Logic, 2000],
and SLATE [TD Technologies, 2000]. For a more comprehensive vendor listing, please refer to the INCOSE
Tools Database [INCOSE, 2000].
Requirements capture. SE/RM tools typically have
well very developed interfaces to word processing software such as Word and Framemaker. This allows the
engineer to define the requirements using a familiar
tool. It can then be imported into the SE/RM tool and
structured into objects by a SE/RM specialist.
Content of product model. SE/RM tools provide
predefined requirement, function, and product-defining
objects and structures that can be adapted to a companys needs. Relationships between the model types
are also included. Life-cycle system defining objects
(e.g., assembly operations) are, however, lacking.
Granularity. An SE/RM tool will typically support
type 1 and 2 traceability with little or no customization.
Type 3 will require major customization, and it is not
clear whether it can be fully supported. Some elements
of type 3, such as including quantitative property models, are to some extent supported today since SE/RM
tools often include function for managing technical and
economic budgets and have integrations with simulation tools such as MATLAB. The difficulty lies in the
mapping to product definition and life cycle parameters. This is a major challenge for future work. SE/RM
tools further often have functions for creating special
reports and for frequently recurring searches such as
requirement tracing.
Integration. A stated above, most SE/RM tools
have well-developed interfaces to word processing software. However, few SE/RM tools have interfaces to

CAD systems or other mechanical engineering application software. Moreover, an SE/RM tool will also need
to interface with the PDM system, at least for transferring the product definition structure.
Data management. SE/RM tools have functionality
for organizing requirement objects into requirement
structures. However, access control is defined on the
document level so a user sees and may be able to make
changes to an entire model. This is similar to a file in
a CAD system. PDM systems allow access control on
the object level. This is vital if an engineering change
process, which starts with the change of a requirement
and ends with the introduction of changed parts in
manufacturing, is to be formally controlled. This means
that the designer may change only a specific requirement, not others that may be grouped with it in a file.
SE/RM tools also have less powerful workflow and
document management functionalities in comparison
with PDM systems.

4.2. PDM Systems

Examples of PDM systems include Matrix [MatrixOne,
2000], Metaphase [SDRC, 2000], and Windchill [Parametric Technology Corp., 2000]. See also the PDMIC
PDM vendor list [PDMIC, 2000]. PDM systems have
the general ambition of managing all product-defining
data during the products entire life cycle. While there
are differences between the systems, they share a common core of functionality: document management,
product structure management, workflow support, data
communication and translation, and integration with
application systems.
Requirements capture. In general, PDM systems
are weaker than SE/RM tools in this dimension. SE/RM
tools provide better functionality for importing requirement documents and organizing the contents in a requirement structure. This is because the import function
works down to the object level. PDM systems also have
integrations with word processors, but these only work
on the document level. Creating a requirement structure
then requires additional work. Requirement objects
would typically be input to a PDM system using some
kind of screen forms. However, this is not as efficient,
especially in situations where the firm already has a
large number of existing requirements documents that
it wants to import to the RM system.
Content of product model. Typically, the only
types of product models included out of the box in a
PDM system are the product-defining ones. The other
model types and relationships need to created by customization. However, PDM are typically good at this.
One limitation that is difficult to work around in a PDM
system is that while the system may support the creation

IMPLEMENTING REQUIREMENTS MANAGEMENT

55

Table 1. Comparison of SE/RM Tools vs PDM Systems

of function structures, these can only be organized in

tree hierarchies, not as networks. Moreover, they lack
the ability to visualize complex relations in matrices.
This is especially useful for analyzing complex relations between parts and for supporting work according
to matrix-based methodologies such as QFD [Akao,
1999; Malmqvist and Svensson, 1999].
Granularity. PDM systems can support type 1
traceability with minor amounts of customization: the
proper document and relationship types need to be
defined. If a PDM system is to support type 2 traceability a new object type, along with necessary attributes,
methods, and processes, needs to defined. However,
suggestions for generic requirements object types have
been published [Malmqvist and Schachinger, 1997],
and company-specific data can be added to these.
Therefore, the amount of customization needed is moderate. It is not clear whether type 3 traceability can in
general be supported by todays PDM systems, even
after major customization, perhaps for very specific
cases.
Integration. Most PDM systems have integrations
to word processors and CAD systems. However, customization is required for creating integrations with

CAE software and in-house developed programs. An

advantage with PDM systems is that they are used by a
large part of the organization and have an interface that
most engineers are familiar with.
Data management. Data management is the purpose of PDM systems, and, therefore, they have some
additional functionality not present in SE/RM tools. For
instance, they include data vaults that control access to
files, and there are formal, workflow-supported, processes for executing engineering changes. PDM systems
have also been tested in very large-scale, global settings. The data management capability of PDM systems
is their greatest advantage in comparison with the
SE/RM tools.
Table I summarizes the findings of this section.

5. DISCUSSION
We have now presented a concept for a requirementsdriven, integrated product and process model and analyzed alternative implementation solutions.
A solution based on an SE/RM tool will give better
support for requirements traceability and a more direct
support for systems engineering. The SE/RM tools

56

MALMQVIST

further provide functionality that needs to be created by

customization in a PDM system, with associated cost
and need for maintenance. The expert tool qualities of
the SE/RM tools enable more advanced use of requirements management which may be a necessity if the tool
is to be used for a specific purpose. Finally, it is unclear
how well SE/RM tools can be integrated with application systems other than word processors, e.g., CAD
systems.
The PDM solution has advantages such as facilitating access to the data from several departments, better
integration with CAD systems, and a better infrastructure for data management in the form of workflow
support, data vaults, etc. Moreover, the company needs
a PDM system regardless of whether or not they intend
to use it for requirements management. By customizing
the PDM system it can support type 1 and 2 traceability.
There are, however, some limitations that are difficult
to customize away, e.g., concerning function modeling.
Also, PDM systems provides less support for working
methods such as systems engineering, since there is a
less direct coupling between the tool and the working
method. PDM systems lack the ability to import a text
document and automatically create a requirements
structure corresponding to its contents. This is a key
capability of some SE/RM tools that allow users to
work in a familiar system (e.g., Word, Excel or Framemaker). It should also be pointed out that while it is in
principle possible to use a PDM system for requirements management, this use is untried. There is a risk
that a failure due to technical reasons may give computer support for requirements management a bad reputation. It may therefore be suitable for a company
wishing to improve its requirements management process to initially use a SE/RM tool to investigate possibilities, and then implement a suitable subset of
requirements management support in its PDM system.
Finally, an implementation based on a PDM system will
probably have a different character than an SE/RM one
because everyone in the company uses the PDM
system, while SE/RM tools are expert tools.
The question is whether the distinction between
PDM systems and SE/RM tools will be as clear in the
future. Since all PDM systems aim at enabling a complete integrated product model, they must provide some
requirements management functionality. They have
three alternatives for realizing this: They can develop
RM functionality as a part of the core in their PDM
system, or they can acquire and integrate an existing
SE/RM tool, or they can develop integrations with
existing SE/RM tools. The most likely strategy appears
to be the acquire-and-integrate alternative, especially if
their customers demand that the PDM systems also
support RM. This is due to the technical advantages of

the SE/RM tools. The acquisition of SLATE by SDRC

is an example. Due to the small size of the SE/RM tool
vendors it is unlikely that they will acquire a PDM
system vendor or develop their data management functionality to a level comparable with the PDM systems.
With regard to technical functionality, it has been
shown that current SE/RM tools support qualitative
traceability. Quantitative traceability is supported for
simple cases such as totaling cost or weight. However,
it is not clear how well the results of more complex
analyses can be traced. This is an important area for
future work.

6. CONCLUSIONS
The proper inclusion of requirement models, product
definition models, life-cycle system models, and property models in product models is important for enabling
design work following the procedures suggested by
modern design methodology. There are two main alternative solutions for implementing such a product modeling system: The system can either be based on a
Systems Engineering/Requirements Management
(SE/RM) tool or a PDM system. SE/RM tools provide
advanced functionality for requirements management
but run the risk of being a tool only for specialists.
SE/RM tools require customization for integration with
engineering application systems such as CAD/CAM.
The PDM alternative gives a broader base for the implementation and includes workflow functionality but
provide less support (without major customization) for
requirements management methodology. This paper
has provided a theoretical analysis of the two concepts.
Current work involves test implementations of both
concepts, using an automobile cockpit as a test object.

ACKNOWLEDGMENTS
The Swedish National Board of Technical Development (NUTEK) financially supported this work.

REFERENCES
Y. Akao, Quality Function Deployment, QFD;Integrating
customer requirements into product design, Productivity
Press, Portland, 1990.
M.M. Andreasen, Designing on a Designers Workbench
(DWB), Proc 9th WDK Workshop, Rigi, Switzerland,
1992.
Ascent Logic Corp., http://www.alc.com, 2000.
B.S. Blanchard and W.J. Fabrycky, Systems engineering and
analysis, 3rd edition, Prentice-Hall, New York, 1998.
V. Hubka and W.E. Eder, Theory of technical systems, Springer-Verlag, Berlin, 1988.

IMPLEMENTING REQUIREMENTS MANAGEMENT

INCOSE, INCOSE Tools Database, http://www.incose.org

/tools, 2000.
Integrated Chipware Corp, http://www.chipware.com, 2000.
J. Malmqvist and P. Schachinger, Towards an implementation
of the chromosome model - focusing the design specification, Proc. ICED-97, Tampere, Finland, 1997, Vol. 3, pp.
203212.
J. Malmqvist and D. Svensson, A design theory based approach towards including QFD data in product models,

57

Paper No DET99/DTM-8769, Proc. DETC99, Las Vegas,

NV, 1999.
MatrixOne, http://www.matrix-one.com, 2000.
Parametric Technology Corp., http://www.ptc.com, 2000.
PDMIC, PDM Product Vendors, http://www.pdmic.com/vendors/vendlist.html, 2000.
Quality Systems & Software, http://www.qssinc.com, 2000.
SDRC, http://www.sdrc.com, 2000.
TD Technologies, http://www.tdtech.com, 2000.
Vitech Corp., http://www.vtcorp.com, 2000.

Associate professor Johan Malmqvist holds the M.Sc., (1988) and Ph.D. (1993) degrees in Mechanical
Engineering from Chalmers University of Technology, Gteborg, Sweden. His current research concerns
design methodology, systems engineering, and product and design process modeling.