1. INTRODUCTION
In the literature, terms such as design rationale (e.g., MacLean et al., Reference MacLean, Young and Moran1989; Rosenman & Gero, Reference Rosenman and Gero1998; Ullman, Reference Ullman2002; Bracewell et al., Reference Bracewell, Ahmed and Wallace2004) and requirements rationale (Sutcliffe, Reference Sutcliffe1995) tend to indicate approaches for tracing design decisions to solutions and design requirements, respectively. According to Moran and Carroll (Reference Moran and Carroll1991), design is the process of making the tangible out of the intangible. Considering this, design rationale can be treated as a formal means of exploring this process (Dillon, Reference Dillon1997). For the purposes of this article, design rationale is a means of representing design reasoning for guiding decision making, keeping track of developed designs, and accumulating knowledge about potential solutions (Rosenman & Gero, Reference Rosenman and Gero1998; Sutcliffe et al., Reference Sutcliffe, Economou and Makris1999; Bracewell et al., Reference Bracewell, Ahmed and Wallace2004; Brown, Reference Brown2006). In a similar way that design rationale refers to why a solution has been chosen or developed, an approach for eliciting design requirements from customer requirements, referred to as requirements rationale, has been suggested by Sutcliffe et al. (Reference Sutcliffe, Economou and Makris1999). However, this approach refers only to a systematic combination of techniques for eliciting customer needs and attributes based on prototypes and questionnaires, and not to a systematic approach for analyzing and translating them to design requirements. Other approaches refer mainly to the source and to the contributor aspects of stakeholder requirements definition (Gotel & Finkelstein, Reference Gotel and Finkelstein1995; Pohl, Reference Pohl1996). For example, Gotel and Finkelstein (Reference Gotel and Finkelstein1995) emphasized the consideration of so-called “pretraceability” (Gotel & Finkelstein, Reference Gotel and Finkelstein1994; Pohl, Reference Pohl1996; Haumer et al., Reference Haumer, Jarke, Pohl and Weidenhaupt2000), and suggested the use of contribution structures for capturing the rationale of stakeholder requirements. Such structures support the identification of interrelationships between humans involved in the definition of stakeholder requirements. Ramesh and Jarke (Reference Ramesh and Jarke2001), in their work toward the establishment of reference models for requirements traceability, observed that the rationale of stakeholder requirements is usually captured as notes; they also observed that the detailed capture of such rationale is impractical because it is a labor-intensive and expensive process, with few tools to facilitate the process.
Ullman (Reference Ullman2002) reported that a way forward for computer-aided design systems is the integration of the functional requirements developed with quality function deployment (QFD)-type methods and the constraints on function and geometry that drive the development of components. He further commented that as the design process evolves from conceptual to detail design, there is a shift on the source of constraints imposed on the design: from constraints imposed outside the control of the designer to constraints imposed based on previous design decisions. Consequently, Ullman highlighted a need to support reasoning behind design decisions. The use of design rationale systems could be one way forward. For example, Reich (Reference Reich2000) adapted QFD to improve its capability with respect to capturing design rationale, and Stahovich and Raghavan (Reference Stahovich and Raghavan2000) offered an approach for computing causal explanations of the purposes of the geometric features on the parts of a device. Brazier et al. (Reference Brazier, Langen and Treur1997) developed a generic task model that specifies the role of design history and design rationale within the design process. The model distinguishes between different types of design rationale based on the functional role they play in the design process. These include information, for example, about options considered for the design decisions and criteria upon which design decisions were made. Regli et al. (Reference Regli, Hu, Atwood and Sun2000) reported a survey on design rationale systems and concluded that, although a number of prototype systems have been developed, the majority of them are still in the laboratory stage and thus impractical for use in industry. They further indicated that research efforts should focus on bringing theoretical constructs to a level at which they can be effectively deployed in practice. Obstacles to this are the technical challenges of organizing and managing knowledge, and the design challenges associated with developing useful and usable systems so that there are identifiable benefits to the product teams that use them. A number of design rationale techniques are offered in the literature for supporting the traceability of functional architectures of products (i.e., the derivation of design requirements from design parameters; e.g., Tseng & Jiao, Reference Tseng and Jiao1998; Jiao & Tseng, Reference Jiao and Tseng1999; Harding et al., Reference Harding, Popplewell, Fung and Omar2001; Suh, Reference Suh2001; Bracewell et al., Reference Bracewell, Ahmed and Wallace2004; Eckert et al., Reference Eckert, Clarkson and Zanker2004); for example, Bracewell et al. (Reference Bracewell, Ahmed and Wallace2004) developed a software tool that enables the capture and documentation of engineering design rationale during the design process. However, these techniques do not provide a comprehensive traceability scheme to support the derivation of design requirements from stakeholder needs and hence capture the design rationale at this early stage. In conclusion, the aforementioned research efforts provide powerful methods and tools for capturing, documenting, and tracing the reasoning behind concrete technical design decisions. However, such efforts do not deal with the reasoning behind the intents of customers and other stakeholders.
1.1. Aim and structure
The scope of the work outlined in this article is that of new product introduction. Its aim is to establish a framework of intentional analysis and its associated methods and techniques for improving design practice during the early phases of the design process. To this end, a key objective of the work is to assist product design teams to improve their ability to demonstrate alignment between the definition of product features, and the identification and analysis of stakeholder needs.
The remainder of the article is structured as follows. Section 2 outlines the key part that intentional structures can play in improving the effectiveness of design rationale systems by focusing on antecedence and consequence. Section 3 presents a framework to support analyses of evolution (central to design rationale systems), and details fundamentals of antecedence and consequence. It also describes instances of the framework at work, drawing examples from the aerospace and power sectors. Section 4 discusses the importance of antecedence and consequence to systematizing the analysis of complex change, presents the conclusions from this study, and gives directions for future research.
2. THE IMPORTANCE OF ESTABLISHING INTENTIONAL STRUCTURES IN DESIGN RATIONALE SYSTEMS
Identification of latent or unarticulated customer and other stakeholder needs has been a significant barrier to improving the efficiency and effectiveness of the front-end phase of new product development processes (Maruca, Reference Maruca2000; Cagan & Vogel, Reference Cagan and Vogel2002; Karkkainen & Elfvengren, Reference Karkkainen and Elfvengren2002). A number of researchers have carried out work in this area. For example, Bruce et al. (Reference Bruce, Wooton and Cooper2000) provide a framework for a requirements capture process. However, this framework is limited to a set of necessary activities, by way of guidelines, for accomplishing effective requirements capture. An explicit method for capturing and analyzing requirements is not provided. Yan et al. (Reference Yan, Chen and Khoo2002) argue that they can elicit customer requirements through an integrated approach based on a sorting technique of single-criterion and fuzzy evaluation. However, sorting techniques are only effective for identifying objective customer requirements based on the preferences of the customers. That is, they are appropriate for ensuring the definition of product attributes but they are not suitable for identifying the underlying needs (apparent or latent) of customers. Morris et al. (Reference Morris, Stauffer and Khadilkar1996) use a customer-focused design taxonomy for identifying customer requirements from a diversity of sources in a given customer context. However, the effectiveness of this kind of taxonomy is biased by the subjective nature of the data gathered from the customers. Again, Morris et al. (Reference Morris, Stauffer and Khadilkar1996) do not address the identification of customer needs. Maruca (Reference Maruca2000) identifies a need for a systematic way for delineating customer needs in more depth than such taxonomies allow. Furthermore, the relationships between the different types of customer data need to be explicitly articulated.
A key to innovation in product design is the decoupling of specific needs from specific solutions or specific design ideas (Agouridas et al., Reference Agouridas, Baxter, McKay and de Pennington2001, Reference Agouridas, McKay and de Pennington2004). There are two issues here that should be taken into account (Agouridas, Yagou, et al., Reference Agouridas, Yagou and Langrish2006):
1. Some needs exist only because of a given solution. In other words, these needs are associated with, or coupled with, a given solution. Therefore, these are solution-dependent needs as they are derived from the adoption of a given solution (see Agouridas et al., Reference Agouridas, Baxter, McKay and de Pennington2001; Suh, Reference Suh2001).
2. Some needs exist irrespective of the existence of a solution. In this case, needs are “looking” for solutions, and hence, are solution independent. (Agouridas, Marshall, et al., Reference Agouridas, Marshall, McKay and de Pennington2006; Agouridas et al., Reference Agouridas, McKay, Winand and de Pennington2008).
Underlying or latent customer needs can be identified in a systematic and traceable manner by decoupling specific needs from specific solutions (Agouridas et al., Reference Agouridas, McKay and de Pennington2004; Agouridas, Marshall, et al., 2006). This is where leap innovation can take place.
2.1. Antecedence and consequence
In-depth determination of stakeholder needs (principally customer needs) entails analysis of their intentions together with subsequent identification and detailed analysis of the antecedent states of those intents. An antecedent state constitutes a necessary condition for another state being actual: it is the reason why things are as they are (Dement, Reference Dement2003). To understand, and therefore meet and satisfy a customer's needs in a given situation, it is crucial to be able to trace those needs to their antecedents. Merely taking them as given, tends to result in poor service for two reasons: it fails to appreciate the customer's own possible lack of information about their needs and why they are as they are, and so fails to provide an independent basis for correcting such misconceptions; and connectedly, it fails to anticipate changes to the customer's needs that arise from their own unanticipated need to react to changing circumstances. It is preferable to be running ahead of the customer than running after them, and appreciation of the antecedents to a customer's needs is the key to this ability. However, it is not enough to simply guess at how a customer's needs arose: it is important to have a reliable, consistent, and self-correcting method for tracing these needs. This same method can and must be used to plan how the needs are to be fulfilled, in other words, to design the consequents of the analysis.
Needs analysis should take account of and analyze the strategic antecedents of all stakeholder intents, not just the technical customer intents. Stakeholders include not just the customer's employees and shareholders, but all with a vital (strategic) interest, positive or negative, in the success of the customer's enterprise. This includes partners, including the service provider itself, local communities, lawgivers and regulators, and even competitors. The method of deriving a system to fulfill customer needs proceeds in stages:
1. elicitation of customer needs,
2. formalization and validation of these in terms of all stakeholder intents,
3. instantiation of the formalized needs in an antecedent/consequent structure,
4. derivation of consequents as action plans directed at fulfilling the needs, and
5. translation of these plans into proposals for a detailed architecture of organizations and processes for fulfilling these plans.
Ideally, one would elicit statements of intent from all stakeholders in an enterprise: in practice, many can be assumed or taken for granted; the most detailed statement obviously comes from the customer. In general, however, adherence to a well-motivated formal scheme elucidating all the essential aspects of antecedent stakeholder intents and customer needs together with a clear analysis of how ensuing actions and the way in which the organization is to be structured or modified effectively to carry out these actions will help to ensure that success in meeting customer needs is a more systematic, less hit and miss affair.
2.1.1. Intentions, wants, and aims
The original and primary kind of intention is one had by an individual person; derivately, intentions are ascribed to groups and organizations. In the primary sense, an intention is a mental state in which an individual, the subject of the intention, is resolved to attempt by their own agency to bring about a certain possible future event or state of affairs. This event or state of affairs is the aim of the intention. Aims may be more or less grandiose. A subject may aim to change the world in some big way, or merely to do something simple, like taking a drink of water. Aims may be distant or proximate, depending on how long they are expected to take to realize. They may be more or less probable, and more or less risky, to the subject and/or to others. Some aims are time specific: they have to be done at or before a certain time, or between two times. Others are time indefinite.
The aim of an intention may or may not be realized. If it is realized, the intention is fulfilled. If it is not realized, the intention is thwarted. Furthermore, if the subject brings about the aim by her/his actions, s/he succeeds in the intention; otherwise, s/he fails in the intention. A thwarted intention is never one in which the subject succeeds, but a fulfilled intention may be one in which the subject fails, because the aim is brought about by another agency. If two assassins independently wish to kill a public figure, and one of them succeeds just before the second gets his chance to try, the second's intention is fulfilled, but he fails because the aim is achieved not by his action but by that of the other assassin.
Subjects intend to do something typically because they believe that succeeding will be beneficial to them in some way: success answers a want on their part. It is senseless to want something you believe yourself already to have. I may believe myself not to have a certain book and so want it, but unknown to myself I already have it. My want is misplaced but not absurd. If I knew I had the book it would be absurd to want it.
A subject cannot have an intention without having at least some idea of how they will attempt to carry it out. Without this, an intention is not genuine but merely idle. Intentions come in differing degrees of seriousness. An idle intention is one without seriousness at all; serious intentions tend to take more effort in planning and execution. However, in the case of standard or routinized actions, the effort is typically minor unless some unexpected impediment occurs. An intention's seriousness may be gauged in part by how strongly the agent prevents planning and execution being impeded by other concerns. This is what is now known as prioritizing.
2.1.2. Actions and attempts
An action, or sequence of actions, which a subject performs with regard to fulfilling an intention constitute an attempt or part of an attempt to realize the aim. An attempt may be unsuccessful and yet the aim achieved if a subsequent attempt is successful. The way in which a subject attempts to realize an aim is the method. Resources used in the attempt constitute means toward realizing the aim.
Like any action, attempts to realize an intention have consequences. Some of these are intended, others are not. Where the consequences include the realization of the aim, clearly the intention succeeds. Most actions have unintended and unforeseen consequences, which may be advantageous or disadvantageous to those affected by them. Consequences, intended or unintended, may assist in realizing an aim, or may help thwart it, or be neutral. It may be worse to succeed in achieving an aim than not, if the costs and consequences of executing it are outweighed by the benefits of attaining it.
Executing or attempting to execute any intention except the simplest involves planning and breaking down the method into sequences of subactions required to secure the overall result. Each subaction in a method is itself the aim or object of a subsidiary intention or subintention of the overarching intention. Anticipated costs and benefits typically vary from those actually accruing, just as anticipated consequences typically vary from those actually occurring.
2.1.3. Scope and coordination
Intentions are frequently ascribed to groups and organizations, in those cases where the group or organization act together in a more or less coordinated way to achieve the aim. The sort of thing that can be intended by a group or organization differs usually in scale, complexity, and effort required from those that can be done by one agent alone. It may take several people acting together to lift a heavy object when one alone could not. Likewise, it takes many people to field a football team, build an aeroplane, fight a battle, or send men to the moon. Group or organizational intentions involve the individual participants themselves wanting to achieve the aim and personally intending to play their part in realizing the aim, at least in sufficient numbers to give it a chance of success.
The coordination of significant numbers of agents in complex production is obviously a principal task of any management, and for this to work smoothly it is desirable for all members of a product development team to be clear how their role relates to the ultimate aim of satisfying stakeholder needs. That is, all actions, products, and features of products should, in principle, be traceable to aspects of stakeholder needs. We call this the normative requirement of traceability in design rationale. Traceability fulfils two roles: it promotes better design, and it maintains team coherence. A design that is not produced with traceability in mind is one that, if it succeeds, does so by luck, experience, and talent rather than by conforming to a method for demonstrating and ensuring traceability. Having a method for eliciting and maintaining traceability assists a product development team to design products and services that genuinely fulfill stakeholder needs. With a method according to which the aims and intermediate steps to achieving them are articulated and publicly shared, members of the team may remain effectively coordinated during the realization of these aims, supporting intersubjective evaluation that the aims are being met, or highlighting the need for corrections if they are not.
3. ANALYSIS OF EVOLUTION: FUNDAMENTALS OF ANTECEDENCE AND CONSEQUENCE
An essential part of the analysis of design rationale for all stakeholders is the notion of results of a change, in particular, the consequences of an action. Every evolution, which is a change or sequence of changes, consists of a number of elements invariant in kind. Every evolution, large or small, intended or not, starts from a status quo, an initial or antecedent situation, as shown in Figure 1.
Fig. 1. The main elements in evolution.
The antecedent situation consists of people and things involved (collectively: participants, also referred to as resources) and the processes and states involving them (collectively: conditions). In any change, some participants survive, others do not, yet others are newly introduced. Some conditions persist, others cease, yet others come about. The result, at the end of the evolution, is a new or consequent situation. This is summarized in the diagram shown in Figure 1.
3.1. Evolution analyzed in terms of antecedence and consequence
The descriptive high-level analysis of the main elements of evolution offered in the last section fits any evolution whatever: natural or artificial, organic or inorganic. To render it more useful in analyzing prospective designs, it must be elaborated. Analysis of the current situation, consisting of current conditions and present resources (also referred to as participants), in conjunction with expressed stakeholder intentions, leads to the identification of stakeholder needs not currently satisfied (putative needs), as shown in Figure 2.
Fig. 2. The developed conceptual framework of antecedence and consequence evolutionary relationships. The entities and relationships of the framework were documented in EXPRESS-G. See Appendix A for notation details. EXPRESS-G is the graphical notation of the EXPRESS data specification language (ISO10303-11).
A proposal is then framed to satisfy them in a projected new situation, which differs from the current one by the addition of new items or the modification or loss of old items, these changes summarized as a collection of difference or “delta” relationships. The projected situation and the actualization process leading to it must then be subject to domain-specific evaluation against stakeholder needs, as shown in Figure 2, highlighting the gains and losses, benefits and costs, of the projected course of action. Under this evaluation, some conditions are found to be likely to enable, promote, and support the change, whereas others will tend to block or inhibit it (yet others may be neutral). Typically, several projections should be comparatively evaluated against one another as well as against the status quo, and the one with the highest expectation of stakeholder satisfaction selected. If necessary, the evaluation can be fed back to prompt a reconsideration and revision of perceived stakeholder needs.
The conceptual framework described above underpinned the approaches adopted, and the tools and methods developed, to address issues in the application cases described in Section 3.2. The unlimited scalability of this scheme should be stressed. In any process of actualization, which in the case of design is simply planned evolution, the current situation stands to the projected situation as antecedent to consequent. This characteristic relationship recurs internally within the actualization process, as one phase of actualization gives way to another; it also recurs beyond a given pair, as the projected situation is actualized and becomes current, to serve as antecedent to further consequents. Because of its extremely general nature, the scheme of antecedent and consequent, and its role in evaluation feedback, is applicable at any level of scale and detail. We have to emphasize at this point that the scheme provides only a conceptual foundation and not a set of specific methods; that is, large and complex applications (i.e., nontrivial) may require tailor-made methods and tools in support of establishing robust and effective traceability structures. The scheme therefore aids the design of the final situation to consider and evaluate the effects at each stage of actualization against assumed stakeholder needs, with respect to all relevant antecedent and consequent items, and as will be discussed in Section 4, it also may be applied to the design of design processes.
3.2. The scheme in action: Two cases
The conceptual framework outlined in this article did not arise in the abstract, but was developed in the course of attempting to solve design problems originating in industrial contexts. The methods developed were thus evaluated, updated, and refined (Agouridas, Reference Agouridas2007) in real applications. Two of these applications are described. One is drawn from the aerospace sector and is directed toward enterprise design. The other comes from the power sector, and is directed toward product design.
3.2.1. Aerospace sector
A case on which one of us worked for a period concerns an airframe manufacturer. At the time, this company, one of the world's largest manufacturers of military aircraft, was facing a difficult transition from the practices and attitudes of the Cold War era to those of its aftermath. Whereas previously the state-funded military budget had partly shielded the company from commercial pressures toward efficient and economically self-sustaining manufacture and new product development, under the new conditions of more open competition and more restricted state budgets, the entrenched practices and attitudes of two generations were making it harder for the company to adapt and survive. The facility in question, one of several owned by the company, but an important one, was suffering from several quite severe problems: it was working well under capacity, sales of established products were disappointing, and the costs and developmental delays of new products were both increasing, prospectively beyond the willingness of their primary customer (the government and military) to tolerate. The manager responsible for turning the facility around was able easily to list over 50 desiderata, large and small: the problem was how to turn this wish list into a workable strategy for the future, indicating the desired direction of development. An analysis of the status quo readily showed the current situation: the problem was to discern and aim for a satisfactory future situation. Using formal methods to break down the analysis and desiderata according to the various stakeholder needs, and consolidating the desiderata into several distinct but complementary goals, it was concluded that the facility should focus more tightly on providing total, integrated solutions to the stakeholder needs that had been thus articulated.
Because they were unable to provide total solutions in-house, one of the principal recommendations was to seek and consolidate partnerships with organizations, both within and outside the larger corporate group, to achieve these solutions. Some processes essential to continuing in the business were to be retained; others, such as the transition to lean manufacturing techniques, were to be speeded up, whereas assets and processes, which on the analysis were marginal to providing the solutions, were to be phased out or discontinued, or if necessary, outsourced to partners, even erstwhile competitors. The case served as a test bed for applying the formal techniques developed to guide change in manufacturing to the case of change in the manufacturing organization itself. What seemed at first to be merely a loose analogy (between products and enterprises) proved to be more: the closer we considered and investigated, the more it seemed that the two cases had exactly the same form, differing only in content. The proposals for aligning stakeholder needs more closely with the facility's operation were discussed by the management and were considered highly promising. They did not proceed to implementation of the proposed changes, however, because a larger scale reorganization of the group intervened. This reorganization, although it curtailed local autonomy and put a stop to implementation of our proposals, in effect largely corroborated our analysis because it resulted in the facility being integrated more closely into the wider group with the intention that stakeholder needs indeed be fulfilled in a more transparently traceable way.
3.2.2. Power sector
A case on which the other one of us worked concerns a case study provided by a globally leading company in the power sector. As part of its core business, the company brings to market large power systems. Such products require material investments to develop and support, and their development requires careful planning. The company has a strong track record in the delivery of such large power systems to its core markets. In this instance, the case study focused on a microturbine for commercial use to meet the demands of emerging distributed power needs. This is a much less complex product than the company's large power systems and more commercially wide compared to its core systems offered. Therefore, the research team proposed a new supplemental approach that would capture and analyze fully stakeholder needs and attributes. One may think that QFD (Hauser & Clausing, Reference Hauser and Clausing1988) could have been proposed instead, as it seems to fundamentally cover the same ground as the proposed approach. However, this is not the case, as QFD has been widely criticized in the literature for its relative ineffectiveness at translating customer and other stakeholder needs into engineering characteristics. This is particularly true for totally new products (Schmidt, Reference Schmidt1997; Brackin & Colton, Reference Brackin and Colton1999; Dawson & Askin, Reference Dawson and Askin1999; Sohn & Choi, Reference Sohn and Choi2001). In addition, the analysis offered by QFD focuses only on determining technical design targets from specific customer requirements; it is assumed that the analyzed customer requirements represent the underlying needs and attributes of the customers. Detailed analyses on the limitations of tools and methods on the derivation of design requirements from stakeholder needs can be found in the literature (e.g., Agouridas, Winand, et al., 2006; Agouridas et al., Reference Agouridas, McKay, Winand and de Pennington2008).
A small team had identified that satisfaction of customer needs, as well as consideration of competitive products, were the most critical success factors in the development of a microturbine for distributed power. A large number of customer and other stakeholder requirements were identified based on initial market research and literature. The research team selected key stakeholder requirements for further analysis. The selection was based on the experience and appreciation of all team members (i.e., research and product teams). The situation was that the majority of the selected stakeholder requirements were both discursive and solution dependent. A comprehensive analysis based on the conceptual framework presented in Figure 2 was carried out using a number of requirements engineering and management tools and techniques (for details, see Agouridas, Marshall, et al., Reference Agouridas, Marshall, McKay and de Pennington2006; Agouridas, Winand, et al., Reference Agouridas, Winand, McKay and de Pennington2006; Agouridas et al., Reference Agouridas, McKay, Winand and de Pennington2008). Figure 3 gives a part from the blueprint of the derived design requirements from the analysis. Note that the exact determination of performance requirements for both functional requirements and global constraints proved challenging, and in many cases was left incomplete (see question marks in Fig. 3). Two reasons for this were the lack of access to the diversity of the required information sources and the need to execute separate studies (e.g., technical and commercial) to acquire the necessary data. These two reasons underscore an important pragmatic issue. For an approach or framework to be successful in practice, the matter of information access must be addressed. The value from the use of the proposed approach, which was underpinned by the conceptual framework presented in this article, originates from the fact that the approach indicated to the team analysts that they had to look at some information that otherwise would have been overlooked and/or lost. Such information was not accessible at the time of the study, but actions (informed from the analysis offered by the approach) were planned by the company to attain the required information. It has to be clarified that the presented conceptual framework aims to ensure that topics and issues that are usually overlooked are considered, and hence, to give direction on identifying sources of information, not of finding the sources themselves. As such, the framework can support teams of analysts in their confidence that important factors are not missing from their analyses.
Fig. 3. A part from the blueprint of design requirements derived for the microenergy solution study. Note that the blueprint of design requirements was informed by work on a functional basis carried out by Hirtz et al. (Reference Hirtz, Stone, McAdams, Szykman and Wood2002).
Reflective analysis on the application of the proposed approach showed that the task of identifying stakeholder needs, attributes, and the relationships between them proved beneficial for the product development team. In effect, these tasks allowed them to deepen their understanding of the problem at hand. Specifically, insights were gained into product and commercial issues. Examples of product issues included accessibility, interfaceability, modularity (e.g., potential use of energy slice modules), and supportability required for the operational effectiveness of the microenergy solution. Commercial issues included branding strategy linked with the delivery of small power packs that differed from that of the large power systems for which the team's business is known. The use of the intentional structure appliedFootnote 1 (Agouridas, Winand, et al., Reference Agouridas, Winand, McKay and de Pennington2006) allowed the members of the product development team to gain a common view on a variety of issues through the removal of misconceptions. This structure proved useful for linking strategic needs dimensions with actual stakeholder needs (for details, see Agouridas, Winand, et al., Reference Agouridas, Winand, McKay and de Pennington2006; Agouridas et al., Reference Agouridas, McKay, Winand and de Pennington2008). Further, the structure proved useful for positioning design alternatives with respect to their competition in terms of technical and other product characteristics. It should be noted that competition related to technical and commercial stakeholder attributes was not analyzed adequately owing to insufficient information and time constraints. Similarly, issues related to volume manufacturing and supply chain management required further analysis, facts that the application of the intentional structure highlighted to the integrated project team.
Articulation of the concepts and relationships of the presented conceptual framework through the applied intentional structure (Agouridas, Winand, et al., Reference Agouridas, Winand, McKay and de Pennington2006) helped the team to clarify and articulate crisply a number of points. For instance, the product development team was supported in linking the power system product with the wider power solution as a whole. This assisted with the articulation of some of the stakeholder needs, which could otherwise not be easily defined. In addition, because of the iteration allowed and supported by the intentional structure insights were gained by the product development team through the determination of relationships between stakeholder needs and attributes. Hence, this enabled the team to augment its confidence in mapping relationships between needs and attributes of prospective solutions. In the end, this helped the team to derive design requirements that were aligned with stakeholder intents.
Overall, the analysis based on the conceptual framework presented in Figure 2 proved useful to the company because it provided additional market insights with respect to explicitly analyzed significant stakeholder requirements, technical insights with respect to the development of solution-independent high-level design requirements for a microenergy solution, and business insights with respect to strategic management issues. The company acknowledged that such insights would support decisions on prospective offerings (portfolio management) through listening to the market and explicitly analyzing its requirements as well as prove beneficial not only to identify significant business issues and insights into the development of a microenergy solution but also to highlight underappreciated issues, thereby derisking the project.
4. DISCUSSION AND CONCLUSIONS
The presented framework builds upon the cross-fertilization of approaches and methods drawn from two distinct subject areas: systems engineering and philosophy. Systems engineering principles, as applied to the early phases of electromechanical product development, provide domain specific context, techniques, and tools; philosophy provides depth analysis of the concepts essential to the effective and efficient implementation of these techniques and tools.
The methodological assumption of this study has been that successful design rationale requires a background analysis that is philosophical in its generality. Any adequate analysis of the evolution brought about by an action attempting to fulfil an intention, and any elucidation of the need to align design attributes to stakeholder needs, entail the employment and depth analysis of such general concepts as action, change, need, requirement, relation, property, condition, and process. Such analyses are nothing new. They were first pursued systematically by the philosopher Aristotle (384–322 BC), and have been integral parts of Western thought ever since. The primary battles about how these concepts are to be analyzed and related have been fought and largely decided, but at the margins there is still room for disagreement, so it is necessary even when using philosophical analyses to assist in understanding such a complex notion as traceability that one pursue an approach which promises stability, consistency, and above all, systematic comprehensiveness. We have therefore focused on the entities involved in any case of change by intention, rather than on what we happen to know about in a particular case. In philosophical terms, we have put ontology above epistemology.
Ontology is “the endeavor to frame a coherent, logical, necessary system of general ideas in terms of which every element of our experience […] shall have the character of a particular instance of the general scheme” (Whitehead, Reference Whitehead1978). What sets it aside from other disciplines is this accustomed aspiration to completeness. In the context of this article, completeness is meant to apply to the elements of evolution and its evaluation via the differences between antecedent/consequent pairs. But it can be invoked at two levels: one at the working level of matching solutions to stakeholder needs, the other at the level of considering the design process itself.
4.1. Antecedence and consequence as key to completeness of requirements in design rationale systems
Generally speaking, design rationale systems aim to support designers to carry out their design analysis work effectively in terms of helping them to navigate through the assumptions, decisions, and trade-offs made and the steps followed during earlier design analyses (e.g., MacLean et al., Reference MacLean, Young and Moran1989; Bracewell et al., Reference Bracewell, Ahmed and Wallace2004; Brown, Reference Brown2006). Considering this, design rationale systems can be regarded as solutions to the requirements of the design process itself. In this article, such requirements are called meta-requirements, to clearly distinguish them from stakeholder requirements for a product. A key meta-requirement of the design requirements derivationFootnote 2 process is that of requirements completeness. The framework presented supports the formalization of stakeholder needs in the light of the comparative effectiveness of projected solutions. That is, assuming a need, a projected situation can be determined and evaluated against already determined and overarching intentions. The outcome of such evaluation is either the acceptance, or refinement or rejection of the assumed need. The developed framework describes entities and relationships that need to be considered when carrying out activities involved with articulating needs (i.e., accepting, refining, and rejecting needs) and matching potential feasible solutions. It should be noted that this article is not dealing with the evaluation of these solutions.
The framework may also be used as a metaframework for the development of systems and processes to guide, monitor, record and document the evolution of design activities (i.e., the design rationale itself). For example, it could be used as a template setting out the steps and activities required to provide support for the evaluation of the adequate derivation of design requirements from stakeholder needs, and hence, to afford greater confidence to product development teams. The process and methods are just the same as for the matching of products or enterprises to stakeholder needs, but the content is shifted to consider applications of the method itself. That the framework can be reflexively self-applied and indeed lead to its own improvement is another indication of its universality.
Lee and Lai (Reference Lee and Lai1991) classified design rationale systems as process oriented (focusing on historical records of design decisions to support selection of design parameters), structure oriented (focusing on the representation of design alternatives), and psychological oriented (a set of psychological claims embodied by an artifact made explicit). The conceptual framework presented in this article incorporates all three of these perspectives. The antecedent/consequent scheme that lies at the center of the framework provides a cell from which to develop either a history of actual successive changes and/or a tree of alternative possible projected designs, and finally, because the approach is based on the key notion of intention, the essential psychological element is incorporated in the capture of design reasoning.
4.2. Concluding remarks
In this article we emphasized the evolution of requirements resulting from changing intentions of stakeholders and status quo of the artifact or system being designed. We also recognized that framing the problem appropriately requires the justification of the framed problems from multiple intentional perspectives. Such an exercise in the framing of the problem can often lead to innovations. As pointed out by Petroski (Reference Petroski1996), innovations are often really reframings of the problem to match the needs that are often unarticulated but felt. We identified the ontological primitives, represented through a conceptual framework, that can be the basis for capturing the entities and the antecedent–consequent evolutionary relationships to provide a more complete picture of the interdependencies inherent in the formulation of the problem. It is acknowledged that the role of methods in design processes whether for rationale, or otherwise, are means for articulation of, and negotiations, among the different stakeholder perspectives. Informality of design requirements is a problem, especially in distributed design teams, because it impacts upon the ability of a team to communicate. Considering this, formalized structures, or structured methods, are valuable in product development processes because, as also highlighted by Ulrich and Eppinger (Reference Ulrich and Eppinger2000), they support explicit decision making that allows a product development team to understand the rationale of the decisions; they act as “checklists” of the key activities in a product development process, and hence, they ensure that important issues are not forgotten; and they are largely self-documenting. Thus, the created records of data can be used for future reference and for educating newcomers. The recording constructs of the presented framework provide a set of building blocks for constructing a boundary object (Bowker & Star, Reference Bowker and Star1999), that is, in a sociological sense, a means to communicate across and within perspectives. This is not surprising; after all, design rationale is both constructed and used collaboratively over space and time.
The described case studies provided an informed evaluation of the usefulness (Agouridas, Reference Agouridas2007) of the presented conceptual framework (boundary object). In specific, the applications within which the framework was developed and evaluated (Agouridas, Reference Agouridas2007) have shown that it provides a systematic representation of constructs that underlie the decisions made in design, and hence, it may be used as a template for any design rationale system. In other words, the framework provides an in-depth analysis of the concepts, and their relationships, that any design rationale system should be built upon. Elaborating on the ways in which antecedents and consequents may be concatenated, related, and evolved is fundamental to the establishment of robust traceability schemes. These, in turn, are a key in improving upstream and downstream impact control.
Future work will explore the extension of the conceptual framework presented in this article to two further operations crucial to adequate design: the formalization of intent,Footnote 3 and the formulation of objectives and measures of assurance. Together, all three operations constitute the requisite activities for the systematic definition of missions, whether strategic or tactical, and of whatever design scale or complexity.
ACKNOWLEDGMENTS
This article is dedicated to our beloved late friend Charles W. Dement, who pioneered the underpinnings of the work presented in this article. The authors thank the referees for their helpful advice and suggestions. Special thanks are due to colleagues from the School of Mechanical Engineering, the Keyworth Institute, and the Department of Philosophy who supported the reported research. This research was partially supported by the UK Engineering and Physical Sciences Research Council through the Managing Asynchronous Product and Process Structures in the Extended Enterprise Project (Grant GR/M56715) and the Knowledge and Information Management Grand Challenge Project (Grant EP/C534220/1).
Vassilis Agouridas is a Design Process Researcher and a Strategic Management Analyst affiliated with the Corporate Strategy and Planning of EADS Headquarters in Paris. His principal research focuses on formalizing the requirements analysis process and on downstream integration management, specifically, on systematic methods for assuring that stakeholder needs and system design attributes are demonstrably aligned. Dr. Agouridas is a Chartered Engineer (registered with the UK Engineering Council), a member of a number of institutions in the United Kingdom, and a member of the international Council on Systems Engineering (INCOSE). He is also a Fellow of the Higher Education Academy (HEA, UK).
Peter Simons is Professor of philosophy at the University of Leeds. His philosophical research centers on metaphysics and ontology, as well as the history of philosophy and logic, especially in Central Europe. During his long-time residence in Salzburg, his prize-winning Austrian Habilitationsschrift Parts: A Study in Ontology was published by Oxford. He is the author of approximately 200 research articles. A keen proponent of the application of metaphysics and ontology, Dr. Simon was an ontological consultant for the US software firm Ontek for many years, and he maintains close contacts with engineers in the UK and elsewhere.
APPENDIX A
EXPRESS-G is a graphical notation for the display of information models. Specifically, it is the graphical notation of the EXPRESS data specification language (ISO10303-11). The notation only supports a subset of the EXPRESS language: that is EXPRESS-G supports the descriptions of entity, type, relationship, and cardinality but it does not support the specification of constraints described in EXPRESS. Therefore, EXPRESS-G models are normally abstractions of EXPRESS models. EXPRESS-G has symbols to represent EXPRESS entities, user-defined types, base (simples) types, enumeration types, relationships (required and optional), and inheritance.
Figure A.1 provides a key to EXPRESS-G constructs (symbols) used in this study. Note that the small circle on the end of the relationship arcs indicates direction only; it has nothing to do with cardinality. The cardinality of a relationship is annotated on the relationship by using text.
Fig. A.1. Key to the EXPRESS-G constructs used in this study.
