a scenario-based approach for requirements management in

http://cer.sagepub.com/Concurrent Engineering

http://cer.sagepub.com/content/20/2/99The online version of this article can be found at:

DOI: 10.1177/1063293X12440895

2012 20: 99 originally published online 16 April 2012Concurrent EngineeringZe-Lin Liu, Zhinan Zhang and Yong Chen

A scenario-based approach for requirements management in engineering design

Published by:

http://www.sagepublications.com

can be found at:Concurrent EngineeringAdditional services and information for

http://cer.sagepub.com/cgi/alertsEmail Alerts:

http://cer.sagepub.com/subscriptionsSubscriptions:

http://www.sagepub.com/journalsReprints.navReprints:

http://www.sagepub.com/journalsPermissions.navPermissions:

http://cer.sagepub.com/content/20/2/99.refs.htmlCitations:

What is This?

- Apr 16, 2012OnlineFirst Version of Record

- Jun 20, 2012Version of Record >>

at Shanghai Jiaotong University on December 13, 2012cer.sagepub.comDownloaded from

http://cer.sagepub.com/

http://cer.sagepub.com/content/20/2/99

http://www.sagepublications.com

http://cer.sagepub.com/cgi/alerts

http://cer.sagepub.com/subscriptions

http://www.sagepub.com/journalsReprints.nav

http://www.sagepub.com/journalsPermissions.nav

http://cer.sagepub.com/content/20/2/99.refs.html

http://cer.sagepub.com/content/20/2/99.full.pdf

http://cer.sagepub.com/content/early/2012/04/12/1063293X12440895.full.pdf

http://online.sagepub.com/site/sphelp/vorhelp.xhtml


Article

Concurrent Engineering: Researchand Applications20(2) 99–109� The Author(s) 2012Reprints and permissions:sagepub.co.uk/journalsPermissions.navDOI: 10.1177/1063293X12440895cer.sagepub.com

A scenario-based approach forrequirements management inengineering design

Ze-Lin Liu, Zhinan Zhang and Yong Chen

AbstractIn engineering design, capturing customers’ requirements exactly and transforming them into design specifications arevital to designing a quality product. However, the expressions of customer requirements are normally imprecise andambiguous due to their linguistic origins. There is still a lack of a systematic approach for elaborating these requirementsand transforming them from informal to formal. Therefore, this article provides a scenario-based, systematic approachfor requirements management in engineering design. The requirements management process is conceptualized as athree-phase model, and scenarios are integrated into this model for elaborating and formally representing the require-ments. A case study of a soy milk maker design is also provided to demonstrate the proposed approach.

KeywordsCustomer needs, engineering design requirement, requirement management, scenario

Introduction

The engineering design process starts with some expres-sion of needs that are to be satisfied by the creation ofa product (Darlington and Culley, 2002). Therefore,capturing customer needs exactly and effectively is cru-cial to designing successful products in new productdevelopment (NPD) (Tseng and Jiao, 1998).Requirements management, which is defined as a pro-cess of creating, disseminating, maintaining, and verify-ing requirements (Fiksel and Hayes-Roth, 1993), isbecoming increasingly important in engineering designtoday. Traditionally, there are two successive stagesinvolved in this process, that is, identification of ‘‘thecustomer’s voice’’ and establishment of product specifi-cations based on the information that has been elicitedfrom the customer (Tseng and Jiao, 1998). However,there are primarily two difficulties associated with thisprocess. One is that the requirement statements fromdifferent groups of customers are often colloquial,ambiguous, and subjective, which may lead a productdesigner to understand the needs based on some vagueassumptions and implicit inference. Furthermore, poorunderstanding of the customer requirements may mis-lead designers into developing a wrong product. Theother is that the product specifications, usually

represented as a list of product requirements (Pahl andBeitz, 1996), are lacking a formal and structural repre-sentation. That is the reason why relatively little prog-ress has been made in providing computer-basedassistance for engineering requirements management.

Facing the difficulties above, existing research onrequirements management in engineering design ismainly concerned with capturing customer needs in amore effective way and transmitting them into productspecifications, involving requirements elicitation, analy-sis, and specification (Jiao and Chen, 2006). However,there is still a lack of a systematic approach for require-ments management in the above field, and rarely doesa formal representation scheme of product specifica-tions exist. Correspondingly, requirements engineering(RE) has been an intense research area in the field ofsoftware and information systems. Scenarios, or use

Institute of Engineering Design, School of Mechanical Engineering,

Shanghai Jiao Tong University, Shanghai, China

Corresponding author:

Zhinan Zhang, Institute of Engineering Design, School of Mechanical

Engineering, Shanghai Jiao Tong University, Room D-339, No. 800

Dongchuan Road, Minhang District, Shanghai, 200240, China

Email: [email protected]



cases, play an important role in conveying designrequirements information in this field. They are infor-mally expressed examples of interactions between theusers and the designed software system, which arewidely used in RE (Alexander and Stevens, 2002;Carroll, 2000; Hooks and Farry, 2001; Kaindl, 2000;Rios et al., 2006; Young, 2001). Therefore, we extendthe concept of scenarios in engineering design and pro-pose a scenario-based systematic approach for engi-neering requirements management. The approach isprimarily composed of two parts, the development of aformal representation scheme of scenario (carrier ofrequirement information) and a scenario-based step-wise process model for guiding engineering require-ments management.

Literature review

As pointed out by Tseng (Tseng and Jiao, 1998),requirements management is a preliminary design stagethat is associated with a transition process from ‘‘voiceof customer’’ (VoC) to ‘‘voice of designer’’ (VoD). Pahland Beitz (1996) define a ‘‘guideline’’ to facilitate thistransition by establishing product specifications to clar-ify the design task. However, in their approach, neithertools nor methods are suggested to ensure that theinformation of customer needs is refined in this stage.The transition is mainly achieved through communica-tion between customers and designers, and largelydepends on the designers’ experience. Many researchersare devoted to exploring approaches to elicit analysisand specify customer needs and are also seeking todevelop computer-aided tools for requirements man-agement (Baxter et al., 2008; Chen et al., 2002; Chenand Occena, 1999, 2000; Fung et al., 2003; HerleaDamian et al., 2005; Jiao and Zhang, 2005; Kano et al.,1984; Kazemzadeh et al., 2009; Kurakawa, 2004; Misraet al., 2005; Potts, 1999; Prasad, 1998, 2000;Prudhomme et al., 2003; Sutcliffe, 2003; Sutcliffe et al.,1998; Tseng and Jiao, 1998; Yan et al., 2002).

Tseng and Jiao (1998) propose to identify functionrequirement (FR) patterns from previous productdesign for addressing a broad spectrum of domain-specific customer requirements. In their model, variousFRs are grouped according to the similarity among cus-tomers. A requirements management database systemis also developed in their work for automatic require-ments management. Prudhomme et al. (2003) articulatethe notions of customers’ needs and professionals’needs. They employ a functional analysis method tomanipulate the needs of those involved in the productlife cycle. Baxter et al. (2008) provide a framework forintegrating design knowledge reuse and requirementsmanagement, enabling the application of requirements

management as a dynamic process. Kano et al. (1984)develop a system for categorizing customer require-ments into a product definition.

Quality function deployment (QFD) is widely usedto convert customer requirements into technical designrequirements. It utilizes a house of quality (HoQ)—amatrix to make explicit the relationships between thecustomer requirements and the quality characteristics(or technical attributes) of products (Prasad, 1998).Based on the conventional QFD, Prasad (2000) furtherdevelops this approach to make it suitable for workgroup–based engineering design. An alternate frame-work called concurrent function deployment (CFD) isproposed in his work. Fung et al. (2003) extend theQFD with resource constraints and allocation.Kazemzadeh et al. (2009) integrate the marketingresearch technology, that is, conjoint analysis and atwo-stage clustering method into the QFD process.

Many methods and tools in the field of artificialintelligence are applied in requirements managementfor product specification development, such as thefuzzy system, neural networks, and expert systems(Chen et al., 2002; Chen and Occena, 1999, 2000; Jiaoand Zhang, 2005; Yan et al., 2002). Yan et al. (2002)proposed an integrated approach on the basis ofrepeated single-criterion sorts and fuzzy evaluation forcustomer requirement elicitation. Jiao and Zhang(2005) apply the association rule mining technique toexploit the patterns of customer needs to functionalrequirements mappings. A strategy for acquiring cus-tomer requirement patterns is provided by Chen et al.(Chen et al., 2002). In their work, a laddering techniqueis employed to enable customer requirements elicita-tion, and an Adaptive Resonance Theory 2 (ART2)neural network is applied as a toolkit for furtherrequirements analysis. They also develop an expert sys-tem for concurrent product design by organizingrequirements information using a graph decompositionalgorithm (Chen and Occena, 2000) and a knowledgehierarchical sorting process (Chen and Occena, 1999).

RE has been an intense research area in the field ofsoftware and information systems; some requirementsanalysis methods in this field have also demonstratedtheir use in engineering design (Darlington and Culley,2002; Misra et al., 2005; Potts, 1999; Sutcliffe, 2003;Sutcliffe et al., 1998). Scenarios are widely advocatedas a means of improving requirements definition in RE(Misra et al., 2005). Typical works in scenario-basedRE includes the ScenIC method (Potts, 1999) and thescenario-based requirements analysis method(SCRAM) (Sutcliffe, 2003; Sutcliffe et al., 1998). Theprogresses in this field might help understanding designrequirements in engineering design domain. Darlingtonand Culley (2002) compare the differences in the natureof engineering design and software engineering. They

100 Concurrent Engineering: Research and Applications 20(2)



state that the formalization of design requirements innatural language can facilitate solution searching inengineering design domain, while resulting in thedescription of solution in the software engineeringdomain. Therefore, how to adjust and extend the sce-nario and make it suitable for requirements manage-ment in engineering design is the primary concern ofthis article. In this regard, there have been some works:Herlea et al. (2005) discuss a method by which the tran-sition from informal to formal expression of the designrequirements can be achieved by the paralleled refine-ment of scenarios and requirements. Kurakawa (2004)proposed a scenario-driven conceptual design informa-tion model based on the cognitive design problem-solving process.

The requirements management researches in engi-neering design reviewed above are only some typicalworks in this field, more works can be found in thestudy by Jiao and Chen (2006). However, in these exist-ing works, there is still a lack of formal approaches orany standard for customer requirements modeling inrelation to engineering design. There also rarely exists aformal representation scheme of product specifications.

Understanding scenario

The term scenario is a widely used concept in RE. Insoftware design, it is employed to model the users of asoftware system and their activities, the interactionbetween human and computer (Alexander and Stevens,2002; Carroll, 2000; Hooks and Farry, 2001; Kaindl,2000; Young, 2001). This concept has been extendedinto the field of engineering design for conveying designrequirements information. In systematic designapproach (Pahl and Beitz, 1996), one method for refin-ing and extending requirements lists is to create scenar-ios in task clarification phase, which sketch out theanswers to ‘‘what might happen to the artifact’’ and‘‘how should the artifact react.’’ Kurakawa (2004)defines an artifact scenario as ‘‘the design informationthat represents the actions of all interested people inoperating the artifact as well as future events and situa-tions in which the artifact may be involved.’’

Scenarios are narrative descriptions of activities ofan artifact, involving how it might be used, who mightuse it or contact with it, when and where it might beused, and the reactions of the artifact in its use. Indeed,scenarios are stories, stories about things happening toan artifact or a summary of a set of real or imaginedevents and actions. Strictly, a scenario contains at leastone specific action of the artifact. It is heavily rooted inpeople’s daily life experiences. Therefore, expression ofrequirements in scenarios makes it easier for designersto communicate with customers with a full range of

needs likely to be associated with the designed artifact.Besides, scenario can also be used by designers to modelthe interactions between an artifact and its workingenvironment.

A complete scenario can be specified with the fol-lowing six characteristic elements: time, location, actor/agent, role (beneficiary, operator, operand, andmedium), action/event, and situation.

Time and location tell when and where a scenariohappens. They are the background elements to sketch ageneral context of a scenario. The actor/agent is thesubject of an action or an event involved in a scenario.The subject can be human users, raw materials to beprocessed, or the designed artifact. Each actor is a par-ticipant and plays a role in the scenario, allowingdesigner to identify its importance in following designand establishing relations between it and other actorsin the same scenario. There are primarily four rolesdefined here, that is, beneficiary, operator, operand, andmedium. Beneficiary refers to a customer group whowill benefit from the actions of the product in the sce-nario. Operator is the product to be designed. Operandis the object processed by the Operator. It could beenergy, material, or signal. Medium is the physical ele-ment permeating in the working environment such asair or water. It affects the product’s working processdirectly or indirectly, though this impact could be posi-tive or negative. For example, assume a scenario thatpeople use a hair dryer to dry their hair. The benefi-ciary refers to the ones who want to dry their wet hair.The electric current (operand) is transformed into heatby the hairdryer (operator), and the heat is sent outthrough the airflow (medium). Action/event refers to theactions and behavior of actors. Some particular actionsof an artifact may cause a state change of the otherassociated actors. The states before and after an actorperforms an action are defined as situation. In theabove case, the electric energy is transformed into heatwhen it passes through the hairdryer (situation). Notethat all these elements need not be included in everyscenario; one or the other can be omitted if the generalidea of the scenario can be understood without them.In this case, the values of them are denoted as ‘‘N/A’’(means ‘‘null’’). In addition, a complex scenario mayinclude causal sequences of events and actions. In orderto specify the initial customer needs into more detaileditems for artifact design, this scenario can be dividedinto a series of subscenarios (also called scene). Eachscene has the same elements of a complete scenario butjust focuses on one episode of the initial customerneeds.

Scenarios are normally expressed in natural language(informal manner) (Alexander and Stevens, 2002; Carroll,2000; Hooks and Farry, 2001; Kaindl, 2000; Kurakawa,2004; Prudhomme et al., 2003; Young, 2001). In order to

Liu et al. 101



facilitate its use in requirements management and furtherthe progress of computer-based assistance in this field, aformal representation scheme of scenarios is proposed inthe next section.

Formal representation of scenario

Scenarios need to be represented in a well-structuredand easily understandable manner and should be pre-cise enough and detailed enough to support furtherproduct development. Yet no standard language existsfor formal representation of a scenario, which may hin-der the further progress of computer support in itsapplications. Therefore, a formal representationscheme is proposed in this section. The formalization isachieved through formally representing the constituentelements of a scenario, that is, how to formally repre-sent the actors, actions, and situation. Based on thestudy in artificial intelligence (Russell and Norvig,1995), the first-order logic, as a representation lan-guage, is close to a natural language and is suitable torepresent objects, their states, and relations. As a result,it is employed here for the scenario formalization.

In this section, before describing the scenario repre-sentation scheme, a product case is presented, whichwill also be used in the following sections of the articleas an example. This product is a soy milk maker. Asimplified schematic diagram of it is shown in Figure 1.It is an electromechanical device that is mainly used toproduce homemade soy milk quickly and conveniently.The raw materials are soaked soybeans and water.Electric energy is taken as the power supply of thisdevice. After a series of processing steps, the output willbe the boiled soy milk.

Representing actors and their states

Actors are the subjects of actions in scenarios. An actorA in a certain state S can be depicted by several proper-ties Pi (i = 1, 2 . n) of it; these are represented as

Pi(A). And if more than one property is used todescribe the state, these properties should be connectedwith the symbol ‘‘L,’’ that is, P1(A)LP2(A)LP3(A) .For example, in the soy milk maker case, the soakedsoybeans (actor), before being processed by themachine, are in a form of complete particles. This ini-tial state of the soybeans is described as ‘‘soaked(Soybeans)Lcomplete (Soybeans).’’

Representing action/event

Action is the movement or behavior of an actor thatwould cause a state change of the actor or some otherassociated actors in the same scenario. This interactionrelationship can be represented by the predicate: action(Pr, (A)), meaning that Pr exerts an action upon anobject A. In product design, the actions of a designedproduct (key actions) are always the top concern ofdesigners. Therefore, the product is taken as the defaultsubject of the key action of a scenario. And the actionof Pr upon A can be simplified as action (A). If multipleobjects are impacted by this action, the expressionshould be: action (A1, A2 . An). For example, one par-ticular action of the soy milk maker (Pr) is ‘‘mix thesoaked soybeans with cold water.’’ This phrase can beformalized as ‘‘mix (soaked (Soybeans), cold (Water)).’’The word in bold is the key verb to express the particu-lar action of this product. In this sentence, the productis the subject of this action, the soybeans (A1) and water(A2) are the objects processed by the product.

Representing situation

Situation indicates the state change of some actors aftera particular action. For one situation, there are at leasttwo states involved, that is, the state before and afteran action. A state is composed of some actors, theirassociated properties, and relations (see Figure 2, left).If actor A and actor B are in relation R, then the first-order logic form is R(A, B). A one-way arrow ‘‘ ’’ isused to denote the state transition in a situation. Forexample, a script in natural language about a situationthat occurs during soybean processing is ‘‘In a mixture

Figure 1. Soy milk maker. Figure 2. The scheme for representing a situation.




of soybeans and water, the soy milk maker breaks thesoaked soybeans into pieces. Then, the crushed soy-beans and water are fully mixed.’’ The action verb‘‘break’’ here is used as a watershed to divide the twostates, which are derived from this description, formu-lated as follows (see Figure 2, right).

Representing constraints

The representation of actors, actions, and situationsforms the framework of a scenario. In order to elabo-rate the requirements in scenarios, more details of cus-tomer needs must be taken into account. Therefore,besides identifying the characteristic elements of scenar-ios, a variety of constraints can be derived from thecustomer needs as supplements to enrich the scenariodescription.

In present approach, the constraint on x is simplifiedas C(x), where the x might be an actor with its proper-ties or a particular action. In the aforementioned soymilk maker case, the container inside the product is usedto keep the mixture of soybeans and water. So it must bemade of waterproof material for rust resistance. Thestatement requires that the container must be water-proof. In first-order logic, they are expressed as:

waterproof material Containerð Þð Þ ð1Þ

resistance material Containerð Þ, rustð Þ ð2Þ

These are constraints on the properties of actors(product or its components). In addition, there are alsoconstraints on some actions of actors, as follows:

noise break soaked Soybeansð Þð Þð Þ80 dBAð Þ ð3Þ

:vibration break soaked Soybeansð Þð Þ,Machinebodyð Þ ð4Þ

Constraint (3) denotes that during the breaking pro-cess of soybeans, the noise made by the machine shouldbe restricted to 80 dBA or less. Meanwhile, the vibra-tion of the machine body should be avoided (in con-straint (4)). By comparing the constraint cases, thereare two categories of constraints that can be distin-guished here, that is, qualitative constraints and quanti-tative constraints. The qualitative constraints describecertain desired properties or state of actors or actions.Their expressions are first-order logic sentences. Theconstraints (1), (2), and (4) are in this category. In con-trast, the quantitative constraints are constructed withsome measurable properties, meaning that the proper-ties are within a range of values in an interval (pair ofnumbers indicating the lower and the upper bound-aries). The interval can be closed or not closed. So thiscategory of constraints can be formulated as equationsor inequalities over the properties of actors. The con-straint (3) is a quantitative constraint.

Scenario-based requirementsmanagement process

This section introduces how scenarios are employed inthe process of engineering requirements management.As shown in Figure 3, the requirements management isa stepwise process that can be conceptualized as athree-phase model (requirements management processmodel (RMPM)). The starting point of this model isthe initial statements of customer needs, and the endingpoint is the design specifications that are represented byformalized scenarios. Between these two points lies awide gap that has to be bridged during the preliminarydesign stage. In this model, the gap is divided intosmaller ones, thus reducing the difficulty and complex-ity of developing the design specifications on the basisof customer needs statements. Three primary phases areincluded in this division to enhance the ease of model-ing the requirements management process: elicitationphase, the decomposition phase, and the formalizationphase. The details of each phase will be introduced inthe following paragraphs of this section.

Elicitation phase

The first phase is the customer needs elicitation (inFigure 3, top left), which emphasizes a transformationthat converts customer verbatim constructs into explicitand objective customer requirements (Jiao and Chen,2006). The initial customer needs statements are nor-mally qualitative and tend to be vague, partial, andsubjective due to their linguistic origins. Sometimes, thestatements from one customer group might have con-siderable conflict with another. Therefore, in this phase,experienced engineering designers should try to deter-mine the requirements as concretely and as completelyas possible, including implicit ones, distinguish manda-tory and desirable requirements, and look for contra-dictions between these requirements. This would be aniterative process that is mainly achieved through inter-views between customers and designers.

Figure 3. Requirements management process model.

Liu et al. 103



After elicitation, the refined statements of customerneeds are often an overview of what customers wantand an overall functionality of the artifact to bedesigned. Subsequently, various scenarios need to becreated to further specify the requirements. During thisprocess, the requirement statements will likely bedecomposed into different scenarios.

Decomposition phase

In this phase, the scenarios begin to be integrated intothe requirements management process. There are tworeasons for the creation of scenarios: one is to furtherspecify the elicited customer needs statements throughidentifying the characteristic elements (introduced insection ‘‘Representing situation’’) of the scenario. Here,the identification is done by inquiry, that is, asking sev-eral distinct types of questions by designers.

� When/where. These questions ask about the timeand location constraints on the event in a scenario,that is, when and where the scenario happens.

� Who. These questions request confirmation aboutthe actors/agents who will participate in a scenario.This means that both the product and its associatedenvironmental elements should be clarified bydesigners in the requirements management process.

� What is. These questions ask about the role anagent plays and its actions in a scenario.

� How. These questions request further clarificationof the agents’ state change process in a scenarioafter some actions are taken, that is, how theactions are performed.

The other reason for creating scenarios is to structu-rally interpret the elicited statements through identify-ing the relationships between these scenarios. There aretwo kinds of relations distinguished here, that is, thesequential relation (SR) and the concurrent relation(CR). Scenarios in SRs refer to those scenarios thathappen sequentially, meaning that the event that occursin a latter scenario is conditional to the event occurringin its former one. Hence, this is a causal sequence. Forexample, in the soy milk production, the scenario of‘‘breaking soybeans’’ occurs after the scenario of ‘‘mix-ing soaked soybeans with water.’’ Scenarios in CRsindicate that one scenario happens during the occur-rence of another. For example, in the soy milk cookingprocess (as scenario A), the boiled liquid may overflowfrom the container (as scenario B). These two scenariosare concurrent scenarios. Anyway, the scenarios in rela-tions of SR or CR can be summarized as interrelatedscenarios. They are strongly associated with the statetransformation process of the operand (energy, mate-rial, or signal) in the use of product. Besides, there are

also scenarios with no direct correlations, for example,the installation and transportation of the soy milkmaker are both product-usage scenarios but have nodirect relations between them and the scenarios of thesoy milk production process.

Formalization phase

In the present approach, the formalization of require-ments is achieved by formally representing various sce-narios. The technology used for formal representationof scenarios has been introduced in section ‘‘Formalrepresentation of scenario.’’

After the formalization phase, the scenario-basedrequirements management process is finished. The threesequential phases indicate a transition process from ini-tial customer needs statements to the final formalizeddesign specifications. During this process, the results ofa latter phase are built based on the foundation of itsformer phase. In this way, the formal product specifica-tions can be traced back to the initial natural languagestatements. Therefore, a clear mapping between them isassured.

An illustrative case

A soy milk maker is a small kitchen appliance thatautomatically cooks soy milk for family members. Thissection reports a case study conducted for the soy milkmaker design to practice the proposed scenario-basedrequirements management methodology. In order tocompare our approach, a design specification (inrequirements list) for the same case is also presented inAppendix 1.

Elicited customer needs statements

As mentioned in section ‘Scenario-based requirementsmanagement process,’’ the start point of requirementsmanagement is often a large collection of natural lan-guage requirements statements. The elicitation of initialcustomer requirements is achieved through comprehen-sive interviews with customers. The communicationprocess is beyond the concern of this article, and thus,it is not given in detail here. Following are the elicitedcustomer needs statements (in italic):

Fresh soy milk is a daily drink for many people, but getting

up early in the morning to purchase soy milk from street ven-

der is an unpleasant thing. Thus, customers require a small

appliance to make high quality soy milk at home for family

members (3-4 people). The soy milk making process should

be simple and safe. This process must be finished within a

short time (30 min), and the cleaning of the device after use

should also be taken into account. Because it is designed for




use in the kitchen, one person should be enough for its trans-

portation. Moreover, the price must be affordable to a com-

mon family.

Requirements decomposition

Based on the elicited statements of customer needs inthe last subsection, various scenarios are created todecompose the statements into many slices, as shownin Figure 4. The creation of a scenario is achieved byidentifying its characteristic elements, following the

inquiry-based way introduced in section ‘‘The decom-position phase.’’ As shown in Figure 4, scenario(I)(abbreviated as S(I)), S(II), S(III), S(IV), and S(VI) arerelevant scenarios that are directly associated with thesoy milk production process. Among them, the S(I),S(II), S(III), and S(IV) are in SRs, dividing the soy milkprocessing into four sequential steps. The bold verb ineach of these four scenarios denotes one action of thesoy milk maker. S(III) and S(VI) are in CR. Theremaining scenarios (S(V), S(VII), and S(VIII)) areabout the installation, cleaning, and transportation of

Figure 4. Informal scenarios graph of soy milk maker.

Liu et al. 105



the machine, respectively. They are relatively indepen-dent. In addition, the specifications associated with theevent happening in a scenario are the sentences in

italics, as restrictions on the scenario. Ultimately, cus-tomer requirements are not only multifaceted but arealso intrinsically open ended; more scenarios can be

Figure 5. Formal scenarios graph of soy milk maker.




added to this graph. However, there is no real sensethat all the requirements can be represented by scenar-ios. For instance, the budget price of the designedproduct is an economic requirement that is hard toassign to a particular scenario, so it is listed as an addi-tional specification at the bottom of this scenariograph.

Scenario formalization

In contrast to Figure 4, Figure 5 illustrates the scenariograph after formalization. In each formalized scenario,the one-way arrow ‘‘ ’’ indicates the state change in asituation. The change is usually caused by a productaction, which is described by a predicate sentence witha bold verb. The contents in italic are the constraints inform of predicate sentences.

Discussion and conclusions

In contrast to the design specifications (in Appendix 1) ofthis design case, the advantages of the scenario-basedrequirements management approach can be mainly sum-marized into the following aspects. First, requirementsmanagement is performed as a stepwise refinement pro-cess in our approach. The RMPM (in Figure 3) providesa guideline for designers to acquire customer require-ments and subsequently refine these requirements step bystep. Second, scenarios play a role as information carrierto represent the specified customer requirements, that is,the informal scenarios in natural language can assistdesigners to clarify customer needs, and the formal sce-narios represent requirements in a certain level of abstrac-tion, which can facilitate design solution searching. Theformal format is also helpful for further development ofcomputer-aided tools in engineering requirements man-agements. Third, the scenarios are created with a primaryconcern for the working process of designed products. Sothe requirements generated in this process are inter-spersed into several interrelated scenarios, rather than thecausal form in a requirements list. The correlations ofthese requirements are thus established.

In conclusion, this article provides a scenario-basedsystematic approach for the identification, elaboration,and specification of engineering design requirements.The requirements management process is conceptua-lized as a three-phase model, and the applicability ofscenarios is also shown in the model. In this approach,the concept of scenarios is extended on the basis of sce-narios known in the field of RE. Furthermore, a com-prehensive view of scenario is introduced on the aspectsof concept, purpose, content, and form. A formal repre-sentation scheme of scenarios is also developed for fur-ther advancement of computer support in engineeringrequirements management. A case study on the

requirements management for a soy milk maker designillustrates the operations in the present approach.

Funding

This research is supported by Natural Science Foundation ofChina (grant nos. 50975173 and 50935004), Ministry ofScience and Technology of China (grant no. 2008AA04Z108),and Science and Technology Commission of ShanghaiMunicipality (grant no. 09QA1402800).

Acknowledgment

We are grateful to the reviewers and the editors for their con-structive suggestions. We specially thank Mr Reynolds forimproving the quality of this article.

References

Alexander IF and Stevens R (2002) Writing Better Require-

ments. London: Addison-Wesley.Baxter D, Gao J, Case K, et al. (2008) A framework to inte-

grate design knowledge reuse and requirements manage-

ment in engineering design. Robotics and Computer-

Integrated Manufacturing 24: 585–593.Carroll J (2000) Five reasons for scenario-based design. Inter-

acting with Computers 13: 43–60.Chen C-H and Occena LG (1999) A knowledge sorting pro-

cess for a product design expert system. Expert Systems

16(3): 170–182.Chen C-H and Occena LG (2000) Knowledge decomposition

for a product design black-board expert system. Artificial

Intelligence in Engineering 14(1): 71–82.Chen C-H, Khoo LP and YanW (2002) A strategy for acquir-

ing customer requirement patterns using laddering tech-

nique and ART2 neural network. Advanced Engineering

Informatics 16(3): 229–240.Darlington MJ and Culley SJ (2002) Current research in the

engineering design requirement. Proceedings of IMechE, Part

B: Journal of Engineering Manufacture 216(3): 375–388.Fiksel J and Hayes-Roth F (1993) Computer-aided require-

ment management. Concurrent Engineering: Research and

Application 1(2): 83–92.Fung RYK, Tang J, Tu PY, et al. (2003) Modeling of quality

function deployment planning with resource allocation.

Research in Engineering Design 14(1): 247–255.Herlea Damian DE, Jonker CM, Treur J, et al. (2005) Inte-

gration of behavioural requirements specification within

compositional knowledge engineering. Knowledge-Based

Systems Journal 18: 353–365.Hooks IF and Farry KA (2001) Customer-Centered Products.

New York: AMACOM.Jiao J and Chen C-H (2006) Customer requirement manage-

ment in product development: a review of research issues.

Concurrent Engineering: Research and Application 14(3):

173–185.Jiao J and Zhang Y (2005) Product portfolio identification

based on association rule mining. Computer-Aided Design

37(2): 149–172.

Liu et al. 107



Clark

高亮

Kaindl H (2000) A design process based on a model combin-

ing scenarios with goals and functions. IEEE Transactions

on Systems, Man and Cybernetics, Part A: Systems and

Humans 30(5): 537–551.Kano N, Seraku N, Takahashi F, et al. (1984) Attractive qual-

ity and must-be quality. Japan Society for Quality Control,

Hinshitsu 14(2): 39–48.Kazemzadeh RB, Behzadian M, Aghdasi M, et al. (2009)

Integration of marketing research techniques into house ofquality and product family design. International Journal of

Manufacturing Technology 41: 1019–1033.Kurakawa K (2004) A scenario-driven conceptual design

information model and its formation. Research in Engi-

neering Design 15: 122–137.Misra S, Kumar V and Kumar U (2005) Goal-oriented or

scenario-based requirements engineering technique-what

should a practitioner select? In: Canadian conference

on electrical and computer engineering, Saskatoon, Canada

1–4 May.Pahl G and Beitz W (1996) Engineering Design. A Systematic

Approach. 2nd ed. New York: Springer–Verlag.Potts C (1999) ScenIC: a strategy for inquiry-driven require-

ments determination. In: 4th IEEE international symposium

on requirements engineering, pp.58–65. Los Alamitos, CA

7–11 June: IEEE Computer Society Press.Prasad B (1998) Review of QFD and related deployment tech-

niques. Journal of Manufacturing Systems 17(3): 221–234.Prasad B (2000) A concurrent function deployment technique

for a workgroup-based engineering design process. Journalof Engineering Design 11(2): 103–119.

Prudhomme G, Zwolinski P and Brissaud D (2003) Integrat-ing into the design process the needs of those involved inthe product life-cycle. Journal of Engineering Design 14(3):333–353.

Rios J, Roy R and Sackett P 92006) Requirements engineer-ing and management for manufacturing, Michigan, USA:Society of Manufacturing Engineers (SME). Blue BookSeries.

Russell S and Norvig P(1995)Artificial intelligence: a modernapproach, 2nd ed. Hong Kong: Pearson Education AsiaLimited and Tsinghua Univ. Press, 2006.

Sutcliffe AG (2003) Scenario-based requirements engineering.In: Proceedings of the 11th IEEE international conference.Montery Bay, CA, 8–12 September 2003, pp.320–329. LosAlamitos, CA: IEEE Computer Society Press.

Sutcliffe AG, Maiden NAM, Minocha S, et al. (1998) Sup-porting scenario-based requirements engineering. IEEE

Transactions on Software Engineering 24(12): 1072–1088.Tseng MM and Jiao J (1998) Computer-aided requirement

management for production definition: a methodologyand implementation. Concurrent Engineering: Research

and Application 6(2): 145–160.Yan W, Chen C-H and Khoo LP (2002) An integrated

approach to the elicitation of customer requirements forengineering design using picture sorts and fuzzy evalua-tion. Artificial Intelligence for Engineering Design, Analysis

and Manufacturing 16(2): 59–71.Young RR (2001) Effective Requirements Practices. Boston,

MA: Addison-Wesley.

Appendix 1 Design specifications of soy milk maker

List of requirements: soy milk maker

1. Geometry:(a) Consideration of the maximum capacity of soy milk production for one time 1200–1800 mL (for 2–3 people to drink)(b) Consideration of the length of a adult user’s palm and arm (portable)

2. Kinematics:(a) Speed range of build-in motor to break soaked soybeans in a container(b) The machine body should stand stable during the working process, vibration control(c) The soy milk production process should be finished in a short time (within 30 min)

3. Weight:(a) Empty: maximum of 3.5 kg(b) Dry soybeans: 80 6 5 g(c) Water and soybeans: 1300–1600 mL

4. Energy:(a) Electric motor þ 220 V AC or electric motor þ accumulator(b) 30-min duration of use per time, 1–10 times of use per day(c) Ambient air temperature during working: 15�C–28�C

5. Material:(a) Waterproof, suitable for kitchen use(b) Free from rust, moisture resistant(c) Consideration of temperature raise during soy milk production(d) Food safe, no contamination to the soy milk(e) Easily cleaned, hard for soy milk residue to attach on the container(f) Materials against minor collision

6. Safety:(a) Overflow prevention(b) Electric power leakage prevention

(continued)




Biographies

Ze-Lin Liu is a PhD candidate of Institute of Engineering Design, School of Mechanical Engineering, ShanghaiJiao Tong University, Shanghai. He has a major in mechanical design. His research interests are knowledge-basedsystem, artificial intelligence in product/engineering design, and supporting tools.

Zhinan Zhang is a postdoctoral candidate in Shanghai Jiao Tong University, China. He also received his PhDdegree in this university. His research interests include design theory and methodology, knowledge flow, and sup-porting tools. Also he has more than 3 years experience on engine tribology.

Yong Chen is an associate professor of Institute of Engineering Design, School of Mechanical Engineering,Shanghai Jiao Tong University, Shanghai. He received his PhD degree in Zhejiang University. His research inter-ests include conceptual design, artificial intelligence in product/engineering design, and knowledge-based system.

Appendix 1 (continued)

List of requirements: soy milk maker

7. Ergonomics:(a) Portable handle(b) Noise control (maximum of 80 dBA noise development)(c) Simple operating and control elements

8. Construction:(a) Complete delivery, possibly only partly preassembled, and container/control panel/handle/filter possibly to be mounted by a

user9. Transportation:

(a) One person is sufficient for transportation10. Maintenance:

(a) Easily cleaned with water(b) No wearing parts, if easily replaceable(c) Easily disassembled to reload raw materials

11. Costs:(a) Budget-priced (maximum of $150)

12. Recycling:(a) Enable separation of waste disposal, environment friendly

Liu et al. 109



a scenario-based approach for requirements management in

Documents