PLM integrated requirements management

SITIO-An approach to PLM-integrated requirements communication in distributed product development processes using aspects of linguistic pragmatics.

PLM integrated requirements management

The fulfillment of customer requirements has a significant influence on product success. Increasing the quality of documentation is therefore the primary goal in requirements management. Since errors often occur due to misinterpretation despite correctly formulated requirements, the quality of the interpretation of requirements documents is currently becoming the focus of attention. Against this background, the authors developed the approach of a PLM-integrated requirements management whose partial aspect, the SITIO, can sustainably improve the interpretation quality by using effects of linguistic pragmatics.

Prerequisites for product success

Sustainable customer satisfaction can only be achieved if customer requirements are met. Thus, the success of a product depends decisively on the exact fulfillment of the defined requirements. Companies are becoming aware, especially against the backdrop of increasing product complexity, the necessary integration of different domains such as mechanics, electrics and electronics, and the need for global collaboration, that accurate design can only succeed if excellent quality of requirements documentation can be ensured throughout the product development process.

In order for these to be fully and correctly translated into a design, the requirements must be fully known to the product developer responsible for their implementation and must also be fully understood and correctly interpreted by him. This process is becoming increasingly difficult as a result of the progressive decentralization of product development across company boundaries, so that the existing methods for supporting it are no longer sufficient.

It is thus necessary to develop methods and information technology tools that can support the process of defining requirements, distributing them within the company, and implementing them in a suitable manner.

Transformation of requirements in the product development process 

According to VDI guidelines 2221 and 2222, a compilation of all requirements for a product is the first work result in the development and design process. The requirements are usually formulated verbally. Kramer (quoted from [1]) proposes a hierarchical structure in three granularity levels for specifying a requirement, which distinguishes between level 1 (statement), level 2 (deepening) and level 3 (specification).

Figure 1: Typical granularity levels of requirements in the automotive industryThe proposal also largely corresponds to the procedure in the automotive industry. Here, the process begins with the derivation of customer expectations - typically requirements from the marketing perspective - into concrete properties and functions. In the automotive industry, for example, this would involve requirements for fuel consumption, safety, or available space - i.e., at the vehicle level. Subsequently, the properties and functions are further detailed across the various levels of granularity down to the level of the individual components (Fig. 1, left pyramid).

The refinement process takes place across departmental boundaries and, through the inclusion of globally distributed suppliers, also across company boundaries. It cannot be assumed that communication between departments and suppliers refers to just one defined level of granularity (cf. Figure 1, total).

Until the product is defined in detail and finally by requirements, numerous information transformations are necessary across the dimensions of "granularity" and "departmental or company boundary" in which the requirements must be verbally formulated, explained, discussed, and subsequently further refined. Each of these transformation steps carries a risk that requirements will be misinterpreted, essential elements will be missing, or their context will be lost.

However, if the quality of the requirements cannot be maintained across the transformation steps, it will be difficult to achieve a high level of customer satisfaction.

Requirements quality

In the consequence the question arises what quality of requirements means. Quality is generally considered to be the degree to which a sum of contained characteristics fulfills the requirements placed on an object [2]. Up-to-date the requirement management focuses essentially on the completeness and formal correctness of requirements. DIN EN ISO 9000:2005 states that high-quality requirements are achieved through appropriateness, completeness, unambiguity, consistency and verifiability. The VDA standard structure for component specifications goes one step further. The VDA standard [3] lists unambiguousness, identifiability, verifiability, necessity, freedom from redundancy, comprehensibility, completeness and freedom from contradictions as essential criteria.

The above-mentioned perspective often leads to the requirement to formulate requirements in greater detail and scope than has been customary in practice to date. As a result, this leads to greater effort and thus increased resource requirements for documenting the requirements. In order to counteract this by reducing effort, another approach is to perform an automated check of requirements. This is done technically, for example, by checking for so-called weak and stop words. The primary goal here is to ensure the unambiguousness of requirements by eliminating fuzzy formulations such as could, should be, would be, etc. should be avoided.

The described procedure for ensuring high-quality requirements is not sufficient, as a major weakness remains. This can be seen by looking at the communication model (Figure 2).

Figure 2: Communication model according to Shannon & Weaver [4]The previous approaches focus on the sender side (Figure 2, detail A). The idea behind this is that it is only necessary to describe a requirement correctly and completely and that the recipient will then understand it correctly "all by himself". In practice, however, it becomes apparent at this point that the correct interpretation of the formulated requirement is a major problem in requirements management (see Figure 2, Detail B).

Another problem arises from the previous way of thinking. The creation of detailed requirements and their subsequent interpretation cost resources and time. In many cases, especially with well-established development teams, experience shows that it is not absolutely necessary, and often even a hindrance, to formulate requirements down to the last detail. When interpreting such detailed requirements, employees lose a lot of time interpreting information that is ultimately already known.

Consequently, the goal must be to find approaches for requirements management that succeed in decisively increasing the quality of interpreting requirements and flexibly aligning the level of detail in the formulation of requirements to the needs of the recipient side.

Aspects of linguistic pragmatics in requirements management

This brings questions of linguistic pragmatics into focus. Essentially, the context in which a person interprets or encodes information must also be taken into account in requirements management. This context can be grasped by the personal frame of reference of a person. The personal frame of reference describes how a person interprets the world and the information he finds. On the one hand, this depends on the learned schema into which information is classified and, on the other hand, on the perspective that results from the role in which the person acts in the interpretation (see [5]).

With regard to employees in the product development process, the relevant frame of reference is essentially represented by the aspects shown in Fig. 3. On the one hand, it is conditioned by aspects from the learned schema, which, in addition to the native language and the cultural context, also covers the qualification and the professional experience acquired (Fig. 3, aspect A). On the other hand, driven by aspects from the role the person takes in the company (Figure 3, aspect B). This is mainly influenced by the technical domain (mechanics, electrics/electronics, mechatronics), the role and the subject matter assigned to the specialist.

Figure 3: Relevant aspects of the personal frame of reference in the product development processA simple example can clarify this. In most languages as well as in natural language usage, the word OR used primarily as an exclusionary disjunction or exclusive or ("I'm going to the stadium. OR with the children to the playground"). In the reference frame of the domains computer science and electrical engineering, the distinction between non-exclusive disjunction (adjunction) has become differentiated (OR and XOR). So this different interpretation can already lead to misunderstandings, although the author would probably have classified it as unambiguous.

The analysis and systematization of the influences of the reference framework is a multilayered topic in connection with the requirement management in the future further research work requires. However, it can be stated that people who exchange information about requirements must align their frames of reference in order to interpret them correctly (e.g., through conversation, documentation, etc.). For the design of the Securing Information Transformation for Input and Output (SITIO) method presented here the question arises therefore like this aspect in the requirement management in simple way practically to be used can.

The goal must be to anchor a comparison of the reference frames in the methodology and, in addition, to exploit an existing high-level agreement of the reference frames of the persons acting in the process chain in such a way that, in such cases, the effort required for the formulation of requirements is reduced while at the same time increasing quality.

Securing Information Transformation for Input and Output (SITIO)

In the context of industrial research work, the authors developed a methodical approach that allows the IT-supported integration of requirements management into an open PLM platform such as Teamcenter. A particular added value of such an integration lies in the system-supported mapping of the interdependencies of requirements as well as their concrete implementation in a component design or a concrete construction. In particular, this enables fast and cost-effective processing of changes to the product without delays and disruptions caused by system or communication interruptions.

One aspect of this methodology is SITIO. It focuses on ensuring a high-quality transformation of requirements across the dimensions of "granularity" and "departmental or company boundaries". Its use can ensure that the participants in the process chain can maintain a common understanding of requirements across all transformation steps.

Figure 4: Basic concept of SITIOFigure 4 shows the flow of a transformation of a formulated requirement. Person A formulates a requirements document. This input document is passed to person B for further detailing. Person B transforms the requirements to a more detailed level of granularity. Once this step is done, person B passes the resulting output document to the successor in the process chain (in Figure 4, person C) who then performs the design task, for example.

In the previous requirements management, checks are essentially performed to ensure quality, which SITIO takes into account by realizing the process step "Craftsmanship". In this process step (Figure 4, 2) [6], a responsible person from person B's department checks the output document for formal compliance with agreed quality standards as well as compliance with the defined process flow for creating the output. The focus here is on checking that the information created by person B is free of redundancy and contradictions.

SITIO adds the two additional elements "Fitness for Use" (Figure 4, 1&4) and "Conformance" (Figure 4, 3) to the process.

The "fitness-for-use" step (Figure 4, 1) focuses on the correct interpretation of the input document by person B. Person B confirms that and which points of the document have been fully understood by his side and reflects his understanding back to person A through a result document or in the context of a work meeting. Person A contrasts his original intention with Person B's understanding. If person A is also convinced that person B has understood all requirements of the input unambiguously, completely and comprehensibly, he releases the process for the actual processing by person B. If the input document has weak points, the input must be revised by the respective author of the information until all weak points have been eliminated.

Person B then carries out the actual transformation process by, for example, refining the requirements described in the input document to a finer level of granularity and recording the result as an output document. The first step in releasing the document created in this way is craftmanship, as described above. To ensure that the output document actually reflects the requirements specified in the input document completely and correctly, person A checks the output document in the "Conformance" step (Fig. 4, 3). Only then is the document released and sent to the follow-up activity, and the process described begins again.

Through the two elements "Fitness for Use" (Fig. 4, 1&4) & "Conformance" (Fig. 4, 3), a check of the requirements on the recipient side is realized. In addition, the advantage of organizationally precisely assigned responsibility for the process steps arises. Thus, for example, person A cannot retreat to having described all information accordingly in the input document. They must also take responsibility for ensuring that person B has understood the statements correctly.

An IT-supported SITIO process and the use of personal reference frames

The introduction of additional steps in requirements management by SITIO appears at first glance to be migratory, especially against the background of the currently prevailing tendency to demand increasingly detailed formulation of requirements.

However, if we take a closer look at the situation, it becomes clear that additional effort would already be justified simply by ensuring high-quality requirements and the resulting avoidance of consequential errors. In fact, communication processes comparable to the "Fitness for Use" and "Conformance" process steps are already taking place in industry, since a comparison of the reference frames of the persons involved is indispensable for the correct understanding of the requirements. Up to now, however, these have been implicit processes which, by sheer necessity, are carried out by the people involved on their own initiative.

If the transformation of requirements is implemented IT-based with the help of SITIO, the previously implicit communication processes are made explicit. The organizational systematization of the communication processes is based on defined workflows that are processed via the PLM platform and are therefore traceable and transparent.

In addition, the effort-reducing effect of common reference frameworks can be used and anchored in the company through implementation. This makes it possible to achieve a reduction in effort compared to previous processes.

The implementation is done e.g. with the open PLM platform Teamcenter. The process flow shown in Fig. 3 is modeled via the Teamcenter "Workflow Engine" and thus communication, document exchange and document release are realized directly via the system. Among other things, it is possible to maintain traceability between input and output documents at subchapter and paragraph level.

The effort-reducing effect of already existing, common reference frames is used in the "Fitness-for-use" and "Conformance" steps. Teamcenter makes it possible to map the people involved in requirements management, their roles and organizational classification, as well as their qualifications, so that during the course of a transformation an analysis of the combinations of people involved and subsequently an analysis of the degree of commonality of their frame of reference can be performed.

Based on the overlap of reference frames analyzed in this way, different documentation templates can be provided depending on the existing reference frames.

In this context, the different documentation templates require a context-dependent detailing of the requirements documents so that unnecessary -because already known- information can be omitted.

As a result, the communication effort between participants in the process chain is reduced accordingly while the quality of the information transformation is increased, the processes are accelerated and thus costs are saved while quality is increased at the same time.

Conclusion

By using SITIO, the loss of information and the falsification of information in the process of requirements transformation can be minimized in the long term.

The criteria currently used to maintain quality will be expanded by integrating "conformance" and "fitness-for-use", and the process will be systematized and anchored in the organization.

The transformation of requirements is bundled and can be implemented system-supported with the help of open PLM platforms such as Teamcenter. The amount of work involved in creating requirements can be reduced by exploiting the effect of personal reference frames while at the same time increasing the quality of the requirements.

With SITIO, a methodical tool is available to sustainably improve requirements management.

Original source:

FISCHER, Jörg W.; Michielsen, Cees; Rebel, Martin; Hasse, Armin:
PLM integrated requirements management.
SITIO-An approach to PLM-integrated requirements communication in distributed product development processes using aspects of linguistic pragmatics.
In: ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb,
Munich, 107(2012)3, pp. 163-167.
(ISSN: 0947-0085)

Literature

[1] Pahl, G.; Beitz, W.; Feldhusen, J.; Grote, K.-H.: Konstruktionslehre - Grundlagen erfolgreicher Produktentwicklung - Methoden und Anwendung, 6th edition, Berlin, Heidelberg: Springer-Verlag, 2005, p. 221.

[2] Beuth Verlag (Ed.): Qaulitätsmanagementsysteme - Grundlagen und Begriffe Trisprachige Fassung (DIN EN ISO 9000:2005), Berlin: Beuth Verlag GmbH, 2005

[3] VDA/QMC: The common quality management in the supply chain - automotive VDA standard structure component load booklet, 1st edition, 2007.

[4] Shannon, Claude E.; Weaver, W.: The mathematical Theory of Communication, University of Illinois Press, 1949.

[5] Gabriel, Paulette: Personal Transformation: The Relationship of Transformative Learning Experiences and Transformational Leadership, Washington University, 2008, p. 15.

[6] Deming, Edwards W.: Out of the Crisis, MIT Press 1986

Leave a Reply

Your email address will not be published. Required fields are marked *

More articles

What are the 7 keys to solve PLM & ERP? Prof. Jörg W. Fischer answers this question in a series of LinkedIn posts....