How to implement the abstract design paradigm: The ...

Int. J. of Product Development, Vol. x, No. x, 2013

1

How to implement the abstract design paradigm: The case of requirements engineering. Jean-Pierre Micaëlli (1) Samuel Deniaud (2) Éric Bonjour (3) Dominique Loise (4) (1) Associate Professor of Industrial Management, Université de Lyon, INSA de Lyon, ITUS, UMR CNRS 5600 EVS, Campus de La Doua LyonTech, 1 rue des Humanités, F-69621 Villeurbanne Cedex, [email protected]. (2) Associate Professor of Mechanical Engineering, IRTES-M3M, University of Technology of Belfort-Montbéliard, F-90010 Belfort Cedex, [email protected]. (3) Professor of Systems Engineering, Université de Lorraine, ENSGSI, ERPI Research Team, 8 rue Bastien Lepage, BP647, F-54010 Nancy Cedex, [email protected]. (4) Head of Systems Engineering Methodology and Tools, PSA Peugeot Citroën, DRD/PES/MISI, Centre Technique de Vélizy B, Case courrier VVB2200, F-78943 Velizy-Villacoublay Cedex, [email protected].

Abstract This paper presents a framework enabling requirements engineering in accordance with the abstract design paradigm, that is, a systems-modeling conception of, and approach to, design. Its main contribution is to show how the ISO 15288 standard can be applied and how the appropriate development of SysML requirement diagrams can help achieve this objective. ISO 15288 recognizes requirements as design entities and specifies the content of a Requirements Definition Process and a Requirements Analysis Process. We propose using four diagrams to map stakeholders’ requirements, to link these requirements via causal relationships, and to ensure their traceability. We apply the proposed framework to the case of a robotized gearbox design.

Keywords Design, Paradigm, Requirements, Systems engineering (SE), SysML.

1. Introduction Design is recognized as a specific human activity that allows people to satisfy their current needs by creating, within a finite time, satisfactory “artifacts” (Simon, 1997). An artifact, which may be a device, tangible object, software package, network, controlled environment, or governmental program against infectious diseases, etc. (Bunge, 1985), integrates functions (syn. services) the designer has programmed and exhibits expected behaviors (Simon, 1997). Most importantly, it includes a number of heterogeneous elements the designer has laid out and synthesized (Simon, 1997). These characteristics allow artifacts to be conceptualized as purposeful systems (Simon, 1997), that is, as functional sets of consistent, interacting elements that may be static (components within a structure, states) or dynamic (behaviors or processes). Moreover, far from being instantaneous or easy, designing an artifact is a complex process involving numerous tasks. Designers carry out these tasks within projects (Simon, 1995), applying physical (prototypes, mock ups, templates, etc.) or symbolic (sketches, drafts, schema models, software simulations, etc.) tools to do so. Nowadays, designers act within formal structures (teams, projects, communities, etc.) set up by design managers. Designers have knowledge pertaining to both the artifact (object knowledge) and the design process (procedural knowledge) (Simon, 1997), and this knowledge can be “codified” (Foray, 2004) in order to be generalized, standardized or taught. Studying when and how changes in artifacts, design tools, knowledge or organizations appear provides insights into the longterm evolution of design. The way design is carried out, conceptualized, tooled, organized and taught has changed over time.

Copyright © 2013 Inderscience Enterprises Ltd.

2 As Stankiewicz (2000) noted, history has seen a succession of “design paradigms”, with design evolving from a craft process to an empirical process, and then to a scientific process (Stankiewicz, 2000). In the current design paradigm, which has been labeled the “abstract design paradigm” (Bonjour et al., 2011), designing is not about the on-site production or prototyping of an end product; it is primarily about producing, using and transforming abstract models of a future product that downstream designers will make concrete as late as possible. For example, the block diagram schema used by automatic control engineering in upstream design is an archetypal abstract design model. In the late 1960s, a framework known as Systems Engineering (SE) (ISO 15288) was developed in order to put into practice the abstract design paradigm. As its name suggests, SE is based on systems thinking and modeling. It provides concepts that can be used to examine the systemic properties of an artifact. SE defines rules for managing complex design projects and improving the efficiency of the design process. In the 2000s, SE and software engineering specialists worked together to develop a language that “supports the specification, analysis, design, verification, and validation of a broad range of complex systems” (OMG, 2010, p.1). Initially devised by computer engineers for software development, the Unified Modeling Language (UML) was later extended into the Systems Modeling Language (SysML) in order to allow communication with systems engineers (Bock, 2005). SysML is a diagrammatic language that can be used to represent future products without referring to any of their concrete attributes (materials, form, size, weight, etc.). Each SysML diagram provides a clear picture of a particular aspect of a product, for example, its external environment, its use, its requirements, its structure, its behaviors, the physical parameters explaining these behaviors, or its states. Rather than analyzing SysML in detail, the present article examines the contribution SysML and the ISO 15288 standard can make to requirements engineering, that is, how they provide a methodical approach for laying out, analyzing and synthesizing requirements. The current movement towards requirements modeling is the result of today’s abstract view of design and, more generally, of a shift in the design paradigm. We believe this movement can only be fully understood in the light of the history of design; therefore, Section 2 of our article presents a short review of the literature on design paradigms, SE and SysML. This review explains what abstract design is, and the way SE and SysML puts it into practice. In Section 3, we show how ISO 15288 and SysML can be applied to requirements engineering and suggest using a minimum of four SysML diagrams to represent requirements. We illustrate these arguments with respect to a simple application, the robotized gearbox (Bonjour and Micaëlli, 2010).

2. The abstract design paradigm 2.1 From epistemology to design theory The philosopher Thomas Kuhn (1922-1996) was the first person to recognize that the long-term dynamics of the natural sciences are not characterized by a continuous and incremental accumulation of homogenous knowledge. Kuhn realized that scientific progress involves a series of major shifts between what he referred to as “paradigms” (Kuhn, 1962). Derived from Ancient Greek, the word paradigm describes a specific set of notions about a model, an example, or a framework. According to Kuhn, each paradigm incorporates a particular ontology of the world and a set of incommensurable concepts or theories. Thus, pre-Galilean physics has nothing in common with the experimental physics of the Enlightenment, which, in turn, is far removed from modern formalized physics. It should be noted that the term paradigm is mostly of heuristic value. From a static point of view, it can be used to describe the elements that ensure the consistency of the science of a particular time. From a dynamic point of view, it emphasizes the shifts in scientific knowledge and practices. Stankiewicz (2000) transferred the Kuhnian notion of paradigm from epistemology to design theory; identifying three “design paradigms” he named “craft design”, “empirical design” and “scientific design”. We refer to this latter paradigm as the “abstract design paradigm”, in order to remove any ambiguity regarding the adjective “scientific” (Bonjour et al., 2011). For example, Thomas Edison (1847-1931), Frederick Winslow Taylor (1856-1915) and Henry Ford (1863-1947) considered themselves to be scientific designers according to the empirical criteria of the epistemology of their time. Under the craft design paradigm, a single person conceives and produces the end product on site, without making sketches or plans. The designer and the client have the same “archetype” (Schön, 1995) in that they have a shared conception of the end product’s main characteristics (functions or services, form, price, etc.). The archetype issues from a traditional line of products, with each particular solution being a variation on this archetype. Design is learnt by imitation and by the transmission of tacit knowledge, with the apprentice copying the master's gestures and know-how. Knowledge transfer is the result of master craftsmen moving from area to area. French ethnologist Jean Cuisenier (2000) gave an excellent example of the craft design paradigm when he described how the richly carved, wooden gates of traditional houses in the Maramureş region of Romania are designed and built. “Someone who comes and asks me to make a gate doesn’t tell me what I have to make, nor how I should make it. He merely asks me to make a gate, and I know what I have to do”. The client’s knowledge of the different models is very vague, as it is simply based on what he has seen from living in houses with gates and passing in front of ten or twenty similar houses every day. But this knowledge does not give the client the skills to make a gate, so he calls upon a craftsman […] Stephan [travelling gate carpenter-sculptor] adds: “So I go to the client […] And I stay at the

Int. J. of Product Development, Vol. x, No. x, 2013

3

client’s house for 25 or 26 days with my three assistants […]” […] Building a gate is still the work of travelling craftsmen, in so far as master carpenter-sculptors work […] directly at the client’s house, under his eyes, in the street, eating at his table and sleeping in his house or in his relatives’ homes” (Cuisenier, 2000, p.77). As this example shows, clients express their requirements orally and craftsmen never use drawings or models. Requirements are past-oriented in that they refer to a product that complies with tradition. They are validated by continuous iterations as the designing and building progresses. This validation focuses on the end product. A major shift away from craft design took place in the nineteenth century with the rise of industrialization based on the mass production of complex products for anonymous clients. This shift resulted in design becoming spatially and chronologically separated from the workshop and from the location where the end product is used. Design became “empirical” (Stankiewicz, 2000), with requirements being entered into bills of requirements. Designers divide these requirements into modules based on the elements of the product. Each module refers to a single skill that has to be integrated by the design office. For example, a design for a machine can be divided into structural and kinematic requirements. Each type of requirement is managed by a specialist. The empirical design process is based on a trial and error process, during which designers use sketches, mock-ups, and detailed drawings to depict the product. Once a design solution has been reached, the designer validates it by creating a realistic scale model. The main tools in empirical design are test benches, and product behavior is explained by empirical laws derived from engineering science (Simon, 1997), some of which can be translated into usable abacuses. In this paradigm, design is the process of producing a realistic model of the end product as quickly as possible, and then validating it as completely as possible via extensive tests. During the second half of the nineteenth century, another approach to design began to emerge in which engineers began to represent products in a more abstract way. For example, the application of techniques such as kinematic diagrams heralded the beginning of a trend for separating upstream design based on schemas from downstream physical design. In addition, design began to be considered a specific disciple (Simon, 1997). Separating design from production and use represents an opportunity for designers, who now have the autonomy to conceptualize and apply design processes without referring to any particular producer or client. Contemporary design exacerbates this characteristic (Bonjour et al., 2011). Such a separation paved the way for a shift to a new paradigm in which design becomes an abstract process that is modeling and software intensive. As well as being used to describe specific solutions, models can depict any product or design process as a system. Today’s designers use systemic models to describe, understand, explore, and simulate different generic attributes of an artifact that does not yet exist. Models help designers understand an artifact’s environment, its interactions with stakeholders, its functions (syn. services), its performance, its behaviors, and “design patterns” (Alexander, Ishikawa and Silverstein, 1977). Abstract models are important means for “codifying” (Foray, 2004) object or procedural design-knowledge. In addition, they can be supported by software applications. On a large scale, they embody the explicit knowledge produced by a “skills network” (Bonjour and Micaëlli, 2010) or a professional community. Table 1 provides a summary comparison of the three design paradigms described above. It includes entities describing design as a “working activity” (Engeström, 1987). The notion of design paradigm describes design in a rudimentary way. Although this notion is of no practical use in itself, it is relevant to current industrial realities. The way modern cars or aircraft are designed has little in common with the design processes used by automobile and aeronautic pioneers. Our hypothesis is that SE provides a particular way of implementing the abstract design paradigm.

2.2 SE as a way of implementing the abstract design paradigm SE was developed in the United States in the late 1960s (Cook, Ferris, 2007). Its designers were not product designers or design managers, but clients defining specifications for complex systems, such as aircraft, satellites, ships, weapons systems, telecommunications networks, and large software packages, whose design is based on formalized processes and project management tools, and involves numerous contractors with different skills. Over a period of forty years, SE was adopted by many different industries, and several standards (IA 632, IEEE 1220, ISO 15288, etc.) have been developed for SE. In addition, numerous organizations, such as the International Council on Systems Engineering (INCOSE), created in 1990, have been set up to develop SE concepts or tools. SE is not a recipe book. It provides a synoptic view, an ontology of design in which both the product and the design organization are conceptualized. Thus, the designers of SE adopted an optimistic, consensual, and democratic approach to design. SE helps product designers develop satisfactory solutions that maximize the satisfaction of all the stakeholders who interact with a product throughout its life cycle. The design process is based on harmonious collaboration between designers, clients, and managers. In order to control and improve the development of balanced solutions, the entire design process must be structured according to a number of key principles. Without being exhaustive, the following paragraphs describe five of the most important of these principles. The first principle is abstraction. As its name suggests, SE is based on the idea that the purpose of design is not to produce a concrete solution, but to create an abstract entity called a system. This system can then be materialized through a number of different solutions. For example, when designers talk about a “powertrain” in SE terminology, they are not thinking about one

4 particular engine, such as a diesel, Wankel, electric, or hybrid powertrain, they are talking about a system operating in a given environment (building, vehicle, consumer device, etc.). An engine is a system that provides a specific service (mechanical energy), satisfies a certain range of performance criteria (power, acceleration, efficiency, etc.), has a pattern (an engine, a gearbox, an energy distribution chain, etc.), and exhibits functional or non-functional behaviors explained by physical laws (friction, heat production, etc.). It can be modeled abstractly using diagrams, block diagrams, black-box models, etc., that do not mention any multilevel bill of materials. Table 1. Comparison of the three Design Paradigms. Craft Design

Empirical Design

Abstract Design

Designer (who does the designing?)

Craftsman.

Empirical inventor.

Modeling specialist.

Design community (in which community does the designer design?)

Master, the master’s assistants and apprentices, and the client.

The design office is clearly separated from the workshop or the site where the end product is used.

Multidisciplinary teams or professional skills networks or communities.

Design outcome (what is the design outcome?)

End product on site.

Realistic models of a specific product.

Abstract models referring to a wide product family, line or class.

Rules (what insures the coherence of the design community?)

Specialized empirical knowledge in the design office, but Tacit knowledge, shared Local or large-scale, softwaredocuments (agreements, bills, archetypes, and continuous verbal based collaboration (groupware, drawings, etc.) circulate between interactions. workflow, Web 2.0 tools, etc.). the design office and other departments (workshop, etc.).

Design process (how does the designer design?)

Create a suitable artifact as quickly as possible. Design is an end-product-driven process.

Division of labor (how is the work divided?)

Formalized generic processes structure the collaboration between the parties involved in Taylor-system type division of The master drives the whole the design process (stakeholders, labor (functional structure) activity. Assistants and designers, design managers, etc.). between the design office and the Each designer has a particular apprentices carry out the detailed workshop, and between the tasks. role (systems architects, work departments of the design office. package managers, reliability specialists, costing specialists, etc.)

Design tools (what tools does the designer use?)

Mnemonics.

Realistic drawings, mock-ups, templates, prototypes, empirical laws, test benches, abacus.

Languages and software applications.

Learning process (How does the designer learn?)

Imitation. Design knowledge is tacit.

Trial and error learning. Design knowledge is empirical.

Product and process modeling. Design knowledge is abstract and codified in software applications.

Create a prototype as quickly as possible. Design is a prototypedriven process.

Create systemic models as quickly as possible. Design is an abstract-model-driven process.

The second principle is semi-decomposability. The systems SE focuses on are defined as “semi-decomposable” structures (Simon, 1997), as they can be broken down into separate modules (modularization) that may cover several layers, including the complete system, its sub-systems, and derived sub-sub-systems, etc. These systems can be said to have an “integrative architecture” (Browning, 2000), as they gain their coherence from the “integrative elements” (Browning, 2000) they include, which may be bodies, platforms, networks, grids or interoperability standards, etc. (Bonjour and Micaëlli, 2010). For example, a car consists of a body, a chassis, a powertrain system, a dashboard, an interior, and an electrical system. The body, the chassis and the electrical system can be considered integrative elements. Decomposed to a second level, the powertrain system consists of an engine and a gearbox. An engine delivers various services, including injection, respiration, and pollution control, etc. Architects can divide these services into functions that can then be mapped to increasingly detailed and concrete components. The third principle is pluralism. The semi-decomposability of systems has important consequences for the structure of design knowledge, as one of its corollaries is pluralism, or the idea that a single entity (the system) can be addressed from complementary points of view. A black box model of an engine has nothing in common with its representation as a geometrical entity or as a bill of materials. In a pluralist context, two designers can have radically different views of a system. For example, a mechanical engineer sees a motor as a mechanical device that allows a car to move, whereas a designer sees it

Int. J. of Product Development, Vol. x, No. x, 2013

5

as an element that severely restricts a car’s body shape. One of the principles of pluralism is that no one point of view is dominant. Therefore, design must be organized in ways that permit the sharing of complex knowledge (Bonjour and Micaëlli, 2010). It is nonsensical to reduce a car to a black box, an engine, a bill of materials or a streamlined body with no engine. However, it is not easy to bring together these complementary aspects of the system. The fourth principle is alignment. Developing a solution requires aligning design processes and product structure (Sosa, Eppinger and Rowles, 2004). The SE approach breaks down product-development projects into sub-projects and teams that focus on specific layers, modules or integrative elements of the complete product (Bonjour and Micaëlli, 2010). These subprojects and teams are both separate and interdependent. Developing a solution involves a succession of projects. The product development process can be represented using the Vee cycle model. In the Vee, the descending leg depicts the embodiment of the system, and the rising leg depicts the integration and the validation of the solution. The highest levels of the Vee cycle are based on client-focused knowledge, whereas the lowest levels are based on empirical object knowledge. The fifth principle is incremental improvement. As noted above, SE concerns both the product and the way design is organized. Therefore, if the product is conceived as a (abstract) system, the way design is organized must be conceived in the same way. Thus, design organization is based on “routines”, that is to say, collective and perennial ways of doing things (Nelson and Winter, 1982). Some of these routines can be “codified” (Foray, 2004), generalized, learned and taught using systemic models, and they can be re-cycled from one project or team to another. In this sense, design routines mirror a product line. As suggested by the “Capability Maturity Model Integration” (CMMI) standard (Jalote, 1999), design managers codify routines in order to improve the operational performance of future design processes (delay, cost, efficiency, reliability, etc.).

2.2 SysML as a system integrative model In the 2000s, SE specialists and software engineers worked together to develop a language that could be used both to codify object knowledge and to specify software applications. They called the result SysML. Based on the UML framework (Bock, 2005; David, Idasiak and Kratz, 2010), SysML satisfies some of the principles of SE and of the UML-based Object Management Group (OMG) object-oriented approach that has been developed since the 1990s. SysML describes products as systems (first principle of SE). It allows designers to describe abstract entities such as environments, use cases, services or functions, architectures, behaviors, requirements, states, and laws (Bock, 2005). However, it cannot be used to describe a solution’s concrete attributes, such as its size, its weight, its form, or its bill of materials. SysML also provides structure diagrams that can be used to model semi-decomposable structures via the notions of classes or associations (second principle). Finally, SysML can be considered a system integrative model (third principle). This characteristic can be assessed in two ways. Firstly, every point of view of a system is relevant to a single skill (modularization). However, an entity created in a given diagram (a point of view) can be re-used in other diagrams (other points of view). For example, the use case diagram for a car may include the driver as an external entity. This entity can be reused when using a sequence diagram to model how the car starts, or when producing an activity diagram integrating the driver's intent. Secondly, because SysML dedicated software applications use the XMI (XML Metadata Interchange) standard, they can inter-operate with other software using the same interchange format (David, Idasiak and Kratz, 2010). SysML can be viewed as a hub that enables knowledge sharing and model migrations between software applications referring to complementary points of view, skills, etc. However, the current SysML framework does not include design alignment (fourth principle) or processes (fifth principle). So far, our analysis has described the abstract design paradigm and shown how it can be applied using SE. SysML satisfies some of the principles of SE (abstraction, semi-decomposability, pluralism). The following section adopts a more practical approach by examining how ISO 15288 and SysML diagrams can be applied to requirements engineering.

3. A step toward requirements engineering 3.1 What do ISO 15288 and SysML say about requirements engineering? Requirements are usually defined as the “needs, wants, expectations and perceived constraints” (ISO 15288) expressed by the client. In craft design, the client expresses these requirements verbally to the craftsman, so the communication is both direct and closed. In empirical design, the designer plays a dominant role, collecting verbally expressed needs as inputs. These needs are outside the core of the design process. It is not the designer’s role to discuss these needs but to put them into a bill of requirements that will form the basis for transactions between the designer and the client. The designer also uses this bill to decompose the overall requirement into separate modules to be worked on by specialist downstream designers. The designer’s role is to create as quickly as possible a prototype the client can evaluate. In craft design, requirements engineering is tacit. In empirical design, it consists of writing documents and breaking down requirements according to a well-known product structure and design office division of labor. This is very different to the way requirements are managed in the abstract design paradigm, in which there is no direct line between independent requirements and well-separated components. The requirements are interdependent and their allocation to components is complex.

6 What is the doctrine of SE with respect to requirements engineering? The SE framework recognizes requirements as a design entity and views the capture, definition and analysis of requirements as important upstream design tasks (Soares and Vranckel, 2008; David, Idasiak, and Kratz, 2010). Thus, ISO 15288 includes an initial process to define stakeholder requirements. The “Stakeholder Requirements Definition Process” is somewhat misleadingly labeled a “technical” process. In fact, it involves defining the community of stakeholders and the transactions between this community and the upstream designer, which can be a team. The stakeholders express “ill-defined” needs (Simon, 1995). The upstream designer, usually referred to as a system architect, must negotiate the requirements with the stakeholders, “refine” (Friedenthal, Moore and Steiner, 2012) these requirements into services and well-defined entities or structures understandable by the downstream designer. The Stakeholder Requirements Definition Process is followed by the “Requirements Analysis Process”. According to ISO 15288, the purpose of this process “[...] is to transform the stakeholder, requirements-driven view of desired services into a technical view of a required product that could deliver those services”. The system architect builds then logical architectures by using different models, e.g. structure diagrams, flow charts, state machines, etc. Each mentioned process has two types of outcome. The first type relates to the future product and encompasses object design knowledge and the type of product-related information provided by the process. The second type relates to procedural design knowledge, that is, the downstream points designers should focus on. It also encompasses the traceability of system requirements. Table 2 summarizes the content of those two design processes. Table 2. Requirements Definition Process vs. Requirements Analysis Process. ISO 15288 Design Processes Requirements Definition

Requirements Analysis System architect

Subject Community ...with the stakeholders. Outcomes Rules Tools

...alone.

Product outcomes: elicited requirements and constraints of the system. Procedural outcomes: traceability of the stakeholders’ requirements, the basis for requirements validation.

Product outcomes: abstract product model. Procedural outcomes: traceability of the technical system requirements with stakeholders’ requirements.

The system architect drives all the tasks. ISO/IEC standards, textual or formal models, documents, agreements, scenarios.

ISO/IEC standards, functional or behavioral models, risk analysis, costing methods, software applications.

ISO 15288 does not stipulate how requirements should be engineered; however, one way system architects can do this is by applying SysML diagrams or formal tools. Thus, Soares and Vrancken (2008) propose a model-driven approach to requirements engineering based on SysML requirements and the application of use case diagrams. Users’ requirements are graphically modeled and their relationships are explicitly mapped. Requirements traceability is enhanced by using SysML diagrams. Friedenthal et al. (2012) used SysML requirement diagrams to efficiently capture functional and performance requirements, and SysML parametric diagrams allow performance and quantitative constraints to be precisely defined (Friedenthal, Moore, and Steiner, 2012). Other authors have combined SysML diagrams with formal methods. This type of approach conceives the requirements model as a graph structure to which consistency tests (David, Idasiak, and Kratz, 2010; Godil et al., 2011; Boness, Finkelstein and Harrison, 2011) or dynamic property checks (Pétin et al., 2010) can be applied. Bouffaron et al. (2012) used high-level Petri nets to describe requirement analysis workflows. Most authors recognize that requirements engineering is not an easy task. It is not a linear or decomposable process (Bouffaron et al., 2012). Ideally, requirements engineering is based on scenarios, use cases, and formal models, etc. Our intention is not to provide a welldefined requirements engineering process or tool, but to show how SysML diagrams can help with the requirements engineering process. We advocate chaining various SysML diagrams, with each diagram representing a particular point of view of the requirements model. The sequence of SysML diagrams we propose complies with the ISO framework presented above.

3.2 Requirements Engineering as Chaining Diagrams According to the SysML standard, “a standard requirement includes properties to specify its unique identifier and text requirement. Additional properties such as verification status, can be specified by the user. Several requirements relationships are specified […] These include relationships for defining a requirement hierarchy, deriving requirements, satisfying requirements, verifying requirements, and refining requirements” (OMG, 2010, p.125). This definition shows that SysML designers recognize requirements as modeling entities. SysML provides requirement diagrams that satisfy some of the principles of SE listed in section 2.2. In a context of complex systems architecting, abstract requirements can be defined without referring to the way they are measured. For example,

Int. J. of Product Development, Vol. x, No. x, 2013

7

“cost” and “fuel consumption” requirements can be created and linked without using metrics, quantitative data or mathematical functions. Stipulating these two requirements and the relationship between them is enough to drive the system architects’ task. They can also generalize requirement diagrams so they can be re-used in subsequent projects. In order to comply with the principle of pluralism, we advocate using several different but complementary ways of expressing engineering requirements. We would suggest presenting requirements via four SysML diagrams, each referring to a specific point of view (ISO/IEC/IEEE 42010:2011) and task. Package Analysis - The first requirement diagram is drawn up as the Stakeholder Requirements Definition Process progresses. Drawing up such diagrams involves defining “package diagrams” (OMG, 2010) relating to each stakeholder’s point of view. System architects can map stakeholders on the basis of two criteria: their nature or the layer in the system with which they interact. Architects can define packages containing the requirements or viewpoint of the user, the customer, the seller, the manufacturer, the reliability specialist, etc. They can also define packages containing different requirements-related external points of view of the whole system, that is external points of view (user, customer, seller, etc.), internal points of view (cost engineer, manufacturer, supplier, etc.), and detailed points of view (reliability specialist). Systems architects must use precise and unambiguous nouns and adjectives to describe the requirements they have identified. Once a system’s packages or requirements have been defined, the system architect can test their completeness and consistency. Static Analysis - The second requirement diagram depicts the causality between requirements. In fact, different requirements are not regarded as independent variables; rather, they are nodes of a graph created by systems architects during the Requirement Analysis Process. Systems architects can define different types of relationship between requirements. Some of these relationships are included in the SysML specification. Among the SysML requirement relationships (derive, satisfy, verify, refine, trace), only DeriveRequirement or SatisfyRequirement can be used to relate the requirements belonging to different layers in the system. The others are used to relate requirements to other elements belonging to other SysML diagrams. Thus, requirements analysis can be refined using other SysML diagrams, such as use-case diagrams, activity diagrams, and block-definition diagrams. However, DeriveRequirement is a specific case of causality, and other forms of causality, especially between requirements within the same layer of a system, must be taken into account. This is why we suggest adding three new relationships. InfluenceRequirement represents a causal relationship between requirements belonging to the same layer in a system. For example, the structure requirement contributes to the behavior requirement, which contributes to the service requirement. DriveRequirement illustrates a relationship between physical requirements (weight, size, rigidity, speed, reliability, etc.) and economic requirements (cost, price, pleasure, utility, etc.). Physical requirements are considered explanatory variables of economic requirements, i.e. cost drivers, value drivers, etc. DriveRequirement can be positive or negative. For example, weight is a cost driver because the lower a system’s weight, the greater the relative amount of expansive purchased commodities or materials needed to build it (aluminum, composite). Hence, the relationship between weight and cost is negative (Drive-). AntagonisticRequirement describes an antagonistic influence between at least two requirements, for example, weight and acceleration. Such “physical contradictions” (Altshuller, 1999) can be tackled actively, for example, by downstream designers inventing solutions that provide better compromises. Antagonistic requirements may also be economic, the best known of which being the contradiction between cost or price and service (syn. function). Downstream designers can use “value analysis” tools to manage this contradiction (Miles, 1961). By connecting requirements and exploring the resulting graph, system architects draw up an integrative model. This model must satisfy a number of criteria. The first criterion is completeness. Does the model incorporate all the requirements included in the package diagrams? The second criterion is connectivity. Are all the requirements interconnected? If not, why? The third criterion is concision. If several requirements are closely connected, can a new requirement be defined that integrates all of them. Traceability Analysis - The third requirement diagram describes the refinement or derivation of relationships between interconnected requirements. This diagram focuses on requirements traceability, as it integrates downstream design information, the means for verifying the requirement, etc. It is based on the alignment principle. System architects have to manage a number of issues: Whose responsibility is it to invent new solutions that provide a better compromise between contradictory requirements? Who will validate the requirements and how will this be done? If the requirements are integrative or antagonistic, how will the coordination between separate validating actors be managed? In line with the fifth principle of SE, designers can continuously improve the operational performance of the processes linking requirement diagrams to downstream design processes. The most important quality of requirement traceability diagrams is integrity, as it is essential to ensure no requirements or attributes are forgotten in downstream design. Dynamic Analysis - The fourth diagram depicts the dynamic relationships between requirements. Metrics (time, weight, size, money, etc.) and SysML parametric diagrams (OMG, 2010) can be used to quantify requirements and study their effectiveness or impact (David, Idasiak and Kratz, 2010). Hence, the dynamic requirements diagram is a simulation model the system architect produces. This model can be formalized following Jay Wright Forrester’s system dynamics framework (Forrester, 1968). Moreover, abacuses can then be drawn up for the different requirements. We chose the term InfluenceRequirement to describe the causal relationship between requirements with quantitative or dynamic attributes.

8 Table 3 summarizes the content of the four requirement diagrams we suggest are essential for SysML-based requirements engineering. Table 3. Requirements Engineering Diagrams. SE Process Requirements Definition Process

Requirements Analysis Process

Task Package Analysis

Service Stakeholders’ requirements mapping. Object-focused diagram.

Static Analysis

Requirements causal relationships mapping. Objectfocused diagram.

Traceability Analysis

Requirements traceability. Design process-focused diagram.

Dynamic Analysis

Requirements simulation. Object-focused diagram.

Entities Entities: stakeholders, packages (viewpoints). Relations: containment, nesting. Entities: requirements with qualitative attributes. Relations: derivation, satisfaction, influence (contribution, driving), antagonistic relation. Entities: requirements. Relations: rationale, verification, satisfaction. Entities: requirements with dynamic attributes, metrics or parametric behaviors. Relations: influence.

Performance Stakeholders’ completeness, unambiguous requirements Requirements completeness, consistency.

Integrity.

Consistency.

4. Case Study 4.1 Design Context The following case study examines an incremental innovation called a robotized gearbox (RG) (Bonjour and Micaëlli, 2010). Gearboxes are old and well-known components that meet the SE definition of a system. The action of changing gears can be accomplished by a variety of mechanisms (manual gearboxes, automatic gearboxes, RGs, etc.), but all these concrete solutions share common abstract attributes, and they all fulfill the same torque-adaptation role (syn. service, function) and operate in the same type of environment. Gearboxes are integrated into vehicles, usually very close to the engine, and include a lubricatingoil feed system. All gearboxes conform to a similar pattern that includes a housing box, a differential, an internal shift control, a synchronizer, a gearshift lever, a clutch, and a greater or lesser number of internal mechanical parts (axles, pinions, etc.). Lastly, gearboxes have to meet certain performance criteria, such as gearshift duration, comfort of use, noise, reliability, torque, etc. From a driver’s point of view, RGs increase driving pleasure, as they give a light workload without increasing fuel consumption. From a customer’s point of view, RGs must be less expensive than automatic gearboxes. The price of a car with a RG must be less than $350 more than the price of a similar car with a manual gearbox. All these requirements can be expressed orally and captured by marketing specialists. As well as translating the above requirements into technical requirements, gearbox architects may need to take into account new stakeholders and extend their package diagrams. For example, from the manufacturer’s point of view, RGs must cover the fixed costs of a capitalist manufacturing system. It must be possible to re-use both the existing manual gearbox assembly line and 80% of the components of manual gearboxes. One way of achieving manufacturability is to re-use mechanical gearbox solutions; hence, manual gearboxes are seen as platforms to which add-on components, such as a robotized actuator, can be added. Consequently, RGs have technological continuity with earlier manual gearboxes. To date, no automaker has designed a RG in-house; they have all been developed by first rank suppliers. Hence, the target price of the RG ($350) is translated into a target cost ($175). RGs must comply with the CO2-emission reductions required by Euro V standards. Lastly, decades of empirical tests show that driving pleasure is affected by the rapidity of gear changes. This requirement can be expressed using time metrics (ms), for example, a target value of 250 ms. This target value and the distribution function (usually a Gaussian curve) is defined by ergonomists or marketing specialists. Cost engineers can define Cost Estimation Relationships (CER). For example, the parametric cost of a gearbox is dependent on gearshift duration (positive relationship) and the level of commonality between the RG and the manual gearbox (negative relationship). Lastly, product managers will express marketing requirements. In this case, they might want RGs to supplant automatic gearboxes in small vehicles (small vehicle market segment).

4.2 Proposed Requirements Diagrams Once all the information required by the first steps of the Requirements Definition Process has been collated, gearbox architects can draw up the above-described diagrams.

9

Int. J. of Product Development, Vol. x, No. x, 2013

Package Analysis - Figure 1 shows the results of this package diagram building process. It provides a map of external (driver, customer, and regulation) and internal (designer, cost engineer, and manufacturer) stakeholders, each of which has a particular viewpoint on a car’s attributes. Figure 1. RG Stakeholders’ Package Diagram. pkg RGRequirements [Stakeholders’ Req diagram] «view» BudgetView «view» UserView

«view» ManufacturabilityView Design Car

Drive Car « include »

Driver

Change Gears

«requirement» Driving_Pleasure

« include »

Make Car

«requirement» Fuel_Consumption

Designer

« include »

Manufacturer «requirement» Means_Reusability

«requirement» Shift_Gear

Re-use Means

«requirement» Components_ Reusability

«view» Price_vs_OptionsView

«requirement» Reliability

«view» CostView

Buy Car «view» RegulationView

Regulator «requirement» CO 2_Emission

Re-use Solutions

Minimize Environmental Impact of the Car

Customer

Cost Car

«requirement» Price

« include »

Cost Engineer

Define CER

«requirement» Cost

Figure 2 shows the gearbox architect’s requirements package diagram. The RG is a system that satisfies different types of requirements, which are usually packaged according to their nature. Thus, Figure 2 contains several packages relating to functional, operational and constraints requirements. The proposed diagram only uses relationships defined by the SysML specification. No new relationships have been added. Figure 2. RG Architect’s Package Diagram. req [package] RGSpecification [req package diagram] Architect’s _Viewpoint

Static Analysis - Figure 3 shows part of the RG static diagram. It does not include all requirements. It contains a wide scope of relationships, some of which are defined by the SysML standard. For example, the behavioral requirement satisfies the service requirements, and physical efficiency derives from the performance requirements. We chose for example a DriveRequirement between physical requirements (shift gear delay, reusability) and cost.

10 Figure 3. RG Static Diagram. req [package] RGRequirements [static diagram]

Architect’s _Viewpoint

Cost driver: « Drive – »

Cost driver: « Drive + »

Traceability Analysis – Before building a traceability diagram, the architect must identify metrics that will drive downstream designers’ tasks (figure 4). Figure 4. RG Modeling Domain Package. pkg ModelingDomain [RG Values and Units] « modelLibrary » Automotive Value Types « modelLibrary » Gearbox Value Types

Architect’s _Viewpoint

«import»

« valueType» Real

Time

Weight

« valueType » unit=sec

« valueType » unit=gr

«unit» {quantityKind=Time} msec «unit» {quantityKind=CO2Emission} E=gr / 100km

Money

« valueType» Distance

« valueType » unit=$

Metric_Distance

Hypermetric_ Distance

« valueType » unit=m

« valueType » unit=d

«unit» {quantityKind=Consumption} C=L / 100km «unit» {quantityKind=Reliability} F=P / t

Figure 5 shows part of the RG requirements traceability diagram. This diagram provides a map of the actors involved in downstream design (downstream designer, reliability expert, analytical costing engineer, marketing mix specialist, simulation specialist, and manufacturer). This map can also be used to define a new chain of requirements diagrams. Figure 5. RG Traceability Diagram. req [package] RGRequirements [traceability diagram] «view» Downstream_Product_Design

«view» Downstream_Reliability

«testCase» Product Family Communality

Downstream Designer

Reliability Expert

«verify»

«verify»

«requirement» Cost

F

dC

«testCase» CER Validation

Cost Engineer

«verify»

«requirement» Reliability

«requirement» Components_Reusability

C($) «view» Simulation_Downstream_Tasks

«view» Marketing_Mix «testCase» Market Study

Product Manager

«view» Analytical_Costing

«testCase» ReliabilityTests

«verify»

Simulation Specialist

«testCase» Chemistry Model

«testCase» Means Communality

«verify»

«requirement» Price

«testCase» Sensorial Tests

P «verify»

«testCase» Numerical Gearbox

«requirement» Physical_Efficiency F

«view» Downstream_Process_Design

«verify»

«requirement» Driving_Pleasure

«requirement» Shift_Gear

D

msec

Manufacturer

«verify»

«requirement» Means_Reusability dM

Dynamic Analysis – Figure 6 shows part of the RG dynamic diagram, which can be used to carry out both technical and economic simulations derived from systems dynamic. The diagram includes abacuses related to physical requirements. It also has abacuses showing hedonic and cost estimation relationships. For example, the more the driving-pleasure requirement

11

Int. J. of Product Development, Vol. x, No. x, 2013

increases, the more the cost requirement increases. Consequently, the relationship between driving pleasure and cost is positive (Induce+). This diagram is not a Forrester’s model because only flows are identified. Figure 6. RG Dynamic Diagram. req [package] RGRequirements [causal dynamic diagram] Architect’s _Viewpoint Value/Cost Package

Efficiency Package

«requirement» Driving_Pleasure

«requirement» Components_ Reusability

«requirement» Means_Reusability

δC

δM

msec

«influence +» «influence +»

«influence +»

«requirement» Shift_Geat_Delay

«requirement» Reliability

«requirement» Reusability

«requirement» Price

D=msec-a

F

δ=Min(δC,δM)

P($)=C($)+Π($)

«infuence+»

«influence +»

«requirement» CO2_Emission

F

E

«influence +»

«influence +»

«influence -»

«requirement» Cost C($)=-bD+cF-dδ

«requirement» Fuel_Consumption

«requirement» Physical_Efficiency «influence +»

Φ=eFαfEβ

4.3 Discussion To date, gearbox architects have not used SysML requirements diagrams when designing RGs, as SysML tools are not yet mature enough to be used on an industrial scale. Nevertheless the SysML diagrams we propose are helpful for codifying the core knowledge of gearbox requirements engineering. Practical SysML-based requirements engineering involves a more complex framework. Firstly, gearbox architects must precisely define the boundaries and purposes of the system (first principle of SE). Therefore, even if they focus on requirements, they should also build SysML “Block Definition Diagrams” that define the system’s boundaries, flows, and ports. Gearbox architects should also use “Use Case Diagrams” to define services requirements, building an “Activity Diagram” or a “Sequence Diagram” and a “State Chart” for each use case to define the behavior of the system. A single diagram is not sufficient for describing the system accurately and completely. As underlined by the third principle of SE (pluralism), requirements-focused viewpoints are not independent. Effective requirements engineering is based on the association of different viewpoints and depends on the coevolution of design-problem setting (what are the requirements?) and design-problem solving (what are the solutions?) (Simon, 1995). In addition, because a gearbox is a semi-decomposable system (second principle of SE), gearbox architects must modify the way they work in order to draw up several diagrams describing the requirements of the different modules that compose each layer of the system. Moreover, the definition of each module to which system requirements are allocated depends on contingent factors as well as technical factors (fourth principle of SE). In the case of RGs, some of the modules were designed by suppliers. As indicated above, although SysML requirements diagrams follow the abstract design paradigm, on their own they cannot ensure the successful requirements engineering of complex systems.

5. Conclusion This paper presents a framework for carrying out requirements engineering in accordance with the abstract design paradigm and SE. Its main contribution is to show how the ISO 15288 standard and SysML requirements diagrams can be applied to help achieve this objective. Under the abstract design paradigm, requirements are entities system architects must model and engineer via models or software applications. ISO 15288 helps designers do this by defining accurate Requirements Definition and Requirements Analysis processes, and SysML provides diagrams that can be used to map stakeholders’ and technical requirements, link these requirements via causal relationships, and ensure their traceability. We are currently planning further work to refine the proposed requirement diagrams. The challenge now is to study a real case with more quantitative variables, functions and abacuses, in order to simulate how variations in certain key requirements impact other interconnected requirements. Indeed, it is difficult to imagine a systemic requirements approach that omits a system’s dynamics, which is a significant aspect of every system! In addition, we wanted to reveal the dynamic relationships between SysML diagrams. We define the requirements model as a nexus of SysML models (use cases, block definition diagrams, activity diagrams, etc.) that must be applied to all layers of the system. The relationship between diagrams for

12 different layers should be determined using the SysML relationship "trace". The present contribution highlights the fact that system architects must think in systemic terms. They must apply the SE framework and extend systemic thinking to the complete object and to procedural design knowledge.

5. References Alexander, C., Ishikawa, S. and Silverstein, M. (1977) A Pattern Language – Towns, Buildings, Constructions, Oxford University Press, New York (NY). Altshuller, G. (1999) The Innovation Algorithm: TRIZ, Systematic Innovation and Technical Creativity, Technical Innovation Center, Worcester (MA). Bock, C. (2005) Systems engineering in the product lifecycle, International Journal of Product Development, Vol. 2, Nos. 1/2, pp.123-137. Boness, K., Finkelstein, A. and Harrison, R. (2011) ‛A method for assessing confidence in requirements analysis’, Information and Software Technology, Vol. 53, pp.1084–1096. Bonjour, É. and Micaëlli, J-P. (2010) Design Core Competence Diagnosis: A Case from the Automotive Industry’, IEEE Transaction on Engineering Management, Vol. 57 No. 2, pp.323–337. Bonjour, É., Deniaud, S., Loise, D. and Micaëlli, J-P. (2011) ‛L’ingénierie système fondée sur les modèles, clef de voute de la conception abstraite ?’, in Bot, L. and Vitali, M-L. (Coord.), Modélisation et Activités des ingénieurs, L'Harmattan, Paris (F), pp.125-144. Bouffaron, F., Gouyon, D., Dobre, D. and Morel, G. (2012) ‛Revisiting the interoperation relationships between Systems Engineering collaborative processes’, 14th IFAC symposium on INformation COntrol problems in Manufacturing, INCOM 2012, Bucharest, RO, May 23-25. Browning, T-R. (2000) ‛Applying the design structure matrix to system decomposition and integration problems’, IEEE Transaction on Engineering Management, Vol. 48 No. 1, pp.292–306. Bunge, M. (1985) Treatise on Basic Philosophy. Volume 7: Philosophy of Science and Technology, Reidel Publishing Company, Dordrecht (NL). Cook, S.C. and Ferris, T.L.J. (2007) ‛Re-evaluating Systems Engineering as a Framework for Tackling Systems Issues’, Systems Research and Behavioral Science, Vol. 24 No. 2, pp.169-181. Cuisenier, J. (2000) Mémoires des Carpathes, Plon, Paris (F). David, P., Idasiak, V. and Kratz, F. (2010) ‛Reliability study of complex systems using SysML’, Reliability Engineering and System Safety, Vol. 95 No. 4, pp.431-450. Engeström, Y. (1987) Learning by Expanding: An Activity-Theoretical Approach to Developmental Research, Orienta Konsultit, Helsinki (FI). Foray, D. (2004) The Economics of knowledge, MIT Press, Cambridge (MA). Forrester, J-W. (1968) Principles of Systems, Wright Allen Press, Cambridge (MA). Friedenthal, S., Moore, A. and Steiner, R. (2012) A Practical Guide to SysML: The Systems Modeling Language, 2nd edition, Morgan Kaufmann Object Management Group, Elsevier, Amsterdam (NL). Godnil, A., Kurtev, I., Van Den Berg, K. and Veldhuis, J-W. (2011) ‛semantics of trace relations in requirements models for consistency checking and inferencing’, Software and Systems Modeling, Vol. 10 No. 1, pp.31-54. International Standards Organization (ISO) (2002) Systems Engineering – System Life Cycle Process. International Standards Organization (ISO) (2011) ISO/IEC/IEEE 42010 – Systems and software engineering — Architecture description. Jalotte, P. (1999) CMM in Practice: Processes for Executing Software Projects at Infosys, Addison-Wesley. Kuhn, T-S (1962) The Structure of Scientific Revolutions, University of Chicago Press, Chicago (IL). Miles, L-D. (1961) Techniques of Value: Analysis and Engineering, McGraw-Hill (NY). Nelson, R.R. and Winter S.G. (1982) An Evolutionary Theory of economic Change, Harvard University Press, Harvard (MA). Object Management Group (OMG). (2010) OMG Systems Modeling Language (OM SysML TM) version 1.2. Available at: http://www.omg.org/spec/SysML/1.2/. (Accessed 23rd January 2012). Pétin, J-F., Evrot, D, Morel, G. and Lamy P. (2010) ‛Combining SysML and formal models for safety requirements verification’, 22nd International Conference on Software & Systems Engineering and their Applications, ICSSEA 2010, Paris, F. Schön, D. (1995) ‛Designing : Worlds, rules, and Types’, in Collen, A. and Gasparski, W.W. (Eds), Design & Systems, Transactions Publishers, New York (NY), pp.259-279. Simon, H-A. (1995) ‛Problem Forming, Problem Finding and Problem Solving in Design’, in Collen, A. and Gasparski, W.W. (Eds.), Design and System, Praxiology, Transaction Publishers, New York (NY), pp. 245-257. Simon, H-A. (1997) The Science of the Artificial, 3rd ed, MIT Press, Cambridge (MA). Soares, M. and Vrancken, J. (2008) ‛Model-driven user requirements specification using SysML’, Journal of Software, Vol. 3 No. 6, pp.5768. Sosa, M.E., Eppinger, S.D. and Rowles, C.M. (2004) ‛The misalignment of product architecture and organizational structure in complex product development’, Management Science, Vol. 50 No. 12, pp.1674-1689.

Int. J. of Product Development, Vol. x, No. x, 2013

13

Stankiewicz, R. (2000) ‛The Concept of “Design Space” ’, in Ziman, J. (Ed.), Technological Innovation as an Evolutionary Process, Cambridge University Press, Cambridge (UK), pp.234-247.