Вы находитесь на странице: 1из 25



Requirements Requirements Title of Blue Book and Engineering Engineering and Manag Management ement f for or Man Manuf ufactur acturing ing

Jose Rios, PhD, Rajkumar Roy, PhD, Name and Peter Sackett, PhD Author Authors

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

Copyright 2006 Society of Manufacturing Engineers This Blue Book may not be reproduced in whole or in part in any form without the express written permission of 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 warranty of reliability or safety of any of the information contained herein. ISSN 0895-5085 Manufactured in the United States


SMEs Manufacturing Enterprise Wheel is a graphical representation of processes and organizational 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 customer at the heart and relates the customer expectations with different facets of manufacturing. The Wheel presents a sociotechnical context to the manufacturing, where customer expectations are realized as a product or service through complex interaction between humans (levels 2 and 3), organizational structures (levels 2 and 3) and technology (levels 3, 4 and 5). Voice of the customer and regulatory responsibilities are represented as requirements. Through the 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 realization process. It is necessary to elicit, represent and manage the requirements in a structured manner to improve the communication between the customer and the engineers. This will improve the interactions between levels 1 to 5 in the Wheel and reduce product realization time and cost.

SME BLUE BOOK SERIES 2006 www.sme.org

About the Authors

Jose 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 Polytechnic University of Madrid, Spain. Since 1998, Rios has held a lecturer position in the Department of Mechanical Engineering and Manufacturing at the University of Madrid. He has participated and led research projects related to manufacturing, CAD/CAM, information modeling, knowledge-based engineering (KBE), cost engineering and product requirements, collaborating with different companies mainly from the aeronautical and the moldmaking sectors. In the standardization area, he was the Spanish representative in the ISO TC 184/SC4 Industrial Data and Global Manufacturing Programming Languages. In September 2003, Rios joined Cranfield University where he holds a research fellow position in the Decision Engineering Centre. Rajkumar Roy, PhD, is the head of the Decision Engineering Centre within the School of Industrial Manufacturing Science at Cranfield University. He has a strong academic, research and industrial background in design and manufacturing. Roy is currently leading a research group in the decision engineering area, specializing in cost engineering, requirements management, knowledge capture, applied soft computing and design optimization. The scale of cost engineering research under the supervision of Roy is perhaps the biggest activity in hardware cost estimating in the world. He has published his work extensively and has co-edited six books in the engineering design and manufacturing area, 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 integrated 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 computer systems. He holds doctoral and master degrees from the University of Manchester, England. He joined 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.


Requirements Engineering and Management for Manufacturing

Requirements engineering is a distinctive discipline. It makes use of a systematic methodology to identify, document, formalize, manage, maintain, verify, validate and disseminate the requirements related to a particular project, system, product or service during its whole life cycle. The increase in the complexity means the relevance of this recently coined manufacturing engineering discipline is becoming greater. A requirement is a statement of a need, something that a stakeholder wants. The requirements issue is being addressed by product design engineering, software engineering and systems engineering. Traditionally, requirements in product design engineering focus on design of electromechanical products. In software engineering, the focus is on the design of software, while in systems engineering, the focus is on the design of complex products that combine electromechanical, electronic, software and other kind of components. However, the software engineering view is considered under the systems engineering discipline; hence, the two main approaches presented deal with the disciplines of product design engineering and systems engineering. This Blue Book reviews the approaches that these disciplines provide. The topics presented show the requirements relevance, review the main issues involved, such as terminology, classification, process and writing, and present requirement management and leading-edge work focused on the automotive and aerospace industries. Guidelines are presented on where to start with requirements.


The authors interpretation of engineering is the application of scientific knowledge to the life cycle of solutions. We have not included in the definition any qualifier related to the solution,

such as compliant with customer demands, cost effective, compliant with specific performance features, compliant with safety regulations, compliant with the business strategy and so on. If we want to engineer a solution, it is because we have a problem to resolve or a need to satisfy. Depending on the kind of problem or need, specific knowledge will be needed. When looking at the solution life cycle from a top view, stages are identified, such as business definition, solution design and development, planning, manufacturing, deployment, support and maintenance, disposal and so on. The complexity of the whole process and of each specific life cycle stage depends on the kind of problem to resolve and the solution adopted. Several questions that can be asked are: What is the problem to be solved? What is the need to be satisfied? How could the solution satisfy the stakeholders? How could the solution add value to the customer? How could we engineer something useful to the stakeholders? How could we validate our product? If we know the stakeholders requirements, then we can engineer any solution properly. The importance of requirements is increasingly recognized because of the clear link with productivity. Several studies have determined that between 60% and 80% of product inconsistencies are created during the requirement definition stage in the development phase [1]. Independent of the complexity of the problem, the solution and its associated processes, the requirements need to be explicitly known because the final objective should be to satisfy them. This statement can be understood from the analysis of the typical flow down of requirements and upward integration and test of the V-model (Figure 1). The term requirement can refer to stakeholder requirement, problem requirement, solution requirement, customer requirement, functional requirement, nonfunctional require-

SME BLUE BOOK SERIES 2006 www.sme.org

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

ment, performance requirement, constraint and more. Definitions from different authors demonstrate that, depending on the source of information, there may be different interpretations and, in many cases, a misunderstanding of what a requirement should be. Depending on the stage of the solution life cycle and the engineering task currently being performed, the term requirement may refer to different kinds of requirements. If we know precisely what a requirement is, then we can capture and formulate it in a way that it can be used during the engineering process.

Definitions from Systems Engineering Discipline

According to IEEE [2], A requirement is a statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines). This definition encompasses most of the attributes a requirement should have. A generic view is provided by Kontoya and Sommerville [3], Requirements are descriptions of how the system should behave, application domain information, constraints on the systems operation, or specifications of a system property or

attribute. Sometimes they are constraints on the development process of the system. A nontechnical and stakeholder-oriented view is provided by Alexander and Stevens [4], A requirement is a statement of need, something that some class of user or other stakeholder wants. Kulak and Guiney [5] state that, A requirement is something that a computer application must do for its users. It is a specific function, feature, quality, or principle that the system must provide in order for it to merit its existence. A distinction is made between functional requirementswhat the users need for the system to work. They are functions and features. And nonfunctional requirements address the hidden areas of the system that are important to the users, even though they may not realize it. They are the global fuzzy factors or principles that relate to the systems overall success. Sometimes they are called the -ilities. This is a software-oriented view, making a distinction between functional and nonfunctional requirements. As will be discussed later, the aim should be to reduce the fuzzy factors from the requirements specifications. Some people suggest that requirements should always be statements of what a system should do rather than a statement of how it should do it. This is an attractive idea but it is too


simplistic in practice [6]. We should therefore plan to document both things because it is likely that we have more than one solution to achieve a specific goal. According to the European Cooperation for Space Standardization [7], customers requirements (needs and objectives) should be analyzed to generate the system specification requirements. The system specification requirements are identified and grouped in relationship to their primary objective: functional, configurational, interfaces, physical, environmental, etc. In this case, two different kinds of requirements are proposed, for example, customer requirements (what is wanted in nontechnical terms) and system specification (different kinds of requirements).

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

Revealed requirementsthose we get by asking

customers what they want.

Expected requirementsalso called unspoken,

unless violated basic needs.

Exciting requirementsthey are usually beyond

the customers knowledge or expectations. Even though understanding the customers needs, also called demanded qualities, is the key point, no guidance is provided in terms of how to better write any of these qualities. According to Terninko [12], the process goes from the demanded quality (customers subjective description of the performance of the product and its functions) to the performance measure (a technical measurement evaluating the performance of some demanded quality; it is often stated how and by what you measure). In axiomatic design theory, a distinction is made between different domains: customer, functional, physical and process. In the customer domain, needs are identified that are then formalized in the functional domain by the designer to define the design problem in the form of functional requirements (what the product has to do). Design parameters that satisfy such functional requirements then have to be defined [13].

Definitions from Product Engineering Design Discipline

Cross [8] states that a requirement is a demand that must be met, and it should be expressed in quantified terms [as] it points out what the product must do. The idea of quantified requirements is important, as is the distinction between problem requirements and solution specification. According to Pahl and Beitz [9], requirements can be demands (requirements that must be met under all circumstances) or wishes (requirements that should be taken into consideration whenever possible). Requirements should, if possible, be quantified and, in any case, defined in the clearest possible terms. They also support the idea of quantified requirements, adding the idea of clearness to their definition. Ulrich and Eppinger [10] draw from customer needs to product target specifications. From their text, the following description can be extracted: A requirement or specification consists of a metric (something that can be measured and facilitates the quantification of some particular customer need) and a value (value of the metric labeled with the appropriated unit). It is important to have quantified requirements because they have to be measurable; hence, a value and a unit are needed in the requirement definition. Quality function deployment (QFD) methodology [11] distinguishes between customer wants and needs and design requirements. It claims to provide a structured transition from the customer wants and needs to the technical specification.

Related Terms
In the problem domain, we can distinguish between functional requirementwhat the stakeholders demand the product must do independently of any possible solution, and nonfunctional requirementthe qualities demanded from the product (qualities related to aesthetics, maintenance, cost and so on) [10,13,14]. In the solution domain, the term design parameter can be found, meaning any physical property whose value determines the functionality of the product (weight, length, surface finish) [13]. Close to this term, product attribute can be defined as a property that identifies a characteristic or quality of a product. A design parameter is a kind of product attribute, but not all the product attributes are design parameters (cost). Finally, the term constraint can be used in both domains. It refers to a measurable restriction that, in general, affects some kind of requirement

SME BLUE BOOK SERIES 2006 www.sme.org

(in the problem domain) or product attribute (in the solution domain) and limits the range of possible solutions to valid ones.

The importance of the requirements. Where in the process the requirement is defined. What the requirements are concerned with. Approaches
According to Sommerville and Sawyer [6], requirements should be classified in a multidimensional approach. To do so, it is necessary to identify certain dimensions and keywords that describe each requirement, including user interface, database and so on. At the beginning of each product project, these dimensions should be defined. The question, however, is should the focus be on the problem or on the solution? If we consider a physical product, these dimensions and keywords could be associated with the subsystems or product breakdown structure and depend on the complexity of the product and the level at which we want to specify the requirements. In the problem domain, it is recommended to make a distinction between the different stakeholders subdomains and the functional subdomain. The definition of user requirements, which are a particular kind of stakeholder requirements, can be the statement of a need or the statement of how to use a product. The definition of use cases is widely accepted in the area of software and systems development [5]. The idea is based on a sequence of steps describing an interaction between a user and a system. However, its application on consumer products is not clear, mainly because of restrictions imposed by the product itself in terms of user access to the product prior to its launching. Another approach to requirements categorization is the use of design spaces [15]. This approach maps requirements to components that already exist and relies on the idea that a known and manageable set of component variants is likely to cover the vast majority of possible requirements. A design space provides design choices that are grouped in hierarchical categories. This approach is applied in the solution-oriented domain. Typical approaches to requirements classification are shown in Table 1. The problem arises when deciding which categories should be included. From the authors point of view, the classification provided by Hooks and Farry [1] is the most appropriated when considering the manufacturing engineering perspective. However, it is very

Definitions Summary: An Integrated View

These different meanings of the word requirement are usually clarified when the domains are considered. A good practice is to use the term requirement with the domain explicitly expressed. We suggest using the term requirement only in the problem domain, adding the problem subdomain name, functional or nonfunctional, depending on the case. In the solution domain, we suggest using the terms product attribute and design parameter, which are usually known as design specifications. Whatever requirement is used, it should be verifiable, measurable, ranked, single, unambiguous, traceable and unique. A requirement is a single, unique and unambiguous statement in natural language of a single what or function that some class of user, stakeholder or client wants, written in a way that it can be ranked, validated, traced, measured and verified. When considering the term constraint, we may find it applied to some kind of requirement (functional or nonfunctional) and to product attributes and design parameters. It represents a boundary or a limit expressed in numerical terms.

There are two main objectives for classifying requirements:

To get a better understanding of what is required (problem or need) and about the product (solution) as these evolve along the product life cycle. Requirements need to be organized in a way that they can be efficiently used during the execution of the tasks and to validate the output of the tasks. This may need a process analysis, and it implies the reuse of the results as a starting point in later projects.

The classification of requirements is a challenging task. The number of requirements can be very large. In some cases, a scenario of use helps to classify the requirements. The creation of a classification could be based on:

Who defines the requirement.


Hooks and Farr y [1] Functional and performance Physical Environmental conditions and sur vivability Reliability Maintainability Availability Ser viceability Transportability and mobility Logistic Usability (human operability) Security Reuse and refurbishment Safety Testability Electromagnetic interference Materials, processes and parts use Labeling Design Interchangeability Workmanship Manufacturing cost and affordability Producibility Disposability Packing Support (manufacturing, test and use) equipment and facility

Kontoya and Sommerville [3] Functional Nonfunctional Process Deliver y Implementation Standards Product Usability Reliability Safety Efficiency Performance Capacity External Legal constraints Economic constraints Interoperability

ECSS-E-10A [7] Functional Configurational Interfaces Physical Environmental Quality factors Operation Support Verification

Pahl and Beitz [9] Geometr y Kinematics Forces Energy Material Signals Safety Ergonomics Production Quality control Assembly Transport Operation Maintenance Recycling Costs Schedules

Robertson and Robertson [14] Functional Nonfunctional Look and feel Usability Performance Operational Maintainability and portability Security Cultural and political Legal

Table 1. Different classifications of requirements.

difficult to recommend a single approach for any specific industrial environment. A more advanced approach to classification of requirements comes from the definition of ontologies [16]. The ontological approach pursues the definition of the meaning of terms and of axioms to enable automatic deduction and reasoning. However, it is still a research area rather than a mature approach adopted widely by industry practitioners. As a general conclusion, requirements have to be classified. How to classify the requirements

depends on the kind of problem or need to be satisfied, as well as the product or solution to be provided. A recommended starting point is to consider stakeholders views and then identify what other elements interface with the problem (company policies, legislation, standards and so on). However, should we expect to create a fully defined classification from the very beginning? The answer is probably no. This task is iterative and amendments may be needed along the product life cycle process. The fundamental aspect is to start classifying the requirements.

SME BLUE BOOK SERIES 2006 www.sme.org


Requirements are the main input to the system/product design and development process. If the whole product life cycle should be considered when defining the requirements, and the main reasoning cycle in the design process is an iterative analysis and synthesis loop where requirements are the input and design solutions are the output, then product engineering design is the basic discipline to consider when addressing how to go from a problem-oriented description to a solution-oriented description. This demonstrates the need for explicitly defined requirement practices and a supporting requirement management process (Figure 2). Two additional conclusions are as follows: 1. Requirements have stakeholder views. All the stakeholder views are considered as a problemoriented view where the problem to resolve is specified. These requirements are the ones used in the analysis phase, and they evolve from stakeholder terms to technical terms, creating system requirements or product requirements. Still, there should be no reference to any kind of solution.

2. The requirements from the analysis phase are used as input in the synthesis phase to generate design solutions, possibly each of them characterized by design parameters, design attributes and related constraints, which are documented as a design specification. This is considered a solution-oriented view, where the solution to create and implement is specified. Because of the complexity of the analysis and synthesis process techniques, facilitate part of the process by formalizing some steps and providing templates to represent requirements and design solution concepts. Among all the possible approaches, we have selected the quality function deployment technique, which is probably the most relevant from an industrial application point of view [11,12,17]. Additionally, axiomatic design theory provides some interesting ideas that could be implemented in an industrial environment [13].

Requirements and Quality Function Deployment

When applying quality function deployment (QFD), the first matrix relates customer wants and needs (named WHATs) with product design characteristics (named HOWs) (Figure 3). This means no distinction between nonfunctional requirements

Figure 2. Relationship between requirements and design.


and functional requirements from the technique itself, but the team applying it could do it. Table 2 presents an example. Considering this example, the requirements are written far from the ideas presented in the summary of requirements definitions in terms of being measurable, verifiable and unambiguous. Ambiguity of some of the terms used (e.g. easy) and lack of information makes it very difficult to evaluate and validate them (cupboard fit). There is no distinction between different kinds of requirements (functional requirement, nonfunctional, design parameters, constraints and so on). The problem is that the requirements specification and relationships identification rely on the judgment of the people defining them. Apart from these issues, QFD is a useful technique when applied in combination with requirements classification and writing guidelines.

Requirements and Axiomatic Design Theory

Figure 3. Requirements and quality function deployment..

Through axiomatic design [13], it is possible to represent the relationship of design and requirements (Figure 4). Requirements (stakeholders needs) and functional requirements should be defined in the stakeholder domain and in the functional domain, respectively; these are problem oriented. From the theoretical perspective, this distinction between domains is clear, but a mapping is needed between the stakeholder domain, where the stakeholder requirements are defined, and the functional domain, where what the product has to do is defined (functional requirements). The process used to represent the functionality of a product will affect the reasoning process of the designers (analysis and synthesis). In that sense, the mapping between the functional domain and the physical domain is where the design solutions are defined [9,18]. The next step considers how to manufacture the solution. Contemplated in the process domain, this incorporates the design for manufacturing concept. The application of this conceptor in generic terms, Design for Ximplies other aspects, such as how to recycle it, how to maintain it and so on.

Easy to use Ver y reliable Aesthetics

Central heating output range Domestic hot water output range Easy to repair

Table 2. List of requirements for a domestic boiler.

The solution domain ranges from the conceptual design to the detail design, where a topdown approach is applied, to flow-down requirements, design parameters and process variables from the top product/system to the final components.


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

SME BLUE BOOK SERIES 2006 www.sme.org

Figure 4. Requirements and axiomatic design.

Requirements Document and Product Design Specification (Figure 2). Table 3 presents a set of requirements engineering processes suggested by different authors. They represent different views of tasks related to requirements with a different degree of generalization. The most important thing is that they provide a reference list of common sense and engineering tasks that should be conducted when dealing with requirements. To support some of those tasks (requirements management), we may need to use software applications. The integration of software applications to support the product life cycle has led to the development of product life cycle management (PLM) systems that include tools for requirements-related tasks. Standards, for example, ISO/ICE on Life Cycle Management [21] and on Design Management Systems [22], provide guidance on how to classify requirements and in requirement-related processes. In particular, Ref. [21] proposes a list of low-level tasks related to stakeholder requirements definition and requirements analysis. Reference [22] gives a wider view, representing the requirements within the context of systems design. Table 4 presents a summary of the tasks proposed in both standards.

It can be concluded both from the standard side and from specific authors that there is plenty of material to consider as a reference and starting point. However, because each particular company has its own practices, the design process with its requirement-related tasks has to be explicitly defined and documented internally.


Requirements can be represented using natural language, both in verbal or in written form, and also using some kind of graphical notation. However, it is widely recommended to use natural language as the primary way, and any other forms of representation should be considered as an addition to a natural language statement. This is based on the assumption that natural language (e.g., English) offers better possibilities to represent what is needed or the problem to be solved. However, reality shows that when a requirement is expressed in a natural language statement, the structure of such statement depends on who makes the statement, when in the process the statement is made, what the statement refers to, what kind of requirement it is and so on.


Young [19] Identifying requirements

Kotonya & Sommerville [3] Requirements elicitation

Hooks & Farr y [1] Scope the product

Kulak & Guiney [5] Find out what the users need

Gilb [20] Define the system scope and the overall scope of the requirements Identify relevant stakeholders Determine the requirements of each type of stakeholder Categorize requirements by type Specify function requirements

Understanding the customers needs requirement elicitation Clarifying and restating the requirements Analyzing the requirements Defining the requirements

Requirement analysis and negotiation Requirements documentation Requirements validation

Develop operational concepts Identify interfaces between the product and the rest of the world Write requirements to guide product design Capture rationale reasons for the requirements existence

Documenting users' needs requirements definition Resolve conflicting requirements Eliminate redundant requirements Find commonality among requirements and abstract them to the level that makes the most sense for the users Separate functional from nonfunctional requirements Requirements traceability

Specifying the requirements Prioritizing the requirements Deriving requirements

Alexander and Stevens [4] Identify stakeholders Gather requirements

Level requirements Assess verification Format requirements

Specify performance requirements Specify resource requirements Identify and question any design constraints and condition constraints

Partitioning requirements

Organize and structure the requirements

Baseline requirements

Robertson and Robertson [14] Specify all known significant relationships of the requirements to any other relevant requirement specifications Project blastoff Get stakeholders to approve the written requirement specification that specifically affect them Carr y out specification quality control on the requirement specification

Allocating requirements

Check requirements

Tracking requirements

Review and baseline requirements

Revelle et al. [11]

Trawl for knowledge

Managing requirements Testing and verifying requirements Validating requirements

Prioritize customer segments

Write the requirements

Understand customer needs and context Quality gateway Translate the previous into engineering language Select the best concept Generate new concepts Target cost Prioritize development projects Establish targets Establish relationships between manufacturing conditions and product performance Prototype the requirements Do requirements post-mortem Taking stock of the specification Domain analysis Reusing requirements

Table 3. Sample of requirements engineering processes.

Requirements Structure
The problems derived from the use of natural language comes from the implicit knowledge and understanding that lies behind every natural language word or graphical symbol. Different actions have been suggested, for instance, a basic

anatomy for writing user requirements [4], requirement templates [14] and the definition of a list of forbidden words, which contains vague qualifier terms and any adjective and adverb created by adding the suffix ly, a practice that is observed in some companies.

SME BLUE BOOK SERIES 2006 www.sme.org

ISO/IEC 15288 [21] Stakeholder requirements definition process Identify stakeholders Elicit stakeholder requirements Define use sequences/operational scenarios and environment Analyze the ability of humans to interact with the system. If justified by risk identification, specify system requirements and functions dealing with safety. If justified by risk identification, specify system requirements and functions dealing with security If justified by risk identification, specify system requirements and functions dealing with other than health and safety Requirement analysis to resolve conflicts, inconsistencies, ambiguities, and unverifiable requirements. Review stakeholder requirements at key decision times. Record stakeholder requirements for suitable management. Check requirements with stakeholders. Requirements analysis process Define system functional boundar y: external behaviour and properties. Define each function that the system is required to perform. Define technical performance metrics. Analyze and define safety considerations. Analyze security considerations. If justified by risk identification, analyze and specify system requirements and functions that relate to critical qualities other than health, safety and security. Analyze the integrity of the system requirements. Demonstrate traceability between the system requirements and the stakeholder requirements. Document and maintain the requirements together with the associated rationale, decisions and assumptions. Concept phase Project inception Analysis of opportunities Analysis of business concepts Personnel requirements Technology requirements Budgetar y requirements Financial requirements

BS 7000 Part 2 [22]

Manufacturing resources available within the organization and among suppliers Material required Timescale for product deliver y and availability Reliability and maintainability Environmental requirements Legislation requirements Socio-political requirements Standards and codes of practice requirements Formulation of the project Feasibility phase Feasibility study Refine characteristics Develop project configuration Evaluation and sanctioning of the project Implementation phase Assemble design team Concept design General arrangement design Detailed design Construction and testing of pre-production prototypes Provision for manufacture and deliver y Introduction and product launch Selling and use Feedback Evaluation Termination phase Decommissioning Disposal

Table 4. Sample of requirements process from standards.

Considering the definition of a requirement, there are seven characteristics that may impact the writing, such as: 1. SingleA requirement is stated only by one sentence without any conjunctions (and, or, also, but, although, because).

2. UniqueThere should not be any other requirement with the same objective. This may also imply adding some identifier that is not repeated. 3. UnambiguousThis implies writing the requirement in a way that everyone involved in








the process can understand it. This can be difficult in a context with different people with different backgrounds. The main idea is to express as much as possible in an explicit way. It could also happen that some additional material (support material) has to be added as reference to the requirement. RankedFor each requirement, an advocate is needed, and an explicit ranking criteria has to be defined. Validated After defining the requirement, one should make sure that the defined requirement is exactly the one that really needed to defined. This can be considered part of the elicitation process, and in principle, it does not imply adding anything to the previous requirements, apart from a mark to show that the requirement has been validated or an attribute showing its status. TracedKeep track of the history, including evolution and changes, and the use of the requirement and its link with the design solution. This demands defining and recording the predecessor-successor relationship between the requirements and also the relationship with other elements, such as arguments and evidences, which are used to support the verification task [23]. The objective is to have an uninterrupted link along the whole product life cycle of all the requirements and related elements. This demands the use of identifiers. MeasuredThis implies that each requirement should refer to some objectively measurable property, and that a measure method for such property should be defined. In general, any objectively measurable property can be specified by a value, a unit of measure and a tolerance of acceptance. VerifiedTo test the final product, or some intermediate models, to check if the requested requirements are satisfied and in which degree. This characteristic is directly linked to the prior one; if a requirement cannot be objectively measured, it will be difficult to verify and demonstrate that the product complies with it.

A general structure of a functional requirement (FR) is proposed based on three main components [24]: 1. Action is expressed by an active transitive verb that refers to a functionsomething the product must do. 2. Object is expressed by a noun that refers to the physical/nonphysical direct object on which the action is performed. 3. Qualifier refers to the limits of the FR and allows representing the constraints associated with the FR. Qualifiers can be expressed by two different elements: a. A quantitative adjective group. b. An adverbial group or prepositional phrase, which indicates time and answers the question, For how long?. Other adverbial groups could indicate how the action must be done, where and when. In these cases, it is recommended to check if the definition of scenarios works better than considering these groups as qualifiers (constraints). Each quantitative qualifier (constraint) must have at least a nominal numerical value, a unit of measure and a tolerance. Because requirements and constraints go through a refinement to narrow the set of possible solutions, the specification of the qualifiers may not have numerical values when they are initially defined. However, when the constraints have to be considered to select a candidate design solution, the numerical values need to be declared. Examples of the proposed structure are shown in Figure 5. Figure 6 provides an example when the proposed structure is applied to a nonfunctional requirement. So far, this Blue Book has focused on natural language written requirements; however, a graphical notation could also be used to define them. The fundamental aspect to consider is that the symbols, the syntax (rules that define how the symbols can be put together) and the semantics (meaning of the symbols and possible layouts) have to be understood by the people involved to avoid misunderstanding the interpretation of the requirements. There have been various attempts to describe some kind of specific language to define requirements [20], which led to the same point: keywords, syntax and semantics have to be known and understood. The use of these alternative languages seems to be less problematic for people in-

Some of the characteristics have a clear relation with the way we write requirements (1, 3 and 7), other characteristics (2, 4, 5 and 6) have a clear relation with some attributes that a requirement object should have (identifier, advocate, priority, status and links).

SME BLUE BOOK SERIES 2006 www.sme.org



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

Figure 6. Requirements structure example applied to nonfunctional requirements.

volved in software development or in the highlevel definition of systems. However, when considering people who work on physical product development, the benefits of adopting this approach are not clear.


Requirements management encompasses tasks such as organization and documenting of requirements, tracking and controlling of their evolution and their visualization and presentation [2,3]. A support process is mainly executed during the product development process but affects the whole product life cycle. To have a product design process that encompasses the management of the requirements is a must. To have such a require-

ments management process defined explicitly should also be a must. The use of a software tool to support requirements management should be the next step. This software tool has to be integrated with other applications used in the product life cycle. Many industries, such as aerospace and automotive, are using digital product development technologies to reduce the product development time. Market forces are driving the necessity to reduce design time further. Upward of 70% of the product development is performed by the supply chain. In this context, the use of collaborative software systems to automate the design management process tries to bring the improvements needed. The use of a requirements management software tool provides a controlled framework for the inte-



gration of development changes and a common method of communication within the project team. When the environment is an extended enterprise, the importance is even higher. In this context, the OEM could monitor and control the evolution of a requirement through the tracking of its changes, if any, its relation with the design solution and its effect on individual design changes. The research being conducted in requirements engineering aims to improve the techniques used to perform activities, such as requirements gathering, requirements ranking, requirements analysis and definition of possible design solutions, trade-offs and conflict analysis, natural language processing and so on. In particular, when looking at requirements research, the efforts are directed toward developing tools and methods that help to reduce ambiguity, trace, flow down, identify, link and reuse requirements. Improved communication and sharing of requirements along the product development life cycle and its changes are the main benefit of such tools. The reduction of manual effort and the possibility of human errors is a must when one of the objectives is to reduce the development time by effectively managing an evolving set of requirements within a complex, iterative product development cycle in an extended enterprise context. In general, the OEMs in the automotive and aerospace sectors have formalized an integrated requirement practice within the product development life cycle [25,26]. When we move down to the supply chain, however, the practices seem to be vague and therefore not well integrated. Additionally, cultural issues, ambiguity and lack of common understanding seem to be relevant problems. In general, there is a clear potential to improve understanding and working practices [27,28].

context, the satisfaction of the stakeholders requirements is not only the business of the OEM but of the whole supply chain. This demands a common understanding of the demanded requirements, both in the problem/need domain and in the solution domain and the communication of them. The use of QFD as a tool to represent the voice of the customer is common in this sector. Its application, however, relies on the judgment of the people using it and the ambiguity in the terms used; the requirements writing is still an issue. This aspect is even more relevant when individual requirements are added, refined or removed by negotiations, discussions and clarifications among different parties [29,30]. In this particular example, the work focused mainly on analyzing driver and passenger seat requirements contained in the requirement documents. Figure 7 represents the basic elements of a driver seat, and Table 5 presents a list of key requirements [31]. Some of the requirements are generic (the first three). Other requirements are related to specific parts of the seat, which means they refer to parts of the basic architecture of the design solution. Some of them have explicit constraints associated with them, while others will be difficult to verify because of the way they are written. This reinforces the difficulty of specifying requirements. In this context, the work was to create a functional representation of the seat to share a common understanding between the OEM and suppliers of the product to be designed and manufactured. The functional representation is based on the functional requirements, and it is


Action on Requirements and Design Ontology Definition

The trend in the automotive sector is that the different agents of the supply chain have greater design responsibilities, and they are involved at earlier stages in the product development phase. This is a direct consequence of the clear pursuit of the concurrent and collaborative engineering practices. This model implies that the OEM relies on the suppliers to satisfy not only them but, more importantly, their customers or end users. In this




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

SME BLUE BOOK SERIES 2006 www.sme.org


Requirements The seat must be able to support the occupant's lower body. The seat must be able to support the occupant's upper body. The seat must be able to support the occupant's head. The occupant must be able to adjust the seat-cushion angle. The occupant must be able to adjust the seat-back angle. The seat quality when touched must be good. The occupant must be able to adjust the seat-back foam. The seat must be firmly secured in the vehicle. There must be a mechanism to remind the occupant to use their seat belt.
Table 5. Example of key requirements for driver seat.


25 from vertical

x-1,024.5, y-161.6, z-71.3 Front seat only

linked to possible design solutions of different components, each of them characterized by design parameters. This action has led to the development of a seat design ontology, and its implementation in a software application helps engineers from both OEM and supplier share knowledge about the product design and also specify the seat in a better way [32,33] (Figure 8).

Action on Cost of Requirements Change

In the aerospace sector, the bidding stage is one of the main phases in the development cycle of systems and components (Figure 9). A multidisciplinary team able to properly evaluate all the different aspects involved (requirements, possible design solutions, manufacturing technologies, conditions of supply, Figure 8. Seat functional design ontology and tool interface. financial implications and so on) is a must for a subcontractor to respond to a request for proposal issued by an OEM. Addicated task. A high number of stakeholders (pilots, tionally, the context is characterized by the sharing airport authorities, airline companies, internaof risk, fixed-price contracts and airworthiness tional aviation authorities, OEM, passengers, supregulations [34]. pliers, governments, crew members and so on) The definition and flow down of requireand hence many kinds of requirements have to be considered and evaluated. Among them, the airments in an airplane life cycle is a quite compli-



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

Figure 9. Top-level aerospace product development cycle.

worthiness regulations affect the deWING Pylons sign, manufacturing, testing, maintenance and operation of every single system and component of an aircraft. Ailerons An aircraft structure has two main Fixed Trailing structural functions: (1) to provide stiffEdge ness (the airframe will not distort, eiSpoilers ther statically or dynamically, in a way Fixed Inner that could compromise the perforTrailing Edge Flaps mance and safety of the aircraft) and Fixed Mid (2) to provide strength (the airframe Trailing Edge Wingbox will sustain all the loads, both statically and dynamically, for a specified time Fixed Outer without collapse). The basic functions Wingtip Trailing Edge can be formulated as: transmit the apSpars plied loads, resist the applied loads, provide an aerodynamic shape and Secondary protect passengers, crew, payload and Structure systems from the environmental conditions. Some basic constraints are associFigure 10. Example of wing breakdown structure. ated with these functions: minimum possible weight, minimum cost and minimum maintenance. Once a basic architecture ding stage, the documentation that is sent to the of the aircraft has been defined, then requiresuppliers for the preparation of the bid is somements have to flow down to the different subaswhere between an SRD and a SDSD. Table 6 shows semblies and individual components along the some examples of the requirements. They were product breakdown structure (PBS) (Figure 10). classified as nonfunctional requirement (NFR), During this process there is an evolution from constraint related to requirement (C), design solustakeholder requirements documents (staketion (DS), design parameter (DP) and constraint holder needs problem/needs domain) to system related to DS (DC). requirements documents (SRD) (technical-related The OEM may want to flex different requirewriting problem/needs domain) and finally to ments to the maximum within an agreed fixed system design specification documents (SDSD) price. In consequence, the subcontractor needs to (technical writing solution domain). At the bidminimize the risk by limiting the amount of

SME BLUE BOOK SERIES 2006 www.sme.org


Requirement General design criteria

Requirement Specification Load cases to be used for the design of the airframe shall be in accordance with loads provided by the purchaser. Loads will include, but are not limited to, fatigue, crash static and so on Access into the outer wing primar y box shall be possible through a build panel on the...

Type C

Airframe Temperatures Critical features and springback


than to requirements as such. The methodology uses input documentation from the OEM, including SRDs, SDSDs and engineering drawings, and it demands the execution of workshops to prioritize and define top relevant requirements and relationships among them. Figure 11 shows the main steps to apply such methodology [35].

The achievable manufacturing tolerances for the airframe shall be in accordance with the following document: xxx The application of titanium in conjunction with composites at joints should be avoided The target weight of the airframe subassembly shall be below xx kg. From the x scheme review, the supplier shall commit to a contractual maximum weight The following materials shall be considered for the construction of the airframe: xx,yy The design of the airframe should minimize the need for special detailed inspections



We can assume that an organization with a higher level of development in its processes is able to develop better products. This was the approach adopted by the U.S. Department of Defense for software development under the capability maturity model concept. A simplified version of that maturity or level of development model has been applied to other kinds of processes, such as the requirements engineering process [3]. The important aspect to understand is that before we identify where we start, we need to identify current state. The way to achieve this is by conducting an audit of the requirements management within the context of the product development process. The objective of starting from a top-down approach is to avoid the definition of two separate processes. You should also understand that you cannot manage (organize and control) something you have not explicitly defined previously (requirements). With these ideas in mind, it is proposed that an audit be conducted to create a picture of your current requirement process to identify its maturity level and possible improvement actions.

Assembly Design target weight


Material Structure requirements


Table 6. Examples of aircraft requirements specifications.

changes introduced to the requirements to levels that can be achieved within the contract price. For this, the subcontractor needs to understand the requirements key cost drivers and the threshold points at which price should be changed to avoid nonaffordable profit margins. The solution to this situation would be the development of a cost-impact analysis tool for requirement changes. Basically, this implies an empirical work to identify and capture the product development practices of the company, with special focus on the bidding process, requirement practices, design practices, cost estimation practices and change execution and management practices [34,35]. Similarly, in the automotive sector, an internal cost-impact analysis study was conducted [31]. As a result, a requirements management and cost-impact analysis methodology, inspired by principles from axiomatic design theory [13], was proposed and developed. In its application, four major cost drivers were identified, such as tooling, materials, labor and machinery, and bought-out items. In addition, a set of rules was created to link each cost driver with the design parameters. The cost analysis is indirectly related to the change of requirements. The reason for this is that most of the changes are related to constraints associated with design parameters, rather

Maturity Model and Audit

To start, the first question you should answer is, Is there an explicitly defined product development process (PDP)? If the answer is yes, then you should start assessing the maturity of such process. If the answer is no, then we recommend you define a PDP prior to continuing to delve into specific requirement-related activities. If you have a PDP, then you are a position to analyze it and assess the level of maturity from the requirements process perspective. This task may demand that an audit be conducted to create the as-is model. From the analysis of the as-is model, an understanding can be gained on the current maturity level of the requirements engineering process (Figure 12).



Figure 11. Requirements management and cost impact analysis methodology.

To conduct the audit, you should remember that requirements have to be captured, structured, formalized, represented, analyzed, validated, managed, verified and used along the PDP. Considering this, it is recommended that you develop a map (as-is model) showing:

The requirements process workflow.

The different kinds of requirement documents used, gathering information about who creates them, contributes to them, uses them and in which activities. For each requirements document, you should have a table of contents to understand what kinds of requirements are documented in it. Could you define a content categorization to facilitate the creation and reading of the documents? Could you define a document template? Identify the level of confidentiality and security of each document. For each activity related to requirements, identify which process is conducted manually, automatically or manually assisted by a software application.

Identify possible bottlenecks in your requirements process. To what extent do current practices, people and technology support or hamper the effective flow and use of requirements? Identify main barriers, such as inappropriate practices, cultural differences, not enough time allocated to create/review/modify the documents, lack of visibility of the requirements relevance, eliciting requirements from users is not performed and so on [27,36]. Identify possible requirements problems, for example, incomplete requirements, product does not satisfy the user requirements, there are too many changes in the requirements or in the design, modifications occur in late development stages or in pre-production, explicit complaints about requirements and so on. Identify the link between the possible requirements problems, the as-is model and the identified barriers. To conduct the requirements process audit, you will need to create specific questionnaires to interview different members of your organization

SME BLUE BOOK SERIES 2006 www.sme.org


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

ments) about the work they are willing to pay for. In this context, the future of requirements engineering points to tackling five specific areas: 1. Elicitation, writing and modeling. This area considers not only the engineering aspect of the activities, but also the cognitive and social part. Techniques to better elicit requirements from stakeholders, easier and more effective ways to represent requirements, capturing and representation of subjective needs and requirements, cognitive aspects of deriving solutions from requirements, creation of requirement ontologies, collaborative requirements definition and natural language processing are some of the actions being pursued by different research groups.


In an industrial environment where the extended enterprise is a common business model and where the project risk is shared between OEMs and suppliers, the bidding process to win contracts demands from the supplier a comprehensive understanding of the requirement set and its evaluation to assess the technical, financial and time implications. OEMs have to deliver to the project bidder accurate information (require-

Figure 12. Requirements engineering simplified maturity levels.



2. Integration of requirements engineering practices within the solution life cycle and in particular within the bidding stage and development and design process. This action may demand conducting a requirements engineering audit to elaborate an as-is model of the current practices to identify possible improvement actions. It also demands the development of integrated applications to automate requirement tasks and to improve the visibility of the requirements impact in the business. In this area, there is a clear trend in the development of requirement software tools. 3. Requirements change impact analysis. There is an understandable interest from the business and engineering perspective to have a clear vision of the implications that requirements changes have in the possible solution, and the effects in the business strategic, tactical and operational levels. Apart from the complexity of the problem the requirements refer to, the complexity is quite high because of the implications of change propagation, and it is very difficult to develop any impact analysis (cost, schedule) with a significant level of accuracy. Several research groups are currently focused on this area of research. 4. Education. This action should aim to increase engineers awareness of the relevance of requirements and to train them to write and document requirements. It should also emphasize the relevance of documenting the relationship between requirements and design solutions. At the management level, there is a need to increase the visibility of the link between requirements, business goals and productivity. Management should lead and promote the actions to improve requirements practices. 5. Transfer expertise and facilitate cultural change in small and medium-sized enterprises. This is not a research-related area, but an area that could be used to increase requirements awareness for small and medium-sized enterprises. With this new-found knowledge, small and medium-sized enterprises can apply requirements engineering activities to their own businesses, delivering parts to their customers at a lower cost and in shorter time.

This Blue Book describes the relevance of requirements from the manufacturing engineering

and business perspective. Terminology used is a fundamental aspect when we use natural language to communicate. We need to be precise when we talk about requirements because of their diversity. Initially, we need to make a distinction between the ones that refer to the problem to be resolved or the need to be satisfied and the ones to specify the solution to be adopted. This is also important because, as a consequence later, we need to classify the requirements as they refer to different aspects of the problem, need or solution. The requirements engineering process has to be integrated, especially with the bidding and development and design phases. There are different proposals about how the requirements process should be, both from different authors and from standards. The first thing to do is audit your own process to have an explicit representation of it (as-is model), understand the level of maturity in the process, and hence, identify possible improvement actions. Axiomatic design proposes some guidelines about how to establish the link between functional requirements and the design parameters that define the possible solution. However, this approach seems to be difficult to use in industry when the problem is complex and if no previous education and training is provided to the engineers. QFD is clearly a technique that is being used to represent requirements and their link to product features, but it seems to be a problem in how we write the requirements. How to manufacture the solution adopted is a key element in this process because it is part of the design for X and should be adopted during the product development and design phase. The key aspect to keep in mind when defining a requirement is that a requirement has a set of features to comply with, such as single, unique, unambiguous, ranked, validated, traced, measured and verified. Some of these features are directly related to how to write a requirement (action, object and qualifier), and others demand attachment to some attributes to it (identifier, advocate, priority, status and links). The key aspect here is that you should define a template to define and write requirements. Currently, there are requirement management software applications that provide a template for this purpose. Requirements are the absolutely essential input to the product design process and also to business decisions, so an integrated view that considers the propagation of the requirements prac-

SME BLUE BOOK SERIES 2006 www.sme.org


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

The authors would like to thank other members of the Decision Engineering Centre, in the Manufacturing Department at Cranfield University, who have contributed to the research conducted in requirements. The teams research was sponsored by the Engineering and Physical Sciences Research Council, Nissan Technology Centre-Europe, Johnson Controls, EDS and GKN Aerospace.

[1] Hooks, I.F. and Farry, K.A. Customer-Centered Products. New York: AMACOM, 2001. [2] IEEE STD 1220-1998. IEEE Standard for Applications and Management of the Systems Engineering Process. Piscataway, N.J.: IEEE, 1999. [3] Kotonya, G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, England: John Wiley & Sons, 1998. [4] Alexander, I.F. and Stevens, R. Writing Better Requirements. London: Addison-Wesley, 2002. [5] Kulak, D. and Guiney, E. Use Cases: Requirements in Context, 2nd ed. Boston: AddisonWesley, 2003. [6] Sommerville, I. and Sawyer, P . Requirements Engineering: A Good Practice Guide. Chichester, England: John Wiley & Sons, 1997. [7] ECSS-E-10A, Space Engineering: System Engineering. Noordwijk, The Netherlands: ECCS, 1996. [8] Cross, N. Engineering Design Methods: Strategies and Tactics for Product Design, 2nd ed. Hoboken, N.J.: John Wiley & Sons, 1994. [8] Pahl, G. and Beitz, W. Engineering Design: A Systematic Approach, 2nd ed. London: Springer-Verlag, 1996. [9] Ulrich, K.T. and Eppinger, S.D. Product Design and Development, 3rd ed. Irwin, N.Y.: McGraw-Hill, 2004. [10] Revelle, J.B.; Moran, J.W .; and Cox, C.A. The QFD Handbook. New York: John Wiley & Sons, 1998. [11] Terninko, J. Step-by-Step QFD: CustomerDriven Product Design, 2nd ed. Boca Raton, Fla.: St. Lucie Press, 1997. [12] Suh, N.P . Axiomatic Design: Advances and Applications. Oxford, England: Oxford Univ. Press, 2001.

[13] Robertson, S. and Robertson, J. Mastering the Requirements Process. Oxford, England: Addison-Wesley, 1999. [14] Baum, L.; Becker, M.; Geyer, L.; and Molter, G. Mapping Requirements to Reusable Components Using Design Spaces. Piscataway, N.J.: IEEE, 2000. [15] Koogan, K. and Sampaio do Prado, J.C. Ontology as a Requirements Engineering Product. Proc. of 11th IEEE Intl Requirements Engg. Conf., 2003. [16] Chan, L.-K. and Wu, M.-L. Quality Function Deployment: A Literature Review. European Journal of Operational Research (v143, n3, 2002), pp463-497. [17] Hirtz, J.; Stone, R.B.; McAdams, D.A.; Szykman, S.; and Wood, K. A Functional Basis for Engineering Design: Reconciling and Evolving Previous Efforts. Research in Engg. Design (v13, n2, 2002), pp65-82. [18] Young, R.R. Effective Requirements Practices. Boston: Addison-Wesley, 2001. [19] Gilb, T. Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering and Software Engineering Using Planguage. 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 Systems: Guide to Managing the Design of Manufactured Products. London: BSI, 1997. [22] Wills, S. Systems Engineering in the Rail Sector Joining Up the Pieces. Telelogic User Group Conf., Oct. 2004. [23] Hunter, R.; Rios, J.; Perez, J.M.; and Vizan, A. A Functional Approach for the Formalization of the Fixture Design Process. Intl Journal of Machine Tools and Manufacture (v46, n6, 2006), pp683-697. [24] Almefelt, L.; Andersson, F.; Nilsson, P.; and Malmqvist, J. Exploring Requirements Management in the Automotive Industry. Intl Conf. on Engg. Design, Stockholm, Aug. 1921, 2003. [25] Roussel, J-C. Benefits of Requirement Engineering with DOORS: Airbus Experience, Telelogic Capital Market Event, June 2005. [26] Kauppinen, M.; Kujala, S.; Aaltio, T.; and Lehtola, L. Introducing Requirements Engineering: How to Make a Cultural Change



Happen in Practice. Proc. of IEEE Joint Intl Conf. on Requirements Engg., 2002. [27] Weber, M. and Weisbrod, J. Requirements Engineering in Automotive Development Experiences and Challenges. Proc. of IEEE Joint Intl Conf. on Requirements Engg., 2002. [28] Kerr, C.I.; Roy, R.; and Sackett, P. J. Requirements Management: An Enabler for Concurrent Engineering in the Automotive Industry. Accepted for Intl Journal of Production Research, 2006. [29] Roy, R.; Kerr, C.I.V .; and Sackett, P. J. Requirements Management for the Automotive Extended Enterprise: The Next Evolution in Digital Product Development. 14th Intl CIRP Design Seminar, Cairo, May 2004. [30] Oduguwa, P. A.; Roy, R.; and Sackett, P. J. Cost Impact Analysis of Requirement Changes in 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 Product Ontology for Automotive Seat Specification. DETC2004-57071, ASME DETC/CIE, Salt Lake City, Oct. 2004. [32] Kerr, C.I.; Roy, R.; and Sackett, P .J. A Knowledge-Based Tool for the Selection of Design Options During the Competitive Tendering of Vehicle Systems. ESDA2004-58044, 7th Biennial ASME Conf. on Engg. Systems Design and Analysis, Manchester, England, July 2004. [33] Rios, J.; Lopez, A.; and Roy, R. Design Requirements Change and Cost Impact Analysis in Airplane Structures. Submitted to Intl Journal of Production Economics, 2006. [34] Roy, R.; Rios, J.; and Lopez, A. Cost Impact Analysis for Requirements Changes within the Aerospace Industry. ICMR Conf., Cranfield, England, Sept. 2005. [35] Davis, P. Ten Questions to Ask Before Opening the Requirements Document. Telelogic User Conf., Marlow, England, Nov. 2005.

SME BLUE BOOK SERIES 2006 www.sme.org