- Email: [email protected]
Managing requirements as the core of multi-disciplinary product development
CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
Contents lists available at ScienceDirect
CIRP Journal of Manufacturing Science and Technology journal homepage: www.elsevier.com/locate/cirpj
Managing requirements as the core of multi-disciplinary product development C. Stechert *, H.-J. Franke Institute for Engineering Design, Technische Universita¨t Braunschweig, Germany
A R T I C L E I N F O
A B S T R A C T
Article history:
This paper shows a methodology that brings existing approaches of requirements management together in a reasonable context. It supports communication between different disciplines and therefore helps identifying important requirements and relations between requirements from different domains. That is crucial in early phases of the design process and in later phases. Not less crucial is to bring early and later phases together by predicting possible changes and by estimating the presumable impact. Thence, the managing of requirements can be seen as the core of successful multi-disciplinary product development. A short example from the field of parallel robots is given. ß 2008 CIRP.
Available online 5 November 2008 Keywords: Requirements management Design methodology Parallel robots
1. Introduction The overall goal of product development is to satisfy customer needs and wishes as well as to meet the own enterprise strategy. To reach this goal it is important to identify the customer requirements (latent and externalized) and requirements from different departments (marketing, project management, mechanical/electronic/software design, sales, support) and suppliers (raw materials, bought-in parts, service/consulting). As the customer is mostly interested in low prices and high qualities, the manufacturer is more likely interested in high returns and enhancement of prestige. He has to reduce costs (e.g. by implementing modular systems, by installing new technologies), shorten the time-tomarket and develop innovations to produce customer enthusiasm or to create new markets. Coming from different domains several approaches like ‘‘customer oriented axiomatic design’’, ‘‘systems engineering with SysML’’, ‘‘extended QFD charts’’ are already known, but often too complex, too complicated or poorly adapted to the special needs of the branch, the specific enterprise and/or the specific product. So they are rarely implemented in practical work especially of small and medium-sized enterprises. When methods are not used at the right time and/or in the right context they are useless and the acceptance decreases. In addition they often just show one side (one domain) of the development process. The main question is: How to conduct information and to ensure consistency? A methodology has to support communication between different disciplines and to identify the important
* Corresponding author. Tel.: +49 531 391 3349; fax: +49 531 391 4572. E-mail address: [email protected] (C. Stechert). 1755-5817/$ – see front matter ß 2008 CIRP. doi:10.1016/j.cirpj.2008.09.008
requirements and relations between requirements from different domains. That is very crucial in the early phases of the design process (more or less qualitatively) and in the later phases (quantitatively on the basis of product models). Not less crucial is to bring early and later phases together by predicting possible changes and by estimating the presumable impact. Thence, the managing of requirements can be seen as the core of successful multi-disciplinary product development. 2. Managing requirements From established publications [1], prevailing textbooks [2], as well as new contributions at pertinent conferences [3], the need and importance to clarify the design task at the very beginning is gathered. Although companies feel to develop what their customers’ need, their development process is often slowed down and characterised by changes [3] that are followed by large iteration loops. A set of requirements should be functional, comprehensive, complete, operational, non-redundant and minimal before the search for solution starts [4]. But requirements often cannot be fixed that early. A too early fixing hinders innovation, because auspicious alternatives were not observed at all. A too large (and unfavourable not or bad structured) database of requirements cannot be handled properly in the following development steps. In [5] it was stated that just ideation supporting specification statements should be taken into consideration for early conceptual design work. Moreover, the consistency is not easy to determine in the early phases, when no or just a rough concept is defined. Nevertheless, the certain identification of goal conflicts is a factor of success for the development process and the product to be developed.
154
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
Coming from different domains the definition of a requirement is slightly different. Even within the same domain but different authors the description differs. The common denominator is that a requirement describes something that the product should fulfil to be successful on the market. This can be described by the theory of affordances [6] where a product should provide positive and must not provide negative affordances. Another approach hierarchically separates the product into properties and characteristics [7]. Characteristics (e.g. shape, material) can be directly influenced by the designer whereas properties (e.g. weight) change due to the change of characteristics. Therefore the modelling of relations is important to know what exactly a designer should create to meet the desired properties. In [8,9] approaches were shown to integrate requirements handling into a holistic product development process. In information technology a well-known approach is to distinguish requirements between functionality, usability, reliability, performance and supportability [10]. In [11] additionally the certainty of requirements was analysed. A usual approach in mechanical engineering is to distinguish whether a requirement is fixed, limited or a wish [12]. Requirements can be assigned to different life-cycle phases (e.g. operation, maintenance), different parts and different views. In [13] it was shown how to structure requirements to the needs of the development task. 2.1. Requirements modelling The modelling of requirements has been a research topic for years. In [14] an overview of related work was given. This paper just focuses on some useful approaches and discusses them in relation to the phases of the development process and the knowledge domains involved. In early phases normally no concrete statements can be made, because the final relations depend on the final realisation of the complete system. In addition, for a complex system some characteristics cannot be forecasted certainly even not in later phases or if virtual prototype techniques are used (e.g. haptics). Since the input data of a method is uncertain the outcomes cannot be seen as certain. Thus the correctness and certainty of requirements data have to be refined and controlled while advancing in the development process. A tool to visualise the existing expert knowledge regarding targets, to help finding possible relations between product characteristics, and to identify strategy points was presented in [15]. It consists of a multidimensional scaling on the basis of pairwise comparison of targets by a group of experts. The targets are visualised in a 3D-space so that supporting targets aggregate and conflicting targets separate. A possible, not yet implemented, extension may provide that if for some conflicting targets the underlying characteristics were known, multidimensional coordinates with skew axes could be drawn. This would allow finding dependencies between characteristics. To model relations on system level one possible approach is the UML extension SysML that is provided by several commercial modelling tools. OMG SysML v1.0 was issued as Available Specification in September 2007 [16] and provides a common basis, so a better exchangeability, to describe requirements, as well as structure (e.g. blocks, packages, constraints) and behaviour (e.g. activities, use cases). So far SysML mainly focuses on the needs of software and electric development, but new profiles containing new classes and stereotypes can be generated for customisation. All relations can be visualised in diagrams and formatted to desired views. From these models requirements lists and traceability matrices can be generated.
The more traditional use of requirements lists [12,17] is supported by a variety of commercial (e.g. DOORS) and scientific [18] tools. They provide amongst others the documentation (particularly the generation of specification sheets), version checking (e.g. baseline, fulfilment control) and linking of requirements. The latter is normally a qualitative linking sometimes with scaling (positive and negative relation). An impact analysis allows identifying indirect relations on the basis of known requirements, hence so far undiscovered goal conflicts. Within the design phase the well-established methods of Quality Function Deployment (QFD) are easy-to-use tools to qualitatively map objects (e.g. requirements, functions, effect principles) to each other. This and other approaches use matrices [19,20]. The obtaining of initial relations is in practice often questionable and can lead to useless outcomes. On the basis of the initial direct relations indirect relations can be identified [14,18]. Where important relations were identified the use of more complicated methods can be used. These are more linked up to physical reality than to expert experience. Such methods base on mathematical models. One approach is to find the relevant physical equations, identify the input and output parameters as well as necessary empirical knowledge (e.g. material constants) and relate the corresponding parameters [19]. Equations can be transformed into similarity ratios. These allow integrating a direction of optimisation for special parameters by assigning them to nominator or denominator. These ratios are connected via graph theory, so that the resulting graph describes the goal function of the subsystem and goal conflicts are identified on a physical basis [21]. The whole model can be used as a pattern for the development of new products. If the early goals were nearly the same as for the pattern the differences in targets could be traced to the requirements and to the specific structural components. A meaningful starting point for variation and/or optimisation is identified. Moreover, the impact this change will have on those goals that should not be changed is detectable. On the other hand the impact a technological push (development of a new not yet implemented technology) has on an existing system can be identified and the worthiness to follow up research in this area can be estimated. In addition, research fields (e.g. to solve goal conflicts) can be found and the convenient amount of labour to be spent can be estimated. 2.2. Product development process Requirements accompany the whole product life-cycle in different manifestations, whereas the early design fixes the better part of costs not only for manufacturing and operation but also for potential reconfigurations and end-of-life treatment. Thence, they have to be considered as a part of the product model and processed during product development [22]. Fig. 1 shows the product development process in the style of the V-model, cp. [23], with different manifestations of requirements added to the process schema. As long as the product surroundings are not fully clarified and the principal design of the product is not well concretised just some uncertain goals can be stated. From these goals fuzzy targets derive that depend on the different views of the involved persons: customer (product buyer, product user) and manufacturer (e.g. management, sales or different design departments). These targets often cannot be quantified to detail—just a range or limits and restrictions (e.g. existing manufacturing methods in the enterprise) can be specified. But it allows choosing a strategy and rough concept (e.g. kinematic principle). However, as far as a customer inquiry
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
155
ordering enterprise. Another possible reason is a new order that bases on an existing solution, but has to be changed to meet the targets of that special order. Here the existing requirements structure can be used to identify appropriate starting points for variation (e.g. when using a modular system [24]) or optimisation [25]. The set into operation at the customer’s site is the crucial step where the final design is adapted to the intended surroundings. 2.3. Relation types
Fig. 1. Requirements in the product development process.
does not often lead to an order it would be unreasonable to invest too many resources into detailing. But if the offer based on too uncertain goals it could lead to risky promises according to schedule, pricing and performance. On the other hand while refining goals to targets the real latent customer wishes can be discovered, so that the risk of a later change decreases. The concept is further modelled on system and subsystem level [24]. The main set of requirements deals with the whole system. These should result from an elaborate discussion between user and manufacturer. The complex system consists of multi-disciplinary parts distinguished into subsystems. For each subsystem (and subsubsystems, respectively) a specific set of requirements can be stated that can often be more concrete than that of the higher level and becomes more detailed as the development process moves further. As in the other steps requirements are related. Even if some subsystems could be delimited to just one knowledge domain, it has in- and output parameters so that an impact on other subsystems follows. Hence, the modelling of relations is extremely important. During design requirements are the guidelines to develop the desired product. From requirements functions structures are developed, functions structures lead to effect principles and so forth. Normally several iteration loops are necessary to implement the subsystems into one system. Thence, the following steps cannot be seen as a strict sequence. But a good clarification, documentation and a valuable assistance to handle and easily access the important requirements for that specific design task is essential to avoid unnecessary iteration loops. Thence, the concretion, fulfilment and perhaps change should be carefully observed and documented. Especially in the domain of electronics and software development test specifications play a big role to validate and verify design. For a mechatronic product testing of the whole system is of importance to guarantee the desired specifications. Recently more and more Original Equipment Manufacturers (OEMs) force their suppliers to guarantee Total Cost of Ownership (TCO), e.g. of tooling machines so that they can be charged, if it does not reach the desired efficiency. Thence, test specifications have to cover the customer’s targets. Moreover, in traditional mechanical design the concept evaluation was and is the key factor to narrow the field of possible solutions down. So the evaluation or testing is a gateway, design concepts have to pass in their different levels of concretion during the design process. The next step in the development process is a change or optimisation of design. In difference to the above-mentioned ‘‘normal’’ iteration loops this can also be a change of the initial requirements. A possible reason is a sudden strategy change of the
Relations can be classified to what and how they relate objects (abstract entities, e.g. parts, parasitic effects, requirements). These relation types are not mutual exclusionary, e.g. a negative relation can be defined quantitatively. Table 1 shows seven identified types of relations in a condensed form. A more precise description follows in the text. If the objects were not related following these relation types they could be seen as independent, i.e. two independent objects have no impact on each other. Relations associated to the development process: Goal-to-target relations describe the refining path from very general and uncertain goals to more precise targets. The documentation of these relations helps to redefine targets when goals change. When contradictoriness of targets is detected it shows which goals may not be satisfied. Target-to-requirement relations describe a refining path from the more or less interdisciplinary linked targets to requirements that can be stated more precisely and (on subsystem level) decoupled. Requirement-to-requirement relations can be seen as a kind of part-to-part relation where a requirement is an abstract part of the requirements structure. Direct relating a requirement to another is difficult, because the coupling is mostly indirect involving, e.g. a mechanical part. Requirement-to-product-surrounding relations are auxiliary to trace the impact the product surrounding (e.g. neighbouring
Table 1 Types of relations. Development steps Goal-to-target Target-to-requirement Requirement-to-requirement Requirement-to-product-surrounding Requirement-to-component Requirement-to-test-specification Granularity System-to-system Part-to-part Part-to-system Causal If-then Support Positive Negative Exclusionary Direction Unidirectional Mutual Linking Direct Indirect Quantifiability Qualitative Quantitative
156
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
systems, weather conditions, use-cases) has on the requirements thence on the design. Requirement-to-component relations describe a mapping of which component (e.g. a drive or software module) satisfies or aids to satisfy a requirement. The requirement-to-test-specification relation describes which requirement (and therefore which goal) can be verified or validated by what test or evaluation criterion. Regarding virtual prototypes and rapid prototyping most verifications and validations can be made early and changes due to the validation process can be implemented fast and at relatively low costs. The granularity describes the hierarchy of related objects [26]. A system can be both an assembly of parts and – more abstract – a group of abstract objects like requirements, functions or use- and test-cases. Moreover surrounding systems (e.g. component supply for automated assembly, weather conditions) have to be considered, too: A system-to-system relation exists between two self-contained systems (e.g. modules of a modular system). Interfaces can be clearly defined and change impact can be forecasted or even avoided by using ‘‘propagation blocker’’ like adapter. Part-to-part relations exist either between different parts of the same system or between parts of different systems. The latter can be a covering relationship of a general pattern to the special development or a mapping to a mechanical part that satisfies the requirement. A part-to-system relation exists either between a part of a system and a different system or between a part and the system it belongs to. As a system is more than the sum of its parts the characteristics of a part induce the properties of the system; properties that a single part does not provide. The causal relation if-then describes that one object is due to another object, e.g. if sand-cast then form big radii. The support states whether there is a so-called goal conflict [9]: Positive relations characterise the mutual supporting of two objects, i.e. increasing the value of one object automatically results in an increasing value of the positive related object. Negative relations are so called goal conflicts. Negative related requirements cannot be optimised at the same time, so that compromises have to be made or new innovative techniques have to be developed to solve the goal conflict. An exclusionary relation states that there is a goal conflict between two objects that cannot be solved by a compromise. The system can just fulfil one requirement or the other. Relations can be considered to be directed: A unidirectional related object impacts the related object. At the same time it cannot be impacted via this link. More precisely, the change of an object influences another object, but some kind of ‘‘propagation buffer’’ hinders the influence in the other direction. The impact one object has on a mutual related object can be inverted. A relation links two objects. This linking can be direct or indirect: A direct relation states a straight link between objects, i.e. one object directly influences another. An indirect relation states a relation between two objects that is due to a third interfering object, i.e. if A was related to B and B
was related to C, there would be a possible relation between A and C. If this relation was at the same time a goal conflict, a variation of the connecting part could be the key factor to solve the conflict. Moreover the quantifiability provides two groups: Qualitative relations cannot be quantified. This can be due to the complexity of the relation for which no analytical mathematical representation can be found. But experts can rate these relations to their experience. A quantitative relation can be modelled by a mathematical equation or set of equations. This type is often not possible to define before a certain state of concretion, so that physical effects can be mapped on the relations. 3. Developing parallel robots Within the Collaborative Research Centre 562 ‘‘Robotic Systems for Handling and Assembly – High Dynamic Parallel Structures with Adaptronic Components’’ concepts for design and modelling of parallel robots for high operating speeds, accelerations and accuracy are developed. Due to the use of closed kinematic chains parallel robots feature relatively small moved masses (drives are mainly placed in the rack) and high stiffness. In comparison with serial mechanisms they offer higher dynamics and high accuracy, especially when new and optimised structure components (e.g. adaptive joints [27] and rods [28]) are used. The disadvantages compared to serial robots are mainly a small ratio of workspace to installation area and the existence of singularities within the workspace. Thence, new design, analysis and control methods were developed to overcome these drawbacks. As a mechatronic product several disciplines are necessary to set the robot in operation. This results in relatively complex products with complex relations. As by now few parallel robots are sold as mass products but customised to the needs of a special customer. The re-use of knowledge, thence the configuration through a modular concept and an effective change management through a systematic holistic view is helpful to provide the desired fast time-to-market as well as high quality and optimal products to the customer needs. 3.1. Product views When considering the product surrounding of the parallel robot different views have to be respected. Fig. 2 shows the product oriented view that is the viewpoint of the manufacturing enterprise [29]. The enterprise has a strategy that is superior to the specific goals of single departments and should be implemented in the department’s goals. With the project schedule the resources are planned to develop the specific robot. The kinematics experts develop optimised kinematics to a problem [25] and the dynamics experts make simulations to guarantee stability and safety [28]. The purchase bargains for bought-in parts and the workshop decides on what can be manufactured. Adaptronic components are developed; the design and construction department develops the detailed structure and integrates the structural components into a complete package. The control department creates the control architecture to control the mechanical structure and related hardware. Then the programming department programmes the robot to fulfil the customer’s desired task. The customer-oriented view is shown in Fig. 3. Here, one has to distinguish between roles of buyer and user. For the buyer the most
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
157
Fig. 3. Customer-oriented view.
Fig. 2. Product oriented view.
important factor is the return on investment that can be characterised by the cycle times (e.g. for the assembly of a cell phone), the quality of the assembly and the actual TCO. For users goals are different. For instance, safety is important. As machine operator a user is interested in ergonomics and usability, i.e. simple and easy-to-use access to the workspace. As programmer the user has to adapt the machine programme to a new task and the usability of the programming interface is a key factor. 3.2. Modelling of relations Fig. 4 shows a simplified extract of the relationship model of a parallel robot on the basis of SysML notation. At the top the goal cycle time is sketched, i.e. the complete cycle to assemble a product (e.g. a cell phone) should be as low as possible. This goal is very vague. Thence, targets were developed that satisfy it and that are more concrete to the robot, e.g. high dynamic. This target is satisfied by the systems requirements high acceleration and speed at the TCP. At the same time the targets high dynamic and high accuracy cause a need for damping, because high dynamic movement results in an excitation of oscillations that have to die down before a precise movement of the TCP can be made. On the right hand side the use case assembly task is shown that refines the systems requirements workspace and payload. These requirements are very important to choose a fitting kinematic
principle and size of the kinematic structure. Thus, the task declares what parts are to be assembled, i.e. weight and dimensions of the part and an idea of necessary degree of freedom and orientation angles at the working platform. At the bottom of Fig. 4 a block drive is shown. It symbolises the module that accelerates the kinematic chains. It is clear by experience that the drive is responsible for the reachable acceleration and speed at the TCP, therefore satisfies the according requirements. At this level it is just a qualitative statement between parts of the different systems structure and requirements. It was neither said whether this is the main influence nor which parameters carry the characteristics of the requirement. Integrating constraints (as quantifiable relations) into the model allows further describing the relations. The velocity constraint describes that the maximum reachable speed at the TCP depends on the maximum reachable acceleration and the maximum length during which the TCP can be accelerated. Hence, a large workspace unidirectional supports a high TCP speed. According to the desired task that is described by the use case assembly task the maximum speed becomes more (long trajectories, e.g. pick and place) or less (short trajectories, e.g. precision assembly of small parts) important to satisfy the goal short cycle time. The power constraint considers the power characteristics of the drive. Via a transformation that uses the characteristics of the kinematic chain the payload is taken into consideration, too. Now, for a desired speed at the TCP the needed drive specifications with a certain kinematic chain and at a certain payload are assessed. A specific drive can be chosen out of a database (e.g. electronic design catalogues).
Fig. 4. Simplified extract of the relationship model of a parallel robot.
158
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
To analyse the impact of a certain requirement or structure element a matrix of this relationship model can be made up. This is the case for change management during configurations, e.g. which goals would be affected if a cheaper but less powerful drive was used. Furthermore, the matrix view can help identifying important indirect relations. For instance, from Fig. 4 a relation can be traced from high payload to damping. With the already described constraints a conflict between payload and speed as well as a support between speed and acceleration was described. This yields to a conflict between payload and acceleration, too. Provided that acceleration and damping are negatively related damping and speed are conflicting, too. Whereas damping and payload are formal presumed to support each other. Now analysing this presumption shows that a high desired payload leads to less dynamic so less oscillation excitation. Thus the need for structural damping is lower. On the other hand a higher payload generates the need for stiffer components in the kinematic chain, which will provide a higher structural damping. 4. Summary This paper shows an approach to use requirements as a guideline through multi-disciplinary development. Existing approaches of requirements management are shown and put in a context. The shown types of relations help structuring the complex requirements relationship model and identifying the important requirements and links between different domains. A short example from the development of parallel robots shows the benefit in principle. Acknowledgements The authors gratefully thank the German research association (DFG) for supporting the Collaborative Research Centre SFB 562 ‘‘Robotic Systems for Handling and Assembly – High Dynamic Parallel Structures with Adaptronic Components’’. References [1] Franke, H.-J., 1975, Methodische Schritte beim Kla¨ren konstruktiver Aufgabenstellungen. Konstruktion 27, Springer Verlag, Du¨sseldorf. 395–402. [2] Pahl, G., Beitz, W., 1999, Engineering Design—A Systematic Approach, Springer, London. [3] Schmidt-Kretschmer, M., Gericke, K., Blessing, L., 2007, Managing Requirements or Being Managed by Requirements—Results of an Empirical Study, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #542, . [4] Roozenburg, N.F., Dorst, M.K., 1991, Some Guidelines for the Development of Performance Specifications in Product Design, in: Proceedings of the 8th International Conference on Engineering Design ICED 91, pp.359–366. [5] Hansen, C.T., Andreasen, M.M., 2007, Specifications in Early Conceptual Design Work, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #498, .
[6] Maier, J.R.A., Fadel, G.M., 2001, Affordance: The Fundamental Concept in Engineering Design, in: Proceedings of ASME Design Theory and Methodology Conference, #DETC2001/DTM-21700, . [7] Weber, C., 2005, CPM/PDD—An Extended Theoretical Approach to Modelling Products and Product Development Processes, in: Proceedings of the 2nd German—Israeli Symposium for Design and Manufacture, pp.159–180. [8] Albers, A., Meboldt, M., 2007, SPALTEN Matrix—Product Development Process on the Basis of Systems Engineering and Systematic Problem Solving, in: Proceedings of the 17th CIRP Design Conference, pp.43–52. [9] Kla¨ger, R., 1993, Modellierung von Produktanforderungen als Basis fu¨r Problemlo¨sungsprozesse in intelligenten Konstruktionssystemen, Shaker Verlag, Aachen. [10] Grady, R., 1992, Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, Englewood Cliffs. [11] Lee, J., Kuo, J.Y., 1998, New Approach to Requirements Trade-Off Analysis for Complex Systems, IEEE Transactions on Knowledge and Data Engineering, 10/ 4: 551–562. [12] Roth, K., 2000, Konstruieren mit Konstruktionskatalogen. Bd. 1 Konstruktionslehre, Springer Verlag, Berlin. [13] Krusche, T., 2000, Strukturierung von Anforderungen fu¨r eine effiziente und effektive Produktentwicklung, Mainz Wissenschaftsverlag, Aachen. [14] Maier, J.R.A., Ezhilan, T., Fadel, G.M., Summers, J.D., Mocko, G., 2007, A Hierarchical Requirements Modeling Scheme to Support Engineering Innovation, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #582, . [15] Bauer, S., Meerkamm, H., 2007, Decision Making with Interdependent Objectives in Design for X, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #362, . [16] The Official OMG Systems Modeling Language (SysML) Site, 2007, http:// www.omgsysml.org/. [17] Pohl, K., 2007, Requirements Engineering—Grundlagen, Prinzipien, Techniken, dPunkt Verlag, Heidelberg. [18] Franke, H.-J., Wrege, C., Stechert, C., Pavlovic, N., 2005, Knowledge Based Development Environment, in: Proceedings of the 2nd International Colloquium of the Collaborative Research Center 562, pp.221–236. [19] Franke, H.-J., 1976, Untersuchungen zur Algorithmisierbarkeit des Konstruktionsprozesses, VDI Verlag GmbH, Du¨sseldorf. [20] Suh, N.P., 1990, The Principles of Design, Oxford University Press, New York. [21] Deimel, M., 2007, A¨hnlichkeitskennzahlen zur systematischen Synthese Beurteilung und Optimierung von Konstruktionslo¨sungen, VDI Verlag GmbH, Du¨sseldorf. [22] Kickermann, H., 1995, Rechnerunterstu¨tzte Verarbeitung von Anforderungen im methodischen Konstruktionsprozess, Berichte des Instituts fu¨r Konstruktionslehre, Maschinen- und Feinwerkelemente, Nr. 44, Braunschweig. [23] VDI 2206, 2004, Entwicklungsmethodik fu¨r mechatronische Systeme, Beuth, Berlin. [24] Stechert, C., Franke, H.-J., 2007, Requirement-oriented Configuration of Parallel Robotic Systems, in: Proceedings of 17th CIRP Design Conference, pp.259–268. [25] Krefft, M., 2006, Aufgabenangepasste Optimierung von Parallelstrukturen fu¨r Maschinen in der Produktionstechnik, Vulkan Verlag, Essen. [26] Ariyo, O.O., Keller, R., Eckert, C.M., Clarkson, P.J., 2007, Predicting Change Propagation on Different Levels of Granularity: An Algorithmic View, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #220, . [27] Stechert, C., Pavlovic, N., Franke, H.-J., 2007, Parallel Robots with Adaptronic Components—Design Through Different Knowledge Domains, in: Proceedings of the 12th IFToMM World Congress, #A99, . [28] Rose, M., Keimer, R., Breitbach, E.J., Campanile, L.F., 2004, Parallel Robots with Adaptronic Components, Journal of Intelligent Material Systems and Structures, 15/9–10: 763–769. [29] Stechert, C., Alexandrescu, I., Franke, H.-J., 2007, Modeling of Inter-Model Relations for a Customer Oriented Development of Complex Products, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #422, .
Contents lists available at ScienceDirect
CIRP Journal of Manufacturing Science and Technology journal homepage: www.elsevier.com/locate/cirpj
Managing requirements as the core of multi-disciplinary product development C. Stechert *, H.-J. Franke Institute for Engineering Design, Technische Universita¨t Braunschweig, Germany
A R T I C L E I N F O
A B S T R A C T
Article history:
This paper shows a methodology that brings existing approaches of requirements management together in a reasonable context. It supports communication between different disciplines and therefore helps identifying important requirements and relations between requirements from different domains. That is crucial in early phases of the design process and in later phases. Not less crucial is to bring early and later phases together by predicting possible changes and by estimating the presumable impact. Thence, the managing of requirements can be seen as the core of successful multi-disciplinary product development. A short example from the field of parallel robots is given. ß 2008 CIRP.
Available online 5 November 2008 Keywords: Requirements management Design methodology Parallel robots
1. Introduction The overall goal of product development is to satisfy customer needs and wishes as well as to meet the own enterprise strategy. To reach this goal it is important to identify the customer requirements (latent and externalized) and requirements from different departments (marketing, project management, mechanical/electronic/software design, sales, support) and suppliers (raw materials, bought-in parts, service/consulting). As the customer is mostly interested in low prices and high qualities, the manufacturer is more likely interested in high returns and enhancement of prestige. He has to reduce costs (e.g. by implementing modular systems, by installing new technologies), shorten the time-tomarket and develop innovations to produce customer enthusiasm or to create new markets. Coming from different domains several approaches like ‘‘customer oriented axiomatic design’’, ‘‘systems engineering with SysML’’, ‘‘extended QFD charts’’ are already known, but often too complex, too complicated or poorly adapted to the special needs of the branch, the specific enterprise and/or the specific product. So they are rarely implemented in practical work especially of small and medium-sized enterprises. When methods are not used at the right time and/or in the right context they are useless and the acceptance decreases. In addition they often just show one side (one domain) of the development process. The main question is: How to conduct information and to ensure consistency? A methodology has to support communication between different disciplines and to identify the important
* Corresponding author. Tel.: +49 531 391 3349; fax: +49 531 391 4572. E-mail address: [email protected] (C. Stechert). 1755-5817/$ – see front matter ß 2008 CIRP. doi:10.1016/j.cirpj.2008.09.008
requirements and relations between requirements from different domains. That is very crucial in the early phases of the design process (more or less qualitatively) and in the later phases (quantitatively on the basis of product models). Not less crucial is to bring early and later phases together by predicting possible changes and by estimating the presumable impact. Thence, the managing of requirements can be seen as the core of successful multi-disciplinary product development. 2. Managing requirements From established publications [1], prevailing textbooks [2], as well as new contributions at pertinent conferences [3], the need and importance to clarify the design task at the very beginning is gathered. Although companies feel to develop what their customers’ need, their development process is often slowed down and characterised by changes [3] that are followed by large iteration loops. A set of requirements should be functional, comprehensive, complete, operational, non-redundant and minimal before the search for solution starts [4]. But requirements often cannot be fixed that early. A too early fixing hinders innovation, because auspicious alternatives were not observed at all. A too large (and unfavourable not or bad structured) database of requirements cannot be handled properly in the following development steps. In [5] it was stated that just ideation supporting specification statements should be taken into consideration for early conceptual design work. Moreover, the consistency is not easy to determine in the early phases, when no or just a rough concept is defined. Nevertheless, the certain identification of goal conflicts is a factor of success for the development process and the product to be developed.
154
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
Coming from different domains the definition of a requirement is slightly different. Even within the same domain but different authors the description differs. The common denominator is that a requirement describes something that the product should fulfil to be successful on the market. This can be described by the theory of affordances [6] where a product should provide positive and must not provide negative affordances. Another approach hierarchically separates the product into properties and characteristics [7]. Characteristics (e.g. shape, material) can be directly influenced by the designer whereas properties (e.g. weight) change due to the change of characteristics. Therefore the modelling of relations is important to know what exactly a designer should create to meet the desired properties. In [8,9] approaches were shown to integrate requirements handling into a holistic product development process. In information technology a well-known approach is to distinguish requirements between functionality, usability, reliability, performance and supportability [10]. In [11] additionally the certainty of requirements was analysed. A usual approach in mechanical engineering is to distinguish whether a requirement is fixed, limited or a wish [12]. Requirements can be assigned to different life-cycle phases (e.g. operation, maintenance), different parts and different views. In [13] it was shown how to structure requirements to the needs of the development task. 2.1. Requirements modelling The modelling of requirements has been a research topic for years. In [14] an overview of related work was given. This paper just focuses on some useful approaches and discusses them in relation to the phases of the development process and the knowledge domains involved. In early phases normally no concrete statements can be made, because the final relations depend on the final realisation of the complete system. In addition, for a complex system some characteristics cannot be forecasted certainly even not in later phases or if virtual prototype techniques are used (e.g. haptics). Since the input data of a method is uncertain the outcomes cannot be seen as certain. Thus the correctness and certainty of requirements data have to be refined and controlled while advancing in the development process. A tool to visualise the existing expert knowledge regarding targets, to help finding possible relations between product characteristics, and to identify strategy points was presented in [15]. It consists of a multidimensional scaling on the basis of pairwise comparison of targets by a group of experts. The targets are visualised in a 3D-space so that supporting targets aggregate and conflicting targets separate. A possible, not yet implemented, extension may provide that if for some conflicting targets the underlying characteristics were known, multidimensional coordinates with skew axes could be drawn. This would allow finding dependencies between characteristics. To model relations on system level one possible approach is the UML extension SysML that is provided by several commercial modelling tools. OMG SysML v1.0 was issued as Available Specification in September 2007 [16] and provides a common basis, so a better exchangeability, to describe requirements, as well as structure (e.g. blocks, packages, constraints) and behaviour (e.g. activities, use cases). So far SysML mainly focuses on the needs of software and electric development, but new profiles containing new classes and stereotypes can be generated for customisation. All relations can be visualised in diagrams and formatted to desired views. From these models requirements lists and traceability matrices can be generated.
The more traditional use of requirements lists [12,17] is supported by a variety of commercial (e.g. DOORS) and scientific [18] tools. They provide amongst others the documentation (particularly the generation of specification sheets), version checking (e.g. baseline, fulfilment control) and linking of requirements. The latter is normally a qualitative linking sometimes with scaling (positive and negative relation). An impact analysis allows identifying indirect relations on the basis of known requirements, hence so far undiscovered goal conflicts. Within the design phase the well-established methods of Quality Function Deployment (QFD) are easy-to-use tools to qualitatively map objects (e.g. requirements, functions, effect principles) to each other. This and other approaches use matrices [19,20]. The obtaining of initial relations is in practice often questionable and can lead to useless outcomes. On the basis of the initial direct relations indirect relations can be identified [14,18]. Where important relations were identified the use of more complicated methods can be used. These are more linked up to physical reality than to expert experience. Such methods base on mathematical models. One approach is to find the relevant physical equations, identify the input and output parameters as well as necessary empirical knowledge (e.g. material constants) and relate the corresponding parameters [19]. Equations can be transformed into similarity ratios. These allow integrating a direction of optimisation for special parameters by assigning them to nominator or denominator. These ratios are connected via graph theory, so that the resulting graph describes the goal function of the subsystem and goal conflicts are identified on a physical basis [21]. The whole model can be used as a pattern for the development of new products. If the early goals were nearly the same as for the pattern the differences in targets could be traced to the requirements and to the specific structural components. A meaningful starting point for variation and/or optimisation is identified. Moreover, the impact this change will have on those goals that should not be changed is detectable. On the other hand the impact a technological push (development of a new not yet implemented technology) has on an existing system can be identified and the worthiness to follow up research in this area can be estimated. In addition, research fields (e.g. to solve goal conflicts) can be found and the convenient amount of labour to be spent can be estimated. 2.2. Product development process Requirements accompany the whole product life-cycle in different manifestations, whereas the early design fixes the better part of costs not only for manufacturing and operation but also for potential reconfigurations and end-of-life treatment. Thence, they have to be considered as a part of the product model and processed during product development [22]. Fig. 1 shows the product development process in the style of the V-model, cp. [23], with different manifestations of requirements added to the process schema. As long as the product surroundings are not fully clarified and the principal design of the product is not well concretised just some uncertain goals can be stated. From these goals fuzzy targets derive that depend on the different views of the involved persons: customer (product buyer, product user) and manufacturer (e.g. management, sales or different design departments). These targets often cannot be quantified to detail—just a range or limits and restrictions (e.g. existing manufacturing methods in the enterprise) can be specified. But it allows choosing a strategy and rough concept (e.g. kinematic principle). However, as far as a customer inquiry
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
155
ordering enterprise. Another possible reason is a new order that bases on an existing solution, but has to be changed to meet the targets of that special order. Here the existing requirements structure can be used to identify appropriate starting points for variation (e.g. when using a modular system [24]) or optimisation [25]. The set into operation at the customer’s site is the crucial step where the final design is adapted to the intended surroundings. 2.3. Relation types
Fig. 1. Requirements in the product development process.
does not often lead to an order it would be unreasonable to invest too many resources into detailing. But if the offer based on too uncertain goals it could lead to risky promises according to schedule, pricing and performance. On the other hand while refining goals to targets the real latent customer wishes can be discovered, so that the risk of a later change decreases. The concept is further modelled on system and subsystem level [24]. The main set of requirements deals with the whole system. These should result from an elaborate discussion between user and manufacturer. The complex system consists of multi-disciplinary parts distinguished into subsystems. For each subsystem (and subsubsystems, respectively) a specific set of requirements can be stated that can often be more concrete than that of the higher level and becomes more detailed as the development process moves further. As in the other steps requirements are related. Even if some subsystems could be delimited to just one knowledge domain, it has in- and output parameters so that an impact on other subsystems follows. Hence, the modelling of relations is extremely important. During design requirements are the guidelines to develop the desired product. From requirements functions structures are developed, functions structures lead to effect principles and so forth. Normally several iteration loops are necessary to implement the subsystems into one system. Thence, the following steps cannot be seen as a strict sequence. But a good clarification, documentation and a valuable assistance to handle and easily access the important requirements for that specific design task is essential to avoid unnecessary iteration loops. Thence, the concretion, fulfilment and perhaps change should be carefully observed and documented. Especially in the domain of electronics and software development test specifications play a big role to validate and verify design. For a mechatronic product testing of the whole system is of importance to guarantee the desired specifications. Recently more and more Original Equipment Manufacturers (OEMs) force their suppliers to guarantee Total Cost of Ownership (TCO), e.g. of tooling machines so that they can be charged, if it does not reach the desired efficiency. Thence, test specifications have to cover the customer’s targets. Moreover, in traditional mechanical design the concept evaluation was and is the key factor to narrow the field of possible solutions down. So the evaluation or testing is a gateway, design concepts have to pass in their different levels of concretion during the design process. The next step in the development process is a change or optimisation of design. In difference to the above-mentioned ‘‘normal’’ iteration loops this can also be a change of the initial requirements. A possible reason is a sudden strategy change of the
Relations can be classified to what and how they relate objects (abstract entities, e.g. parts, parasitic effects, requirements). These relation types are not mutual exclusionary, e.g. a negative relation can be defined quantitatively. Table 1 shows seven identified types of relations in a condensed form. A more precise description follows in the text. If the objects were not related following these relation types they could be seen as independent, i.e. two independent objects have no impact on each other. Relations associated to the development process: Goal-to-target relations describe the refining path from very general and uncertain goals to more precise targets. The documentation of these relations helps to redefine targets when goals change. When contradictoriness of targets is detected it shows which goals may not be satisfied. Target-to-requirement relations describe a refining path from the more or less interdisciplinary linked targets to requirements that can be stated more precisely and (on subsystem level) decoupled. Requirement-to-requirement relations can be seen as a kind of part-to-part relation where a requirement is an abstract part of the requirements structure. Direct relating a requirement to another is difficult, because the coupling is mostly indirect involving, e.g. a mechanical part. Requirement-to-product-surrounding relations are auxiliary to trace the impact the product surrounding (e.g. neighbouring
Table 1 Types of relations. Development steps Goal-to-target Target-to-requirement Requirement-to-requirement Requirement-to-product-surrounding Requirement-to-component Requirement-to-test-specification Granularity System-to-system Part-to-part Part-to-system Causal If-then Support Positive Negative Exclusionary Direction Unidirectional Mutual Linking Direct Indirect Quantifiability Qualitative Quantitative
156
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
systems, weather conditions, use-cases) has on the requirements thence on the design. Requirement-to-component relations describe a mapping of which component (e.g. a drive or software module) satisfies or aids to satisfy a requirement. The requirement-to-test-specification relation describes which requirement (and therefore which goal) can be verified or validated by what test or evaluation criterion. Regarding virtual prototypes and rapid prototyping most verifications and validations can be made early and changes due to the validation process can be implemented fast and at relatively low costs. The granularity describes the hierarchy of related objects [26]. A system can be both an assembly of parts and – more abstract – a group of abstract objects like requirements, functions or use- and test-cases. Moreover surrounding systems (e.g. component supply for automated assembly, weather conditions) have to be considered, too: A system-to-system relation exists between two self-contained systems (e.g. modules of a modular system). Interfaces can be clearly defined and change impact can be forecasted or even avoided by using ‘‘propagation blocker’’ like adapter. Part-to-part relations exist either between different parts of the same system or between parts of different systems. The latter can be a covering relationship of a general pattern to the special development or a mapping to a mechanical part that satisfies the requirement. A part-to-system relation exists either between a part of a system and a different system or between a part and the system it belongs to. As a system is more than the sum of its parts the characteristics of a part induce the properties of the system; properties that a single part does not provide. The causal relation if-then describes that one object is due to another object, e.g. if sand-cast then form big radii. The support states whether there is a so-called goal conflict [9]: Positive relations characterise the mutual supporting of two objects, i.e. increasing the value of one object automatically results in an increasing value of the positive related object. Negative relations are so called goal conflicts. Negative related requirements cannot be optimised at the same time, so that compromises have to be made or new innovative techniques have to be developed to solve the goal conflict. An exclusionary relation states that there is a goal conflict between two objects that cannot be solved by a compromise. The system can just fulfil one requirement or the other. Relations can be considered to be directed: A unidirectional related object impacts the related object. At the same time it cannot be impacted via this link. More precisely, the change of an object influences another object, but some kind of ‘‘propagation buffer’’ hinders the influence in the other direction. The impact one object has on a mutual related object can be inverted. A relation links two objects. This linking can be direct or indirect: A direct relation states a straight link between objects, i.e. one object directly influences another. An indirect relation states a relation between two objects that is due to a third interfering object, i.e. if A was related to B and B
was related to C, there would be a possible relation between A and C. If this relation was at the same time a goal conflict, a variation of the connecting part could be the key factor to solve the conflict. Moreover the quantifiability provides two groups: Qualitative relations cannot be quantified. This can be due to the complexity of the relation for which no analytical mathematical representation can be found. But experts can rate these relations to their experience. A quantitative relation can be modelled by a mathematical equation or set of equations. This type is often not possible to define before a certain state of concretion, so that physical effects can be mapped on the relations. 3. Developing parallel robots Within the Collaborative Research Centre 562 ‘‘Robotic Systems for Handling and Assembly – High Dynamic Parallel Structures with Adaptronic Components’’ concepts for design and modelling of parallel robots for high operating speeds, accelerations and accuracy are developed. Due to the use of closed kinematic chains parallel robots feature relatively small moved masses (drives are mainly placed in the rack) and high stiffness. In comparison with serial mechanisms they offer higher dynamics and high accuracy, especially when new and optimised structure components (e.g. adaptive joints [27] and rods [28]) are used. The disadvantages compared to serial robots are mainly a small ratio of workspace to installation area and the existence of singularities within the workspace. Thence, new design, analysis and control methods were developed to overcome these drawbacks. As a mechatronic product several disciplines are necessary to set the robot in operation. This results in relatively complex products with complex relations. As by now few parallel robots are sold as mass products but customised to the needs of a special customer. The re-use of knowledge, thence the configuration through a modular concept and an effective change management through a systematic holistic view is helpful to provide the desired fast time-to-market as well as high quality and optimal products to the customer needs. 3.1. Product views When considering the product surrounding of the parallel robot different views have to be respected. Fig. 2 shows the product oriented view that is the viewpoint of the manufacturing enterprise [29]. The enterprise has a strategy that is superior to the specific goals of single departments and should be implemented in the department’s goals. With the project schedule the resources are planned to develop the specific robot. The kinematics experts develop optimised kinematics to a problem [25] and the dynamics experts make simulations to guarantee stability and safety [28]. The purchase bargains for bought-in parts and the workshop decides on what can be manufactured. Adaptronic components are developed; the design and construction department develops the detailed structure and integrates the structural components into a complete package. The control department creates the control architecture to control the mechanical structure and related hardware. Then the programming department programmes the robot to fulfil the customer’s desired task. The customer-oriented view is shown in Fig. 3. Here, one has to distinguish between roles of buyer and user. For the buyer the most
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
157
Fig. 3. Customer-oriented view.
Fig. 2. Product oriented view.
important factor is the return on investment that can be characterised by the cycle times (e.g. for the assembly of a cell phone), the quality of the assembly and the actual TCO. For users goals are different. For instance, safety is important. As machine operator a user is interested in ergonomics and usability, i.e. simple and easy-to-use access to the workspace. As programmer the user has to adapt the machine programme to a new task and the usability of the programming interface is a key factor. 3.2. Modelling of relations Fig. 4 shows a simplified extract of the relationship model of a parallel robot on the basis of SysML notation. At the top the goal cycle time is sketched, i.e. the complete cycle to assemble a product (e.g. a cell phone) should be as low as possible. This goal is very vague. Thence, targets were developed that satisfy it and that are more concrete to the robot, e.g. high dynamic. This target is satisfied by the systems requirements high acceleration and speed at the TCP. At the same time the targets high dynamic and high accuracy cause a need for damping, because high dynamic movement results in an excitation of oscillations that have to die down before a precise movement of the TCP can be made. On the right hand side the use case assembly task is shown that refines the systems requirements workspace and payload. These requirements are very important to choose a fitting kinematic
principle and size of the kinematic structure. Thus, the task declares what parts are to be assembled, i.e. weight and dimensions of the part and an idea of necessary degree of freedom and orientation angles at the working platform. At the bottom of Fig. 4 a block drive is shown. It symbolises the module that accelerates the kinematic chains. It is clear by experience that the drive is responsible for the reachable acceleration and speed at the TCP, therefore satisfies the according requirements. At this level it is just a qualitative statement between parts of the different systems structure and requirements. It was neither said whether this is the main influence nor which parameters carry the characteristics of the requirement. Integrating constraints (as quantifiable relations) into the model allows further describing the relations. The velocity constraint describes that the maximum reachable speed at the TCP depends on the maximum reachable acceleration and the maximum length during which the TCP can be accelerated. Hence, a large workspace unidirectional supports a high TCP speed. According to the desired task that is described by the use case assembly task the maximum speed becomes more (long trajectories, e.g. pick and place) or less (short trajectories, e.g. precision assembly of small parts) important to satisfy the goal short cycle time. The power constraint considers the power characteristics of the drive. Via a transformation that uses the characteristics of the kinematic chain the payload is taken into consideration, too. Now, for a desired speed at the TCP the needed drive specifications with a certain kinematic chain and at a certain payload are assessed. A specific drive can be chosen out of a database (e.g. electronic design catalogues).
Fig. 4. Simplified extract of the relationship model of a parallel robot.
158
C. Stechert, H.-J. Franke / CIRP Journal of Manufacturing Science and Technology 1 (2009) 153–158
To analyse the impact of a certain requirement or structure element a matrix of this relationship model can be made up. This is the case for change management during configurations, e.g. which goals would be affected if a cheaper but less powerful drive was used. Furthermore, the matrix view can help identifying important indirect relations. For instance, from Fig. 4 a relation can be traced from high payload to damping. With the already described constraints a conflict between payload and speed as well as a support between speed and acceleration was described. This yields to a conflict between payload and acceleration, too. Provided that acceleration and damping are negatively related damping and speed are conflicting, too. Whereas damping and payload are formal presumed to support each other. Now analysing this presumption shows that a high desired payload leads to less dynamic so less oscillation excitation. Thus the need for structural damping is lower. On the other hand a higher payload generates the need for stiffer components in the kinematic chain, which will provide a higher structural damping. 4. Summary This paper shows an approach to use requirements as a guideline through multi-disciplinary development. Existing approaches of requirements management are shown and put in a context. The shown types of relations help structuring the complex requirements relationship model and identifying the important requirements and links between different domains. A short example from the development of parallel robots shows the benefit in principle. Acknowledgements The authors gratefully thank the German research association (DFG) for supporting the Collaborative Research Centre SFB 562 ‘‘Robotic Systems for Handling and Assembly – High Dynamic Parallel Structures with Adaptronic Components’’. References [1] Franke, H.-J., 1975, Methodische Schritte beim Kla¨ren konstruktiver Aufgabenstellungen. Konstruktion 27, Springer Verlag, Du¨sseldorf. 395–402. [2] Pahl, G., Beitz, W., 1999, Engineering Design—A Systematic Approach, Springer, London. [3] Schmidt-Kretschmer, M., Gericke, K., Blessing, L., 2007, Managing Requirements or Being Managed by Requirements—Results of an Empirical Study, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #542, . [4] Roozenburg, N.F., Dorst, M.K., 1991, Some Guidelines for the Development of Performance Specifications in Product Design, in: Proceedings of the 8th International Conference on Engineering Design ICED 91, pp.359–366. [5] Hansen, C.T., Andreasen, M.M., 2007, Specifications in Early Conceptual Design Work, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #498, .
[6] Maier, J.R.A., Fadel, G.M., 2001, Affordance: The Fundamental Concept in Engineering Design, in: Proceedings of ASME Design Theory and Methodology Conference, #DETC2001/DTM-21700, . [7] Weber, C., 2005, CPM/PDD—An Extended Theoretical Approach to Modelling Products and Product Development Processes, in: Proceedings of the 2nd German—Israeli Symposium for Design and Manufacture, pp.159–180. [8] Albers, A., Meboldt, M., 2007, SPALTEN Matrix—Product Development Process on the Basis of Systems Engineering and Systematic Problem Solving, in: Proceedings of the 17th CIRP Design Conference, pp.43–52. [9] Kla¨ger, R., 1993, Modellierung von Produktanforderungen als Basis fu¨r Problemlo¨sungsprozesse in intelligenten Konstruktionssystemen, Shaker Verlag, Aachen. [10] Grady, R., 1992, Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, Englewood Cliffs. [11] Lee, J., Kuo, J.Y., 1998, New Approach to Requirements Trade-Off Analysis for Complex Systems, IEEE Transactions on Knowledge and Data Engineering, 10/ 4: 551–562. [12] Roth, K., 2000, Konstruieren mit Konstruktionskatalogen. Bd. 1 Konstruktionslehre, Springer Verlag, Berlin. [13] Krusche, T., 2000, Strukturierung von Anforderungen fu¨r eine effiziente und effektive Produktentwicklung, Mainz Wissenschaftsverlag, Aachen. [14] Maier, J.R.A., Ezhilan, T., Fadel, G.M., Summers, J.D., Mocko, G., 2007, A Hierarchical Requirements Modeling Scheme to Support Engineering Innovation, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #582, . [15] Bauer, S., Meerkamm, H., 2007, Decision Making with Interdependent Objectives in Design for X, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #362, . [16] The Official OMG Systems Modeling Language (SysML) Site, 2007, http:// www.omgsysml.org/. [17] Pohl, K., 2007, Requirements Engineering—Grundlagen, Prinzipien, Techniken, dPunkt Verlag, Heidelberg. [18] Franke, H.-J., Wrege, C., Stechert, C., Pavlovic, N., 2005, Knowledge Based Development Environment, in: Proceedings of the 2nd International Colloquium of the Collaborative Research Center 562, pp.221–236. [19] Franke, H.-J., 1976, Untersuchungen zur Algorithmisierbarkeit des Konstruktionsprozesses, VDI Verlag GmbH, Du¨sseldorf. [20] Suh, N.P., 1990, The Principles of Design, Oxford University Press, New York. [21] Deimel, M., 2007, A¨hnlichkeitskennzahlen zur systematischen Synthese Beurteilung und Optimierung von Konstruktionslo¨sungen, VDI Verlag GmbH, Du¨sseldorf. [22] Kickermann, H., 1995, Rechnerunterstu¨tzte Verarbeitung von Anforderungen im methodischen Konstruktionsprozess, Berichte des Instituts fu¨r Konstruktionslehre, Maschinen- und Feinwerkelemente, Nr. 44, Braunschweig. [23] VDI 2206, 2004, Entwicklungsmethodik fu¨r mechatronische Systeme, Beuth, Berlin. [24] Stechert, C., Franke, H.-J., 2007, Requirement-oriented Configuration of Parallel Robotic Systems, in: Proceedings of 17th CIRP Design Conference, pp.259–268. [25] Krefft, M., 2006, Aufgabenangepasste Optimierung von Parallelstrukturen fu¨r Maschinen in der Produktionstechnik, Vulkan Verlag, Essen. [26] Ariyo, O.O., Keller, R., Eckert, C.M., Clarkson, P.J., 2007, Predicting Change Propagation on Different Levels of Granularity: An Algorithmic View, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #220, . [27] Stechert, C., Pavlovic, N., Franke, H.-J., 2007, Parallel Robots with Adaptronic Components—Design Through Different Knowledge Domains, in: Proceedings of the 12th IFToMM World Congress, #A99, . [28] Rose, M., Keimer, R., Breitbach, E.J., Campanile, L.F., 2004, Parallel Robots with Adaptronic Components, Journal of Intelligent Material Systems and Structures, 15/9–10: 763–769. [29] Stechert, C., Alexandrescu, I., Franke, H.-J., 2007, Modeling of Inter-Model Relations for a Customer Oriented Development of Complex Products, in: Proceedings of the 16th International Conference on Engineering Design ICED 07, #422, .