Knowledge-enriched Requirement Specification for One-of-a ...

CONCURRENT ENGINEERING: Research and Applications

Knowledge-enriched Requirement Specificationfor One-of-a-kind Complex Systems

Svetan Ratchev,1,* Kulwant S. Pawar,1 Esmond Urwin1 and Dirk Mueller2

1School of Mechanical, Materials, Manufacturing Engineering and Management, University of Nottingham, UK2Institute of Mechanical Engineering, Technical University of Clausthal, Germany

Abstract: Requirement engineering (RE) process is becoming a key factor for the success of complex one-of-a-kind products. The RE

process is commonly viewed as an early system engineering phase with a major bearing on response time, quality, and cost. This study reports

on the knowledge acquisition and sharing for requirement engineering (KARE), approach for requirement specification of one-of-a-kind

complex systems. The approach provides a generic view of key RE processes clustered into three groups of activities – requirements

elicitation, analysis, and negotiation. The process is supported by a set of knowledge functions aimed at facilitating the requirement engineers

in matching customer requirements to product characteristics. At the analysis stage, the customer requirements are transformed into product

requirements, which can be compared to existing company knowledge, for example, previous products, technology platforms, and production

capabilities. The specified product requirements are then interactively evaluated and negotiated against customer and supplier performance

indicators.

Key Words: requirement engineering, knowledge management, system engineering.

1. Introduction

Requirement engineering (RE) has evolved as a keystage in the overall system engineering process [1].The increasing product complexity, market placeglobalization, and the changes in product life cycleshave underlined the need for increased reuse ofcomponents, information, and knowledge acrossprojects to deliver efficient and cost-effective productsolutions. This is particularly valid in large one-of-a-kind projects requiring significant effort at the initialproduct specification stages, where a large proportionof the product cost is committed. In fact, in developingproducts with high complexity in industries, such asaerospace, it is widely accepted that almost 60% ofthe product cost is allocated during the first 5% of theproduct development cycle. The success of the require-ment specification in new design projects largelydepends on an accurate match between customerrequirements and company product and process knowl-edge. The successful understanding of the user require-ments and their transformation into clear productrequirements therefore becomes a critical element withinthe overall realization of a successful product [2].

Poor understanding of the RE process and inaccurateassumptions made during the elicitation of user require-ments can have significant negative implications on thedesign and manufacture of the product affecting quality,lead time, and cost [3].

Customers usually encode the knowledge relatedto their requirements of needs, into text, drawings, orverbal messages, i.e., into information. The conversionof this knowledge into explicit information stems fromthe transformation of tacit knowledge [4], i.e., personalknowledge that is implicit and cannot easily be commu-nicated. The main disadvantage of such form of knowl-edge is that it avoids critical discussion and there aredoubts about its level of objectivity [5,6]. This, therefore,not only makes the management of the RE processdifficult, but on occasions can also obstruct criticalproduct and process considerations and hence, thedevelopment of the knowledge on RE. The complexityof the customer–supplier interaction is further exacer-bated by intercultural differences between businesspartners. Requirement defects can thus be created whena supplier guesses as to what is implied by an incompleteor ambiguous requirement statement that often losespart of the explicit meaning through an incorrecttranslation of the customer’s implicit knowledge [7,8].Despite the recent developments in both RE and knowl-edge management, there is still a lack of generic methodsand models that could support knowledge acquisitionand sharing for RE in a one-of-a-kind environment.

*Author to whom correspondence should be addressed.E-mail: [email protected]

Volume 13 Number 3 September 2005 1711063-293X/05/03 0171–13 $10.00/0 DOI: 10.1177/1063293X05055003

� 2005 Sage Publications

According to Hooks [9], customer statements oftenproduced without sufficient product-related informa-tion, are generally initial requirements that are either ill-defined or are goals, objectives, and design statementsrather than actual requirements [10]. Such statementsare subject to changes partly due to the lack of vision ofthe new product to be developed and possible technol-ogical changes that might occur during the productdevelopment process. These potential changes needa requirement change management process, whichmust be performed throughout each phase of therequirement specification process. It is, therefore, ofinterest to analyze specifically the contents and linksbetween each of the different phases. In this analysis,the complexity of the system to be developed andits requirements, the available knowledge within theapplication domain, the level of skills within the projectteam (including the customer), and organizationalculture must be taken into account.The requirement specification process for a one-of-a-

kind system can also be very specific [10]. The under-standing of its content and structure requires themonitoring of the activities, which have been carriedout in real life. The modeling of these activities hasbecome a major research area because of the complexityof integrating several application domains that involvedifferent groups of individuals with different problems,solutions, and interests at stake. These activities shouldbe intensively supported by knowledge, which includesdata about the system or product and organizations(market place, legislation, technological data, standards,etc.). This data is collected and used differently at widelydispersed locations. Different rules are often used toturn this data into knowledge, resulting in a lack ofconsensus between knowledge experts [4]. Therefore,the mechanisms for acquiring and distributing knowl-edge within multidimensional domain applications areessential for providing organizations with flexible waysof bridging gaps between requirements and knowledgeengineering.The current research in engineering requirements

has been summarized in [11]. Although research in thesefields has been performed for general design projects,these cover specific areas for each specific case. No studyhas been reported that encapsulates all the areas withapplication to a single field, i.e., using prescriptivemethods to provide automated or semiautomated designtogether with descriptive means.Furthermore, the differences between the application

of RE in software and engineering disciplines areoutlined where engineering design aims to ‘arrive ata complete, concise and correct description of the designneed, expressed in natural language.’ This involves theformalization of design requirements into a structuredmethodology, whereas software requirements are moreflexible and do not need to be processed in this way.

Bray [12] highlights the need for RE and providesa basic definition of the principles. Furthermore, theimportance of design requirements is acknowledgedby Stadzisz and Henrioud [13] who describe how require-ments are filtered throughout the design cycle asproducts and product families are created to serve thewants and needs of customers.

Research in this field is generally fragmentedwith applications developed to satisfy specific needs.For example, the NIBA project [14] recognizes theimportance of requirements and the need for betteranalysis of user requirements. As user requirementsare usually elicited in natural language, a linguisticallybased method for analyzing these requirements isthought to be beneficial. This approach decomposesthe syntax of requirement statements and analyzessentences to ensure that they are syntacticallycorrect. Although this provides a useful basis forcompleteness and consistency checking, no furtherwork has been reported that uses the output from thismethod.

Despite the recent developments, there is still a lack oftransparency and consistent definition of the activitiesin RE. There is also a lack of structured methods forcapturing relevant enterprise knowledge and deploy-ing it in support of decision making for requirementspecification.

The article reports on a new knowledge-‘enriched’RE approach for one-of-a-kind complex products. Themethodology is based on the development of a genericknowledge model that supports the key RE steps ofrequirement elicitation, analysis, and negotiation.

2. Overview of the KARE Methodology

The knowledge acquisition and sharing for require-ment engineering (KARE) [15,16] methodology is aimedat supporting the RE process in a one-of-a-kindenvironment. The RE process (Figure 1) starts with aninvitation to tender (ITT) and finishes with a require-ments baseline. KARE provides an interface for thesystem requirement review (SRR), which ensures thatsystem requirements are sufficient to meet missionobjectives, the expected performance, and that costfigures of merit are realistic. The approved requirementsat the SRR are then passed on to the conceptual design(CD) stage.

The KARE approach has two main integratedcomponents a requirement engineering (RE) processand a knowledge engineering (KE) process [12].The KARE RE process comprises a three-step process:(1) requirements elicitation, (2) requirements analysis,and (3) requirements negotiation. The model assumesthat the customers’ ability to articulate their needs variesand accordingly, defines the elicitation of customer

172 S. RATCHEV ET AL.

requirements as the first step in RE. Requirementselicitation is a process of discovering system require-ments through consultation with stakeholders, fromsystem documents, domain knowledge, or any othermeans of information. Requirements elicitation andanalysis are closely linked processes. As requirementsare discovered during elicitation, some analysis isinevitably carried out [7]. The requirements analysisinvestigates the requirements and then different stake-holders confer to decide on which requirements are to beaccepted. The RE processes establish an iterativesequence, sometimes referred to as stages [17]. The KEmodule supports this sequence at all the stages.

The customer and the supplier confer requirementsduring the requirements negotiation. Both the partiesmay agree on top-level requirements. Additionalrequirements may be derived according to customerneeds; requirements may be updated and then, re-enterthe requirements elicitation process. The customerand the supplier negotiate the requirements supportedby the requirement request engine. Every negotiationpotentially relaunches the requirements elicitationprocess until a baseline is defined.

The RE process is developed in four stages – (1) theidentification of system type, (2) identification ofproduct range, (3) comparison with products, and(4) trade-off studies. The four stages of the processare to a great extent arbitrary and whether theseare applied depends naturally on product complexityand on the company-specific practices. However, therequirements elicitation, analysis, and negotiationactivities are performed at each stage resulting inan incremental requirements update in accordancewith customer–supplier negotiations. Figure 2 illustratesthe major phases of this process. Here, the emphasischanges from capturing customer needs at the firstrefinement iteration to consolidating requirements atthe following refinement phases. Finally, prior tospecifying the baseline definition, the suitability analysis

is conducted. The purpose of this phase is tospecify suitable products with a level of trade-offin defining the particular product features. Suchsolutions are the basis for the selection of the product,which defines the baseline for the follow-up conceptualdesign.

Each of the RE processes are supported by knowledgefunctions. The underlying component of the KAREsystem that supports and enriches the RE process isthe KE process module (refer Figure 1). KE supportsthe RE process through eliciting, analyzing, andanswering support requests. A second objective of theKE module is the transformation of implicit knowledgeinto explicit knowledge through conceptual modeling.The KE process features two types of activities –knowledge elicitation and knowledge analysis. In theKARE context, the knowledge elicitation is definedas a process of collection, capture, and formalization ofknowledge. The knowledge content is investigated indetail in the knowledge analysis process to validate andquantify the knowledge before the knowledge repositoryis added to and/or updated. The knowledge elicitationand knowledge analysis processes constitute a recursiveloop that supports RE at any stage throughout the REprocess.

RequirementsEngineering

KARE

Conceptualdesign

ITTEXIT to CD

Requirementsengineering

ElicitationAnalysis

Negotiation Knowledge engineering

Elicitation

Analysis

Engineeringdesign and development

Requests from other SE modules

SRR

Abbreviations:SRR - System requirements reviewCD - Conceptual designSE - System engineering

System engineering

Figure 1. The KARE knowledge-enrichedrequirement engineering approach.

Level 1 Level 2 Level 3 Level 4

Systemtype

Existingproducts

Trade-offnegotiation

Producttype

Ideal products Existing products Negotiated productGeneric system

KEM

REM REM REM REM

Enterprise knowledge

ITT

Figure 2. KARE requirement definition stages.

Knowledge-enriched Requirement Specification for Complex Systems 173

3. KARE Requirement Engineering Process

The RE activities address the broad and diversedomain of customer needs. Customers may have verydetailed concepts of their needs, or in some cases haveonly an idea about a product. It is very likely that themajority of the requests for specification of customerrequirements of needs would rank somewhere betweenthese two extremes. As described earlier, the KAREgeneric RE process model is based on three iterativeknowledge-supported decisionmaking steps – (1) require-ments elicitation, (2) requirements analysis, and (3)requirements negotiation. Through a number of itera-tions, the supplier and the customer negotiate therequirements, which result in requirement updatesuntil a product requirement baseline is defined [1].

3.1 Requirements Elicitation

The goal of the requirements elicitation process is tocollect and capture the relevant customer needs. Theseare then formatted, i.e., checked for ambiguous words,adequate grammar rules are applied, and the customerand supplier terminologies are related using a glossary.The process comprises three steps – requirementcollection, capture, and formatting (Figure 3). Therequirement collection is triggered by ITT with a set ofuser requirements of need, or further requests for elici-tation resulting from downstream system engineering

activities. The requirement collection requires customer–supplier interactions and is technically limited to thecollection of all the information that contains possiblerequirements. The input includes documents, files,drawings and the like, which are input to the require-ments capture. Furthermore, it may contain require-ments, which the subsequent requirements formattingstep has considered as incomprehensible and as suchhave been referred back to the requirements capturestage. Requirements collection may require interviewswith customer representatives, which call for consider-able skills and can have a considerable impact on thecustomer–supplier relationship [7].

The requirements capture step segregates therequirements from unrelated information. This stepis required to determine which of the collected customerrequirements, are indeed the requirements and whichare not. Within the KARE environment, the require-ment engineer can request knowledge messages tosupport the decision making in the form of requirementidentification rules.

A KARE requirements dictionary supports therequirements formatting step. The dictionary providesrequirements terms and meanings for the formattingprocess, thus allowing the customer and the supplierterminologies to be related. Moreover, a list ofinappropriate terms and knowledge of requirementgrammar is provided to support the process. Theformatting step is facilitated by requirement templates,which provide the format in which the customer

I2Invitation totender

I3Requirementsupdate

I1Customer needs

C1Decision support

O3Customer

requirements

O1

Knowledgeupdate

Requirementscollection

A1111

Requirementscapture

A1112

Requirementsformatting

A1113

Information

Requirementsinformation

Collection knowledge Requirementsidentification rules

Document template (tool based)

O2

Requestfor decision

support

KARE dictionarygrammar rules

Incomprehensible, ambiguous requirements

Figure 3. Requirements elicitation process – an overview.


requirements are referred to in subsequent processes.Ambiguous and incomprehensible requirements arereferred back to requirements collection stage to seekfurther information or verify specific statements.

3.2 Requirements Analysis

The goal of the requirements analysis stage is togenerate the reference requirements that would form theproduct baseline. The requirements analysis is a highlyrecursive and knowledge-intensive process (Figure 4).It consists of three major steps – (1) requirementsquality analysis, (2) suitability analysis, and (3) pre-paration for requirement negotiation.

The requirements quality analysis investigates thequality of the requirements themselves, through require-ments checking, testability analysis, and requirementsvalidation. The goal of these processes is the produc-tion of requirements that are consistent, valid in termsof feasibility and necessity, and are quantifiable andverifiable.

The suitability analysis features three steps – require-ments mapping, risk analysis, and identification ofrequirements to negotiate. It starts with the validatedrequirements being mapped to existing functional andnonfunctional product requirements. For requirementsthat cannot be mapped to existing products, newproducts must be developed. Therefore, requirementsmapping relies on knowledge about products that have

been produced. A trade-off analysis is used to considerthe effects of requirement alterations and changes. Somerequirements are usually mandatory (e.g., legal obliga-tions), while others leave scope for alterations or maypossibly be changed altogether. Considerations dependupon technical importance with regard to the customerneeds, technical difficulty, environmental operatingconsiderations, costs, etc. [18].

The risk analysis process allocates and assessesthe risk to product components and refers unsuitedcomponents back to the mapping process. To supportthe data analysis, a matrix showing components andcompany-specific risk criteria is generated and used toevaluate the risk for every component on a predefinedscale.

The last step is the identification of requirements tonegotiate, where decisions about the requirements ofthe potential solution sets need to be negotiated with thecustomer.

4. KARE Requirement EngineeringKnowledge Model

The KARE RE process is supported by a knowledgemodel which has three distinctive levels [19] – domainknowledge, inference knowledge, and task knowledge.This makes explicit all the rules, reasoning processes,and knowledge within the processes. Keeping this inmind, a measure of control and standardization can be

Validated

z

Requirementchecking

Testabilityanalysis

Riskanalysis

Identification ofrequirementsto negotiate

Consistentrequirements

Formalized requirements

List ofrequirementsto negotiate

Decision support message

Request for knowledgesupport

Modifiedrequirements Knowledge update

requirements

Verifiablerequirements

Risk assessedsolution sets

Solutionsets

Unclear requirements

Requirementmapping

Unsuitedrequirements

Requirements to negotiate

Quality analysis

Suitabilityanalysis

Requirementsvalidation

Figure 4. Requirements analysis process – an overview.


applied throughout the entire RE knowledge modelingprocess.The knowledge model categorizes knowledge into two

main areas [19]:

. Control knowledge which defines both the contentand the structure of task- and inference-specificknowledge in a procedural form. It consists of twoknowledge categories:

– Task knowledge which describes how to decomposethe top-level reasoning task and how to imposecontrol on this decomposition.

– Inference knowledge which describes how to usedomain knowledge in elementary reasoning steps(inferences).

. Domain knowledge which is static knowledge andconsists of the concepts, relations, and facts that areneeded to reason about a certain application domain.It defines both the content and the structure ofdomain-specific knowledge in declarative form.

The KARE approach differentiates between declara-tive and procedural RE knowledge. The declarativeknowledge, for instance, is the knowledge aboutproducts and requirements, which is processed bythe procedural knowledge. The procedural knowledgeis defined as the knowledge about how to transformrequirements. KARE differentiates between procedural

knowledge, for which explicit rules can be identified asKARE knowledge and that which eludes rule-baseddescriptions. The former, the KARE procedural knowl-edge, is coded into automatic processes and incorpo-rated into the KARE workbench. The latter is relevantinsofar that it defines the processes where humandecision making is essential.

The KARE approach in managing and maintainingthe RE knowledge is based on four tasks – knowledgeelicitation, analysis, mapping, and sharing.

4.1 Knowledge Elicitation

The knowledge elicitation function provides declara-tive knowledge for the RE process. The acquisition ofsuch knowledge is a constant process throughout each ofthe RE processes. From each RE process, a numberof requirements are elicited, which are collected as a partof the knowledge acquisition process (Figure 5).

This potential new knowledge is then captured withthe aid of a knowledge engineer, which is then checkedagainst the current knowledge base as to whether or notit already exists and is utilized. Potential new knowledgethat is not present proceeds to the knowledge formali-zation process, where it is formatted according topredefined forms. Once the three knowledge elicitationinferences have been completed, the potential newknowledge is passed to the knowledge analysis processfor validation and verification.

Knowledgecapture

Knowledgeformalization

Inference knowledge

Task knowledge

Domain knowledge

Knowledgecollection

User needlist

Knowledgeelicitation

User

Customerrequirements

Customer ProductRequirements

Supplier

Supplierknowledge

General + badkeyword lists

Dictionary

Keywordlists

Figure 5. Knowledge elicitation model.


4.2 Knowledge Analysis

The knowledge analysis task seeks to verify and checknew knowledge for completeness and consistency. It issupported by two inferences for knowledge reviewand knowledge negotiation (Figure 6). The knowledgereview inference receives the formalized knowledge andchecks its the completeness and consistency. It appliesthe declarative knowledge stored in the knowledge base,for example for the completeness of the new knowledge,the knowledge formatting rules are accessed fromwithin the relevant domain (Figure 6). These are appliedagainst the item in question and a decision is made as towhether or not it is complete. If complete, the itemproceeds to the negotiation phase, if not, input willbe requested from a knowledge engineer to completethe item. Once reviewed, the knowledge is passed to theknowledge negotiation inference. The validity of theknowledge is checked using validity rules and the inputof a knowledge engineer. Once both the inferences havecompleted the necessary iterations, the task of knowl-edge analysis is to update the knowledge base with thenew knowledge.

4.3 Knowledge Mapping

For the knowledge base to be a useful and anintuitive item to use, the knowledge must be logicallyrelated to the physical world, i.e., RE. New knowledge

will have meaning attached to it, but can be consideredas stand-alone items with no relationships or links toany of the RE knowledge. Therefore, some mappingof the knowledge must take place to add the relation-ships and links between the requirements knowledgeand other areas of the knowledge base. The knowl-edge components are linked to their process applications.For instance, the customer knowledge is mainlyapplied to customer requirement elicitation, whilstrequirement knowledge is applied throughout the REprocess.

The secondary function of the task is the character-ization of knowledge. The process starts with theidentification of the knowledge utilized for each activityand breaking each activity into its constituting compo-nents. These are then classified as either declarative orprocedural knowledge. The procedural knowledge isclassified according to either rule-based behavior (RBB)or knowledge-based behavior (KBB). Table 1 providesan example of the knowledge classification and showsthe functional mapping of requirements, which is asubset of requirements mapping activity.

Functional mapping requires both declarative andprocedural knowledge. The explicit declarative knowl-edge is applied to requirement characteristics and prod-uct properties. Procedural knowledge is encoded intoRBB provided that the rules and algorithms are explicitor can be elicited. When the need for KBB is highlightedfor example, when a new product must be defined,

Knowledgereview

Knowledgenegotiation

Inference knowledge

Task knowledge

Domain knowledge

Knowledgeanalysis

Customer

Dictionary

ProductRequirements

Supplier

General + badkeyword lists

RequirementcharacteristicsCustomer

knowledgeSupplier

knowledgeKeyword

lists

Figure 6. Knowledge analysis model.


the input and control of a human is needed to completethe complex procedural knowledge process (Table 2).

4.4 KARE Knowledge Domains

The KARE knowledge base is organized into fivedifferent top-level knowledge domains (Figure 7). Eachof the knowledge domains comprises different entities,for example the product domain, is comprised of artifactclasses. Such artifact classes are likely to be companyspecific.Figure 8 shows an example, which differentiates

between system types (e.g., weapon system, surveillancesystem), the product ranges of a system type, existingand new products based on technology that will bedeveloped and new technology platforms for newproduct ranges.The product domain is linked to the supplier domain.

The supplier knowledge domain features a list ofsuppliers with their artifacts and artifact properties. Inaddition, the domain includes knowledge about compe-titors and competing artifacts and attributes, such asprice and delivery data, which are used to evaluatethe market position of the supplier during a productinvitation to tender/bid phase. The supplier terminologydescribes declarative company knowledge aboutrequirements expressions and terminology, for example,

ambiguous wordings. This knowledge can be linked tocustomer knowledge about customer terminology andother background knowledge about the customer (e.g.,preferences, cultural issues).

Overall, the RE knowledge content tends to be verycompany specific and dependent upon the businessprocesses a company deploys for RE. Therefore, theRE processes as well as their knowledge support proces-ses have to be configured to meet company-specificcharacteristics. The KARE methodology provides gen-eric processes and procedural knowledge, which aresupported by different knowledge domains and need to

Customer

Requirement engineering knowledge domain

ProductKnowledgeRequirement

ProductKnowledgeProduct

SupplierKnowledge

SupplierKnowledgeSupplier

User/consumer

Figure 7. KARE knowledge domains.

System type

Product range

Potential product

New technology product

New technology platform

Existing product

System types

Price range

Performance

Create()

Get attribute()

Link knowledge()

Validate knowledge()

Figure 8. Product knowledge categories.

Table 2. Linking knowledge to domains.

Process Knowledge Type Domain

Functional mapping Requirement characteristics Declarative Requirements knowledgeProduct properties Declarative Product knowledge

Supplier knowledgeMatching of propertiesand characteristics

Procedural RBB Coded process

Define new products Procedural KBB Human controlDefine new propertiesof new products

Procedural KBB Human control

Table 1. Knowledge classification.

Activity Knowledge Type

Functionalmapping

Requirementcharacteristics

Declarative

Product properties DeclarativeMatching of propertiesand characteristics

Procedural RBB

Define new products Procedural KBBDefine new propertiesof new products

Procedural KBB

Similarity threshold DeclarativeDiscrimination threshold DeclarativeDefine (new) similaritythreshold

Procedural KBB

Define (new)discrimination threshold

Procedural KBB


be customized to capture the company- and product-specific knowledge.

4.5 Knowledge Sharing

The knowledge sharing function in the KAREapproach is focused on the RE process and is supportedby the knowledge acquisition, analysis, and mappingprocesses. The knowledge acquisition and analysisprocesses consist of rule-based procedural knowledge,which is coded into the KARE workbench.

The knowledge sharing activity provides knowledgesupport for the RE processes. During the operation ofthese processes, requests for knowledge are sent to theknowledge engine. It responds by supplying the relevantknowledge based upon the request wherever possible.For example, after the capture of a customer’s require-ments, they must then be identified and formatted tostandardize their representation. The knowledge engineprovides support for the process by supplying require-ment terms, meanings, grammar rules, and a list of badwords. These are applied to each of the requirements toallot it a relative identity and meaning. The applicablecustomer document templates are then supplied to theformatting process to enable the correct representationof the identified requirements.

5. Contributions to the Developmentof the System Engineering Data Exchange

Standard Step AP233

The requirement model developed within the KAREapproach [20] was adapted and incorporated into theongoing work on developing a systems engineeringexchange standard Application Protocol 233 (AP233)at ISO level. The AP233 model features a model-basedrepresentation of requirements, which allows the appli-cation of knowledge functions. A major problemtoday is that most requirements are specified in naturallanguage.

The systems engineering AP 233 aims at providingsupport for system design processes. This applicationprotocol defines the context, scope, and informationrequirements for various developmental stages duringthe design of a system and specifies the integratedresources necessary to satisfy these requirements. Thisapplication protocol shall be applicable to any type ofsystem including complex aerospace systems, such aslaunch vehicles, aircraft, and their subsystems, suchas avionics, aeroengines, or aerostructures. In general,these systems cannot be simply considered as a sum ofsingle components, the point of view taken must be oneof their integrated behavior, which in most cases is real-time dependent and has to be defined, validated, andverified at early product specification stages.

The following categories are within the scope of thesystems engineering application protocol [20]:

. products with conformity to the concept of a system;

. system definition data and configuration control datapertaining to the design and the validation phases ofa system’s development;

. requirements;

. functional analysis data including functional behav-ior specifications;

. physical architecture and synthesis data providing ahigh level view on the system under specification;

. elements that are used to represent and trace require-ments and the allocation of functions.

The ISO 10303-AP233 systems engineering applicationsprotocol consists of the following modules (Figure 9):system architecture; requirements; functional design;behavioral design; configuration management; physicaldesign/architecture; properties; graphics; data types.

The KARE requirement model that was built withinthe AP233 has taken into account the functional require-ments specification and input from projects, such asSEDRES, QCIM PM, and AP233 working group [20].The KARE formalized requirements model providespart of the information that is necessary to enable thecapabilities defined by the KARE knowledge model andby methodology. Since the AP233 EXPRESS model alsodefines relationships and constraints, some parts of themodel can be considered as knowledge entities. This isdue to the fact that the relationships and constraints alsoimply indirectly the operations or functions applied onthem. According to the KARE methodology, all entitiesof the requirements model represent the knowledgeobjects, while relationships and constraints indirectlydefine some parts of the object types. Further research iscurrently undertaken in extending the KARE require-ment model to include knowledge functions that embedthe KARE RE knowledge model.

The interfaces developed in the RE data serverenables the knowledge module to access the entitiesthat are stored and managed within the KARE REmodule.

6. System Implementation

The KARE knowledge model and methodology havebeen implemented in a prototype software ‘workbench’aimed at facilitating the RE activities performed bysystem engineers. The KARE ‘workbench’ utilizes thenewly proposed ISO STEP application protocol AP233[21] for data modeling and exchange. It has beendeveloped as a plug-in environment to the systemengineering tool DOORSTM [22]. It utilizes two pro-prietary packages, a requirement formalization tool


Demanda II [20] and a knowledge management toolWISDOMTM [23] that have been integrated to deliverthe key features of the KARE approach (Figure 10). Theutilization of the STEP file format allows the seam-less transfer of information between DOORSTM,WISDOMTM, and Demanda II whilst requirementsare being engineered.Figure 11 illustrates the menu list of the integrated

KARE environment within the system engineering toolDOORSTM. It shows the currently implemented elicita-tion, analysis, and data exchange modules, which aresupported by knowledge functions.The KARE model, methodology, and prototype

‘workbench’ have been validated through a number ofindustrial cases of collaboration between the customerand the supplier on defining a ‘baseline’ systemspecification for complex aerospace systems. Threetypes of RE activities have been supported:

. Supplier tasks These include definition of companyorganization, level of knowledge application by theproject team, role of RE, and use of related tools,methods for system architectural design;

. Customer–supplier exchange tasks These includeelicitation of high-level requirements, refinement

of requirements, suitability analysis, and baselinedefinition;

. Requirement and knowledge interface This includesdetermination of product range, system type, domainknowledge updates, definition of system raw price,delivery schedule, and missing/incomplete require-ments.

Although no formal and complete benchmarking toprevious products was possible due to the complexityand the uniqueness of the systems and the nature ofthe industry, the pilot applications presented an effec-tive way of testing different elements of the proposedmethodology. The results from the industrial validationof the KARE prototype ‘workbench’ have shownsignificant improvements in terms of accuracy andconsistency of requirements specification and reducedoverall lead time. The advantages of using the prototypeKARE ‘workbench’ were specifically evident in cases ofidentifying product types and suggesting key productrequirements not specified by the customer. The KARE‘workbench’ performed less efficiently in cases ofdefinition of validation requirements due to the limitedsize of the prototype knowledge base and requiredexpert-based decisions.

Support information

Engineering process

+uses

+provides

Generic model constructs

System architecture

+system architecture

+records process

+uses

+provides

Generic modelconstructs

Specification elements

+uses

+providesGeneric model constructs

+system specification elements

+recordsprocess

Processreference

+defined by

+assigned to

Presentation information Configuration management Administration information Data types

Requirement allocation Functional allocation

Requirements representation Physical architecture

Requirement allocation

Functional architecture

Requirement allocation Functional allocation

PropertiesExternal document Classification

Figure 9. The information model AP233 in a conceptual view.


Figure 10. KARE ‘workbench’ components and architecture.

Figure 11. Screenshot of the KARE ‘workbench’ prototype using DOORSTM.


7. Conclusions

The KARE methodology has been developed tosupport the sharing and reuse of knowledge in captur-ing, processing, and managing requirements in a one-of-a-kind environment. A new requirements engineering(RE) methodology has been developed that reflectsthe specific processes in specifying high-cost complexproducts. A key element of the reported research is theRE knowledge model that comprises task-, inference-,and domain-level knowledge categories specific tothe system engineering activities at the early productspecification stages.The KARE RE knowledge model and methodology

have been applied using industrial validation cases toillustrate the key benefits of the approach in terms ofimproved accuracy and consistency of requirementspecification, reduced number of iterations and as aresult, reduced overall lead time and cost of systemspecification.

Acknowledgments

This research is part of the KARE project funded bythe EU ESPRIT programe. The authors would also liketo gratefully acknowledge the contributions of allpartners to the research in the KARE project.

References

1. Stevens, R., Brook, P., Jackson, K. and Arnold, S. (1998).System Engineering, Coping with Complexity, HemelHempstead: Prentice Hall Europe.

2. Daugulis, A. (2000). Time Aspects in RequirementsEngineering: or Every Cloud has a Silver Lining,Requirements Engineering, 5(2): 137–143.

3. Zhu, H. and Jin, L. (2000). Scenario Analysis in anAutomated Tool for Requirements Engineering,Requirements Engineering, 5(1): 2–22.

4. Gaines, B.R. and Shaw, M.L.G. (1992). IntegratedKnowledge Acquisition Architectures, Journal ofIntelligent Information Systems, 1(1): 9–34.

5. Polanyi, M. (1967). The Tacit Dimension, London:Routledge & Kegan.

6. Popper, K.R. (1986). Objective Knowledge – AnEvolutionary Approach, Oxford: Oxford University Press.

7. Kotonya, G. and Sommerville, I. (1998). RequirementsEngineering: Processes and Techniques, Chichester: JohnWiley & Sons.

8. Overmeyer, S.P. (1999). A Methodology for ConstructingUser-Oriented Requirements Specifications for Large-ScaleSystems Using Electronic Hypermedia, RequirementsEngineering, 4(1): 1–18.

9. Hooks, I. (1990). Why Johnny can’t Write Requirements,In: Proceedings of AIAA Space Programs and TechnologiesConference, Huntsville, AL, pp. 25–28.

10. Lauesen, S. and Vinter, O. (2001). Preventing RequirementDefects: An Experiment in Process Improvement,Requirements Engineering, 6: 37–50.

11. Darlington, M.J. and Culley, S.J. (2002). Current Researchin the Engineering Design Requirement, Proceedings of theInstitute of Mechanical Engineers, Journal of EngineeringManufacture, 216B: 375–388.

12. Bray, I.K. (2002). An Introduction to RequirementsEngineering, Harlow, Essex (UK): Pearson EducationLtd. ISBN 0201 767929.

13. Stadzisz, P.C. and Henrioud, J.M. (1998). An IntegratedApproach for the Design of Multi-Product AssemblySystems, Computers in Industry, 36(1–2): 21–29.

14. Fliedl, G., Kop, C., Mayr, H.C., Mayerthaler, W. andWinkler, C. (2000). Linguistically Based RequirementsEngineering – The NIBA Project, Data & KnowledgeEngineering, 36(2): 111–120.

15. KARE, Knowledge Acquisition and Sharing forRequirement Engineering (KARE), ESPRIT Project No.28916, www.kare.org.

16. Ratchev, S., Urwin, E., Muller, D., Pawar, K.S. andMoulek, I. (2003). Knowledge based RequirementEngineering for One-of-a-kind Complex Systems,Knowledge-Based Systems, 16(1): 1–5.

17. Kang, K.C., Lee, K.W., Lee, J.Y. and Kim, G.J. (1998).ASADAL/SIM: An Incremental Multi-level Simulationand Analysis Tool for Real-time Software Specifications,Software-practice & Experience, 28(4): 445–462.

18. Wang, J. (1999). Fuzzy Outranking Approach to PrioritiseDesign Requirements in Quality Function Deployment,International Journal of Production Research, 37(4):899–916.

19. Schreiber, G., Akkermans, H., Anjewierden de Hoog, R.,Shadbolt, N., Van de Velde, W. and Wielinga, B. (2000)Knowledge Engineering and Management – TheCommonKADS Methodology, The MIT Press,Cambridge, Massachusetts, USA.

20. Muller, D., Heimannsfeld, K. and Muller, N. (2000).Requirements Engineering Knowledge Management basedon STEP AP233, In: ProSTEP Science Days ConferencePaper, 114–123.

21. McDonald, I. (2000). ISO TC184/SC4 N911: ApplicationReference Model for the Exchange of System EngineeringData, ISO TC184/SC4 Document.

22. DOORSTM, Quality Systems & Software Ltd., UK, 1998,www.telelogic.com.

23. WISDOMTM, Arthur Andersen Business Consulting,Holland, 1997, www.arthurandersen.com.

Dr Svetan Ratchev

Dr Ratchev is the Readerin Precision Manufacturingand head of the PrecisionManufacturing Group inthe School of Mechanical,Materials and ManufacturingEngineering at the Universityof Nottingham in the UK.Dr Ratchev is a CharteredEngineer and Member ofthe Institution of Electrical


Engineers. He has 20 years of relevant researchexperience in modeling, integration, and reengineeringof reconfigurable manufacturing systems, collaborativeproduct design and manufacture, knowledge-basedsystems in manufacturing, precision machining, andmicroassembly. He has published over 100 articles andhas actively participated in a number of internationalconferences and seminars. He is the founding chair ofthe International Precision Assembly Seminar (IPAS).

Professor Kulwant S. Pawar

Professor Pawar is theDirector of the Centre forConcurrent Enterprise andProfessor of OperationsManagement at the Universityof Nottingham BusinessSchool. He has over 10 yearsindustrial experience in pro-duct design and development,manufacturing engineering,and managerial environment

in large multinational firms. His research interestsinclude managing new product design, linkages betweenproduct development and supply chain, managing designteams in virtual enterprises, organizational readiness fornew product development, knowledge transfer and sharein the extended enterprise. He has published almost 200

articles and actively participated in a number ofinternational conferences. He is the founder andChairman of the International Symposium on Logistics(ISL) and Co-chairman of the International Conferenceon Concurrent Enterprising (ICE). He is Editor-in-Chiefof the International Journal of Logistics: Research &Application. He is the Coordinator of the ConcurrentEnterprising Network of Excellence (CE-NET) inEurope.

Dipl.-Ing. Dirk Muller

Dipl.-Ing. Dirk Muller is aresearch engineer working atthe Technical University ofClausthal in Germany. Hespecializes in requirementsengineering and design datamodeling. Dirk was bornin 1969 and graduated fromthe Technical University ofClausthal in 2000. Sincethen he has been workingas a Research Engineer in a

number of national and international projects. In theKARE project, Dirk was responsible for developingthe requirements data model and had contributed tothe development of STEP AP 233.


Knowledge-enriched Requirement Specification for One-of-a ...

Documents

Transcript of Knowledge-enriched Requirement Specification for One-of-a ...