|METHODES / METHODS > B- DEMARCHES / APPROACHES > TOOL CHARACTERISTICS TO SUPPORT ALL LIFECYCLE STAKEHOLDERS’ REQUIREMENTS IN COLLABORATIVE ENGINEERING DESIGN|
TOOL CHARACTERISTICS TO SUPPORT ALL LIFECYCLE STAKEHOLDERS’ REQUIREMENTS IN COLLABORATIVE ENGINEERING DESIGN|
Maria Paz Claros Salinas, Guy Prudhomme and Daniel Brissaud / 3S Laboratory, University of Grenoble, BP 53, 38041 Grenoble cedex 9 (Knowllence partners)
vendredi 28 décembre 2007 , Sandrine Beaujon
Of course, requirements will be evolving throughout the design project, as needs and constraints do.
3. THE THREE-DIMENSIONAL ANALYZER
Requirement management tools are classified in three groups by industrialists : requirements definition assistant tools, that assist designers and engineers to define the requirements from the identification of the needs to the formal expression ; requirements transformation assistant t ools, that assist designers to follow–up and support the transformation of requirements during the design process ; requirements monitoring assistant tools, that assist designers to regulate, control and check requirements throughout the design process. This classification is too loose for a good characterization of requirement management tools. In this section, we aim to present the three-dimensional space highlighted by our work in order to analyze the performance of requirement management tools throughout the design process. The three dimensions are : the project view, the representation of the product and the design process properties. They are described in detail in the following.
3.1 The project stage dimension
This dimension is a project management view of the design process. Most of the companies organize their work by projects. A project is a temporary endeavor undertaken to create a product or a service. It includes a deadline and, from a management viewpoint, goes from a milestone to the next. So this dimension contains the different stages of a project, which will be separated by assessments or decisional meetings. According to Palh & Beitz, the first stage of a design process is to identify the needs. At the end of the second stage, called clarification of the task, requirements have to be defined. Then the following stages are : conceptual design phase in which designers propose structural solution ; embodiment phase in which a mechanism description has to be proposed ; detail design phase to define parts ; industrialization to define production process ; etc.
This project view is useful for design process management. This axis is therefore relevant to identify which stage of the project is supported.
3.2 The product representation dimension
During the project development, designers use different product representations : functional, structural and physical ones. At the beginning of the design process, the representation of the product is mostly functional, then it turns to structural representation and finally to physical representation. The product representation passes from an abstract representation to a concrete one. Yet, from a cognitive and co-evolutionary point of view, this evolution does not happen sequentially (Darses, 1997) : the designers work simultaneously on the three representation levels, zigzagging across those levels. This axis is relevant to identify the type of representation supported.
A Functional Representation includes functions that the product must fulfill and constraints that has to be respected. Functions and constraints are characterized by associated criteria and levels. Functional representation is an external description of an answer to the customer’s demand. It can also be a technical description of the functional possibilities to fit the external functions. For example, a specification list or a QFD matrix are both considered as functional representations.
A Structural Representation describes the possible structure of a product. It can be a schematic representation, like a cinematic scheme, or a diagram including components and links among them. A block diagram coming from the value analysis methodology is a good example of structural representation.
A Physical Representation describes geometrical and technological properties of the product. Numerical representations in CAD tools, prototyping are included in this representation level.
3.3 The properties of the design process dimension
This axis is relevant to identify the capabilities to support the properties of the design process. As mentioned at the beginning of the paper, the design process is no longer an individual work but a collective one. In a Concurrent Engineering context, the team of designers is composed of people coming from different companies and expertise fields. Each one has his own viewpoint and requirements concerning the product. Each one expresses his needs to the team, who has to build a common understanding (processes of elicitation and formalization). Once the first level of requirements is formalized, designers use them as baselines to look at the solutions. But these requirements are not definitively fixed since they are co-evolving throughout the design process, depending on new constraints and candidates. The stakeholders who are concerned by the requirement changes must be aware of them : the design process has properties of dynamics and propagation. And of course requirements should be consistent at any time of the design process (properties of correlation) and across product families (properties of traceability).
This axis is composed of the six main properties of the design process : elicitation, formalization, propagation, dynamic, correlation and traceability processes.
Elicitation : Eliciting means to bring something out, calling forth or drawing out (information or response). Methods are needed to help designers to be the more rigorous and exhaustive during this activity. For example 6WH method (Who, What, When, Which, Why, Where, How) can be seen as a possible method helping designers to elicitate requirements.
Formalization : Formalization is the action of setting requirements in a formal language. This language must enable all stakeholders to express their own requirements, to share viewpoints and to negotiate. Functional analysis is a formal language standing for being a method to help designers to formalize requirements.
Propagation : Requirements at different stages of the design process are not independent from each other but they relate to each other. The propagation is the capability to build relations between the requirements and to propagate the impact of changes onto impacted requirements, upstream and downstream in the design process.
Dynamic : A requirement can be added or removed from at any stage of the design process : the list of requirements is dynamic. The consequence is that new dependence links are going to appear and disappear. This connection between requirements impacts the possibility of creating or giving up requirements while designing. The Quality Function Deployment method can support the property of criteria propagation thanks to the matrix relation. Unfortunately these matrixes are static ones because requirements cannot easily and quickly be added or removed.
Correlation : The correlation is a relationship between requirements at the same stage of the design process. Correlation is the relation between two variables varying one according to the other. The roof of the QFD matrix enables designers to make this sort of correlation.
Traceability : Requirements should be traced forward from an initial statement to specifications and design components, and backward from design components to their motivating requirements. Backward tracing is necessary for system modification and maintenance, while forward traceability is used in managing development from requirements to implementation. Traceability is the ability to trace the history or location of an entity by means of recorded identifications.
The content of the three-dimensional analyzer is summarized on figure 1.
Figure 1- Three-dimensional analyzer content
4. APPLICATION OF THE ANALYZER
Let us apply the three dimensional analyzer on two commercial tools of requirement management. It will help the understanding of the analysis framework and highlight the properties that are not covered yet.
4.1 Project Stages
TDC Need® : The first information to introduce in the tool, addresses the project definition. Designers must answer a list of questions coming form the AFNOR standards (AFNOR, 1990), (AFNOR, 1991). Then, the identified needs are expressed in the form of functions. Those functions are formalized in the characterization table proposed by the Functional Analysis method. TDC Need® is positioned on the two first stages of the axis.
DOORS® : Baseline requirements must be identified and defined before beginning the work on DOORS®. Those requirements are introduced in DOORS®. Then, designers can use the tool to support requirements evolution in other stages of the project. It covers most of the stages of the axis.
4.2 Product representation
TDC Needs® mainly supports the functional representation of the product because of the external Function Analysis method. This functional representation only addresses the first level of the product requirements definition : the external clients needs expressed with functional terms.
DOORS® supports the functional representation of the product allover the product life cycle.
4.3 Properties of the design process
TDC Needs® : The design method included gives the capability to support designers on the requirements expression and formalization to the tool. It allows to save the different versions of the requirements. Those traceability and propagation properties only address the functional aspect.
DOORS® : This tool is able to support the designers during requirement formalization. It also helps to define the links between requirements and allows propagation. DOORS® enables the designers to have a general view over the changes and evolutions (add, change, delete…) of requirements.
Figure 2- TDC Need® and DOORS® on the three-dimensional analyzer space
These properties are summarized in Figure 2. The analyzing space proposed is more accurate than the rough classification made by the industrials. Indeed, according to their classification, Requirement Definition tools spot the intersection between Elicitation and Needs Identification ; Requirement Transformation tools spot several categories of the space ; Requirement Monitoring tools spot the surface between Project Stages and Design Process. As visualized on Figure 2, the two tools do not support the same activities : DOORS® is mainly a Requirement Monitoring tool and TDC Needs® a Requirement Definition tool. Both of them mainly address the functional representation of product. They are complementary tools and do not cover the whole space together.
This paper started with three main questions. The first one was about requirements definitions. Our answer is that a requirement is a formal expression of a need or a constraint expressed by any stakeholder of the design process. The next two questions can be answered together. The characteristics that requirements management tools must support have been extracted and structured in a three dimensional space : project management, product representation and design process properties. These three axis and the values proposed on each of them, enable us to analyze and identify tools capabilities and consequently their lacks. The first applications of the analyzer give us relevant information.
The issue now is to propose a exhaustive list of specifications for a computer-aided tool supporting the whole cycle of requirement management throughout the design process. As seen on Figure 2 a wide part of the space is not addressed so far and the properties that must be covered have to be documented and implemented.
1. Darses Françoise, "L’ingénierie concourante : un modèle en meilleure adéquation avec les processus cognitifs de conception”, Ingénierie concourante de la technique au social, 1997, ISBN : 2-7178-3498-2
2. Harwell R., Aslaksen, E., Hooks, I., Mengot, R., Ptack, K., "What is a Requirement ?" in Proceedings of the Third International Symposium of the NCOSE, 1993. Retrieved September 2001, from http://www.incose.org/rwg/what_is.html
3. Jinxin Lin, Mark S. Fox and Taner Bilgic, "A Requirement Ontology for Engineering Design”, Enterprise Integration Laboratory, Dept. of Industrial Engineering, August 1996
4. Pahl G. and Beitz W., Engineering Design : A Systematic Approach, Springer Verlag, 1996 (2nde éd.).
5. Lonchampt P, Prudhomme G, Brissaud D, "Supporting Problem Expression within a Co-Evolutionary Design Framework", in Advances in Design, ElMaraghy, Hoda A. ; ElMaraghy, Waguih H. (Eds.), pp 185-194, Springer, 2006, ISBN : 1-84628-004-
6. Maher M.L., Tang H.T., "Co-evolution as a computational and cognitive model of design", Research in Engineering Design, 14, 1, 2003.
7. Software Engineering Standards Committee of the IEEE Computer Society, IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process, January 1999, p34-42. Retrieved October 2001,
8. Ulrich K.T. and Eppinger S.D. , Product design and development, Second edition, McGraw Hill International editions, 2000
9. AFNOR NF X 50-150, Vocabulaire de l’analyse de la valeur et de l’analyse fonctionnelle, Association Française de Normalisation, 1990
10. AFNOR NF X 50-151, L’analyse fonctionnelle, Association Française de Normalisation, 1991