- Email: [email protected]
Formalized specification of functional requirements
Formalized specification of functional requirements K Jakobsen, J Sigurj6nsson and ~ Jakobsen Division of Machine Design, University of Trondheim, The Norwegian Institute of Technology, N-7034, Trondheim, Norway
With the increasing use of the computer as a design aid, the need for new software products is increasing rapidly. Computer aids for the conceptual phase of the design process are now emerging. A basic problem in making design aids for this phase is to formulate the functional requirements in a way suitable for computer processing. In this paper, an approach to solving this task is presented. These functional requirements (FRs) are formulated as a set of verb-noun pairs. A thesaurus will define the set of verbs and nouns applicable in the definitions of the FRs and a synonym table will be available, to aid the user in finding appropriate words within the thesaurus. For further processing of the FRs a classification system for verbs and nouns is proposed. The classification is based on object oriented programming languages. Keywords: computer-aided design, functional requirements In recent years there has been growing interest in design methodology. One of the reasons is the rapid evolution of computer technology and the common use of computers in engineering applications. Therefore, the need for a theoretical base for the conceptual phase has become more obvious. Such a theoretical base is the prerequisite for successful development of computer tools for use in the preliminary steps of design. Some of the current research projects in this field, are discussed elsewhere 1'2. Design problems are by nature ill structured problems and most of the experiments with computer systems for use in preliminary design have been a limited success. By limited we mean that all the reported applications deal with a narrow line of products and are not yet commercially available. The ideas presented in this paper deal with requirement specifications independent of a special category of design problems. They are a contribution to the work of establishing a general theoretic framework for conceptual design.
Vol 12 No 4 October 1 9 9 1
FUNCTIONAL REQUIREMENTS Background The function is here defined as 'what the product (or component or part) shall perform, or do or be, in other words: the problem set'. Reference is also made to theory of technical systems3, and also to the well known technique of value analysis. In Ref. 4 Jakobsen suggests the following structure for the basic specification of a design problem. • Functional requirements: a list of functions to be accomplished • Evaluation criteria: criteria for ranking and selecting design proposals • Boundary conditions: external conditions that must be fulfilled by the solution
0142-694X/91/04221-04 © 1991 Butterworth-HeinemannLtd
221
STATE 1
Volume = V1 Inputd Temperature = v] Position = P1
STATE 2 T1
Volume = V2 Transformation _J T e m p e r a t u r e = T2
I
I etc...
q Position = P2 [etc...
]
d
Control
Figure 1
Transformation from State 1 to State 2
Specifications of functions Functional requirements are to be expressed as pairs o f a transitive verb and a noun. The task to be carried out is determined by the combined verb-noun pair and their attributes. The functions must be formulated independent of solutions, and of each other (orthogonal functions). A thesaurus will define the system boundaries, i.e. the 'vocabulary' of the verbs and nouns. An accompanying list of synonyms will aid the user in formulating his function in the terms included in the thesaurus.
State notation The concepts of state and change are parts of the underlying ideas for the classification of functional requirements presented here. A state is a snapshot of the world at an incident. At different points in time the world can be in different states 5. In this context a state will contain the description of the technical system in question and its relevant environments. The state description will generally consist of a list of properties and their values. The number and nature of these properties will vary, according to the degree of abstraction and the resolution in each case. The function of a technical system can then be viewed as a change from one state to another state, i.e. a transformation in state space (Figure 1). It is found necessary to distinguish between the transformation and control of the state variables. The verb-noun pair, may be regarded as operator(operand), the operator being defined by the verb and the noun will represent a state variable, i.e. operand.
CLASSIFICATION
based system, to be used as a design aid, is the classification hierarchy for words and terms. Even with the most creative implementation of the user interface, the system will have to recognize and manipulate information expressed with words. Such a module has the role of identifying and interpreting the text input from the user and informing the user of the terms used as keywords, in various parts of the system. In addition to handling the input of the specifications (problem definition) the module must also handle words and terms related to the solutions of design problems. Terms describing form, material, manufacturing process, technical principles etc.. In the following, the classification of words is related to the formulation of functional requirements. The classification system presented is not a grammatical one. It is based on the technical interpretation of the word in question. Important criteria are degree of abstraction and technical relationship. The attributes assigned to one class, are inherited by all subclasses of that class. General attributes assigned to both verb and noun and by that common to all wordclasses are such as: German translation, French translation, description and comment. Examples of specific attributes are shown later in the paper. The following guidelines are important, in the process of building a classification hierarchy for words. • when possible, a word shall appear only once in the hierarchy • words can be allocated to classes on all levels • a word is allocated to a class on lowest possible level. If a word naturally belongs in other classes then the word should be placed in the common superclass • when a word is ambiguous, i.e. has more than one technical interpretation it must be placed in all the potential classes.
Verb In the verb/noun pair, the verbs indicates the operation and the noun the object or operand. The verbs are classified according to the character in the operation in three main classes as shown in Figure 2. Attributes of the verb are not treated explicitly here, only a short description of the classes is given. How to handle the operational attributes of the verb is a subject for further research work. The classes in Figure 2 are as follows:
The classification hierarchy proposed here follows the same line of thought as in object oriented programming (OOP) languages, such as Smalltalk and C + + . An important feature is the inheritance of attributes (maybe also attribute values) and methods, from a superclass to a subclass. For more details on OOP see Refs. 6 or 7.
Transformation: This class represents the actions/ operations that effect the change from one state to another. Three subclasses have been defined, depending on the nature of the effects on the operand.
Classification of words
• Process: changes of geometry or form of the operand.
• Change: changes in the internal state of the operand.
Verbs like: increase, heat
One of the building blocks of an 'intelligent' computer
222
This class has subclasses o Coupling verbs like: couple, divide, tie, . . .
DESIGN STUDIES
/Change / /Coupling . Transformation~--~Process / ~ ~Working "Movement / Verb~
~Active Control~ P a s s i v e
Generation Figure 2 A simplified example of a classification hierarchy for verbs o Working
verbs like: drill, machine, squeeze,
• Movement: change of position or alignment of the operand Control: this class represents the actions/operations that control or measure the properties of one state or the changes of the properties in the transformation from one state to another. We discriminate between active control: regulate, store, s t e e r , . . , and passive control: measure, analyse, count, . . . Generation: examples are: provide, give, g e n e r a t e , . . .
Nouns The nouns are divided into four main classes as shown in Figure 3. The first two classes relate to properties of the product or the involved environment or properties of a part of the product. Qualitative noun: This class shall represent the properties' that are not measureable on some universally accepted scale. E.g: quality, comfort, fashion, odour, etc• Attributes are scale, indicating the scale used, and value indicating the limiting value for requirements and the assigned value after evaluation of a solution proposal. The scale used can as an example be the integers from 0 to 4, or a user defmed value function. This class is maybe not necessary for description of functional requirements. But these properties are useful for setting up the evaluation criteria (see earlier section). Quantitative noun: This class represents properties that can be related to an accepted unit or scale. For physical and mechanical properties the SI system is an adequate basis• Regarding cost (the single most important property) the US dollar seems a good choice at present. Attributes are unit, and upper- and lower limit that will hold required boundary values for the property. A module for automatic conversion of the units input by the user to the internal SI representation is suggested in this context. The most common abbreviations should also be recognized. The third and fourth classes refer to the product or the environment. The objective referred can also be a part of the product or the environment.
Vol 12 No 4 October 1991
Concrete noun: this class represents artifacts or objects from the real world• Examples are: fish, rock, steel, person, floor, chair, car, . . . Conceptual noun: this class contains abstract concepts like: program, system, method, result, . . .
The class of function The description of a function consists basically of the verb-noun pair with the attributes connected to the verb and the noun. Furthermore, some attributes can only be related to the function as a whole. Consider the following three basic characteristics of a function from 4. • Complexity: a measure of the degree of resolution. Elementary functions that cannot be resolved further comprise the lowest degree • Degree of abstraction: Each function may be described at various levels from concrete to abstract. This influences the number of possible means to realize the function • Category of purpose: the transformation function that fulfills the purpose of the technical system is accompanied by a series of additional functions: auxiliary, driving and energy delivery, regulating and controlling, connecting and supporting The first and the second of these can be expressed with a single value related to the function. They are attributes of the function. The third, category of purpose implies a hierarchy of functions, similar to our hierarchy of verbs in the previous section. Therefore we propose a single class of functions with the following attributes. • • • •
verb (a verb known in the classification hierarchy) noun (a noun known in the classification hierarchy) degree of resolution (complexity) degree of abstraction
With this notation we also have access to the information bound to the verb and noun.
APPLICATIONS A good definition of a design problem is an important landmark on the way to a successful solution. The
/Length .,,,.Angle ~.lWidth / ~ Dimension~Height - - Quantitative~ Area ~ Thickness • ~ ~Volume ~etc. Noun~ ~ Force N,~Concrete "etc. /
•Qualitative
Conceptual Figure 3 A simplified example of a classification hierarchy for nouns
223
definition must be specific enough to make the objective clear and broad enough so that the solution space is not too limited. A classification hierarchy like the one presented here will be a useful tool for investigating the boundaries of the solution space 8. By traversing the hierarchy up or down we respectively increase or decrease the number of possible solutions. An ideal product model should represent both the resulting design and a description of the process and decisions leading to that design. It should be possible to trace the process and find the underlying reasons for each feature of the result. Tools for systemizing the specifications from the very beginning are essential to realise this task.
CONCLUSIONS In the first phases of a design process, much of the work is built on the linguistic description of the task. A computer system with the purpose to aid the designer in the design process and log the decisions, must include tools to handle the users input from the very beginning. The work presented here accesses some of the difficulties in building such a system. The future challenge is to establish the theory for a general system for handling the words and terms that are a necessary ingredient in the process of design. Important features of such a system must be a thesaurus and a synonym table a module for recognising and interpreting the users input. A synonym table will be a part of this module
224
• a classification hierarchy fpossibly different h l e r a r chies for different purposes) • a specifications module (including functional requirements) • a solution module
REFERENCES Andreasen, M M and Hansen, C T, Development of a knowledge-based design-system, Institute of Engineering Design Technical University of Denmark, 1990 (in Danish) Akman, V, ten Hagen, P J W and Tomiyama, T, A fundamental and thereotical framework for an intelligent CAD system, Computer-aided Design Vol 22, No 6, (1990) 3 Hubka, V and Eder, W E, Theory of Technical Systems, Springer-Verlag, New York (1988) Jakobsen, K, Functional requirements in the design process, Modern Design Principles, Tapir, Trondheim (1988) pp 41-53 Geneseret, M R and Nilsson, N J, Logical foundations of artificial intelligence, Morgan Kaufmann Publishers Inc. Los Altos (1987) 6 Small talk/V 286, Tutorial And Programming Handbook, Digitalc Inc., Los Angeles, (1988) 7 Dewhurst, S C and Stark, K T, Programming in C+ +, Prentice Hall Inc., New Jersey, (1989) McMahon, E H, 'Structured boundary examination' In WDK 18 - Proceedings of ICED 89, Harrogate, Institution of Mechanical Engineering, London, pp 597-604.
DESIGN STUDIES
With the increasing use of the computer as a design aid, the need for new software products is increasing rapidly. Computer aids for the conceptual phase of the design process are now emerging. A basic problem in making design aids for this phase is to formulate the functional requirements in a way suitable for computer processing. In this paper, an approach to solving this task is presented. These functional requirements (FRs) are formulated as a set of verb-noun pairs. A thesaurus will define the set of verbs and nouns applicable in the definitions of the FRs and a synonym table will be available, to aid the user in finding appropriate words within the thesaurus. For further processing of the FRs a classification system for verbs and nouns is proposed. The classification is based on object oriented programming languages. Keywords: computer-aided design, functional requirements In recent years there has been growing interest in design methodology. One of the reasons is the rapid evolution of computer technology and the common use of computers in engineering applications. Therefore, the need for a theoretical base for the conceptual phase has become more obvious. Such a theoretical base is the prerequisite for successful development of computer tools for use in the preliminary steps of design. Some of the current research projects in this field, are discussed elsewhere 1'2. Design problems are by nature ill structured problems and most of the experiments with computer systems for use in preliminary design have been a limited success. By limited we mean that all the reported applications deal with a narrow line of products and are not yet commercially available. The ideas presented in this paper deal with requirement specifications independent of a special category of design problems. They are a contribution to the work of establishing a general theoretic framework for conceptual design.
Vol 12 No 4 October 1 9 9 1
FUNCTIONAL REQUIREMENTS Background The function is here defined as 'what the product (or component or part) shall perform, or do or be, in other words: the problem set'. Reference is also made to theory of technical systems3, and also to the well known technique of value analysis. In Ref. 4 Jakobsen suggests the following structure for the basic specification of a design problem. • Functional requirements: a list of functions to be accomplished • Evaluation criteria: criteria for ranking and selecting design proposals • Boundary conditions: external conditions that must be fulfilled by the solution
0142-694X/91/04221-04 © 1991 Butterworth-HeinemannLtd
221
STATE 1
Volume = V1 Inputd Temperature = v] Position = P1
STATE 2 T1
Volume = V2 Transformation _J T e m p e r a t u r e = T2
I
I etc...
q Position = P2 [etc...
]
d
Control
Figure 1
Transformation from State 1 to State 2
Specifications of functions Functional requirements are to be expressed as pairs o f a transitive verb and a noun. The task to be carried out is determined by the combined verb-noun pair and their attributes. The functions must be formulated independent of solutions, and of each other (orthogonal functions). A thesaurus will define the system boundaries, i.e. the 'vocabulary' of the verbs and nouns. An accompanying list of synonyms will aid the user in formulating his function in the terms included in the thesaurus.
State notation The concepts of state and change are parts of the underlying ideas for the classification of functional requirements presented here. A state is a snapshot of the world at an incident. At different points in time the world can be in different states 5. In this context a state will contain the description of the technical system in question and its relevant environments. The state description will generally consist of a list of properties and their values. The number and nature of these properties will vary, according to the degree of abstraction and the resolution in each case. The function of a technical system can then be viewed as a change from one state to another state, i.e. a transformation in state space (Figure 1). It is found necessary to distinguish between the transformation and control of the state variables. The verb-noun pair, may be regarded as operator(operand), the operator being defined by the verb and the noun will represent a state variable, i.e. operand.
CLASSIFICATION
based system, to be used as a design aid, is the classification hierarchy for words and terms. Even with the most creative implementation of the user interface, the system will have to recognize and manipulate information expressed with words. Such a module has the role of identifying and interpreting the text input from the user and informing the user of the terms used as keywords, in various parts of the system. In addition to handling the input of the specifications (problem definition) the module must also handle words and terms related to the solutions of design problems. Terms describing form, material, manufacturing process, technical principles etc.. In the following, the classification of words is related to the formulation of functional requirements. The classification system presented is not a grammatical one. It is based on the technical interpretation of the word in question. Important criteria are degree of abstraction and technical relationship. The attributes assigned to one class, are inherited by all subclasses of that class. General attributes assigned to both verb and noun and by that common to all wordclasses are such as: German translation, French translation, description and comment. Examples of specific attributes are shown later in the paper. The following guidelines are important, in the process of building a classification hierarchy for words. • when possible, a word shall appear only once in the hierarchy • words can be allocated to classes on all levels • a word is allocated to a class on lowest possible level. If a word naturally belongs in other classes then the word should be placed in the common superclass • when a word is ambiguous, i.e. has more than one technical interpretation it must be placed in all the potential classes.
Verb In the verb/noun pair, the verbs indicates the operation and the noun the object or operand. The verbs are classified according to the character in the operation in three main classes as shown in Figure 2. Attributes of the verb are not treated explicitly here, only a short description of the classes is given. How to handle the operational attributes of the verb is a subject for further research work. The classes in Figure 2 are as follows:
The classification hierarchy proposed here follows the same line of thought as in object oriented programming (OOP) languages, such as Smalltalk and C + + . An important feature is the inheritance of attributes (maybe also attribute values) and methods, from a superclass to a subclass. For more details on OOP see Refs. 6 or 7.
Transformation: This class represents the actions/ operations that effect the change from one state to another. Three subclasses have been defined, depending on the nature of the effects on the operand.
Classification of words
• Process: changes of geometry or form of the operand.
• Change: changes in the internal state of the operand.
Verbs like: increase, heat
One of the building blocks of an 'intelligent' computer
222
This class has subclasses o Coupling verbs like: couple, divide, tie, . . .
DESIGN STUDIES
/Change / /Coupling . Transformation~--~Process / ~ ~Working "Movement / Verb~
~Active Control~ P a s s i v e
Generation Figure 2 A simplified example of a classification hierarchy for verbs o Working
verbs like: drill, machine, squeeze,
• Movement: change of position or alignment of the operand Control: this class represents the actions/operations that control or measure the properties of one state or the changes of the properties in the transformation from one state to another. We discriminate between active control: regulate, store, s t e e r , . . , and passive control: measure, analyse, count, . . . Generation: examples are: provide, give, g e n e r a t e , . . .
Nouns The nouns are divided into four main classes as shown in Figure 3. The first two classes relate to properties of the product or the involved environment or properties of a part of the product. Qualitative noun: This class shall represent the properties' that are not measureable on some universally accepted scale. E.g: quality, comfort, fashion, odour, etc• Attributes are scale, indicating the scale used, and value indicating the limiting value for requirements and the assigned value after evaluation of a solution proposal. The scale used can as an example be the integers from 0 to 4, or a user defmed value function. This class is maybe not necessary for description of functional requirements. But these properties are useful for setting up the evaluation criteria (see earlier section). Quantitative noun: This class represents properties that can be related to an accepted unit or scale. For physical and mechanical properties the SI system is an adequate basis• Regarding cost (the single most important property) the US dollar seems a good choice at present. Attributes are unit, and upper- and lower limit that will hold required boundary values for the property. A module for automatic conversion of the units input by the user to the internal SI representation is suggested in this context. The most common abbreviations should also be recognized. The third and fourth classes refer to the product or the environment. The objective referred can also be a part of the product or the environment.
Vol 12 No 4 October 1991
Concrete noun: this class represents artifacts or objects from the real world• Examples are: fish, rock, steel, person, floor, chair, car, . . . Conceptual noun: this class contains abstract concepts like: program, system, method, result, . . .
The class of function The description of a function consists basically of the verb-noun pair with the attributes connected to the verb and the noun. Furthermore, some attributes can only be related to the function as a whole. Consider the following three basic characteristics of a function from 4. • Complexity: a measure of the degree of resolution. Elementary functions that cannot be resolved further comprise the lowest degree • Degree of abstraction: Each function may be described at various levels from concrete to abstract. This influences the number of possible means to realize the function • Category of purpose: the transformation function that fulfills the purpose of the technical system is accompanied by a series of additional functions: auxiliary, driving and energy delivery, regulating and controlling, connecting and supporting The first and the second of these can be expressed with a single value related to the function. They are attributes of the function. The third, category of purpose implies a hierarchy of functions, similar to our hierarchy of verbs in the previous section. Therefore we propose a single class of functions with the following attributes. • • • •
verb (a verb known in the classification hierarchy) noun (a noun known in the classification hierarchy) degree of resolution (complexity) degree of abstraction
With this notation we also have access to the information bound to the verb and noun.
APPLICATIONS A good definition of a design problem is an important landmark on the way to a successful solution. The
/Length .,,,.Angle ~.lWidth / ~ Dimension~Height - - Quantitative~ Area ~ Thickness • ~ ~Volume ~etc. Noun~ ~ Force N,~Concrete "etc. /
•Qualitative
Conceptual Figure 3 A simplified example of a classification hierarchy for nouns
223
definition must be specific enough to make the objective clear and broad enough so that the solution space is not too limited. A classification hierarchy like the one presented here will be a useful tool for investigating the boundaries of the solution space 8. By traversing the hierarchy up or down we respectively increase or decrease the number of possible solutions. An ideal product model should represent both the resulting design and a description of the process and decisions leading to that design. It should be possible to trace the process and find the underlying reasons for each feature of the result. Tools for systemizing the specifications from the very beginning are essential to realise this task.
CONCLUSIONS In the first phases of a design process, much of the work is built on the linguistic description of the task. A computer system with the purpose to aid the designer in the design process and log the decisions, must include tools to handle the users input from the very beginning. The work presented here accesses some of the difficulties in building such a system. The future challenge is to establish the theory for a general system for handling the words and terms that are a necessary ingredient in the process of design. Important features of such a system must be a thesaurus and a synonym table a module for recognising and interpreting the users input. A synonym table will be a part of this module
224
• a classification hierarchy fpossibly different h l e r a r chies for different purposes) • a specifications module (including functional requirements) • a solution module
REFERENCES Andreasen, M M and Hansen, C T, Development of a knowledge-based design-system, Institute of Engineering Design Technical University of Denmark, 1990 (in Danish) Akman, V, ten Hagen, P J W and Tomiyama, T, A fundamental and thereotical framework for an intelligent CAD system, Computer-aided Design Vol 22, No 6, (1990) 3 Hubka, V and Eder, W E, Theory of Technical Systems, Springer-Verlag, New York (1988) Jakobsen, K, Functional requirements in the design process, Modern Design Principles, Tapir, Trondheim (1988) pp 41-53 Geneseret, M R and Nilsson, N J, Logical foundations of artificial intelligence, Morgan Kaufmann Publishers Inc. Los Altos (1987) 6 Small talk/V 286, Tutorial And Programming Handbook, Digitalc Inc., Los Angeles, (1988) 7 Dewhurst, S C and Stark, K T, Programming in C+ +, Prentice Hall Inc., New Jersey, (1989) McMahon, E H, 'Structured boundary examination' In WDK 18 - Proceedings of ICED 89, Harrogate, Institution of Mechanical Engineering, London, pp 597-604.
DESIGN STUDIES