Go to the table of contents.

Hubka and Eder (1988) introduced the *theory of technical systems* (TTS). Many different systems, such as transformation processes, technical systems, human systems, and active environment system can be treated in TTS. The technical system (together with human beings, the information and management systems, and the active environment) exerts the effects on the operands that are necessary to accomplish the desired transformation. Technical systems are the principal means by which the transformation is achieved (Hubka and Eder, 1988). The purpose of a transformation system is to transform input, an existing state of an operand, into output, a desired state. Technical processes are essential elements of socio-technical transformation systems. Further, they exist only to realize a (usually desired) transformation. All elements of the transformation system are brought together to perform a technical process. The technical process is most likely to be used when humans can and actually do participate in the transformation, and where the technical system can be classified as a *machine*. The description of each process (transformation function) or operation must contain a verb and a noun. The same is the case for functions. The purpose of a technical system is thus represented by the system of its output effects (purpose functions). This system of effects is frequently referred to as the *total function of the TS*. Andreasen (1980) developed the *theory of domains* (ToD), based on the theory of technical systems (Hubka and Eder, 1988). The original ToD model for describing a mechanical system consists of four views: the process domain, the function system, the organ domain, and the component domain. The original ToD has been modified over the years. The chromosome product model (Mortensen, 1999) is a generic structure based on the theory of domains.

Figure 13: The chromosome product model (Mortensen, 1999)

The chromosome product model includes a constitutive model and a behavioral model. The behavioral model is divided into a model of the wanted behavior (*soll* behavior) and the actual behavior (*ist* behavior). The design is modeled from two viewpoints: organs and parts. The organs are units that possess functions and the parts are the units that are physically realized. Technology is exploited to define organs that provide the necessary function. One or more parts are physically realized to implement the organs.

The function-means (F-M) tree, developed by Andreasen (1980), is a graphical representation of Hubka’s law, where the co-evolution between function and physical/abstract solution is made explicit. This approach is similar to Axiomatic Design (Suh, 1990) with its zigzagging between Functional Requirement (FR) and Design Parameter (DP). Hubka’s law, according to Andreasen (1980), states that: "*the primary functions of a machine system are supported by a hierarchy of subordinate functions, which are determined by the chosen means (organs)*". This means that functional decomposition cannot be separated from synthesis, and that a solution for the main function must be stated before further decomposition can be carried out. This model was then extended (Andersson et al. 2000; Schachinger & Johannesson, 2000) to also include relations between means and the ability to link additional information, as shown in Figure 14.

Figure 14: Extended function-means tree (Schachinger & Johannesson, 2000)

The objects used in the model are Functional Requirements (FRs), Design Solutions (DSs) (e.g. means, systems, organs, functional carriers, components), and Constraints (Cs) (constraints may also be referred to as non-functional requirements). Descriptions such as function performance attributes, constraining limit values or design solution characteristics can be linked to the objects. It is also possible to link descriptive documents and other models to the different objects. A DS represents the design solution, a FR is a solution driver, and a C constrains the possible solution space. The model also uses six different relationships (actually seven with the links to the supporting information objects) to describe the interaction between the objects in the model, as shown in Figure 14. The constraints, or non-functional requirements, can either be a means for evaluation and selection between solution alternatives or a source of sub-FRs (Tate, 1999; Söderberg & Johannesson, 1998).

To support the identification of all objects and related information regarding the product lifecycle, the Olsson table with context interaction maps can be used as a supporting checklist and structure (Olsson, 1978), as shown in Figure 15.

Figure 15: The Olsson checklist with context interaction maps (Olsson, 1978).

Functional coupling described in axiomatic design (Suh, 1990) can be represented in the model through the *iib* relations. In this case the model can provide a graphical representation of the axiomatic design equation for a group of parallel DSs and their governing FRs on an arbitrarily chosen level in the F-M structure model. The axiomatic design matrix elements then correspond to the *iib* relations in the model. Functional couplings are defined as interactions between incompatible parallel design solutions or between design solutions causing negative constitutive influence (Johannesson, 1996). In mechanical design the main types of incompatibility come from geometry, time, system physics, and driving effort and material. Constitutive influence can be described in terms of cause and effect. Similar to incompatibilities between design solutions in order to fulfill the governing functional requirements, the design solutions may be incompatible in terms of meeting the constraints.

Figure 16: Basic elements of product design (Ullman, 1997).

The management of design information is a major undertaking in a company (Ullman, 1997). Design information is a large part of a company’s intellectual property and is one of its most valuable assets. Today design information is to a large extent computer-based, as are the methods used to manage the information. A kind of computer systems specifically designed to manage both product and process information is referred to as a *product data management *(*PDM*) system. The development process from concept to product requires work on all the information elements shown in Figure 16. The form of the product is roughly defined by the spatial *constraints* that provide the envelope in which the product operates. Within this envelope the product is defined as the *configuration* of *connected components*. In other words, form development is the evolution of components, how they are configured relative to each other, and how they are connected to each other. Furthermore, decisions on production require development of how the product’s components are manufactured from materials and how these components are assembled. Simultaneous evolution of the product and the processes used to produce it is one of the key features of concurrent engineering. The interaction of manufacturing and assembly decisions will affect the generation of the product. Production considerations are very important in evaluating the product. Configuration is the architecture, structure, or arrangement of the components and assemblies of components in the product. The development of connections, the creation and refinement of interfaces for functions, is a key step when embodying a concept. It is important to maintain functional independence in the design of an assembly or component. Care must also be taken in separating the product into separate components. Complexity arises since one function often occurs across many components or assemblies and because one component may play a role in many functions.

The understanding and management of requirements are of course fundamental issues in any product development and design effort. As such, the area has been focused upon in both research and applications as long as people have been performing development and design – which, of course, is a very long time. Even though this area is not in the core scope of the research presented in this thesis, it is touched upon at the boundary of the results presented; especially those concerning product variety, commonality, and design bandwidth (see section 5.8.2). Andersson (2003) presents a framework of requirements and their dynamics for product development. A basic structure that can be used to relate to requirements is presented in Figure 17.

*Design intent *forms the underlying reason for why a certain artifact exists and can be thought of as the relation between the intended behavior and the structure designed to realize the intended behavior. It thereby answers the question: "*why things are*"? It can also be thought of as the dreams, visions, objectives, goals, and intended behavior of the product describing the *idea with* and the *idea in* the product. *Design rationale *includes not only the reasons behind a design decision (the *intent*) but also the *justifications* for it: the other *alternatives* considered; the *trade-offs* evaluated; and the *argumentation* that led to the decision. The design rationale thereby answers the question: "*why things are and why these things are the way they are*"? Finally, the *design history*, in addition to design intent and rationale, includes the recorded process of the design evolution and progression, thereby also including an answer to: "*how the things came into being*"?

Figure 17: Design history, including design intent and rationale (Andersson, 2003)

In relation to requirements Andersson (2003) states that complete rationale for a design cannot be elicited and represented formally. This is the case since reasoning is not a finite task; and reasoning is guided by issues ranging from knowledge to pure guess work and assumptions. Andersson (2003) proposes that design rationale can be viewed from three perspectives: *requirement rationale*, *solution rationale*, and *evaluative rationale*. Requirement rationale captures the argumentation and justification underlying the intentions with the product. Solution rationale represents the arguments and justifications for and against different alternative solutions that are put forward. Evaluative rationale is the reasons for choosing one solution over another.

Figure 18: Formal notations for the representation of design rationale (Andersson, 2003).

Andersson (2003) discusses the issue of formal versus informal representations for design rationale. Formal representation, using a mathematical or logical language, creates a framework that enables computational support. However, such an approach is a tedious and costly process. Furthermore, while a formal approach enables active computational support, it limits the sets of elements and relationships that are allowed to be used to represent the reasoning process. Thereby, many aspects of a design are doomed not to be captured or, even worse, not elaborated at all. An informal approach such as documentation in electronic notebooks, diaries, etc. in natural language allows for a richer description of rationale. This kind of informal representation can be supported through a systematic approach to documentation (e.g. using standardized documents). In a semi-formal approach parts of the representation can be formalized while rich information that is difficult to formalize is treated informally, but related to the formalized set of information. This would enable some computerized support while not losing richness in the complete representation. Two approaches to formal representation are referred to and discussed by Andersson (2003) and illustrated in Figure 18. The issue-based information system (IBIS) deals with issues, positions, and arguments with an emphasis on recording the argumentation process for a single design. The question, options, and criteria (QOC) notation focuses on assessments that are relationships between the entities: questions, options, and criteria. Andersson (2003) presents an approach to modeling design rationale based on a combination of the two formal approaches that is furthermore related to the product model in such a way that the three perspectives of rationale (requirement, solution, and evaluative) can be managed (see Figure 19).

Figure 19: A design rationale model related to a product model (Andersson et al., 2003).

In addition to the functions of a product, constraints on product design are also important. Roozenburg & Eekels (1995) point out that people tend to apply constraints knowingly (due to conformity) or unknowingly (due to habit). The more constraints a problem is subjected to, the less solution space is available (see Figure 20). Constraints must, therefore, be expressed explicitly. If this is done using a systematic and consistent representation there is a possibility to apply computer support in the manipulation of the constraints, which can provide several advantages. Constraints can be checked for accuracy, sufficiency, and completeness of decisions. Information about the constraints can help the design engineers to a better understanding of the design problem. Furthermore, if computer support is available, the constraints can be automatically checked for consequences of a design change (Lin & Chen, 2002). In axiomatic design, Suh (1990) distinguished between *input constraints* and *system constraints*. Input constraints are those given in design specifications and usually express bounds on size, weight, materials, and cost. System constraints are imposed by the system in which the design solution must function. Examples of system constraints are interfacial bounds such as geometric shape and capacity of machines.

Figure 20: Assumptions constraining the solution space.

Lin & Chen (2002) explains that a functional requirement (as used in axiomatic design applications) is composed of a *function* and a *requirement*. A function states "what to do" and a requirement is described by a *performance measure* either as a *preference* or a *bound*. Lin & Chen (2002) continue with some examples of different definitions of constraints: a relation between a set of DPs; a piece of information that limits design variables to a specific set of permissible values; constraints imposing certain relationships or restrictions on variables; a restriction on a space of possibilities; and Lin & Chen consider a constraint as either a bound on a single DP or the relation among a set of DPs.

Lin & Chen (2002) furthermore present some critique on the topic of constraints and state that: representations of constraints are studied in both research and industrial communities. Feature-based design methods use geometric constraints to model the geometric relationships within a feature or among different features. Although constraint modeling of features and geometry is well supported by the feature-based design methodology, it only models the results of a decision, not the constraints that govern the decision. In the early design stage, design engineers are more concerned about functions, constraints, and the overall structure of the design than about its detailed geometry. Representation of the constraints that affect the decisions is of great importance because a good decision should be based on explicit and complete information.

Three representation schemes for modeling a set of constraints are reported in the literature (Lin & Chen, 2002): (1) the constraint network; (2) the constraint-variable incidence matrix; and (3) the adjacency matrix (see Figure 21).

Figure 21: Example of representation of a group of constraints (Lin & Chen, 2002).

Lin & Chen (2002) state that three types of constraint-based design methods are identified in the literature: *constraint monitoring* (or *constraint checking*); *constraint satisfaction*; and *constrained optimization*. Constraint monitoring uses constraints passively to check whether a decision satisfies all constraints. Constraint satisfaction uses constraints actively to derive some values or variables based on given input values of other variables. Constraint monitoring and constraint satisfaction do not have the notion of finding the *best* solution. Constrained optimization, in contrast, aims at finding the best solution from the different alternatives to maximize or minimize the objective functions (or utility functions) subject to constraints. Constraint satisfaction systems tend to automate the design process whereas constraints monitoring takes advantage of the engineer’s knowledge and intelligence. Constraint monitoring requires less computational effort and has more flexibility than constraint satisfaction. In constraint monitoring, the engineer assigns values to variables, one after another. The algorithm propagates the values through the constraint network. If an assignment violates any constraint, the engineer has to provide a different value. The process proceeds as long as the assignment does not violate any constraint. When all variables are assigned values and no constraints are violated, a solution is found. This design cycle can be repeated to find more – and better – solutions.

Additional work on requirements and the management of requirements has been described by Nilsson (2004) from the perspectives of: requirements and concept modeling; incorporating customer needs through QFD; stakeholder integration; product and process modeling; and management and structuring of manufacturing requirements. The approach to requirements modeling is based on the function-means approach (see section 4.2.2). Nilsson (2004) provides a more detailed view on how the function-means approach can be used in the early phases of development in order to capture and manage requirements. The approach described can therefore be applied as a complement to the results presented in this thesis. Nilsson (2004) highlights the relationship between product and manufacturing requirements and emphasizes on the issue of balancing the manufacturing and product targets.

A *constraint* describes a relation that should be satisfied. Constraints are useful in systems because they allow users to declaratively state a relation that is to be maintained. Constraints are normally multi-directional (e.g. a constraint such as might be used to find the value of one of *a*, *b*, or *c*). In general there may be many interrelated constraints in a given application and it is left to the system to sort out how they interact and to keep them all satisfied. Further, it is in many cases useful to be able to state both *required *and *preferential* constraints. The required constraints *must* hold, whereas the preferential constraints should be satisfied if possible, but no error condition arises if it can not. The preferential constraints can be associated with an arbitrary number of *levels of preference* (e.g. each successive level being more *weakly* preferred than the previous one). The set of all constraints, both required and preferred, labeled with their respective strength, is called a *constraint hierarchy*.

Theoretically, a *constraint system* consists of a set of constraints *C *and a set of variables *V*. A constraint is an *n*-ary relation among a sub-set of *V*. Each constraint has a set of methods, any of which may be executed to cause the constraint to be satisfied. Each method uses some of the constraint’s variables as inputs and computes the remainder as outputs. A method may only be executed when all of its inputs and none of its outputs have been determined by other constraints. A user may be willing to relax some constraint if not all of them can be satisfied. This is represented by labeling each constraint with a *strength*. One of these strengths, the required strength, is special, in that the constraints it labels *must* be satisfied. The remaining strengths all indicate preferences of varying degrees. There can be an arbitrary number of different strengths. If *C _{0}* is defined to be the required constraints then

A *solution* to a given constraint hierarchy is a mapping from variables to values. A solution that satisfies all the required constraints in the hierarchy is called *admissible*. There may be many admissible solutions to a given hierarchy. However, since the preferred constraints should be satisfied as well as possible, with respect to their strengths, there are intuitively a set of *best* solutions that, besides their satisfying the required constraints, also satisfy the preferred constraints such that no other better solution exists (note that there may be several different best solutions). To define the set of best solutions formally a *comparator* that compares two admissible solutions is required. A number of different comparators can be used. These comparators differ as to whether they measure constraint satisfaction using an error metric or a simple Boolean predicate (satisfied/not satisfied). They also differ as to whether they compare admissible solutions by considering one constraint at a time or whether they take some aggregate measure of how well the constraints are satisfied at a given level. Comparators that compare solutions constraint-by-constraint are *local*; those that use an aggregate measure are *global*.

Constraints are convenient mechanisms for specifying relations among objects. They may however lead to problem definitions that are very difficult to solve. Furthermore, different applications have different requirements and preferences. Some applications require a fast and restricted algorithm that finds one solution (not all), whereas other applications (e.g. general engineering tasks) may require a more complete algorithm and accept that such an algorithm is slower and requires more computational power.

In some applications (e.g. user interface applications) the constraint hierarchy can change frequently while at the same time the constraint solver must be able to find solutions without reducing responsiveness. Freeman-Benson et al. (1990) describe an incremental constraint solver that uses the DeltaBlue algorithm. The DeltaBlue algorithm maintains an evolving solution to the constraint hierarchy as constraints are added and removed while it minimizes the cost of finding a new solution after each change by exploiting its knowledge of the last solution. The DeltaBlue incremental constraint solver exploits the fact that the user’s actions often have only local effects on the constraint hierarchy. In such a case, it is more expedient to maintain an evolving solution, making only minor changes to this solution as constraints are added or removed, than it is to solve the constraint hierarchy from scratch every time. Experience with the DeltaBlue constraint solver is also described in Sannella et al. (1993). SkyBlue is a successor algorithm to DeltaBlue (Sannella, 1995). SkyBlue is substantially different from DeltaBlue. To support multi-output methods and cycles, SkyBlue uses a backtracking search to construct *method vines* when selecting methods to execute and generalizes the concept of *walkabout strengths *used in DeltaBlue. A comprehensive description of SkyBlue is provided in Sannella (1994).

The use of constraints provides a way of stating problems declaratively, i.e. what must be satisfied, without having to state a detailed way of reaching the solution, i.e. define how to solve the problem. For this reason, they constitute a highly appropriate way of expressing original design problems, and the suitability of using constraints to support conceptual design has been described for instance by O’Sullivan (1999). Even in parametric product models (especially in, but not limited to, embodiment design), constraints have become a common technology to connect objects and make calculations.

O’Sullivan (1999) presents a contribution to the body of knowledge in the fields of constraint processing and computer-aided design. O’Sullivan describes an approach to how constraint processing can be used to support conceptual design. The concept of the function-means tree is extended and used as a vehicle for interactively developing alternative constraint-based models of a product having particular properties while providing a particular functionality (Figure 22). Furthermore, the concept of Pareto optimality is used within the constraints paradigm to actively prune uninteresting parts of the design space. An interactive approach is used to ensure that the designer’s expertise, knowledge, and creativity are utilized.

O’Sullivan (1999) refers to Serrano (1987) as one of the earliest works in the field of constraint management for conceptual design. At MIT Serrano’s work resulted in the development of a computer tool called "Concept Modeler". The system is based on a set of graph processing algorithms that use bipartite matching and strong component identification for solving systems of equations. The system allows the designer to construct models of a product using iconic abstractions of machine elements. A number of issues are, however, not addressed as for instance the dynamic nature of conceptual design. During conceptual design, constraints may be added or deleted at any point.

Figure 22: Icons to represent function and means (O’Sullivan, 1999).

O’Sullivan (1999) further refers to Buckley et al. (1992) and Reddy et al. (1996) as concerns a system called "Design Sheet" that facilitates flexible trade-off studies during conceptual design. The system permits a designer to build a model of a design by entering a set of algebraic constraints which can then be used to change the set of independent variables and perform trade-off studies, optimization, and sensitivity analysis.

O’Sullivan (1999) also briefly describes the CADET (Computer-Aided Embodiment Design Tool). CADET assists the designer in formulating and satisfying large sets of algebraic constraints and comprises a generic database of components that can be used to develop a constraint-based model of the geometry of the product being designed. CADET uses simulated annealing as the basis for its constraint satisfaction algorithm when solving the constraint-based representation of the geometric product model. Rodgers et al. (1999) discuss more recent work re-implementing CADET in a web-based architecture.

Sabin & Freuder (1996) describe how to approach configuration as a composite constraint satisfaction problem. Selecting and arranging parts is the core of a configuration task. The validity of a configuration is defined in terms of constraints. Sabin & Freuder (1996) state that the constraint satisfaction problem (CSP) paradigm, being highly declarative, domain independent, and simple to use, offers an adequate framework for the configuration task. The basic paradigm is, however, not powerful enough to capture or take advantage of essential aspects of configuration, such as the unknown a priori number of constituent parts of a system or the inherent internal structure of these parts. Sabin & Freuder (ibid.) describe what they refer to as *composite CSP*, which aims to unify several CSP extensions, thereby providing a more comprehensive and efficient basis for formulating and solving configuration problems.

Wilhelms (2005) compares constraint networks with the design matrix in axiomatic design that constitutes a similar view: the design parameter vector (corresponding to the characteristics) yields for a specific design solution an amount of data (corresponding to properties) to be compared to the functional requirements. However, the actual comparison between achieved properties and required properties is not very clearly stated in axiomatic design other than that constraints are recorded. There is little support in finding the relevant characteristics. Determining the relevant characteristics is not necessarily obvious, as they are not known until the effect is chosen and as they vary with different effects. Consequently, design support systems will need to store characteristics and properties as well as methods for analysis (in the sense of gaining the properties from characteristics) and synthesis (in the sense of determining characteristics needed to achieve desired properties).

Wilhelms (2005) views design parameters available for creating products as elementary functions solved by physical, chemical, and biological effects, incorporated in function carriers (e.g. shape, or surface elements) and described by physical quantities (e.g. parameters such as time, length, area, voltage, or heat flux). When choosing *characteristics* (parameters referring to the structure of the design, e.g. material, dimensions, surface treatment) certain *properties *(parameters referring to the behavior, e.g. lifetime) of the chosen solution are obtained as a result. These properties are then compared against the requirements. Only characteristics are directly determinable and possible to manipulate by the designer. Properties are received as a consequence of the chosen characteristics. Properties can furthermore be classified as *external properties *and *internal properties*. External properties are exposed over the system boundary and thus observable and detectable from outside. Internal properties are hidden inside the system and may only be observable through additional measures.* *Choices of characteristics can comprise: the type and number of functions; the combination of function into a structure (e.g. serial, parallel, or redundant); the type, number, and structure of effects; the type and structure of function carriers; and in embodiment design form, material, dimensions, and surfaces. Analytical models can be applied for the purpose of estimating properties from given characteristics.

Features are based on parametrics, offering a more extensive strategy for arranging the contents of parametric models (Wilhelms, 2005). Features have been found to be a powerful way of describing and storing technical product data by connecting data with non-geometric and geometric structures. Initially, features were conceived to support embodiment design, but they can also be suitable for early phases. Features: (1) constitute *information units* representing a region of particular (technical) interest of one or several products; (2) are described by *aggregated properties* (this description containing relevant properties, their values and their relations and constraints); and (3) represent a *specific view* of the product model, which is related to certain classes of properties and certain phases of the product lifecycle.

Features formalize and embrace a group of properties to make them able to be represented in a product model and permit communication at a higher level, which aligns better with human reasoning in chunks. Features are moreover crucial for expressing the meaning (and enabling semantic product modeling expressing the meaning) of the designed product in addition to its geometric definition. Various aspects are expressed by different feature types, i.e. requirement features, function features, solution principle features, shape features, part features, and technology features. Features are mainly suitable for original and adaptive designs.

Wilhelms (2005) applies a constraint network to model the relations between different parameters in an extended F/M tree (Figure 23). By incrementally constraining an initially undetermined network, the design is increasingly specified. Therefore, there is no need to completely specify an initial state, which aligns with a least-commitment approach. In early conceptual design, it is usually not desirable to commit to fixed parameter values for all parameters. Constraints are defined implicitly, i.e. without direction, and can be used to calculate any variable occurring in them. Changes are incrementally propagated in order to maintain consistency. Determining the propagation direction is not trivial. In an undetermined default state, a requirement’s desired value could steer the evolving design, thus prescribing a certain design parameter. Once the design parameter is chosen accordingly, the direction is reversed, and the determined design parameter produces an actual value for the requirement.

Figure 23: Constraints of different types (Wilhelms, 2005).

Constraints generally occur in several forms: as *value assignments *(a numeric value is assigned to a parameter); as *production rule *(if condition A is the case, then execute procedure B); or as *algebraic constraints *(A, B, C, D, …) relate according to a formula, equation, or inequality).

In the model used in Wilhelms (2005), constraints are used for three purposes: (1) *value assignment *(modeling a decision regarding a parameter value, e.g. to assign a concrete value to the transmission ratio of a gear pair, see type 1 below); (2) *requirement-function *assignment (modeling that a function is declared responsible for fulfilling a goal setting requirement, e.g. a function "provide torque" is set as being responsible to fulfill a requirement stating the necessary torque, see type 2 below); and (3) relations *between variables* (to model relations between functions and means, see detailed examples for types 3-5 below).

The constraints for these purposes can operate on different objects, which results in the following five constraint types occurring in the information model: (1) *value assignment *to parameters in means (values are never assigned to variables of functions); (2) *requirement-function *coupling (requirements are never coupled to means in order to ensure easy exchangeability); (3) *internal *constraints between parameters of the same means (applied to describe physical effects); (4a) *external *relations between the parameters of two different functions; (4b) *collecting external *relations between a parameter of a means and a parameter of one of its sub-functions (e.g. to calculate a total mass from all contributing sub-functions); and (5) *identity *constraints between a parameter of a function and the corresponding parameter of one of its means, namely the one that is currently selected into a concept. Upon selection of a means into a concept, these constraints are automatically set and removed again when deselecting the means. In this way the general means description is connected to the task specific function structure.

Re-use requires three basic operations: *detaching *a solution element from the current context in the product model, which will break inter-element relations across the re-use boundary and enable storing the detached solution element in generic format in a database; *re-attaching *a solution element from a database to a new context in a product model, which will create or restore suitable inter-element relations across the re-use boundary, so that the inserted solution can interact with the adjacent solution elements; Synthesis as the *adaptation *of the re-used solution element’s characteristics so that it becomes suitable and fulfills its purpose in the new context together with other solution elements that exist or are to be created or re-used.

A reusable solution element must have clear boundaries and well-defined interfaces. Therefore, in order to achieve reusability, inter-element couplings must be systematically structured.

The importance of a modular, well-structured constraint network for re-use has been recognized for example in Arndt et al. (2000). The authors there suggest dividing according to constraints over parameters in one single system and constraints over parameters of different systems (within the same sub-system or across sub-system borders). This division into *internal *and *external *constraints is used by Wilhelms (2005) and extended to be able to express relations between requirements, functions, and solutions.

Go to table of contents.