1. requirements engineering and management for manufacturing

NameAuthor

Title ofBlue Book

SME

RequirementsRequirementsRequirementsRequirementsRequirementsEngineering andEngineering andEngineering andEngineering andEngineering andManagManagManagManagManagement fement fement fement fement forororororManManManManManufufufufufacturacturacturacturacturinginginginging

Jose Rios, PhD, Rajkumar Roy, PhD,and Peter Sackett, PhD

Authors

BLUE BOOK SERIES2006

Published by the Society of Manufacturing Engineers

RequirementsRequirementsRequirementsRequirementsRequirementsEngineering andEngineering andEngineering andEngineering andEngineering andManagManagManagManagManagement fement fement fement fement forororororManManManManManufufufufufacturacturacturacturacturinginginginging

Copyright 2006Society of Manufacturing Engineers

This Blue Book may not be reproduced in whole or in part in any form without the express written permissionof the Society of Manufacturing Engineers. By publishing this Blue Book, SME neither endorses any product,

service or information discussed herein, nor offers any advice. SME specifically disclaims any warrantyof reliability or safety of any of the information contained herein.

ISSN 0895-5085Manufactured in the United States

PUBLISHED BY THE SOCIETY OF MANUFACTURING ENGINEERS

Society of Manufacturing Engineers One SME Drive P.O. Box 930 Dearborn, Michigan 48121 USA(313) 271-1500 FAX (313) 425-3400 www.sme.org

SME MANUFACTURING ENTERPRISE WHEEL

SME BLUE BOOK SERIES 2006 z www.sme.org

SMEs Manufacturing Enterprise Wheel is a graphical representation of processes and organiza-tional knowledge required to operate within the emerging manufacturing environment. As architecture,it provides a manufacturing context for system-level analysis and integration. The architecture puts cus-tomer at the heart and relates the customer expectations with different facets of manufacturing. TheWheel presents a sociotechnical context to the manufacturing, where customer expectations are realizedas a product or service through complex interaction between humans (levels 2 and 3), organizationalstructures (levels 2 and 3) and technology (levels 3, 4 and 5).

Voice of the customer and regulatory responsibilities are represented as requirements. Throughthe requirements, the expectations are communicated to the designers and manufacturing engineers.Human ambiguity in requirements definition is often the source of inefficiency in the product realiza-tion process. It is necessary to elicit, represent and manage the requirements in a structured manner toimprove the communication between the customer and the engineers. This will improve the interac-tions between levels 1 to 5 in the Wheel and reduce product realization time and cost.


About the AuthorsJose Rios, PhD, worked for one year in the Department of Industrial and Manufacturing Engineering

at Penn State University. In 1997, he obtained the University PhD Award in Manufacturing from the Poly-technic University of Madrid, Spain. Since 1998, Rios has held a lecturer position in the Department ofMechanical Engineering and Manufacturing at the University of Madrid. He has participated and led re-search projects related to manufacturing, CAD/CAM, information modeling, knowledge-based engineer-ing (KBE), cost engineering and product requirements, collaborating with different companies mainlyfrom the aeronautical and the moldmaking sectors. In the standardization area, he was the Spanish repre-sentative in the ISO TC 184/SC4 Industrial Data and Global Manufacturing Programming Languages. InSeptember 2003, Rios joined Cranfield University where he holds a research fellow position in the Deci-sion Engineering Centre.

Rajkumar Roy, PhD, is the head of the Decision Engineering Centre within the School of Indus-trial Manufacturing Science at Cranfield University. He has a strong academic, research and industrialbackground in design and manufacturing. Roy is currently leading a research group in the decision en-gineering area, specializing in cost engineering, requirements management, knowledge capture, ap-plied soft computing and design optimization. The scale of cost engineering research under thesupervision of Roy is perhaps the biggest activity in hardware cost estimating in the world. He has pub-lished his work extensively and has co-edited six books in the engineering design and manufacturingarea, as well as edited the book Industrial Knowledge Management.

Peter John Sackett, Eur Ing, MSc, PhD, CEng, FIEE, Cert Ed, senior SME member, is professor of in-tegrated systems and director of CIM Limited, the consultancy company within the School of Industrial &Manufacturing Science, as well as head of the Information Systems Group supporting 650 networked com-puter systems. He holds doctoral and master degrees from the University of Manchester, England. Hejoined the staff of Cranfield University in 1985 and was made a full professor at the university in 1990.Sackett has published over 200 papers in the field of integrated enterprise technology application.

SME BLUE BOOK SERIES 2006 z www.sme.org1

Requirements Engineeringand Management for

Manufacturing

INTRODUCTIONRequirements engineering is a distinctive dis-

cipline. It makes use of a systematic methodologyto identify, document, formalize, manage, main-tain, verify, validate and disseminate the require-ments related to a particular project, system,product or service during its whole life cycle. Theincrease in the complexity means the relevance ofthis recently coined manufacturing engineeringdiscipline is becoming greater.

A requirement is a statement of a need,something that a stakeholder wants. The require-ments issue is being addressed by product designengineering, software engineering and systems en-gineering. Traditionally, requirements in productdesign engineering focus on design of electrome-chanical products. In software engineering, the fo-cus is on the design of software, while in systemsengineering, the focus is on the design of complexproducts that combine electromechanical, elec-tronic, software and other kind of components.However, the software engineering view is consid-ered under the systems engineering discipline;hence, the two main approaches presented dealwith the disciplines of product design engineeringand systems engineering.

This Blue Book reviews the approaches thatthese disciplines provide. The topics presentedshow the requirements relevance, review the mainissues involved, such as terminology, classification,process and writing, and present requirement man-agement and leading-edge work focused on the au-tomotive and aerospace industries. Guidelines arepresented on where to start with requirements.

WHY REQUIREMENTS ARE NEEDEDThe authors interpretation of engineering is

the application of scientific knowledge to the lifecycle of solutions. We have not included in thedefinition any qualifier related to the solution,

such as compliant with customer demands, cost ef-fective, compliant with specific performance fea-tures, compliant with safety regulations, compliantwith the business strategy and so on. If we want toengineer a solution, it is because we have a prob-lem to resolve or a need to satisfy. Depending onthe kind of problem or need, specific knowledgewill be needed. When looking at the solution lifecycle from a top view, stages are identified, such asbusiness definition, solution design and develop-ment, planning, manufacturing, deployment, sup-port and maintenance, disposal and so on. Thecomplexity of the whole process and of each spe-cific life cycle stage depends on the kind of prob-lem to resolve and the solution adopted.

Several questions that can be asked are: What isthe problem to be solved? What is the need to be sat-isfied? How could the solution satisfy the stakehold-ers? How could the solution add value to thecustomer? How could we engineer something usefulto the stakeholders? How could we validate ourproduct? If we know the stakeholders requirements,then we can engineer any solution properly.

The importance of requirements is increas-ingly recognized because of the clear link withproductivity. Several studies have determined thatbetween 60% and 80% of product inconsistenciesare created during the requirement definitionstage in the development phase [1].

Independent of the complexity of the prob-lem, the solution and its associated processes, therequirements need to be explicitly known becausethe final objective should be to satisfy them. Thisstatement can be understood from the analysis ofthe typical flow down of requirements and upwardintegration and test of the V-model (Figure 1).

The term requirement can refer to stake-holder requirement, problem requirement, solu-tion requirement, customer requirement,functional requirement, nonfunctional require-


2

ment, performance requirement, constraint andmore. Definitions from different authors demon-strate that, depending on the source of informa-tion, there may be different interpretations and, inmany cases, a misunderstanding of what a require-ment should be. Depending on the stage of thesolution life cycle and the engineering task cur-rently being performed, the term requirement mayrefer to different kinds of requirements. If weknow precisely what a requirement is, then we cancapture and formulate it in a way that it can beused during the engineering process.

Definitions from SystemsEngineering Discipline

According to IEEE [2], A requirement is astatement that identifies a product or process op-erational, functional, or design characteristic orconstraint, which is unambiguous, testable or mea-surable, and necessary for product or process ac-ceptability (by consumers or internal qualityassurance guidelines). This definition encompassesmost of the attributes a requirement should have.

A generic view is provided by Kontoya andSommerville [3], Requirements are descriptionsof how the system should behave, application do-main information, constraints on the systems op-eration, or specifications of a system property or

attribute. Sometimes they are constraints on thedevelopment process of the system. A nontechni-cal and stakeholder-oriented view is provided byAlexander and Stevens [4], A requirement is a state-ment of need, something that some class of user orother stakeholder wants.

Kulak and Guiney [5] state that, A require-ment is something that a computer applicationmust do for its users. It is a specific function, fea-ture, quality, or principle that the system must pro-vide in order for it to merit its existence. Adistinction is made between functional require-mentswhat the users need for the system towork. They are functions and features. Andnonfunctional requirements address the hiddenareas of the system that are important to the users,even though they may not realize it. They are theglobal fuzzy factors or principles that relate to thesystems overall success. Sometimes they are calledthe -ilities. This is a software-oriented view, mak-ing a distinction between functional and nonfunc-tional requirements. As will be discussed later, theaim should be to reduce the fuzzy factors from therequirements specifications.

Some people suggest that requirementsshould always be statements of what a systemshould do rather than a statement of how itshould do it. This is an attractive idea but it is too

Figure 1. Typical V-model for requirements flow down and upward verification and test.


simplistic in practice [6]. We should thereforeplan to document both things because it is likelythat we have more than one solution to achieve aspecific goal.

According to the European Cooperation forSpace Standardization [7], customers require-ments (needs and objectives) should be analyzedto generate the system specification requirements.The system specification requirements are identi-fied and grouped in relationship to their primaryobjective: functional, configurational, interfaces,physical, environmental, etc. In this case, two dif-ferent kinds of requirements are proposed, for ex-ample, customer requirements (what is wanted innontechnical terms) and system specification (dif-ferent kinds of requirements).

Definitions from ProductEngineering Design Discipline

Cross [8] states that a requirement is a de-mand that must be met, and it should be ex-pressed in quantified terms [as] it points out whatthe product must do. The idea of quantified re-quirements is important, as is the distinction be-tween problem requirements and solutionspecification.

According to Pahl and Beitz [9], require-ments can be demands (requirements that mustbe met under all circumstances) or wishes (re-quirements that should be taken into consider-ation whenever possible). Requirements should,if possible, be quantified and, in any case, definedin the clearest possible terms. They also supportthe idea of quantified requirements, adding theidea of clearness to their definition.

Ulrich and Eppinger [10] draw from cus-tomer needs to product target specifications. Fromtheir text, the following description can be ex-tracted: A requirement or specification consists ofa metric (something that can be measured and fa-cilitates the quantification of some particular cus-tomer need) and a value (value of the metriclabeled with the appropriated unit). It is impor-tant to have quantified requirements because theyhave to be measurable; hence, a value and a unitare needed in the requirement definition.

Quality function deployment (QFD) method-ology [11] distinguishes between customer wantsand needs and design requirements. It claims toprovide a structured transition from the customerwants and needs to the technical specification.

QFD makes use of the Kano model for quality,where three types of customer requirements areconsidered, as follows:

Revealed requirementsthose we get by askingcustomers what they want.

Expected requirementsalso called unspoken,unless violated basic needs.

Exciting requirementsthey are usually beyondthe customers knowledge or expectations.

Even though understanding the customersneeds, also called demanded qualities, is the keypoint, no guidance is provided in terms of how tobetter write any of these qualities. According toTerninko [12], the process goes from the de-manded quality (customers subjective descriptionof the performance of the product and its func-tions) to the performance measure (a technicalmeasurement evaluating the performance of somedemanded quality; it is often stated how and bywhat you measure).

In axiomatic design theory, a distinction ismade between different domains: customer, func-tional, physical and process. In the customer do-main, needs are identified that are thenformalized in the functional domain by the de-signer to define the design problem in the form offunctional requirements (what the product has todo). Design parameters that satisfy such functionalrequirements then have to be defined [13].

Related TermsIn the problem domain, we can distinguish

between functional requirementwhat the stake-holders demand the product must do indepen-dently of any possible solution, and nonfunctionalrequirementthe qualities demanded from theproduct (qualities related to aesthetics, mainte-nance, cost and so on) [10,13,14].

In the solution domain, the term design pa-rameter can be found, meaning any physical prop-erty whose value determines the functionality ofthe product (weight, length, surface finish) [13].Close to this term, product attribute can be de-fined as a property that identifies a characteristicor quality of a product. A design parameter is akind of product attribute, but not all the productattributes are design parameters (cost).

Finally, the term constraint can be used inboth domains. It refers to a measurable restrictionthat, in general, affects some kind of requirement


4

(in the problem domain) or product attribute (inthe solution domain) and limits the range of pos-sible solutions to valid ones.

Definitions Summary:An Integrated View

These different meanings of the word re-quirement are usually clarified when the domainsare considered. A good practice is to use the termrequirement with the domain explicitly expressed.We suggest using the term requirement only in theproblem domain, adding the problem subdomainname, functional or nonfunctional, depending onthe case. In the solution domain, we suggest usingthe terms product attribute and design parameter,which are usually known as design specifications.

Whatever requirement is used, it should beverifiable, measurable, ranked, single, unambigu-ous, traceable and unique. A requirement is asingle, unique and unambiguous statement innatural language of a single what or functionthat some class of user, stakeholder or clientwants, written in a way that it can be ranked, vali-dated, traced, measured and verified. When con-sidering the term constraint, we may find itapplied to some kind of requirement (functionalor nonfunctional) and to product attributes anddesign parameters. It represents a boundary or alimit expressed in numerical terms.

CLASSIFICATION OFREQUIREMENTS

There are two main objectives for classifyingrequirements:

To get a better understanding of what is re-quired (problem or need) and about the prod-uct (solution) as these evolve along the productlife cycle.

Requirements need to be organized in a waythat they can be efficiently used during the ex-ecution of the tasks and to validate the outputof the tasks. This may need a process analysis,and it implies the reuse of the results as a start-ing point in later projects.

The classification of requirements is a chal-lenging task. The number of requirements can bevery large. In some cases, a scenario of use helpsto classify the requirements. The creation of a clas-sification could be based on:

Who defines the requirement.

The importance of the requirements. Where in the process the requirement is defined. What the requirements are concerned with.

ApproachesAccording to Sommerville and Sawyer [6], re-

quirements should be classified in a multidimen-sional approach. To do so, it is necessary toidentify certain dimensions and keywords that de-scribe each requirement, including user interface,database and so on. At the beginning of eachproduct project, these dimensions should be de-fined. The question, however, is should the focusbe on the problem or on the solution? If we con-sider a physical product, these dimensions andkeywords could be associated with the subsystemsor product breakdown structure and depend onthe complexity of the product and the level atwhich we want to specify the requirements. In theproblem domain, it is recommended to make adistinction between the different stakeholderssubdomains and the functional subdomain.

The definition of user requirements, whichare a particular kind of stakeholder requirements,can be the statement of a need or the statement ofhow to use a product. The definition of usecases is widely accepted in the area of softwareand systems development [5]. The idea is basedon a sequence of steps describing an interactionbetween a user and a system. However, its appli-cation on consumer products is not clear, mainlybecause of restrictions imposed by the product it-self in terms of user access to the product prior toits launching.

Another approach to requirements categori-zation is the use of design spaces [15]. This ap-proach maps requirements to components thatalready exist and relies on the idea that a knownand manageable set of component variants islikely to cover the vast majority of possible re-quirements. A design space provides designchoices that are grouped in hierarchical catego-ries. This approach is applied in the solution-ori-ented domain.

Typical approaches to requirements classifica-tion are shown in Table 1. The problem ariseswhen deciding which categories should be in-cluded. From the authors point of view, the clas-sification provided by Hooks and Farry [1] is themost appropriated when considering the manufac-turing engineering perspective. However, it is very


]1[yrraFdnaskooH ]3[ellivremmoSdnaayotnoK ]7[A01-E-SSCE ]9[ztieBdnalhaP ]41[nostreboRdnanostreboR

ecnamrofrepdnalanoitcnuF lanoitcnuF lanoitcnuF yrtemoeG lanoitcnuF

lacisyhP lanoitcnufnoN lanoitarugifnoC scitameniK lanoitcnufnoN

ytilibavivrusdnasnoitidnoclatnemnorivnE ssecorP secafretnI secroF leefdnakooL

ytilibaileR yrevileD lacisyhP ygrenE ytilibasU

ytilibaniatniaM noitatnemelpmI latnemnorivnE lairetaM ecnamrofreP

ytilibaliavA sdradnatS srotcafytilauQ slangiS lanoitarepO

ytilibaecivreS tcudorP noitarepO ytefaS ytilibatropdnaytilibaniatniaM

ytilibomdnaytilibatropsnarT ytilibasU troppuS scimonogrE ytiruceS

citsigoL ytilibaileR noitacifireV noitcudorP lacitilopdnalarutluC

)ytilibareponamuh(ytilibasU ytefaS lortnocytilauQ lageL

ytiruceS ycneiciffE ylbmessA

tnemhsibruferdnaesueR ecnamrofreP tropsnarT

ytefaS yticapaC noitarepO

ytilibatseT lanretxE ecnanetniaM

ecnerefretnicitengamortcelE stniartsnoclageL gnilcyceR

esustrapdnasessecorp,slairetaM stniartsnoccimonocE stsoC

gnilebaL ytilibareporetnI seludehcS

ngiseD

ytilibaegnahcretnI

pihsnamkroW

ytilibadroffadnatsocgnirutcafunaM

ytilibicudorP

ytilibasopsiD

gnikcaP

tnempiuqe)esudnatset,gnirutcafunam(troppuSytilicafdna

Table 1. Different classifications of requirements.

difficult to recommend a single approach for anyspecific industrial environment.

A more advanced approach to classificationof requirements comes from the definition of on-tologies [16]. The ontological approach pursuesthe definition of the meaning of terms and of axi-oms to enable automatic deduction and reasoning.However, it is still a research area rather than a ma-ture approach adopted widely by industry practi-tioners.

As a general conclusion, requirements haveto be classified. How to classify the requirements

depends on the kind of problem or need to besatisfied, as well as the product or solution to beprovided. A recommended starting point is to con-sider stakeholders views and then identify whatother elements interface with the problem (com-pany policies, legislation, standards and so on).However, should we expect to create a fully de-fined classification from the very beginning? Theanswer is probably no. This task is iterative andamendments may be needed along the productlife cycle process. The fundamental aspect is tostart classifying the requirements.


6

REQUIREMENTS: FUNDAMENTALINPUT TO PRODUCT ENGINEERINGDESIGN

Requirements are the main input to the sys-tem/product design and development process. Ifthe whole product life cycle should be consideredwhen defining the requirements, and the mainreasoning cycle in the design process is an itera-tive analysis and synthesis loop where require-ments are the input and design solutions are theoutput, then product engineering design is thebasic discipline to consider when addressing howto go from a problem-oriented description to a so-lution-oriented description. This demonstrates theneed for explicitly defined requirement practicesand a supporting requirement management pro-cess (Figure 2). Two additional conclusions are asfollows:

1. Requirements have stakeholder views. All thestakeholder views are considered as a problem-oriented view where the problem to resolve isspecified. These requirements are the onesused in the analysis phase, and they evolvefrom stakeholder terms to technical terms, cre-ating system requirements or product require-ments. Still, there should be no reference toany kind of solution.

2. The requirements from the analysis phase areused as input in the synthesis phase to generatedesign solutions, possibly each of them charac-terized by design parameters, design attributesand related constraints, which are documentedas a design specification. This is considered asolution-oriented view, where the solution tocreate and implement is specified.

Because of the complexity of the analysis andsynthesis process techniques, facilitate part of theprocess by formalizing some steps and providingtemplates to represent requirements and design so-lution concepts. Among all the possible ap-proaches, we have selected the quality functiondeployment technique, which is probably the mostrelevant from an industrial application point ofview [11,12,17]. Additionally, axiomatic designtheory provides some interesting ideas that couldbe implemented in an industrial environment [13].

Requirements and QualityFunction Deployment

When applying quality function deployment(QFD), the first matrix relates customer wants andneeds (named WHATs) with product design charac-teristics (named HOWs) (Figure 3). This means nodistinction between nonfunctional requirements

Figure 2. Relationship between requirements and design.


and functional requirements from thetechnique itself, but the team applying itcould do it. Table 2 presents an example.

Considering this example, the re-quirements are written far from theideas presented in the summary of re-quirements definitions in terms of be-ing measurable, verifiable andunambiguous. Ambiguity of some of theterms used (e.g. easy) and lack of infor-mation makes it very difficult to evalu-ate and validate them (cupboard fit).There is no distinction between differ-ent kinds of requirements (functionalrequirement, nonfunctional, design pa-rameters, constraints and so on). Theproblem is that the requirements speci-fication and relationships identificationrely on the judgment of the people de-fining them. Apart from these issues,QFD is a useful technique when ap-plied in combination with requirementsclassification and writing guidelines.

Requirements andAxiomatic Design Theory

Through axiomatic design [13], it is possibleto represent the relationship of design and re-quirements (Figure 4). Requirements (stakehold-ers needs) and functional requirements should bedefined in the stakeholder domain and in thefunctional domain, respectively; these are problemoriented. From the theoretical perspective, thisdistinction between domains is clear, but a map-ping is needed between the stakeholder domain,where the stakeholder requirements are defined,and the functional domain, where what the prod-uct has to do is defined (functional requirements).The process used to represent the functionality ofa product will affect the reasoning process of thedesigners (analysis and synthesis). In that sense,the mapping between the functional domain andthe physical domain is where the design solutionsare defined [9,18].

The next step considers how to manufacturethe solution. Contemplated in the process do-main, this incorporates the design for manufactur-ing concept. The application of this conceptorin generic terms, Design for Ximplies other as-pects, such as how to recycle it, how to maintain itand so on.

The solution domain ranges from the con-ceptual design to the detail design, where a top-down approach is applied, to flow-downrequirements, design parameters and process vari-ables from the top product/system to the finalcomponents.

REQUIREMENTS ENGINEERINGPROCESS

Requirements are used and evolve along thewhole product life cycle. We could limit our viewto derive, validate and maintain a systems/productrequirements documents, something that has tobe done, but then the scope would be narrowed.The evolution of requirements leads to havingmore than one requirements document: Users(Stakeholders) Requirements Documents, Product

Table 2. List of requirements for a domestic boiler.

esuotysaE egnartuptuognitaehlartneC

elbaileryreV egnartuptuoretawtohcitsemoD

scitehtseA riaperotysaE

Figure 3. Requirements and quality function deployment..


8

Requirements Document and Product DesignSpecification (Figure 2).

Table 3 presents a set of requirements engi-neering processes suggested by different authors.They represent different views of tasks related torequirements with a different degree of generali-zation. The most important thing is that they pro-vide a reference list of common sense andengineering tasks that should be conducted whendealing with requirements. To support some ofthose tasks (requirements management), we mayneed to use software applications. The integrationof software applications to support the productlife cycle has led to the development of productlife cycle management (PLM) systems that includetools for requirements-related tasks.

Standards, for example, ISO/ICE on LifeCycle Management [21] and on Design Manage-ment Systems [22], provide guidance on how toclassify requirements and in requirement-relatedprocesses. In particular, Ref. [21] proposes a list oflow-level tasks related to stakeholder requirementsdefinition and requirements analysis. Reference[22] gives a wider view, representing the require-ments within the context of systems design. Table4 presents a summary of the tasks proposed inboth standards.

It can be concluded both from the standardside and from specific authors that there is plentyof material to consider as a reference and startingpoint. However, because each particular companyhas its own practices, the design process with itsrequirement-related tasks has to be explicitly de-fined and documented internally.

HOW TO REPRESENTREQUIREMENTS

Requirements can be represented using natu-ral language, both in verbal or in written form,and also using some kind of graphical notation.However, it is widely recommended to use naturallanguage as the primary way, and any other formsof representation should be considered as an ad-dition to a natural language statement. This isbased on the assumption that natural language(e.g., English) offers better possibilities to repre-sent what is needed or the problem to be solved.However, reality shows that when a requirement isexpressed in a natural language statement, the struc-ture of such statement depends on who makes thestatement, when in the process the statement ismade, what the statement refers to, what kind ofrequirement it is and so on.

Figure 4. Requirements and axiomatic design.


Requirements StructureThe problems derived from the use of natu-

ral language comes from the implicit knowledgeand understanding that lies behind every naturallanguage word or graphical symbol. Different ac-tions have been suggested, for instance, a basic

anatomy for writing user requirements [4], re-quirement templates [14] and the definition of alist of forbidden words, which contains vaguequalifier terms and any adjective and adverb cre-ated by adding the suffix ly, a practice that is ob-served in some companies.

]91[gnuoY ]3[ellivremmoS&aynotoK ]1[yrraF&skooH ]5[yeniuG&kaluK ]02[bliG

stnemeriuqergniyfitnedI noitaticilestnemeriuqeR tcudorpehtepocS deensresuehttahwtuodniF ehtdnaepocsmetsysehtenifeDehtfoepocsllarevo

stnemeriuqer

sremotsucehtgnidnatsrednUnoitaticiletnemeriuqersdeen

dnasisylanatnemeriuqeRnoitaitogen

stpecnoclanoitarepopoleveD sdeen'sresugnitnemucoDnoitinifedstnemeriuqer

sredlohekatstnaveleryfitnedI

ehtgnitatserdnagniyfiralCstnemeriuqer

noitatnemucodstnemeriuqeR tcudorpehtneewtebsecafretniyfitnedIdlrowehtfotserehtdna

stnemeriuqergnitcilfnocevloseR fostnemeriuqerehtenimreteDredlohekatsfoepythcae

stnemeriuqerehtgnizylanA noitadilavstnemeriuqeR tcudorpediugotstnemeriuqeretirWngised

tnadnuderetanimilEstnemeriuqer

epytybstnemeriuqerezirogetaC

stnemeriuqerehtgninifeD ehtrofsnosaerelanoitarerutpaCecnetsixestnemeriuqer

gnomaytilanommocdniFmehttcartsbadnastnemeriuqertsomehtsekamtahtlevelehtot

sresuehtrofesnes

stnemeriuqernoitcnufyficepS

stnemeriuqerehtgniyficepS ]4[snevetSdnarednaxelA stnemeriuqerleveL -nonmorflanoitcnufetarapeSstnemeriuqerlanoitcnuf

ecnamrofrepyficepSstnemeriuqer

stnemeriuqerehtgnizitiroirP sredlohekatsyfitnedI noitacifirevssessA ytilibaecartstnemeriuqeR stnemeriuqerecruoseryficepS

stnemeriuqergnivireD stnemeriuqerrehtaG stnemeriuqertamroF ngisedynanoitseuqdnayfitnedInoitidnocdnastniartsnoc

stniartsnoc

stnemeriuqergninoititraP ehterutcurtsdnaezinagrOstnemeriuqer

stnemeriuqerenilesaB ]41[nostreboRdnanostreboR tnacifingisnwonkllayficepSehtfospihsnoitaler

rehtoynaotstnemeriuqertnemeriuqertnaveler

snoitacificeps

stnemeriuqergnitacollA stnemeriuqerkcehC ffotsalbtcejorP ehtevorppaotsredlohekatsteGnoitacificepstnemeriuqernettirw

mehttceffayllacificepstaht

stnemeriuqergnikcarT enilesabdnaweiveRstnemeriuqer

]11[.lateelleveR egdelwonkroflwarT ytilauqnoitacificepstuoyrraCtnemeriuqerehtnolortnoc

noitacificeps

stnemeriuqergniganaM stnemgesremotsucezitiroirP stnemeriuqerehtetirW

stnemeriuqergniyfirevdnagnitseT txetnocdnasdeenremotsucdnatsrednU yawetagytilauQ

stnemeriuqergnitadilaV gnireenigneotnisuoiverpehtetalsnarTegaugnal

stnemeriuqerehtepytotorP

tpecnoctsebehttceleS metrom-tsopstnemeriuqeroD

stpecnocwenetareneG noitacificepsehtfokcotsgnikaT

tsoctegraT sisylananiamoD

stcejorptnempolevedezitiroirP stnemeriuqergnisueR

stegrathsilbatsE

neewtebspihsnoitalerhsilbatsEtcudorpdnasnoitidnocgnirutcafunam

ecnamrofrep

Table 3. Sample of requirements engineering processes.


10

Considering the definition of a requirement,there are seven characteristics that may impact thewriting, such as:

1. SingleA requirement is stated only by one sen-tence without any conjunctions (and, or, also,but, although, because).

]12[88251CEI/OSI ]22[2traP0007SB

ssecorpnoitinifedstnemeriuqerredlohekatS esahptpecnoC

sredlohekatsyfitnedI noitpecnitcejorP

stnemeriuqerredlohekatsticilE seitinutroppofosisylanA

tnemnorivnednasoiranecslanoitarepo/secneuqesesuenifeD stpecnocssenisubfosisylanA

.metsysehthtiwtcaretniotsnamuhfoytilibaehtezylanA stnemeriuqerlennosreP

.ytefashtiwgnilaedsnoitcnufdnastnemeriuqermetsysyficeps,noitacifitnediksirybdeifitsujfI stnemeriuqerygolonhceT

ytiruceshtiwgnilaedsnoitcnufdnastnemeriuqermetsysyficeps,noitacifitnediksirybdeifitsujfI stnemeriuqeryrategduB

ytefasdnahtlaehnahtrehtohtiwgnilaedsnoitcnufdnastnemeriuqermetsysyficeps,noitacifitnediksirybdeifitsujfI stnemeriuqerlaicnaniF

.stnemeriuqerelbaifirevnudna,seitiugibma,seicnetsisnocni,stcilfnocevloserotsisylanatnemeriuqeR sreilppusgnomadnanoitazinagroehtnihtiwelbaliavasecruosergnirutcafunaM

.semitnoisicedyektastnemeriuqerredlohekatsweiveR deriuqerlairetaM

.tnemeganamelbatiusrofstnemeriuqerredlohekatsdroceR ytilibaliavadnayreviledtcudorprofelacsemiT

.sredlohekatshtiwstnemeriuqerkcehC ytilibaniatniamdnaytilibaileR

ssecorpsisylanastnemeriuqeR stnemeriuqerlatnemnorivnE

.seitreporpdnaruoivaheblanretxe:yradnuoblanoitcnufmetsysenifeD stnemeriuqernoitalsigeL

.mrofrepotderiuqersimetsysehttahtnoitcnufhcaeenifeD stnemeriuqerlacitilop-oicoS

.scirtemecnamrofreplacinhcetenifeD stnemeriuqerecitcarpfosedocdnasdradnatS

.snoitaredisnocytefasenifeddnaezylanA tcejorpehtfonoitalumroF

.snoitaredisnocytirucesezylanA esahpytilibisaeF

seitilauqlacitircotetalertahtsnoitcnufdnastnemeriuqermetsysyficepsdnaezylana,noitacifitnediksirybdeifitsujfI.ytirucesdnaytefas,htlaehnahtrehto

ydutsytilibisaeF

.stnemeriuqermetsysehtfoytirgetniehtezylanA scitsiretcarahcenifeR

.stnemeriuqerredlohekatsehtdnastnemeriuqermetsysehtneewtebytilibaecartetartsnomeD noitarugifnoctcejorppoleveD

.snoitpmussadnasnoisiced,elanoitardetaicossaehthtiwrehtegotstnemeriuqerehtniatniamdnatnemucoD tcejorpehtfogninoitcnasdnanoitaulavE

esahpnoitatnemelpmI

maetngisedelbmessA

ngisedtpecnoC

ngisedtnemegnarralareneG

ngiseddeliateD

sepytotorpnoitcudorp-erpfognitsetdnanoitcurtsnoC

yrevileddnaerutcafunamrofnoisivorP

hcnualtcudorpdnanoitcudortnI

esudnagnilleS

kcabdeeF

noitaulavE

esahpnoitanimreT

gninoissimmoceD

lasopsiD

Table 4. Sample of requirements process from standards.

2. UniqueThere should not be any other re-quirement with the same objective. This mayalso imply adding some identifier that is not re-peated.

3. UnambiguousThis implies writing the re-quirement in a way that everyone involved in


the process can understand it. This can be diffi-cult in a context with different people with dif-ferent backgrounds. The main idea is to expressas much as possible in an explicit way. It couldalso happen that some additional material (sup-port material) has to be added as reference tothe requirement.

4. RankedFor each requirement, an advocate isneeded, and an explicit ranking criteria has tobe defined.

5. ValidatedAfter defining the requirement,one should make sure that the defined re-quirement is exactly the one that reallyneeded to defined. This can be consideredpart of the elicitation process, and in prin-ciple, it does not imply adding anything tothe previous requirements, apart from a markto show that the requirement has been vali-dated or an attribute showing its status.

6. TracedKeep track of the history, includingevolution and changes, and the use of the re-quirement and its link with the design solution.This demands defining and recording the pre-decessor-successor relationship between the re-quirements and also the relationship with otherelements, such as arguments and evidences,which are used to support the verification task[23]. The objective is to have an uninterruptedlink along the whole product life cycle of allthe requirements and related elements. This de-mands the use of identifiers.

7. MeasuredThis implies that each requirementshould refer to some objectively measurableproperty, and that a measure method for suchproperty should be defined. In general, any ob-jectively measurable property can be specifiedby a value, a unit of measure and a tolerance ofacceptance.

8. VerifiedTo test the final product, or some in-termediate models, to check if the requested re-quirements are satisfied and in which degree.This characteristic is directly linked to the priorone; if a requirement cannot be objectivelymeasured, it will be difficult to verify and dem-onstrate that the product complies with it.

Some of the characteristics have a clear rela-tion with the way we write requirements (1, 3 and7), other characteristics (2, 4, 5 and 6) have a clearrelation with some attributes that a requirementobject should have (identifier, advocate, priority,status and links).

A general structure of a functional require-ment (FR) is proposed based on three main com-ponents [24]:

1. Action is expressed by an active transitive verbthat refers to a functionsomething the prod-uct must do.

2. Object is expressed by a noun that refers to thephysical/nonphysical direct object on which theaction is performed.

3. Qualifier refers to the limits of the FR and al-lows representing the constraints associatedwith the FR. Qualifiers can be expressed by twodifferent elements:

a. A quantitative adjective group.b. An adverbial group or prepositional phrase,

which indicates time and answers the ques-tion, For how long?. Other adverbialgroups could indicate how the action mustbe done, where and when. In these cases, itis recommended to check if the definition ofscenarios works better than consideringthese groups as qualifiers (constraints).

Each quantitative qualifier (constraint) musthave at least a nominal numerical value, a unitof measure and a tolerance. Because require-ments and constraints go through a refinement tonarrow the set of possible solutions, the specifica-tion of the qualifiers may not have numerical val-ues when they are initially defined. However,when the constraints have to be considered to se-lect a candidate design solution, the numericalvalues need to be declared.

Examples of the proposed structure areshown in Figure 5. Figure 6 provides an examplewhen the proposed structure is applied to a non-functional requirement.

So far, this Blue Book has focused on naturallanguage written requirements; however, a graphi-cal notation could also be used to define them.The fundamental aspect to consider is that thesymbols, the syntax (rules that define how thesymbols can be put together) and the semantics(meaning of the symbols and possible layouts)have to be understood by the people involved toavoid misunderstanding the interpretation of therequirements. There have been various attempts todescribe some kind of specific language to definerequirements [20], which led to the same point:keywords, syntax and semantics have to be knownand understood. The use of these alternative lan-guages seems to be less problematic for people in-


12

volved in software development or in the high-level definition of systems. However, when con-sidering people who work on physical productdevelopment, the benefits of adopting this ap-proach are not clear.

LEADING EDGE IN REQUIREMENTSMANAGEMENT

Requirements management encompassestasks such as organization and documenting of re-quirements, tracking and controlling of their evo-lution and their visualization and presentation[2,3]. A support process is mainly executed duringthe product development process but affects thewhole product life cycle. To have a product designprocess that encompasses the management of therequirements is a must. To have such a require-

ments management process defined explicitlyshould also be a must. The use of a software toolto support requirements management should bethe next step. This software tool has to be inte-grated with other applications used in the productlife cycle.

Many industries, such as aerospace and auto-motive, are using digital product developmenttechnologies to reduce the product developmenttime. Market forces are driving the necessity to re-duce design time further. Upward of 70% of theproduct development is performed by the supplychain. In this context, the use of collaborative soft-ware systems to automate the design managementprocess tries to bring the improvements needed.The use of a requirements management softwaretool provides a controlled framework for the inte-

Figure 5. Requirements structure examples applied to FRs. (a) FR related to a machining fixture and (b) FRrelated to an aircraft wing structural component.

(a)

(b)

Figure 6. Requirements structure example applied to nonfunctional requirements.


gration of development changes and a commonmethod of communication within the projectteam. When the environment is an extended en-terprise, the importance is even higher. In thiscontext, the OEM could monitor and control theevolution of a requirement through the trackingof its changes, if any, its relation with the designsolution and its effect on individual designchanges.

The research being conducted in require-ments engineering aims to improve the techniquesused to perform activities, such as requirementsgathering, requirements ranking, requirementsanalysis and definition of possible design solu-tions, trade-offs and conflict analysis, natural lan-guage processing and so on. In particular, whenlooking at requirements research, the efforts aredirected toward developing tools and methodsthat help to reduce ambiguity, trace, flow down,identify, link and reuse requirements. Improvedcommunication and sharing of requirements alongthe product development life cycle and itschanges are the main benefit of such tools. The re-duction of manual effort and the possibility of hu-man errors is a must when one of the objectives isto reduce the development time by effectivelymanaging an evolving set of requirements within acomplex, iterative product development cycle inan extended enterprise context.

In general, the OEMs in the automotive andaerospace sectors have formalized an integratedrequirement practice within the product develop-ment life cycle [25,26]. When we move down tothe supply chain, however, the practices seem tobe vague and therefore not well integrated. Addi-tionally, cultural issues, ambiguity and lack of com-mon understanding seem to be relevant problems.In general, there is a clear potential to improveunderstanding and working practices [27,28].

Action on Requirements andDesign Ontology Definition

The trend in the automotive sector is that thedifferent agents of the supply chain have greaterdesign responsibilities, and they are involved atearlier stages in the product development phase.This is a direct consequence of the clear pursuit ofthe concurrent and collaborative engineeringpractices. This model implies that the OEM relieson the suppliers to satisfy not only them but, moreimportantly, their customers or end users. In this

context, the satisfaction of the stakeholders re-quirements is not only the business of the OEMbut of the whole supply chain. This demands acommon understanding of the demanded require-ments, both in the problem/need domain and in thesolution domain and the communication of them.

The use of QFD as a tool to represent thevoice of the customer is common in this sector.Its application, however, relies on the judgmentof the people using it and the ambiguity in theterms used; the requirements writing is still anissue. This aspect is even more relevant whenindividual requirements are added, refined orremoved by negotiations, discussions and clarifi-cations among different parties [29,30].

In this particular example, the work focusedmainly on analyzing driver and passenger seat re-quirements contained in the requirement docu-ments. Figure 7 represents the basic elements of adriver seat, and Table 5 presents a list of key re-quirements [31].

Some of the requirements are generic (thefirst three). Other requirements are related to spe-cific parts of the seat, which means they refer toparts of the basic architecture of the design solu-tion. Some of them have explicit constraints asso-ciated with them, while others will be difficult toverify because of the way they are written. This re-inforces the difficulty of specifying requirements.

In this context, the work was to create afunctional representation of the seat to share acommon understanding between the OEM andsuppliers of the product to be designed andmanufactured. The functional representation isbased on the functional requirements, and it is

Figure 7. Basic elements of a driver seat. (Imagecourtesy of Johnson Controls.)

HEADREST

SEAT-CUSHION

BACKREST

SEAT TRACK


14

linked to possible design solutionsof different components, each ofthem characterized by design param-eters. This action has led to the de-velopment of a seat design ontology,and its implementation in a softwareapplication helps engineers fromboth OEM and supplier share knowl-edge about the product design andalso specify the seat in a better way[32,33] (Figure 8).

Action on Cost ofRequirements Change

In the aerospace sector, the bid-ding stage is one of the main phasesin the development cycle of systemsand components (Figure 9). Amultidisciplinary team able to prop-erly evaluate all the different aspectsinvolved (requirements, possible de-sign solutions, manufacturing tech-nologies, conditions of supply,financial implications and so on) is amust for a subcontractor to respondto a request for proposal issued by an OEM. Addi-tionally, the context is characterized by the sharingof risk, fixed-price contracts and airworthinessregulations [34].

The definition and flow down of require-ments in an airplane life cycle is a quite compli-

cated task. A high number of stakeholders (pilots,airport authorities, airline companies, interna-tional aviation authorities, OEM, passengers, sup-pliers, governments, crew members and so on)and hence many kinds of requirements have to beconsidered and evaluated. Among them, the air-

stnemeriuqeR stniartsnoC

.ydobrewols'tnapuccoehttroppusotelbaebtsumtaesehT

.ydobreppus'tnapuccoehttroppusotelbaebtsumtaesehT

.daehs'tnapuccoehttroppusotelbaebtsumtaesehT

.elgnanoihsuc-taesehttsujdaotelbaebtsumtnapuccoehT lacitrevmorf52

.elgnakcab-taesehttsujdaotelbaebtsumtnapuccoehT

.doogebtsumdehcuotnehwytilauqtaesehT

.maofkcab-taesehttsujdaotelbaebtsumtnapuccoehT

.elcihevehtniderucesylmrifebtsumtaesehT x ,5.420,1- y ,6.161- z 3.17-

.tlebtaesriehtesuottnapuccoehtdnimerotmsinahcemaebtsumerehT ylnotaestnorF

Table 5. Example of key requirements for driver seat.

Figure 8. Seat functional design ontology and tool interface.


worthiness regulations affect the de-sign, manufacturing, testing, mainte-nance and operation of every singlesystem and component of an aircraft.

An aircraft structure has two mainstructural functions: (1) to provide stiff-ness (the airframe will not distort, ei-ther statically or dynamically, in a waythat could compromise the perfor-mance and safety of the aircraft) and(2) to provide strength (the airframewill sustain all the loads, both staticallyand dynamically, for a specified timewithout collapse). The basic functionscan be formulated as: transmit the ap-plied loads, resist the applied loads,provide an aerodynamic shape andprotect passengers, crew, payload andsystems from the environmental condi-tions. Some basic constraints are associ-ated with these functions: minimumpossible weight, minimum cost andminimum maintenance. Once a basic architectureof the aircraft has been defined, then require-ments have to flow down to the different subas-semblies and individual components along theproduct breakdown structure (PBS) (Figure 10).During this process there is an evolution fromstakeholder requirements documents (stake-holder needs problem/needs domain) to systemrequirements documents (SRD) (technical-relatedwriting problem/needs domain) and finally tosystem design specification documents (SDSD)(technical writing solution domain). At the bid-

ding stage, the documentation that is sent to thesuppliers for the preparation of the bid is some-where between an SRD and a SDSD. Table 6 showssome examples of the requirements. They wereclassified as nonfunctional requirement (NFR),constraint related to requirement (C), design solu-tion (DS), design parameter (DP) and constraintrelated to DS (DC).

The OEM may want to flex different require-ments to the maximum within an agreed fixedprice. In consequence, the subcontractor needs tominimize the risk by limiting the amount of

Figure 9. Top-level aerospace product development cycle.

WING

Fixed Trailing Edge

Ailerons

Spoilers

Flaps

Wingbox

Wingtip

Pylons

Fixed Inner Trailing Edge

Fixed Mid Trailing Edge

Fixed Outer Trailing Edge

Spars

Secondary Structure

Figure 10. Example of wing breakdown structure.

Phase 0 Pre - Bid Evaluation

Phase 1 Bid Submission

Process

Phase 2 Final Bid Evaluation

& Appraisal

Phase 3 Joint Definition Phase Design

Phase 4 Production Scheming

Phase 5 Release to Manufacture

Phase 6 Product Certification

Phase 7 Series Production

Phase 8 In - Service Support


16

than to requirements as such. The methodologyuses input documentation from the OEM, in-cluding SRDs, SDSDs and engineering drawings,and it demands the execution of workshops toprioritize and define top relevant requirementsand relationships among them. Figure 11 showsthe main steps to apply such methodology [35].

REQUIREMENTS MANAGEMENT:WHERE TO START?

We can assume that an organization with ahigher level of development in its processes is ableto develop better products. This was the approachadopted by the U.S. Department of Defense forsoftware development under the capability matu-rity model concept. A simplified version of thatmaturity or level of development model has beenapplied to other kinds of processes, such as the re-quirements engineering process [3].

The important aspect to understand is thatbefore we identify where we start, we need toidentify current state. The way to achieve this is byconducting an audit of the requirements manage-ment within the context of the product develop-ment process. The objective of starting from atop-down approach is to avoid the definition oftwo separate processes. You should also under-stand that you cannot manage (organize and con-trol) something you have not explicitly definedpreviously (requirements).

With these ideas in mind, it is proposed thatan audit be conducted to create a picture of yourcurrent requirement process to identify its matu-rity level and possible improvement actions.

Maturity Model and AuditTo start, the first question you should answer

is, Is there an explicitly defined product develop-ment process (PDP)? If the answer is yes, then youshould start assessing the maturity of such process.If the answer is no, then we recommend you de-fine a PDP prior to continuing to delve into spe-cific requirement-related activities.

If you have a PDP, then you are a position toanalyze it and assess the level of maturity from therequirements process perspective. This task maydemand that an audit be conducted to create theas-is model. From the analysis of the as-is model,an understanding can be gained on the currentmaturity level of the requirements engineeringprocess (Figure 12).

changes introduced to the requirements to levelsthat can be achieved within the contract price. Forthis, the subcontractor needs to understand the re-quirements key cost drivers and the thresholdpoints at which price should be changed to avoidnonaffordable profit margins. The solution to thissituation would be the development of a cost-im-pact analysis tool for requirement changes. Basi-cally, this implies an empirical work to identifyand capture the product development practices ofthe company, with special focus on the biddingprocess, requirement practices, design practices,cost estimation practices and change executionand management practices [34,35]. Similarly, inthe automotive sector, an internal cost-impactanalysis study was conducted [31]. As a result, a re-quirements management and cost-impact analysismethodology, inspired by principles from axiom-atic design theory [13], was proposed and devel-oped. In its application, four major cost driverswere identified, such as tooling, materials, laborand machinery, and bought-out items. In addition,a set of rules was created to link each cost driverwith the design parameters.

The cost analysis is indirectly related to thechange of requirements. The reason for this isthat most of the changes are related to con-straints associated with design parameters, rather

tnemeriuqeR noitacificepStnemeriuqeR epyT

airetircngisedlareneG ehtfongisedehtrofdesuebotsesacdaoLsdaolhtiwecnadroccaniebllahsemarfria

,edulcnilliwsdaoL.resahcrupehtybdedivorpdnacitatshsarc,eugitaf,otdetimiltoneratub

noos

C

emarfriA ebllahsxobyramirpgniwretuoehtotnisseccA...ehtnolenapdliubahguorhtelbissop

CD

serutarepmeT RFN

kcabgnirpsdnaserutaeflacitirC rofsecnarelotgnirutcafunamelbaveihcaehTehthtiwecnadroccaniebllahsemarfriaeht

xxx:tnemucodgniwollof

RFN

ylbmessA htiwnoitcnujnocnimuinatitfonoitacilppaehTdediovaebdluohsstniojtasetisopmoc

CD

thgiewtegratngiseD ylbmessabusemarfriaehtfothgiewtegratehTemehcsxehtmorF.gkxxwolebebllahs

aottimmocllahsreilppuseht,weiverthgiewmumixamlautcartnoc

C

lairetaM rofderedisnocebllahsslairetamgniwollofehT:emarfriaehtfonoitcurtsnoceht xx , yy

CD

stnemeriuqererutcurtS eziminimdluohsemarfriaehtfongisedehTsnoitcepsnideliatedlaicepsrofdeeneht

RFN

Table 6. Examples of aircraft requirementsspecifications.


To conduct the audit, you should rememberthat requirements have to be captured, structured,formalized, represented, analyzed, validated, man-aged, verified and used along the PDP. Consider-ing this, it is recommended that you develop amap (as-is model) showing:

The requirements process workflow. The different kinds of requirement documents

used, gathering information about who createsthem, contributes to them, uses them and inwhich activities.

For each requirements document, you shouldhave a table of contents to understand whatkinds of requirements are documented in it.Could you define a content categorization to fa-cilitate the creation and reading of the docu-ments? Could you define a document template?

Identify the level of confidentiality and securityof each document.

For each activity related to requirements, iden-tify which process is conducted manually, auto-matically or manually assisted by a softwareapplication.

Identify possible bottlenecks in your require-ments process. To what extent do current prac-tices, people and technology support or hamperthe effective flow and use of requirements?

Identify main barriers, such as inappropriatepractices, cultural differences, not enough timeallocated to create/review/modify the docu-ments, lack of visibility of the requirements rel-evance, eliciting requirements from users is notperformed and so on [27,36].

Identify possible requirements problems, for ex-ample, incomplete requirements, product doesnot satisfy the user requirements, there are toomany changes in the requirements or in the de-sign, modifications occur in late developmentstages or in pre-production, explicit complaintsabout requirements and so on.

Identify the link between the possible require-ments problems, the as-is model and the identi-fied barriers.

To conduct the requirements process audit,you will need to create specific questionnaires tointerview different members of your organization

Figure 11. Requirements management and cost impact analysis methodology.


18

and to observe the current practices being used.From the analysis of the audit results, you should beable to identify the level of maturity of the process(Figure 12) and possible actions of improvement.

REQUIREMENTS: THE FUTUREIn an industrial environment where the ex-

tended enterprise is a common business modeland where the project risk is shared betweenOEMs and suppliers, the bidding process to wincontracts demands from the supplier a compre-hensive understanding of the requirement set andits evaluation to assess the technical, financial andtime implications. OEMs have to deliver to theproject bidder accurate information (require-

ments) about the work they are willing to pay for.In this context, the future of requirements engi-neering points to tackling five specific areas:

1. Elicitation, writing and modeling. This area con-siders not only the engineering aspect of the ac-tivities, but also the cognitive and social part.Techniques to better elicit requirements fromstakeholders, easier and more effective ways torepresent requirements, capturing and represen-tation of subjective needs and requirements, cog-nitive aspects of deriving solutions fromrequirements, creation of requirement ontolo-gies, collaborative requirements definition andnatural language processing are some of the ac-tions being pursued by different research groups.

Figure 12. Requirements engineering simplified maturity levels.


2. Integration of requirements engineering prac-tices within the solution life cycle and in particu-lar within the bidding stage and developmentand design process. This action may demandconducting a requirements engineering audit toelaborate an as-is model of the current practicesto identify possible improvement actions. It alsodemands the development of integrated applica-tions to automate requirement tasks and to im-prove the visibility of the requirements impact inthe business. In this area, there is a clear trend inthe development of requirement software tools.

3. Requirements change impact analysis. There isan understandable interest from the businessand engineering perspective to have a clear vi-sion of the implications that requirementschanges have in the possible solution, and theeffects in the business strategic, tactical and op-erational levels. Apart from the complexity ofthe problem the requirements refer to, thecomplexity is quite high because of the implica-tions of change propagation, and it is very diffi-cult to develop any impact analysis (cost,schedule) with a significant level of accuracy.Several research groups are currently focusedon this area of research.

4. Education. This action should aim to increaseengineers awareness of the relevance of re-quirements and to train them to write anddocument requirements. It should also empha-size the relevance of documenting the relation-ship between requirements and designsolutions. At the management level, there is aneed to increase the visibility of the link be-tween requirements, business goals and pro-ductivity. Management should lead and promotethe actions to improve requirements practices.

5. Transfer expertise and facilitate cultural changein small and medium-sized enterprises. This isnot a research-related area, but an area thatcould be used to increase requirements aware-ness for small and medium-sized enterprises.With this new-found knowledge, small and me-dium-sized enterprises can apply requirementsengineering activities to their own businesses,delivering parts to their customers at a lowercost and in shorter time.

CONCLUSIONThis Blue Book describes the relevance of re-

quirements from the manufacturing engineering

and business perspective. Terminology used is afundamental aspect when we use natural languageto communicate. We need to be precise when wetalk about requirements because of their diversity.Initially, we need to make a distinction betweenthe ones that refer to the problem to be resolvedor the need to be satisfied and the ones to specifythe solution to be adopted. This is also importantbecause, as a consequence later, we need to clas-sify the requirements as they refer to different as-pects of the problem, need or solution.

The requirements engineering process has tobe integrated, especially with the bidding and de-velopment and design phases. There are differentproposals about how the requirements processshould be, both from different authors and fromstandards. The first thing to do is audit your ownprocess to have an explicit representation of it (as-ismodel), understand the level of maturity in theprocess, and hence, identify possible improvementactions. Axiomatic design proposes some guidelinesabout how to establish the link between functionalrequirements and the design parameters that definethe possible solution. However, this approachseems to be difficult to use in industry when theproblem is complex and if no previous educationand training is provided to the engineers. QFD isclearly a technique that is being used to representrequirements and their link to product features, butit seems to be a problem in how we write the re-quirements. How to manufacture the solutionadopted is a key element in this process because itis part of the design for X and should be adoptedduring the product development and design phase.

The key aspect to keep in mind when defin-ing a requirement is that a requirement has a set offeatures to comply with, such as single, unique,unambiguous, ranked, validated, traced, measuredand verified. Some of these features are directlyrelated to how to write a requirement (action, ob-ject and qualifier), and others demand attachmentto some attributes to it (identifier, advocate, prior-ity, status and links). The key aspect here is thatyou should define a template to define and writerequirements. Currently, there are requirementmanagement software applications that provide atemplate for this purpose.

Requirements are the absolutely essential in-put to the product design process and also tobusiness decisions, so an integrated view that con-siders the propagation of the requirements prac-


20

tices is a necessity. We understand that educationand transfer of expertise are fundamental actions toimprove the processes and, therefore, productivity.

ACKNOWLEDGMENTThe authors would like to thank other mem-

bers of the Decision Engineering Centre, in theManufacturing Department at Cranfield University,who have contributed to the research conductedin requirements. The teams research was spon-sored by the Engineering and Physical SciencesResearch Council, Nissan Technology Centre-Eu-rope, Johnson Controls, EDS and GKN Aerospace.

REFERENCES[1] Hooks, I.F. and Farry, K.A. Customer-Cen-

tered Products. New York: AMACOM, 2001.[2] IEEE STD 1220-1998. IEEE Standard for Appli-

cations and Management of the Systems Engi-neering Process. Piscataway, N.J.: IEEE, 1999.

[3] Kotonya, G. and Sommerville, I. RequirementsEngineering: Processes and Techniques.Chichester, England: John Wiley & Sons, 1998.

[4] Alexander, I.F. and Stevens, R. Writing BetterRequirements. London: Addison-Wesley, 2002.

[5] Kulak, D. and Guiney, E. Use Cases: Require-ments in Context, 2nd ed. Boston: Addison-Wesley, 2003.

[6] Sommerville, I. and Sawyer, P. RequirementsEngineering: A Good Practice Guide.Chichester, England: John Wiley & Sons, 1997.

[7] ECSS-E-10A, Space Engineering: System En-gineering. Noordwijk, The Netherlands:ECCS, 1996.

[8] Cross, N. Engineering Design Methods: Strat-egies and Tactics for Product Design, 2nd ed.Hoboken, N.J.: John Wiley & Sons, 1994.

[8] Pahl, G. and Beitz, W. Engineering Design: ASystematic Approach, 2nd ed. London:Springer-Verlag, 1996.

[9] Ulrich, K.T. and Eppinger, S.D. Product De-sign and Development, 3rd ed. Irwin, N.Y.:McGraw-Hill, 2004.

[10] Revelle, J.B.; Moran, J.W.; and Cox, C.A. TheQFD Handbook. New York: John Wiley &Sons, 1998.

[11] Terninko, J. Step-by-Step QFD: Customer-Driven Product Design, 2nd ed. Boca Raton,Fla.: St. Lucie Press, 1997.

[12] Suh, N.P. Axiomatic Design: Advances and Ap-plications. Oxford, England: Oxford Univ.Press, 2001.

[13] Robertson, S. and Robertson, J. Masteringthe Requirements Process. Oxford, England:Addison-Wesley, 1999.

[14] Baum, L.; Becker, M.; Geyer, L.; and Molter,G. Mapping Requirements to Reusable Com-ponents Using Design Spaces. Piscataway,N.J.: IEEE, 2000.

[15] Koogan, K. and Sampaio do Prado, J.C. On-tology as a Requirements Engineering Prod-uct. Proc. of 11th IEEE Intl RequirementsEngg. Conf., 2003.

[16] Chan, L.-K. and Wu, M.-L. Quality FunctionDeployment: A Literature Review. EuropeanJournal of Operational Research (v143, n3,2002), pp463-497.

[17] Hirtz, J.; Stone, R.B.; McAdams, D.A.;Szykman, S.; and Wood, K. A Functional Basisfor Engineering Design: Reconciling andEvolving Previous Efforts. Research in Engg.Design (v13, n2, 2002), pp65-82.

[18] Young, R.R. Effective Requirements Prac-tices. Boston: Addison-Wesley, 2001.

[19] Gilb, T. Competitive Engineering: A Hand-book for Systems Engineering, RequirementsEngineering and Software Engineering UsingPlanguage. Burlington, Mass.: Elsevier, 2005.

[20] ISO/IEC 15288 CD2, Life Cycle Management System Life Cycle Processes. ISO/IEC JTC 1/SC 7/WG 7 N0316, 2000.

[21] BS 7000 2: 1997, Design Management Sys-tems: Guide to Managing the Design of Manu-factured Products. London: BSI, 1997.

[22] Wills, S. Systems Engineering in the Rail Sec-tor Joining Up the Pieces. Telelogic UserGroup Conf., Oct. 2004.

[23] Hunter, R.; Rios, J.; Perez, J.M.; and Vizan, A.A Functional Approach for the Formalizationof the Fixture Design Process. Intl Journal ofMachine Tools and Manufacture (v46, n6,2006), pp683-697.

[24] Almefelt, L.; Andersson, F.; Nilsson, P.; andMalmqvist, J. Exploring Requirements Man-agement in the Automotive Industry. IntlConf. on Engg. Design, Stockholm, Aug. 19-21, 2003.

[25] Roussel, J-C. Benefits of Requirement Engi-neering with DOORS: Airbus Experience,Telelogic Capital Market Event, June 2005.

[26] Kauppinen, M.; Kujala, S.; Aaltio, T.; andLehtola, L. Introducing Requirements Engi-neering: How to Make a Cultural Change


Happen in Practice. Proc. of IEEE Joint IntlConf. on Requirements Engg., 2002.

[27] Weber, M. and Weisbrod, J. Requirements Engi-neering in Automotive Development Experi-ences and Challenges. Proc. of IEEE Joint IntlConf. on Requirements Engg., 2002.

[28] Kerr, C.I.; Roy, R.; and Sackett, P. J. Require-ments Management: An Enabler for Concur-rent Engineering in the Automotive Industry.Accepted for Intl Journal of Production Re-search, 2006.

[29] Roy, R.; Kerr, C.I.V.; and Sackett, P. J. Require-ments Management for the Automotive Ex-tended Enterprise: The Next Evolution inDigital Product Development. 14th Intl CIRPDesign Seminar, Cairo, May 2004.

[30] Oduguwa, P. A.; Roy, R.; and Sackett, P. J.Cost Impact Analysis of Requirement Changesin the Automotive Industry: A Case Study.Submitted to Journal of Engg. Manufacture,Part B, IMechE, 2006.

[31] Kerr, C.I.; Roy, R.; and Sackett, P. J. A ProductOntology for Automotive Seat Specification.DETC2004-57071, ASME DETC/CIE, Salt LakeCity, Oct. 2004.

[32] Kerr, C.I.; Roy, R.; and Sackett, P.J. A Knowl-edge-Based Tool for the Selection of DesignOptions During the Competitive Tendering ofVehicle Systems. ESDA2004-58044, 7th Bien-nial ASME Conf. on Engg. Systems Designand Analysis, Manchester, England, July 2004.

[33] Rios, J.; Lopez, A.; and Roy, R. Design Re-quirements Change and Cost Impact Analysisin Airplane Structures. Submitted to IntlJournal of Production Economics, 2006.

[34] Roy, R.; Rios, J.; and Lopez, A. Cost ImpactAnalysis for Requirements Changes within theAerospace Industry. ICMR Conf., Cranfield,England, Sept. 2005.

[35] Davis, P. Ten Questions to Ask Before Open-ing the Requirements Document. TelelogicUser Conf., Marlow, England, Nov. 2005.

1. requirements engineering and management for manufacturing

Documents

manufacturing context

customer expectations

university phd award

humans levels

technology levels

requirements definition

throughthe requirements

authorsjose rios