Content uploaded by Mitchell M Tseng
Author content
All content in this area was uploaded by Mitchell M Tseng
Content may be subject to copyright.
A requirement management database system for
product definition
Jianxin Jiao
The Hong Kong University of Science and Technology, Kowloon, Hong Kong
Mitchell M. Tseng
The Hong Kong University of Science and Technology, Kowloon, Hong Kong
1. Introduction
The first phase of the overall product reali-
zation process is product definition (Ullman,
1992). During this phase, the design team may
explore any combination of customer needs,
corporate objectives, product ideas, and
related technological capabilities, concluding
the process with a definition of the product.
Usually, the product's definition is repre-
sented as a list of product requirements, also
known as product specifications or target
values. This information is often a mix of
quantitative values and qualitative descrip-
tions of the product. Often, only highlights of
the design are recorded for future reference,
or the company may produce a formal
document that must routinely undergo many
amendments along with scrutiny, and may
require to be signed off by many individuals
(Ullman, 1992; Redmond, 1988).
Most researchers in the field and industrial
designers involve themselves wholeheartedly
in the process of mapping from customer
needs to design solutions, i.e. the latter part
of the design process subsequent to product
definition. However, they are involved only
spasmodically and usually highly subjec-
tively in the first part of the design process,
i.e. product definition (Redmond, 1988). As
discussed by Tseng and Jiao (1997), there are
formidable hindrances inherent in the pro-
duct definition process, including contextual
mismatching, lack of defined structures in
requirements, and no structured mapping
from requirements to design parameters.
Product definition has long been a tedious,
time-consuming and error-prone effort en-
acted between customers, marketers, and
designers (Figure 1). This is further com-
pounded by the tendency for requirements to
be vague and fuzzy and difficult to manage. In
most cases, requirements are negotiable and
conflict with each other, and tradeoffs are
often necessary. In addition, in the practice
of concurrent engineering, product develop-
ment teams must keep track of myriad
requirements derived from different per-
spectives on the product life cycle, including
manufacturing, reliability, maintainability,
and environmental safety, to name but a few.
Yet, despite great advances over the past
decade in computer-aided design and engi-
neering, there has been relatively little pro-
gress in providing analogous support for
requirement management. As a result, Fiksel
and Hayes-Roth (1993) point out the necessity
to manage requirement information during
the product definition process. They defined
requirement management as the process of
creating, disseminating, maintaining, and
verifying requirements.
The requirement management process con-
sists of four main functions that are per-
formed repeatedly in an iterative fashion.
These are requirement elicitation, require-
ment analysis, requirement tracking, and
requirement verification (Fiksel and Hayes-
Roth, 1993; Tseng and Jiao, 1997). Requirement
elicitation deals with eliciting customer needs
and acquiring the voice of the customers.
Requirement analysis is the process of inter-
preting customer needs and deriving explicit
requirements that can be understood and
interpreted by people and/or computer pro-
grams. Requirement tracking involves con-
tinuous interchange and negotiation within a
project team regarding conflicting and chan-
ging objectives. Requirement verification em-
bodies the procedures for determining
whether or not a product design complies
with a designated set of requirements.
Straightforwardly, requirement manage-
ment automation will facilitate a more struc-
tured product development process, at the
same time, a more effective integration of
humans and machines that reduces product
development costs and cycle time while im-
proving product quality. Engineers will be
able to comprehend and articulate better the
many relationships and tradeoffs among pro-
duct requirements and different technical
approaches. It has been foreseen that, as
companies review and enhance their product
[ 146 ]
Integrated Manufacturing
Systems
10/3 [
1999] 146±153
# MCB University Press
[
ISSN 0957-6061]
Keywords
Automation, Design, Engineering,
Product design,
Requirements planning
Abstract
This paper presents a database
system developed to provide a
computerized environment for re-
quirement management during the
product definition phase. The
scope of this database system is
to facilitate and demonstrate a
methodology for product definition
by recognizing and adopting func-
tional requirement patterns from
previous product designs so as to
address a broad spectrum of
domain-specific customer require-
ments and organize requirement
information for product specifica-
tions. The database system
improves the product definition
process during design and rede-
sign efforts by integrating custo-
mer and design information all
together and by reusing this
information. A prototype require-
ment management database sys-
tem is implemented on a PC
platform using Microsoft Access.
This research is partially
supported by Computer
Products Asia-Pacific Ltd.
(Power Conversion, Hong
Kong) under grant number
CPI 95/96.EG01, the HKUST
Research Infrastructure
Grant (RI 93/94 EG08), and
Hong Kong Research Grant
Council (HKUST 797/96E).
development processes, they will increasingly
demand various types of automated require-
ment management capabilities (Fiksel and
Hayes-Roth, 1993). As a result, it is imperative
to explore requirement management meth-
odologies and develop computer tools to sup-
port requirement management automation.
Towards this end, this paper presents a
database system developed to provide a
computerized environment for requirement
management during the product definition
phase, namely the requirement management
database (RMDB) system. The scope of this
database system is to facilitate and demon-
strate a methodology for product definition
by recognizing functional requirement (FR)
patterns, noted as the PDFR methodology.
The PDFR methodology adopts FR patterns
from previous product designs to address a
broad spectrum of domain-specific customer
requirements and to organize requirement
information for design specifications. The
RMDB system is an implementation of the
PDFR methodology to improve the product
definition process during design and rede-
sign efforts. The prototype RMBD system is
implemented on a PC platform using Micro-
soft Access.
In the next section, the background re-
search leading to the PDFR methodology is
presented upon which the requirement man-
agement database system is based. In Section
3, the system design issues involved in the
development of the RMDB system are de-
scribed, along with an existing database
technologies review. The software selection
and the RMDB system implementation are
also discussed in Section 3. In Section 4, an
example of product definition in designing
power supply products is presented with a
focus on the usage of the RMDB system. In
Section 5, a plan for future work is presented
and finally in Section 6 the paper is concluded.
2. Requirement management
methodology
Approaches to defining product specifica-
tions by capturing, analyzing, understanding,
and projecting customer needs, sometimes
called the Voice of the Customer (VoC), have
received a significant amount of interest
from both academia and practitioners in
recent years (Fung and Popplewell, 1995;
Fiksel and Hayes-Roth, 1993). A method used
for transforming the VoC to product specifi-
cations is developed by Ofuji et al. (Shoji et
al., 1993), in which semantics methods, such
as the KJ method (affinity diagram) and
MPM (multipickup method), are applied as
the basis for discovering underlying facts
from affective language. Kano et al. (1984)
develop systematics to categorize customer
needs for product definition. Towards this
end, marketing researchers emphasize cus-
tomer profiling by applying regression ana-
lysis to compare customer characteristics to
determine their overall rankings in contri-
bution towards profitability (Jenkins, 1995).
Marketing research techniques include focus
groups, one-on-one interviews, and similar-
ity-dissimilarity attribute rankings (Griffin
and Hauser, 1992). While these types of
activities are helpful for discovering the VoC,
it is difficult for them to obtain design
information
because marketers do not know what engi-
neers need to know. They have shortcomings
in facilitating the synchronization of mar-
keting and engineering to develop product
definitions coherently.
In the engineering community, total design
(Pugh, 1991) points out the importance of
understanding and interpreting market in-
formation and encapsulating these in a
comprehensive and thorough product design
specification. Quality function deployment
(QFD) (Clausing, 1994) joins both marketing
and engineering efforts using a very basic
tool of the matrix, namely the house of
quality (HoQ). While QFD excels in convert-
ing customer information to design require-
ments, it is limited as a means of actually
discovering the VoC (Hauge and Stauffer,
1993). To empower QFD with marketing
aspects, Fung and Popplewell (1995) propose
to pre-process the VoC prior to its being
entered as customer attributes into the HoQ.
In pre-processing, they adopted an affinity
diagram (KJ method) to categorize and the
analytic hierarchy process (AHP) to prior-
itize the customer requirements. Fukuda and
Matsuura (1993) also propose to prioritize the
customer's requirements by AHP for con-
current design.
In summary, most approaches assume
product development starts from a clean
sheet of paper. In practice, however, most
new products evolve from existing products.
There is little attention paid to evolutionary
product design in terms of product definition.
Figure 1
The elaboration/refinement process of product
definition
......
......
[ 147 ]
Jianxin Jiao and
Mitchell M. Tseng
A requirement management
database system for product
definition
Integrated Manufacturing
Systems
10/3 [1999] 146±153
Historical data, the product evolution path,
and feedback from customers on current
products are often considered only implicitly,
if not ignored. As a result, product design
seldom has the opportunity to take advantage
of the wealth of customer requirement in-
formation in existing products. Furthermore,
with a shortened product life-cycle, expen-
sive investments in product development,
and the proliferation of product varieties, the
existing approaches are often constrained by
the schedule deadline and lack of objectivity
in defining product specifications.
In order to improve the product definition
process during design and redesign efforts,
we develop a systematic approach to product
definition through recognizing functional
requirement patterns from existing products
(noted as PDFR; Tseng and Jiao, 1997). These
patterns help modify product designs based
on historical data about customers' needs
through underlying patterns of functional
requirements (FR) as well as patterns of their
interrelationships.
In PDFR methodology, FR patterns consist
of FR topology, FR classification, and FR
templates. The terminological FR variables
and the interrelationships among them are
referred to as FR topology, which implicates
the decomposition hierarchy of FR variables
and a taxonomy of FRs. FR topology enhances
the design taxonomy (Hauge and Stauffer,
1993), which aims at assisting customer
requirement acquisition, in that FR topology
is more specialized to reflect product domain-
specific requirements. FR classification
manifests itself through and corresponds to a
spectrum of product families with different
sets of requirements. FR templates help
product redesign by providing a history of
past designs, thus allowing for the easy reuse
and inheritance of design knowledge.
The PDFR methodology is divided into two
phases, i.e. the FR pattern recognition phase
and the FR pattern adoption phase. The FR
pattern recognition phase is a preparatory
stage in which FR patterns are extracted
from historical data regarding existing
designs. The FR patterns, in essence, repre-
sent a set of FRs for a spectrum of product
offerings in a company. Such a generic
representation of FRs can then be used to
develop product specifications for a new
design in the FR pattern adoption phase.
Figure 2 summarizes the procedures of the
PDFR methodology.
3. Requirement management
database system
Recognizing the importance of improving
customer needs elicitation, generating pro-
duct specifications, and managing this infor-
mation, much of the development efforts of
the PDFR methodology are geared towards
organizing the customer and design infor-
mation in such a way that it brings together
marketing and design engineering in the
product definition phase. As a methodology
of organizing specifications for engineering,
PDFR facilitates the storage and retrieval of
customer requirements and product specifi-
cations. FR patterns allow for easy reuse of
design knowledge by providing a design
history. Thus, when filled with appropriate
information, they accommodate design teams
with the knowledge necessary for defining
the requirements for a new product.
3.1 Domain information management
The requirement management database
(RMDB) is a demonstration and implemen-
tation of PDFR methodology to organize
customer and design information effectively
for product definition. The tasks of the RMDB
include integrating customer requirements
and product specification, generating pro-
duct specifications that will satisfy customer
Figure 2
The procedures of the PDFR methodology
[ 148 ]
Jianxin Jiao and
Mitchell M. Tseng
A requirement management
database system for product
definition
Integrated Manufacturing
Systems
10/3 [1999] 146±153
needs, and making the information available
for downstream design activities. RMDB
employs FR classification patterns to orga-
nize various products and a functional
decomposition hierarchy to represent custo-
mer needs. FR patterns are extracted from
product repositories and consist of the FR
topology and FR templates corresponding to
different FR classifications.
To help in the elicitation of customer
needs, FR topology is used to prompt the
marketer and the customer for their inter-
active question probe, which alleviates the
domain knowledge acquisition bottleneck in
the product definition process. To assist
design engineers to define product specifica-
tions, customer needs should be presented in
an organized and systematic way. A FR
template conforms to a product family and
provides a class-member relationship be-
tween a product family and a new design.
That is, a new product specification can be
defined through instantiating the related
class template for specific customer needs.
Therefore, the integration of the customers,
the marketer, and the design engineer can be
supported by underlying FR patterns. All FR
patterns, used by marketing to probe the
customer, are also used to organize customer
requirements and design specifications. By
Figure 3
Product definition activity model
Marketer
Figure 4
The role of RMDB in product definition
Figure 5
ER model for RMDB system
[ 149 ]
Jianxin Jiao and
Mitchell M. Tseng
A requirement management
database system for product
definition
Integrated Manufacturing
Systems
10/3 [1999] 146±153
doing so, marketing and design engineering
share customer information in the identical
format and in a structural manner. A typical
product development adopting RMDB is
resembled in Figure 3. In such a model, both
the marketer and design engineer use the
same FR patterns to elicit and organize
customer needs.
3.2 Data model and development software
Popular data models in database management
systems include hierarchical, network, rela-
tional, and object-oriented. The hierarchical
data model allows the user to represent each
one-to-many relationship by a parent-child
designation. In the hierarchical model, many-
to-many relationships can be implemented
only in a clumsy way, which often results in a
redundancy stored data (Elmasri and Na-
vathe, 1994). In addition, the operations of
insertion and deletion become very complex
as a result of strict hierarchical ordering. In
practice, there often exist many-to-many re-
lationships between customer needs and de-
sign attributes in product definition.
Therefore, RMDB cannot be adequately sup-
ported by the hierarchical model. Like the
hierarchical model, a network schema can
directly represent one-to-many relationships.
Unlike in the hierarchical model, a record
type can be the child of more than one parent.
However, in addition to the complexity of the
network model, there is a restriction on the
configuration of many-to-many relationships
in a network model, in which a record type
that is the child for a relationship cannot also
be the parent for a relationship. The result is a
schema that has only shallow levels (Elmasri
and Navathe, 1994) and is therefore not
applicable to RMDB. The relational model has
been popular owing to its simple tabular data
format and convenient support to nonproce-
dural requests and data independence.
Although the object-oriented approach pro-
mises to reduce the time and cost involved in
software development, it is not yet fully
developed to handle complex engineering de-
sign tasks (Law et al., 1990). Recently, the
trend is to extend the relational model using
an object-oriented approach that provides
certain features lacking in the relational
model (Law et al., 1990). Engineering applica-
tions like product design involving teamwork
can benefit from the object-oriented exten-
sions without sacrificing the advantages of
the relational model. The enhanced entity-
relationship (EER) model (Elmasri and Na-
vathe, 1994) incorporates important concepts
from the object-oriented approach into the
entity-relationship (ER) model to represent
more complex requirements of engineering
applications.
The end-users of RMDB are marketers and
design engineers, therefore a PC-based plat-
form is considered. The same consideration
is given to the Windows operating system
owing to its popularity. The RMDB prototype
system is implemented using Microsoft Ac-
cess database management tool (User's guide,
1994). Microsoft Access is a relatively easy to
use software package system for the Win-
dows environment with powerful database
management capabilities. As a virtual pro-
gramming tool with strengths in relational
database applications, it provides event-dri-
ven mechanisms to build graphical user
Figure 7
Main screen dump
Figure 6
Entity-relationships and data sharing in RMDB
[ 150 ]
Jianxin Jiao and
Mitchell M. Tseng
A requirement management
database system for product
definition
Integrated Manufacturing
Systems
10/3 [1999] 146±153
interface easily. Its floating toolbar, along
with cue cards and powerful wizards simplify
many programming tasks, resulting in a
professional looking program.
3.3 Functional analysis
Requirement analysis is the first step of the
database life-cycle. RMDB attempts to sup-
port three sets of users: the customers who
select product offerings from a company by
specifying their wants, the marketers who
play an important role in bridging the
customers and the engineers to acquire and
refine customer requirements, and the en-
gineering designers who define product spe-
cifications according to elaborated customer
requirements and manufacturing considera-
tions.
The functional modeling of RMDB is
shown in Figure 4, described using IDEF0.
The marketers analyze the customer needs
based on the PDFR methodology and then
search appropriate FR patterns to elaborate
the customer requirements. Often negotia-
tion and interaction between the customers
and engineers are necessary to make trade-
offs among product features, technological
feasibility, and production capabilities, as
well as cost and lead-time constraints. The
designers resort to FR templates to define
product specifications for new designs and
determine the development plans such as
customization decisions. In the RMDB
system, the PDFR methodology performs as a
unifying framework for marketers and de-
signers to organize customer information
and define product specifications coherently
so as to maintain the integrity of the product
families and the continuity of the infrastruc-
ture, hence leveraging existing design and
manufacturing investments.
3.4 Database design
Data modeling is an important step following
requirement analysis to help the database
designer conceptualize the entities and their
relationships. The ER model for the RMDB
system is shown in Figure 5 with major
entities and their relationships. The subse-
quent logical design aims at obtaining a
representation that uses as efficiently as
possible the facilities for structuring data
and modeling constraints available in the
logical design (Elmasri and Navathe, 1994). In
the logical design of the RMDB system, the
conceptual data schema (ER model) is trans-
lated into a logical schema (Figure 6) tailored
to the specific database management system
(Microsoft Access). All these issues are
implemented during the physical database
design by using Microsoft Access( database
software. The RMDB system interacts with
the user through various views or forms. The
first form, as shown in Figure 7, is the main
menu of a prototype RMDB system. The
menu structure can be defined according to
user identification and task analysis. The
menu structure of the RMDB system embo-
dies four sets of tasks as shown in Figure 8.
They are product selection, order processing,
product specification, and DB maintenance,
conveying the customer view, marketing
view, engineering view, and system view on
the RMDB system, respectively.
4. RMDB for power supply design
Power supplies possess a special trait in
product definition common to industrial
products. That is, in addition to the general
hindrance shown in Figure 1, the product
Figure 8
RMDB menu structure
Figure 9
FR topology-aided customer needs elicitation
[ 151 ]
Jianxin Jiao and
Mitchell M. Tseng
A requirement management
database system for product
definition
Integrated Manufacturing
Systems
10/3 [1999] 146±153
definition is a cooperative effort among the
customer, the marketer and the engineer.
Unlike many consumer products, it seldom
can be developed by the customer or engineer
alone. By applying the PDFR methodology,
the RMDB system alleviates the difficulties
inherent in the product definition for power
supply design. The screen shot in Figure 9
illustrates the elicitation of customer needs
with the aid of FR topology so as to help
customers articulate requirement informa-
tion in completeness. FR templates offer a
structured mechanism for defining product
specifications, as shown in Figure 10. An
example of the formatted product specifica-
tion report is given in Figure 11. In RMDB,
FR patterns are extracted from the product
repositories and organized by a coding sys-
tem according to FR classification patterns.
5. Future work
Design can be described as a mapping
process from customer requirements in the
functional domain to design solutions in the
physical domain (Suh, 1990). RMDB captures
requirement information in the functional
domain to facilitate product definition. The
subsequent design mapping can also be
supported by the PDFR methodology if de-
sign information can be appropriately repre-
sented and organized in the database. That is,
the requirement management (RM) database,
as shown in Figure 3, is extended to act as an
engineering database, along with a compre-
hensive product repository. In such a way, a
concurrent design environment can be es-
tablished within a coherent framework.
Moreover, in evolutionary design, how to
find a similar case for a new design is often
experience dependent and mostly by trial and
error. Case-based reasoning technique has
proved promising in finding a similar design
for accommodating the new design context,
in which the PDFR methodology can perform
as a fundamental mechanism for case
memory organization.
6. Summary
This paper presents a domain independent
requirement management database system
for organizing requirement information
during product definition. It is based on a
methodology for requirement management
which provides a framework to integrate
customer and design information and to
reuse such information. A prototype RMDB
system is implemented on the PC platform
using Microsoft Access database software.
An application of RMDB system to power
supply design is reported to illustrate the
feasibility and the potential of the RMDB
system.
References
Clausing, D. (1994), Total Quality Development: A
Step-by-Step Guide to World Class Concurrent
Engineering, ASME Press, New York, NY.
Elmasri, R. and Navathe, S.B. (1994), Fundamen-
tals of Database Systems, Benjamin/
Cummings, Redwood City, CA.
Fiksel, J. and Hayes-Roth, F. (1993), ``Computer-
aided requirements management'',
Figure 10
Defining product specifications based on FR templates
Figure 11
Screen shot of product specification report
[ 152 ]
Jianxin Jiao and
Mitchell M. Tseng
A requirement management
database system for product
definition
Integrated Manufacturing
Systems
10/3 [1999] 146±153
Concurrent Engineering: Research and Appli-
cations, Vol. 1 No. 2, pp. 83-92.
Fukuda, S. and Matsura, Y. (1993), ``Prioritizing
the customer's requirements by AHP for
concurrent design'', Design for Manufactur-
ability, DE-Vol. 52, ASME, pp. 13-19.
Fung, R.T.K. and Popplewell, K. (1995), ``The
analysis of customer requirements for effec-
tive rationalization of product attributes in
manufacturing'', Proceedings of 3rd Interna-
tional Conference on Manufacturing Technol-
ogy, Hong Kong, pp. 287-96.
Griffin, A. and Hauser, J.R. (1992), The Voice of the
Customer, MSI Working Paper Series, Report
No. 92-106, Marketing Sciences Institute,
Boston, MA.
Hauge, P.L. and Stauffer, L.A. (1993), ``ELK: a
method for eliciting knowledge from custo-
mers'', Design and Methodology, DE-Vol. 53,
ASME, pp.73-81.
Jenkins, S. (1995), ``Modeling a perfect profile'',
Marketing, July, p. 6.
Kano, N., Seraku, N., Takahashi, F. and Tsuji, S.
(1984), ``Attractive quality and must-be
quality'', Hinshirtsu 14, No. 2, The Japan
Society for Quality Control.
Law, H.K., Barsalou, T. and Wiederhold, G. (1990),
``Management of complex structural engi-
neering objects in a relational framework'',
Engineering with Computers, Vol. 6 No. 2,
pp. 81-92.
Pugh, S. (1991), Total Design: Integrated Methods
for Successful Product Engineering, Addison-
Wesley, Wokingham.
Redmond, J. (1988), ``Product research ± a case
study'', The 7th International Conference on
Information for Designers, Southampton.
Shoji, S., Graham, A. and Walden, D. (1993), A
New American TQM, Productivity Press,
Portland, OR.
Suh, N. (1990), The Principles of Design, Oxford
University Press, New York, NY.
Tseng, M.M. and Jiao, J. (1997), ``A variant
approach to functional requirement
acquisition for evolutionary product design'',
Journal of Engineering Design, Vol. 8 No. 4,
pp. 329-40.
Ullman, D.G. (1992), The Mechanical Design
Process, McGraw Hill, New York, NY.
User's guide (1994), Microsoft Access: Relational
Database Management System for Windows,
Version 2.0, Microsoft Corp.
[ 153 ]
Jianxin Jiao and
Mitchell M. Tseng
A requirement management
database system for product
definition
Integrated Manufacturing
Systems
10/3 [1999] 146±153
