# 9 Glossary The definitions and explanations for the terms listed are based on the following sources, among others: MSR-MEPRO partners DIN/ISO 8402 “Quality Management and Quality Assurance - Terms” DQS (German Quality Society) Publication 11-04. Change Control Board (CCB) Term used here describing a board with representatives from the supplier and the customer, which deliberates on the technical implementation of change requests. Change requests are evaluated according to various criteria, and they are managed and monitored centrally in case they are implemented. The CCB is responsible for ensuing that changes are understandable and traceable. The activities of the CCB belong to the change management process area. Data Model A data model describes a real object or one that is to be created. A data model may contain only a partial view of a real object, for example the technical-geometric description (for example a 3-D CAB model), the functional description (for example a simulation model) or the documented authoritative level of the design status. The data model normally only describes part of the current design status. Design State The design state describes the current status of design encompassing both manufacturer and supplier. The current design state is described in the data model, which is continually updated. Customer Specification (per DIN 69 905 – VDI/VDE 3694 – VDA 6.1) All of the requirements placed by the customer on the products and services delivered by the supplier. Requirements from the user's point of view including all constraints must be described in this specification. These requirements should be quantifiable and verifiable. The specification should define what the task is and why it needs to be solved. The specification is maturity-dependent document, in which requirements and functions of the design task as well as nominal and tolerance levels are defined. It forms the basis for the technical implementation of a concept and for costing. In case a design project is to be given to a third party, the specification becomes a part of the tender for bids and provides the supplier with the basis for making a price offer. The specification can be updated and details can be added in parallel with design activity. Changes that are made must not exceed the scope of the agreed design contract. When design is complete, the specification becomes a required part of the documentation. Requirements can be laid down regarding the structure and format of a specification (for example MSR-MEDOC-DTD). Sample, sample status (per DGQ publication 11-04) Sample: material unit that is subjected to quality inspection/test for a particular reason or that is required within the context of a quality inspection/test. "Sample" designates the physical manifestation of the system to be delivered. Pre-production sample: sample that has not been manufactured with the methods and processes that are intended to be used for subsequent mass production and/or have not been manufactured under conditions that will exist in subsequent mass production. Test sample: sample for functional and reliability testing. First Article: sample produced with the equipment and process that will be used for mass production under the appropriate conditions. Supplier Specification (per DIN 69 905 – VDI/VDE 3694 – VDA 6.1) Implementation requirements developed by the supplier based on implementation of the customer specification. The supplier specification contains the customer specification. The supplier specification contains details relating to application requirements. It is also expanded to provide a description of implementation requirements including concrete approaches to a solution. The supplier specification contains a definition of how and what resources will be used to implement the requirements. The supplier creates the supplier specification after award of the contract and delivers it to the manufacturer. It describes in greater detail implementation of the requirements profile, which is contained in the customer specification (for example data structures and function sequences). The supplier maintains the supplier specification, which always mirrors the current development status. It is also part of the documentation for the development project. Requirements can be laid down regarding the structure and format of the supplier specification (for example MSR-MEDOC-DTD). The supplier specification and the customer specification can be combined in one document. Product Development Process The product development process starts with the project decision in favour of a concrete product and the first specification, for example in an outline specification. It continues through the creation of the customer and supplier specifications up to release to mass production. All product development projects run in this process, regardless of whether new, new version or modification design is involved. The result of the product development process is a tested system/product that has reached production maturity and is ready for delivery. Documentation of production, acquisition, logistics, sales and service is available. The process ends with release for production and delivery. Prototype A prototype is a model of the product that is to be developed. It describes all or part of the overall product requirements. A prototype is used to verify functionality and can be generated both in virtual form (data model) and in real form. Process Set of interdependent resources and activities that convert inputs to results. [EN ISO 8402, QM Terms, 1995]. Resources can include personnel, financing, systems, equipment, technology and methods. Test Requirements Test parameters includes information about stimuli, nominal values and associated key values for testing a function. Test Procedure A test specification describes how to test a test object in accordance with the test specification and what resources to use. Test Specification (in accordance with the V model for SW development, KBSt 92) The specification contains the description of test requirements and goals, test methods, test criteria derived from requirements and test cases. Test case coverage of requirements is documented using a coverage matrix. With the aid of the test specification, it must be decided whether the test was successful or not. A test specification is created for each test object. Quality management (QM) plan (per DIN EN ISO 8402, 3.13). Reference Point (RP) Coordination point, with defined content, between the manufacturer and the supplier in the product development process. The function of a reference point is to synchronise the product development process between the manufacturer and the supplier. Reference points support the planning and coordination of development projects on the basis of process models Reference points should be planned for and used to prepare for and ensure adherence to schedule milestones Reference points essentially are defined by setting goals and content or input/output entries. Checklists help concretise the content of reference points and adapt it to the various development tasks and stages. Various activities are required to implement a reference point, for example to prepare and evaluate input or generate output. Reference points can occur once (fixed reference points) or more than once (generic reference points) in the development process. Since the term "milestone" is open to various interpretations regarding its "range", reference points can also be regarded as a particular manifestation of milestones. The characteristic attributes of reference points are: Reference points are based on process models Reference points are described using input and output agreements Reference points act to prepare for and secure adherence to schedule milestones SW Configuration / Configuration Management Putting together a software product from different versions/configurations that all must be brought together, along with the associated documentation and all amendments, in a clear and reproducible manner. The process of consistent monitoring, planning and storage of different software versions and modules is defined under the term configuration management . (Refer to ISO 9004-7, V model, IEEE etc.). Process Segment A process segment is a thematically closed segment of a (total) process. Typical process segments in the product development process for E/E systems are system design, hardware component development, software component development, system integration and test and start of production.