< Previous | Contents | Next >
Information item characteristics listed in this Annex can be used when reviewing potential outputs of process implementation. The characteristics are provided as guidance for the attributes to look for, in a particular sample work product, to provide objective evidence supporting the assessment of a particular process.
A documented process and assessor judgment is needed to ensure that the process context (application domain, business purpose, development methodology, size of the organization, etc.) is considered when using this information.
Information items are defined using the schema in table B.1. Information items and their characteristics should be considered as a starting point for considering whether, given the context, they are contributing to the intended purpose of the process, not as a check-list of what every organization must have.
Information item identifier | An identifier number for the Information item which is used to reference the Information item. |
Information item name | Provides an example of a typical name associated with the Information item characteristics. This name is provided as an identifier of the type of Information item the practice or process might produce. Organizations may call these Information items by different names. The name of the Information item in the organization is not significant. Similarly, organizations may have several equivalent Information items which contain the characteristics defined in one Information item type. The formats for the Information items can vary. It is up to the assessor and the organizational unit coordinator to map the actual Information items produced in their organization to the examples given here. |
Information item characteristics | Provides examples of the potential characteristics associated with the Information item types. The assessor may look for these in the samples provided by the organizational unit. |
Table B.1 — Structure of IIC tables
Information items (with the ID NN-00) are sets of characteristics that would be expected to be evident in Information items of generic types as a result of achievement of an attribute. The generic Information items form the basis for the classification of specific Information items defined as process performance indicators.
Specific Information item types are typically created by process owners and applied by process deployers in order to satisfy an outcome of a particular process purpose.
Note: The generic Information items denoted with * are not used in the Automotive SPICE process assessment model but are included for completeness.
ID | Name | Characteristics |
01-00 | Configuration item | Item which is maintained under configuration control: - may include components, subsystems, libraries, test cases, compilers, data, documentation, physical media, and external interfaces - Version identification is maintained Description of the item is available including the: - type of item - associated configuration management library, file, system - responsible owner - date when placed under configuration control - status information (i.e., development, baselined, released) - relationship to lower level configured items - identification of the change control records - identification of change history |
01-03 | Software component | Software element in the software architecture above the software unit level. Represented by a design model element or executable code such as libs or scripts and a configuration description, if applicable. |
01-50 | Integrated software | Software executable (e.g. simulator with stubbing, debug-able, object code) including - application parameters values - all configured software elements |
01-51 | Application parameter | Name Description Value domain, threshold values, characteristic curves Owner Means of data application (e.g. flashing interfaces) If necessary a grouping/a categorization: - name of the category/group/file name - description Actual value or characteristic curve applied |
01-52 | Configuration item list | Identifies items under configuration control Identifies the name of work product and an associated reference (to file, to tool artifact) Identifies required attributes |
01-53 | Trained ML model | The trained ML model is the output of the training process. It consists of the software representing the ML architecture, the set of weights which were optimized during the training, and the final set of hyperparameters. |
01-54 | Hyperparameter | Hyperparameters are a subset of application parameters (see 01-51) and are used to control the ML model which has to be trained, e.g. - Learn rate of training - Scaling of network (number of layers or neurons per layer) - Loss function |
ID | Name | Characteristics |
02-00 | Contract | Defines what is to be purchased or delivered Identifies time frame for delivery or contracted service dates Identifies any statutory requirements Identifies monetary considerations Identifies any warranty information Identifies any copyright and licensing information Identifies any customer service requirements Identifies service level requirements References to any performance and quality expectations/constraints/monitoring Standards and procedures to be used Evidence of review and approval As appropriate to the contract the following are considered: - references to any acceptance criteria - references to any special customer needs (i.e., confidentiality requirements, security, hardware, etc.) - references to any change management and problem resolution procedures - identification of any interfaces to independent agents and subcontractors - identification of customer's role in the development and maintenance process - identification of resources to be provided by the customer |
02-01 | Commitment / agreement | Signed off by all parties involved in the commitment/agreement Establishes what the commitment is for Establishes the resources required to fulfill the commitment, such as: - time - people - budget - equipment - facilities |
03-00 | Data | A reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or communication, or processing |
03-03 | Benchmarking data | Results of measurement of current performance that allow comparison against historical or target values Relates to key goals/process/product/market need criteria and information to be benchmarked |
03-04 | Customer satisfaction data | Determines levels of customer satisfaction with products and services Mechanism to collect data on customer satisfaction: - results of field performance data - results of customer satisfaction survey - interview notes - meeting minutes from customer meetings |
ID | Name | Characteristics |
03-06 | Process Performance information | Data comparing process performance against expected levels Defined input and output work products available Meeting minutes Change records Task completion criteria met Quality criteria met Resource allocation and tracking |
03-50 | Verification Measure data | Verification measure data are data recorded during the execution of a verification measure, e.g. - for test cases: raw data, logs - measurements: values - calculations: values - simulations: protocol - reviews such as optical inspections à findings record - analyses: values |
03-51 | ML data set | Selection of ML Data for e.g., ML model training (ML Training and Validation Data Set) or test of the trained and deployed model (ML Test Data Set). |
03-53 | ML data | Datum to be used for Machine Learning. The datum has to be attributed by metadata, e.g., unique ID and data characteristics. Examples: - Visual data like a photo or videos (but a video could also be considered as sequence of photos depending on the intended use) - Audio recording - Sensor data - Data created by an algorithm - Data might be processed to create additional data. E.g., processing could add noise, change colors or merge pictures. |
03-54 | Hardware production data | Consists of bill of materials Consists of layout e.g. GERBER data Specifies requirements for EOL test e.g. - Test type (AOI, ICT, boundary scan) - Test coverage - Electrical loads Acceptance criteria In case of semiconductor development: mask data (GDS2) |
04-00 | Design | Describes the overall product/system structure Identifies the required product/system elements Identifies the relationship between the elements Consideration is given to: - any required performance characteristics - any required interfaces - any required security characteristics |
ID | Name | Characteristics |
04-02 | Domain architecture | Identified domain model(s) tailored from overall architecture ?? Identified product and work product specifications Definition of boundaries, dependencies and relationships with other domains (Domain Interface Specification) Identification of domain vocabulary Identification of the domain representation standard Provides an overview of the functions, features, and concepts in the domains |
04-03 | Domain model | Must provide a clear explanation and description, on usage and properties, for reuse purposes Identification of the management and structures used in the model |
04-04 | Software architecture | A justifying rationale for the chosen architecture. Behavior of software elements: - Allocation of requirements to software elements - Reusable components - Describes the individual behavior of an element - Describes the relationship between software elements - Settings for system parameters (such as application parameters) Interface Definitions: - Technical characteristics of interfaces for relationships between software elements: o Synchronization of Processes and tasks o Programming language call o APIs o Specifications of SW libraries - Method definitions in an object- oriented class definitions or UML/SysML interface classes - Callback functions, “hooks” Dynamics of software elements and software states: - Operating modes (e.g. start-up, shutdown, normal mode, calibration, diagnosis, etc.) - intercommunication (processes, tasks, threads) and priority - time slices and cycle time - interrupts with their priorities - interactions between software elements |
04-05 | Software detailed design | Elements of a software detailed design: - Control flow definition - Provides format of input/output data - Algorithms - Defined data structures - Justified global variables Examples for expression languages, depending on the complexity or criticality of a software unit: - natural language or informal languages - semi-formal languages (e.g. UML, SysML) - formal languages (e.g. model-based approach) |
04-06 | System architecture | A justifying rationale for the chosen architecture. Behavior of system elements: - Mapping of requirements to system elements - Reusable components - Describes the individual behaviors of an element - Describes the interrelationship between system elements - Manual/human control actions, e.g., according to STPA - Settings for system parameters (such as application parameters) Interface Definitions: - Technical characteristics of interfaces for relationships between two system elements: Interfaces for System e.g. - bus interfaces (CAN, MOST, LIN, Flexray etc.) - thermal influences - hardware-software-interfaces (HSI), see below - electromagnetic interfaces - optical interfaces - hardware-mechanical-interfaces (e.g., a cable satisfying both mechanical and electrical requirements, housing interface to a PCB) - hardware-mechanical interconnection technology such as connectors, pressfit - creepage and clearance distances Fixations such as adhesive joints, screw bolts/fitting, riveted bolts, welding System interfaces related to EE Hardware e.g. - analogue or digital interfaces (PWM, I/O) and their pin configurations - SPI bus, I2C bus, electrical interconnections - placement, e.g., thermal interfaces between hardware elements (heat dissipation) - soldering - creepage and clearance distances Interfaces for mechanical engineering e.g. - friction - thermal influences - tolerances - clutches - fixations such as adhesive joints, screw bolts/fitting, riveted bolts, welding - forces (as a result of e.g., vibrations or friction) - placement - shape - A hardware-software interface, e.g. - connector pin configurations and floating IOs for µCs/MOSFETs - signal scaling & resolution to be reflected by the application software Mechanical-hardware interfaces e.g. - such as mechanical dimensioning - positioning of connectors - positioning of e.g. hall sensors in relation to the bus-bar - tolerances Dynamics of system elements and system states: |
ID | Name | Characteristics |
- Description of the system states and operation modes (startup, shutdown, sleep mode, diagnosis/calibration mode, production mode, degradation, emergency such as “limp-home”, etc.) - Description of the dependencies among the system components regarding the operation modes - Interactions between system elements such as inertia of mechanical components to be reflected by the ECU, signal propagation and processing time through the hardware and software and e.g. bus systems | ||
04-50 | Build list | Identification of aggregates of the software application system Identification of required system elements (application parameter settings, macro libraries, data bases, job control languages, etc.) Necessary sequence ordering identified for compiling the software release Input and output source libraries identified |
04-51 | ML architecture | An ML architecture is basically a special part of a software architecture (see 04-04). Additionally - ML architecture describes the overall structure of the ML-based software element - ML architecture specifies ML architectural elements including an ML model and other ML architectural elements, provided to train, deploy, and test the ML model. - describes interfaces within the ML-based software element and to other software elements - ML architecture describes details of the ML model like used layers, activation functions, loss function, and backpropagation - ML architecture contains defined hyperparameter ranges and initial values for training start - resource consumption objectives are defined - ML architecture contains allocated ML requirements |
04-52 | Hardware architecture | Describes the overall hardware structure Identifies the required hardware components Includes the rationale for chosen options of hardware architecture Identifies own developed and supplied hardware components Identifies the required internal and external hardware component interfaces Specifies the interfaces of the hardware components Specifies the dynamic behaviour Identifies the relationship and dependency between hardware components Describes all hardware variants to be developed Describes power supply, thermal and grounding concepts |
ID | Name | Characteristics |
04-53 | Hardware detailed design description | Describes the interconnections between the hardware parts Specifies the interfaces of the hardware parts Specifies the dynamic behavior (Examples are: transitions between electrical states of hardware parts, power-up and power-down sequences, frequencies, modulations, signal delays, debounce times, filters, short circuit behavior, self-protection) Describes the conclusions and decisions based on e.g. analysis reports, datasheets, application notes Describes the constraints for layout |
04-54 | Hardware Schematics | Identifies the hardware parts Specifies the connections of the hardware parts Specifies the unique identification of all hardware parts Specifies unique variant identification |
04-55 | Hardware Layout | Specifies the placement of the hardware parts and labels Specifies manufacturing data e.g. circuit paths (width, routing), vias, testing points, number of layers, drillings, material of the PCB, shape, soldering resist mask, PCB coating Specifies a unique layout identification |
04-56 | Hardware element interface | is defined by output, input, type, and electrical characteristics including signal tolerances. Examples of interfaces are - high level interfaces like SPI, I2C, CAN, LIN, Ethernet - electrical interconnections - thermal interfaces between hardware elements (heat dissipation) |
05-00 | Goals | Identifies the objective to be achieved Identifies who is expected to achieve the goal Identifies any incremental supporting goals Identifies any conditions/constraints Identifies the timeframe for achievement Are reasonable and achievable within the resources allocated Are current, established for current project, organization Are optimized to support known performance criteria and plans |
05-01 | Resource Consumption Targets | Resource consumption targets for software architectural elements referring to resources like memory (ROM, RAM, external / internal EEPROM or Data Flash), CPU load |
06-00 | User documentation | Identifies: - external documents - internal documents - current site distribution and maintenance list maintained Documentation kept synchronized with latest product release Addresses technical issues |
ID | Name | Characteristics |
06-02 | Handling and Storage Guide | Defines the tasks to perform in handling and storing products including: - providing for master copies of code and documentation - disaster recovery - addressing appropriate critical safety and security issues Provides a description of how to store the product including: - storage environment required - the protection media to use - packing materials required - what items need to be stored - assessments to be done on stored product Provides retrieval instructions |
06-04 | Training material | Updated and available for new releases Coverage of system, application, operations, maintenance as appropriate to the application Course listings and availability |
06-50 | Integration sequence instruction | Identification of required physical elements (e.g. hardware, mechanical, wiring elements), and software executables and application parameter settings necessary sequence or ordering of integration preconditions for starting system integration |
06-51 | Tailoring guideline | Criteria for tailoring, Proceeding of tailoring describing how to derive the defined process from the standard process Requirements for the defined process to ensure integrity and consistency of the defined process Subset of process assets that is essential for the defined process |
06-52 | Backup and recovery mechanism information | Description / confirmation of existing backup and recovery mechanisms References to corresponding procedures or regulations |
07-00 | Measure | Available to those with a need to know Understood by those expected to use them Provides value to the organization/project Non-disruptive to the workflow Appropriate to the process, life cycle model, organization: - is accurate - source data is validated - results are validated to ensure accuracy Has appropriate analysis and commentary to allow meaningful interpretation by users |
07-01 | Customer satisfaction survey | Identification of customer and customer information Date requested Target date for responses Identification of associated hardware/software/product configuration Ability to record feedback |
ID | Name | Characteristics |
07-02 | Field metric | Measures attributes of the performance of system's operation at field locations, such as: - field defects - performance against defined service level measures - system ability to meet defined customer requirements - support time required - user complaints (may be third party users) - customer requests for help - performance trends - problem reports - enhancements requested |
07-04 | Process metric | Measurements about the process' performance: - ability to produce sufficient work products - adherence to the process - time it takes to perform process - defects related to the process Measures the impact of process change Measures the efficiency of the process |
07-05 | Project metric | Monitors key processes and critical tasks, provides status information to the project on: - project performance against established plan - resource utilization against established plan - time schedule against established plan - process quality against quality expectations and/or criteria - product quality against quality expectations and/or criteria - highlight product performance problems, trends Measures the results of project activities: - tasks are performed on schedule - product's development is within the resource commitments allocated References any goals established |
07-06 | Quality metric | Measures quality attributes of the work products defined: - functionality - reliability - usability - efficiency - maintainability - portability Measures quality attributes of the "end customer" quality perception Note: Refer ISO/IEC 25010 for detailed information on measurement of product quality. |
ID | Name | Characteristics |
07-08 | Service level metric | Real time metrics taken while a system is operational, it measures the system's performance or expected service level Identifies aspects such as: - capacity - throughput - operational performance - operational service - service outage time - up time - job run time |
07-50 | Process performance metric | Monitors key activities and critical tasks, provides status information to the project on: - task progress against established plan - resource utilization against established schedule - process performance quality against defined criteria - highlight process performance problems, trends |
08-00 | Plan | As appropriate to the application and purpose: - Identifies what objectives or goals there are to be satisfied - Establishes the options and approach for satisfying the objectives, or goals Identification of the plan owner Includes: - the objective and scope of what is to be accomplished - assumptions made - constraints - risks - tasks to be accomplished - schedules, milestones and target dates - critical dependencies - maintenance disposition for the plan Method/approach to accomplish plan Identifies: - task ownership, including tasks performed by other parties (e.g. supplier, customer) - quality criteria - required work products Includes resources to accomplish plan objectives: - time - staff (key roles and authorities e.g. sponsor) - materials/equipment - budget Includes contingency plan for non-completed tasks Plan is approved |
ID | Name | Characteristics |
08-04 | Configuration management plan | Defines or references the procedures to control changes to configuration items Defines measurements used to determine the status of the configuration management activities Defines configuration management audit criteria Approved by the configuration management function Identifies configuration library tools or mechanism Includes management records and status reports that show the status and history of controlled items Specifies the location and access mechanisms for the configuration management library Storage, handling and delivery (including archival and retrieval) mechanisms specified |
08-12 | Project plan | Contains strategies to achieve the project objectives Defines responsibilities for performance of activities Defines internal and external stakeholders and their commitments Defines internal and external communication Defines an escalation mechanism Defines: - work products to be developed - life cycle model and methodology to be used - customer requirements related to project management - project resources Milestones and target dates: - estimates - quality criteria - processes and methods to employ - contingency actions |
08-13 | Quality plan | Objectives/goal for quality Defines the activities tasks required to ensure quality References related work products References any regulatory requirements, standards, customer requirements Identifies the expected quality criteria Specifies the monitoring and quality checkpoints for the defined life cycle and associated activities planned Defines the methods of assuring quality Identifies the quality criteria for work products and process tasks Specifies the threshold/tolerance level allowed prior to requiring corrective actions Defines quality measurements and timing of the collection Specifies mechanism to feed collected quality record back into process impacted by poor quality Defines the approach to guaranteeing objectivity Approved by the quality responsible organization/function: - identifies escalations opportunities and channels - defines the cooperation with customer and supplier QA |
ID | Name | Characteristics |
08-14 | Recovery plan | Identifies what is to be recovered: - procedures/methods to perform the recovery - schedule for recovery - time required for the recovery - critical dependencies - resources required for the recovery - list of backups maintained - staff responsible for recovery and roles assigned - special materials required - required work products - required equipment - required documentation - locations and storage of backups - contact information on who to notify about the recovery - verification procedures - cost estimation for recovery |
08-16 | Release plan | - Identifies the functionality to be included in each release - Identifies the associated elements required (i.e., hardware, software, documentation etc.) - Mapping of the customer requests, requirements satisfied to particular releases of the product |
08-17 | Reuse plan | Defines the policy about what items to be reused Defines standards for construction of reusable objects: - defines the attributes of reusable components - quality/reliability expectations - standard naming conventions Defines the reuse repository (library, CASE tool, file, data base, etc.) Identifies reusable components: - directory of component - description of components - applicability of their use - method to retrieve and use them - restrictions for modifications and usage Method for using reusable components Establishes goal for reusable components |
08-18 | Review plan | Defines: - what to be reviewed - roles and responsibilities of reviewers - criteria for review (check-lists, requirements, standards) - expected preparation time - schedule for reviews Identification of: - procedures for conducting review - review inputs and outputs - expertise expected at each review - review records to keep - review measurements to keep - resources, tools allocated to the review |
ID | Name | Characteristics |
08-19 | Risk management plan | Project risks identified and prioritized Mechanism to track the risk Threshold criteria to identify when corrective action required Proposed ways to mitigate risks: - risk mitigator - work around - corrective actions activities/tasks - monitoring criteria - mechanisms to measure risk |
08-20 | Risk mitigation plan | Planned risk treatment activities and tasks: - describes the specifics of the risk treatment selected for a risk or combination of risks found to be unacceptable - describes any difficulties that may be found in implementing the treatment Treatment schedule Treatment resources and their allocation Responsibilities and authority: - describes who is responsible for ensuring that the treatment is being implemented and their authority Treatment control measures: - defines the measures that will be used to evaluate the effectiveness of the risk treatment Treatment cost Interfaces among parties involved: - describes any coordination among stakeholders or with the project’s master plan that must occur for the treatment to be properly implemented - Environment/infrastructure: - describes any environmental or infrastructure requirements or impacts (e.g., safety or security impacts that the treatment may have) Risk treatment plan change procedures and history |
08-27 | Problem management plan | Defines problem resolution activities including identification, recording, description and classification Problem resolution approach: evaluation and correction of the problem Defines problem tracking Mechanism to collect and distribute problem resolutions |
08-28 | Change management plan | Defines change management activities including identification, recording, description, analysis and implementation Defines approach to track status of change requests Defines verification and validation activities Change approval and implication review |
08-29 | Improvement plan | Improvement objectives derived from organizational business goals Organizational scope Process scope, the processes to be improved Key roles and responsibilities Appropriate milestones, review points and reporting mechanisms Activities to be performed to keep all those affected by the improvement program informed of progress |
ID | Name | Characteristics |
08-50 | Test specification | Test Design Specification Test Case Specification Test Procedure Specification Identification of test cases for regression testing Additionally, for system integration: - identification of required system elements (hardware elements, wiring elements, settings for parameters (such as application parameters or global variables) , data bases, etc.) - necessary sequence or ordering identified for integrating the system elements |
08-52 | Test plan | Test Plan according to ISO29119-3 Context: - project/Test sub-process - test item(s) - test scope - assumptions and constraints - stakeholder - testing communication Test strategy - identifies what needs there are to be satisfied - establishes the options and approach for satisfying the needs (black-box and/or white-box-testing, boundary class test determination, regression testing strategy, etc.) - establishes the evaluation criteria against which the strategic options are evaluated - identifies any constraints/risks and how these will be addressed - test design techniques - test completion criteria - test ending criteria - test start, abort and re-start criteria - metrics to be collected - test data requirements - retesting and regression testing - suspension and resumption criteria - deviations from the Organizational Test Strategy - Test data requirements - Test environment requirements - Test sub-processes - Test deliverables - Testing activities and estimates |
08-53 | Scope of work | Summary of deliverables for a project Intended use for the deliverables Main functions to be realized Target delivery date and major milestones Work products and activities that are not in scope of the project as needed Target markets Applicable standards and legal requirements Relevant customer requirements for performance of activities Reuse options Integration of third party deliveries |
ID | Name | Characteristics |
08-54 | Feasibility analysis | Statement about the ability of the project to achieve the project objectives with available resources |
08-55 | Risk measure | Identifies the probability of risk occurring Identifies the impact of risk occurring Establishes measures for each risk defined Measures the change in the risk state |
08-56 | Schedule | Identifies the activities to be performed Identifies the releases of products Identifies the expected and actual start and completion date for required activities against progress/completion of activities Identifies dependencies between activities and critical paths Has a mapping to scheduled resource data Identifies resource allocation, resource workload and critical resources Note: A schedule is consistent with the defined work packages, see 14-10 |
08-57 | Validation Measure Selection Set | Include criteria for re-validation in the case of changes (regression). Identification of validation measures, also for regression |
08-58 | Verification Measure Selection Set | Include criteria for re-verification in the case of changes (regression). Identification of test cases, also for regression testing |
08-59 | Validation Measure | A validation measure can be a test case, a measurement, a simulation, an emulation, or an end user survey The specification of a validation measure includes - pass/fail criteria for validation measures (completion and end criteria) - a definition of entry and exit criteria for the validation measures, and abort and re-start criteria Techniques Necessary validation environment & infrastructure Necessary sequence or ordering |
08-60 | Verification Measure | A verification measure can be a test case, a measurement, a calculation, a simulation, a review, an optical inspection, or an analysis The specification of a verification measure includes - pass/fail criteria for verification measures (test completion and ending criteria) - a definition of entry and exit criteria for the verification measures, and abort and re-start criteria Techniques (e.g. black-box and/or white-box-testing, equivalence classes and boundary values, fault injection for Functional Safety, penetration testing for Cybersecurity, back-to- back testing for model- based development, ICT) Necessary Verification environment & infrastructure Necessary sequence or ordering |
ID | Name | Characteristics |
08-61 | Resource allocation | Detailed / named resources are allocated to process tasks Overall resource workload is considered (e.g., allocation of resources to multiple projects) Note: Work breakdown structure may be used to refine the detailed resource allocation Note: A resource allocation may be integrated into/part of the schedule, see 14-06 |
08-62 | Communication matrix | List of relevant process internal / external stakeholders Roles and contact information of the parties involved Definition of required interfaces between stakeholders Communication subject Communication means and frequency Documentation needs of the communication (e.g., type of communication record) |
08-63 | Process Monitoring Method | Measures including criteria for monitoring effectiveness, suitability, and adequacy of the standard process Method for collecting and analyzing the monitoring measures |
08-64 | ML test approach | The ML test approach describes - test scenarios with distribution of data characteristics (e.g., sex, weather conditions, street conditions within the ODD) defined by ML requirements - quantity of each test scenario inside the test data set - expected test result per test datum - pass/fail criteria for the ML testing - entry and exit criteria for the ML testing - the required ML testing infrastructure and environment configuration |
08-65 | ML training and validation approach | The ML Training and Validation approach describes at least: - entry and exit criteria of the ML training - approaches for hyperparameter tuning / optimization to be used in the training - approach for data set creation and modification - training environment, including required training hardware (e.g., GPU, or supercomputer to be used) - interface adapter for provision of input data and storage of output data - if required, actions to organize the data set and training environment The ML training and validation approach may additionally include methods for robustification methods like random dropout |
09-00 | Policy | Authorized Available to all personnel impacted by the policy Establishes practices/rules to be adhered to |
ID | Name | Characteristics |
09-03 | Reuse policy | Identification of reuse requirements Establishes the rules of reuse ·Documents the reuse adoption strategy including goals and objectives Identification of the reuse program Identification of the name of the reuse sponsor Identification of the reuse program participants Identification of the reuse steering function Identification of reuse program support functions |
10-00 | Process description | Process description of a standard or defined process (e.g., after tailoring), including: - Scope and the intended use of the process - Process activities including description and dependencies - Inputs including information needed and expected outputs - Entry and exit criteria - Roles assigned to process activities (e.g., as RASIC ) - Guidelines - Templates - Description of specific methods |
10-50 | Role description | Name/identifier (Unique within the organization) Assigned activities (e.g., as RASIC) Responsibilities and authorities Required competencies Required skills Required experience and trainings |
10-51 | Qualification method description | Training courses Training material Mentoring concepts Self-learning material |
10-52 | Process resource and infrastructure description | Required facilities Required tools and corresponding licenses Required networks Required services Required samples |
11-00 | Product | Is a result/deliverable of the execution of a process, includes services, systems (software and hardware) and processed materials Has elements that satisfy one or more aspects of a process purpose May be represented on various media (tangible and intangible) |
ID | Name | Characteristics |
11-03 | Release note | Coverage for key elements (as appropriate to the application): Description of what is new or changed (including features removed) System information and requirements Identification of conversion programs and instructions Release numbering implementation may include: - the major release number - the feature release number - the defect repair number - the alpha or beta release; and the iteration within the alpha or beta release Identification of the component list (version identification included): - hardware / software / product elements, libraries, etc. - associated documentation list New/changed parameter information (e.g. for application parameters or global variables) and/or commands Backup and recovery information List of open known problems, faults, warning information, etc. Identification of verification and diagnostic procedures Technical support information Copyright and license information The release note may include an introduction, the environmental requirements, installation procedures, product invocation, new feature identification and a list of defect resolutions, known defects and workarounds |
11-04 | Product release package | Includes the hardware/software/product Includes and associated release elements such as: - system hardware/software/product elements - associated customer documentation - application parameter definitions defined - command language defined - installation instructions - release letter |
11-05 | Software Unit | Software design model element at the lowest level, or commented source code including - parameter and return value information - variables and data structures defined - data types defined - algorithms defined - configuration files - or executable code - or commented scripts - or auto-coded code represented by model elements |
11-06 | Integrated System | Integrated product Application parameters values All configured elements for the product release are included |
11-50 | Deployed ML model | The deployed model is a ML specific software item. It is derived from the trained ML model (see 01-53) and is to be integrated into the target system. It may differ from the trained ML model which often requires powerful hardware and uses interpretative languages. |
ID | Name | Characteristics |
12-01 | Request for quotation | Reference to the requirements specifications Identifies supplier selection criteria Identifies desired characteristics, such as: - system architecture, configuration requirements or the requirements for service (consultants, maintenance, etc.) - quality criteria or requirements - project schedule requirements - expected delivery/service dates - cost/price expectations - regulatory standards/requirements - Identifies submission constraints: - date for resubmission of the response - requirements with regard to the format of response |
12-03 | Reuse candidate | Identifies the product to be reused Identifies the responsible person for the products to be reused Identifies the reuse goals and objectives Identifies the list of reuse assets Identifies the issues/risks of reusing the component including specific requirements (hardware, software, resource and other reuse components) Identifies the person who will be qualifying the reuse candidate |
13-00 | Record | Work product stating results achieved or provides evidence of activities performed in a process An item that is part of a set of identifiable and retrievable data |
13-01 | Acceptance record | Record of the receipt of the delivery Identification of the date received Identification of the delivered components Records the verification of any customer acceptance criteria defined Signed by receiving customer |
13-04 | Communication evidence | All forms of interpersonal communication e.g.: - letters - e-mails - blog - forum - live chat - wikis - photo protocol - meeting support record |
13-06 | Delivery evidence | Evidence of items shipped/delivered electronically to customer Identification of: - to whom it was sent - address, where delivered - delivery date - receipt of delivered product |
ID | Name | Characteristics |
13-07 | Problem record | Identifies the submitter of the problem Identifies the group/person(s) responsible for providing problem resolution Includes a description of the problem Identifies classification of the problem (criticality, urgency, relevance etc.) Identifies the status of the problem - States such as “open”, “in review”, “in implementation”, “closed”, “rejected”, “cancelled”, … - Transitions between states with conditions and authorities Identifies the expected closure date |
13-08 | Baseline | Identifies a state of one or a set of work products and artifacts which are consistent and complete Basis for next process steps and/or delivery Is unique and may not be changed Note: This should be established before a release to identify consistent and complete delivery |
13-09 | Meeting support record | Agenda and minutes that are records that define: - purpose of meeting - attendees - date, place held - reference to previous minutes - what was accomplished - identifies issues raised - any open issues - next meeting if any |
13-10 | Configuration management record | Status of the configuration items and modifications Identifies activities performed e.g. backup, storage, archiving, handling and delivery of configuration items Supports consistency of the product, e.g. - work product revision - when updated - work product status - when approved - reference to approval source |
13-13 | Product release approval | Content information of what is to be shipped or delivered Identification of: - for whom it is intended - the address where to deliver - the date released - Evidence of supplier approval |
ID | Name | Characteristics |
13-14 | Progress status record | Record of the status of a plan(s) (actual against planned) such as: - status of actual activities/work packages against planned activi- ties/work package - status of actual results against established objectives/goals - status of actual resources allocation against planned resources - status of actual cost against budget estimates - status of actual time against planned schedule - status of actual quality against planned quality Record of any deviations from planned activities and reason why |
13-15 | Proposal review record | Scope of proposal and requirements Possible contingencies or risks Alignment of the proposal with the strategic business plan of the organization Protection of proprietary information Requirements which differ from those in the original documentation Capability to meet contractual requirements Responsibility for subcontracted work Terminology Supplier ability to meet obligations Approved |
13-16 | Change request | Identifies purpose of change Identifies requester contact information Impacted system(s) Impact to operations of existing system(s) defined Impact to associated documentation defined Criticality of the request, due date Information supporting the tracking of change requests to closure - progress status attribute (e.g., open, allocated, implemented, closed) - time stamp of status change - person who changed a status - rationale for changing a status |
13-18 | Quality record | Identifies what tasks/activities/process produce the information Identifies when the data was collected Identifies source of any associated data Identifies the associated quality criteria Identifies any associated measurements using the information Identifies any requirements to be adhered to create the record, or satisfied by the record |
ID | Name | Characteristics |
13-19 | Review record | Provides the context information about the review: - what was reviewed - lists reviewers who attended - status of the review Provides information about the coverage of the review: - check-lists - review criteria - requirements - compliance to standards Records information about: - the readiness for the review - preparation time spent for the review - time spent in the review - reviewers, roles and expertise Review findings: - non-conformances - improvement suggestions Identifies the required corrective actions: - risk identification - prioritized list of deviations and problems discovered - the actions, tasks to be performed to fix the problem - ownership for corrective action - status and target closure dates for identified problems |
ID | Name | Characteristics |
13-20 | Risk action request | Date of initiation Scope Subject Request originator Risk management process context: - this section may be provided once, and then referenced in subsequent action requests if no changes have occurred - process scope - stakeholder perspective - risk categories - risk thresholds - project objectives - project assumptions - project constraints Risks: - this section may cover one risk or many, as the user chooses - where all the information above applies to the whole set of risks, one action request may suffice - where the information varies, each request may cover the risk or risks that share common information - risk description(s) - risk probability - risk consequences - expected timing of risk Risk treatment alternatives: - treatment option selected- avoid/reduce/transfer - alternative descriptions - recommended alternative(s) - justifications Risk action request disposition: - each request should be annotated as to whether it is accepted, rejected, or modified, and the rationale provided for whichever decision is taken |
13-21 | Change control record | Used as a mechanism to control change to baselined products/products in official project release libraries Record of the change requested and made to a baselined product (work products, software, customer documentation, etc.): - identification of system, documents impacted with change - identification of change requester - identification of party responsible for the change - identification of status of the change Linkage to associated customer requests, internal change requests, etc. Appropriate approvals Duplicate requests are identified and grouped |
ID | Name | Characteristics |
13-22 | Traceability Record | All requirements (customer and internal) are to be traced Identifies a mapping of requirement to life cycle work products Provides the linkage of requirements to work product decomposition (i.e., requirement design code test deliverables, etc.) Provides forward and backwards mapping of requirements to associated work products throughout all phases of the life cycle Note: this may be included as a function of another defined work product (example: A CASE tool for design decomposition may have a mapping ability as part of its features) |
13-24 | Validation Results | Validation data, logs, feedback, or documentation Validation measure passed Validation measure not passed Validation measure not executed Information about the validation execution (date, participants etc.) Abstraction or summary of validation results |
13-25 | Verification results | Verification check-list Passed items of verification Failed items of verification Pending items of verification Problems identified during verification Risk analysis Recommendation of actions Conclusions of verification Signature of verification |
13-50 | Test result | Level Test Log Anomaly Report Level Test Report (Summary) - test cases not passed - test cases not executed - information about the test execution (date, tester name etc.) Additionally where necessary: Level Interim Test Status Report Master Test Report (Summary) |
ID | Name | Characteristics |
13-51 | Consistency Evidence | Demonstrates bidirectional traceability between artifacts or information in artifacts, throughout all phases of the life cycle, by e.g. - tool links - hyperlinks - editorial references - naming conventions Evidence that the content of the referenced or mapped information coheres semantically along the traceability chain, e.g. by - performing pair working or group work - performing by peers, e.g. spot checks - maintaining revision histories in documents - providing change commenting (via e.g. meta-information) of database or repository entries Note: verification measures and verification results are, by definition, consistent, however still need to be traceable. This evidence can be accompanied by e.g. Definition of Done (DoD) approaches. |
13-52 | Communication Evidence | All forms of interpersonal communication such as - e-mails - tool-supported workflows - podcast - blog - videos - forum - live chat - wikis - photo protocol - meeting, orally or via meeting minutes |
13-53 | Qualification evidence | Qualification check-list Passed items of Qualification Failed items of Qualification Pending items of Qualification Problems identified during Qualification Risk analysis Recommendation of actions Conclusions of Qualification Approval |
13-54 | Configuration management record | Status of the configuration item and modifications Identifies activities performed e.g. backup, storage, archiving, handling and delivery for the configuration item Supports consistency of the product, e.g. - work product revision - when updated - work product status - when approved - reference to approval source Befüllter Status des jeweiligen Eintrags in der CI Liste. Wird laufend aktualisiert. Dient u.A. zur Statusermittlung. |
ID | Name | Characteristics |
13-55 | Process resource and infrastructure documentation | Information on availability, allocation, and usage of - Facilities - Tools and corresponding licenses - Networks - Services - Samples for non-standard and critical resources and infrastructure. |
14-00 * | Register | A register is a compilation of data or information captured in a defined sequence to enable: - an overall view of evidence of activities that have taken place - monitoring and analyzes - provides evidence of performance of a process over time |
14-01 | Change history | Historical records of all changes made to an object (document, file, software component, etc.): - description of change - version information about changed object - date of change - change requester information - change control record information |
14-02 | Corrective action | Identifies the initial problem Identifies the ownership for completion of defined action Defines a solution (series of actions to fix problem) Identifies the open date and target closure date Contains a status indicator Indicates follow up audit actions |
14-08 | Tracking system | Ability to record customer and process owner information Ability to record related system configuration information Ability to record information about problem or action needed: - date opened and target closure date - severity/criticality of item - status of any problem or actions needed - information about the problem or action owner - priority of problem resolution Ability to record proposed resolution or action plan Ability to provide management status information Information is available to all with a need to know Integrated change control system(s)/records |
ID | Name | Characteristics |
14-09 | Work breakdown structure | Defines tasks to be performed, and their amendments Documents ownership for tasks Documents critical dependencies between tasks Documents inputs and output work products Documents the critical dependencies between defined work products Method to assign tasks for support processes, management processes and primary life cycle processes Information needed to perform these tasks Major work packages External and internal dependencies Note: A work breakdown structure may be integrated into/part of the schedule, see 14-06 |
14-10 | Work package | Defines activities to be performed Documents ownership for activities e.g., by domains Documents critical dependencies to other work packages Documents input and output work products Documents the critical dependencies between defined work products Information needed to perform these activities Note: The work package descriptions may be integrated into/part of the schedule, see 08-56 |
14-50 | Stakeholder groups list | Identifies: - relevant stakeholder groups // affected or involved parties?? - weight/importance of each stakeholder group - representative(s) for each stakeholder group - information needs of each stakeholder group |
14-51 | Cybersecurity scenario register | Identifies: - damage scenarios - ID - title - description - impact category: o safety o financial o operational o privacy o quality Threat scenarios - ID - asset concerned - security property: o confidentiality o integrity o availability Attack feasibility (high/medium/low/very low) |
ID | Name | Characteristics |
14-52 | Asset Library | Identifies: - title - description - security property: o confidentiality o integrity o availability - stakeholders related to the asset |
14-53 | Role Assignment | Assignment of person(s) to roles - required competencies vs existing competencies - required skills vs existing skills - required experience and trainings based on identified competencies / skills gap |
14-54 | Hardware Bill of materials | Uniquely identifies type, supplier, and amount of the complete set of all hardware parts of the hardware |
15-00 * | Report | A work product describing a situation that: - includes results and status - identifies applicable/associated information - identifies considerations/constraints - provides evidence/verification |
15-01 | Analysis report | What was analyzed? Who did the analysis? The analysis criteria used: - selection criteria or prioritization scheme used - decision criteria - quality criteria Records the results: - what was decided/selected - reason for the selection - assumptions made - potential risks Aspects of correctness to analyze include: - completeness - understandability - testability - verifiability - feasibility - validity - consistency - adequacy of content |
15-03 | Configuration status report | Identification of the number of items under configuration management Identification of risks associated to configuration management Identification of the number of configuration management items lost and reason for their loss Identification of problem and issues related to configuration management Identification of receiving parties Identification of baselines made |
ID | Name | Characteristics |
15-05 | Evaluation report | States the purpose of evaluation Method used for evaluation Requirements used for the evaluation Assumptions and limitations Identifies the context and scope information required: - date of evaluation - parties involved - context details - evaluation instrument (check-list, tool) used Records the result: - data - identifies the required corrective and preventive actions - improvement opportunities, as appropriate |
15-06 | Project status report | A report of the current status of the project Schedule: - planned progress (established objectives/goals) or completion (dates/deadlines) of tasks against - actual progress of tasks - reasons for variance from planned progress - threats to continued progress - contingency plans to maintain progress Resources (human resources, infrastructure, hardware/materials, budget): - planned expenditure against actual expenditure - reasons for variance between planned and actual expenditure - expected future expenditure - contingency plans to achieve budget goals Quality goals: - actual quality measures - reasons for variance from planned quality measures - contingency plans to achieve quality goals Project issues: - issues which may affect the ability of the project to achieve its goals. - contingency plans to overcome threats to project goals |
15-07 | Reuse analysis evidence | Identification of reuse opportunities Identification of constraints for reuse Identification of regression test cases Identification of reuse infrastructure Identification of known defects |
ID | Name | Characteristics |
15-08 | Risk analysis | Identifies the risks analyzed ID Impact scenario (e.g., damage scenario) Records the results of the analysis: - potential ways to mitigate the risk - selected risk treatment option (e.g. risk acceptance as cybersecurity claim or risk reduction) - assumptions made - probability of occurrence (e.g., attack feasibility) - risk value - constraints |
15-09 | Risk status | Identifies the status of an identified risk: - related project or activity - risk statement - condition - consequence - changes in priority - duration of mitigation, when started - risk mitigation activities in progress - responsibility - constraints |
15-12 | Problem status report | Presents a summary of problem records: - by problem categories/classification - by status of problem resolution - by other relevant categories - indicates progress of problem resolution |
15-13 | Assessment/audit report | States the purpose of assessment Method used for assessment Requirements used for the assessment Assumptions and limitations Identifies the context and scope information required: - date of assessment - organizational unit assessed - sponsor information - assessment team - attendees - scope/coverage - assesses and information - assessment Instrument (check-list, tool) used Records the result: - data - identifies the required corrective actions - improvement opportunities |
15-16 | Improvement opportunity | Identifies what the problem is Identifies what the cause of a problem is Suggest what could be done to fix the problem Identifies the value (expected benefit) in performing the improvement Identifies the penalty for not making the improvement |
ID | Name | Characteristics |
15-18 | Process performance report | No requirements additional to Evaluation report (Generic) |
15-50 | Vulnerability analysis report | Identifies - ID - description - attack path concerned - attack feasibility (e.g., CVSS (Common Vulnerability Scoring System) rating) |
15-51 | Analysis Results | Identification of the object under analysis. The analysis criteria used, e.g. selection criteria or prioritization scheme used decision criteria quality criteria The analysis results, e.g. what was decided/selected reason for the selection assumptions made potential risks Aspects of the analysis may include correctness understandability verifiability feasibility validity |
15-52 | Verification Results | Verification data and logs - Verification measure passed - Verification measure not passed - Verification measure not executed - information about the test execution (date, tester name etc.) - Abstraction or summary of verification results |
15-53 | Configuration status report | Summary of configuration management records including relevant status Analysis of the configuration management overall state, such as - identification of risks associated to configuration management - identification of the number of configuration management items lost and reason for their loss - identification of problem and issues related to configuration management - identification of receiving parties - identification of baselines made |
15-54 | Tailoring documentation | Applied criteria for tailoring, Evidence that the defined process is tailored from the standard process according to the defined criteria |
ID | Name | Characteristics |
15-55 | Problem analysis evidence | Author and involved parties Date of the analysis Context and root cause of the problem Analysis result may include - Impact - Potential risks - Affected parties - Potential solution (if known) |
15-56 | Configuration status summary | Summary of configuration management records including relevant status Analysis of the configuration management overall state Identification of baselines made |
16-00 * | Repository | Repository for components Storage and retrieval capabilities Ability to browse content Listing of contents with description of attributes Sharing and transfer of components between affected groups Effective controls over access Maintain component descriptions Recovery of archive versions of components Ability to report component status Changes to components are tracked to change/user requests |
16-03 | Configuration management system | Supports the configuration management for the scope of the configuration item list contents Correct configuration of products Can recreate any release or test configuration Ability to report configuration status Has to cover all relevant tools |
16-06 | Process repository | Contains process descriptions Supports multiple presentations of process assets |
16-50 | Organization structure | Disciplinary reporting line Organizational units and sub-units, if applicable |
16-51 | Process Infrastructure | Description of methods and guidelines needed to perform the process Templates or at least detailed requirements for the documented information of the process Tools or work environment needed to perform the process |
16-52 | ML data management system | The ML data management system is part of the configuration management system (see 16-03) and Supports data management activities like data collection, description, ingestion, exploration, profiling, labeling/annotation, selection, structuring and cleansing Provides the data for different purposes, e.g., training, testing Supports the relevant sources of ML data |
ID | Name | Characteristics |
17-00 | Requirement | An expectation of functions and capabilities (e.g. nonfunctional requirements), or one of its interfaces - from a black-box perspective - that is verifiable, does not imply a design or implementation decision, is unambiguous, and does not introduce contradictions to other requirements. A requirements statement that implies, or represents, a design or implementation decision is called “Design Constraint”. Examples for requirements aspects at the system level are thermal characteristics such as - heat dissipation - dimensions - weight - materials Examples of aspects related to requirements about system interfaces are - connectors - cables - housing Examples for requirements at the hardware level are - lifetime and mission profile, lifetime robustness - maximum price - storage and transportation requirements - functional behavior of analog or digital circuits and logic - quiescent current, voltage impulse responsiveness to crank, start- stop, drop-out, load dump - temperature, maximum hardware heat dissipation - power consumption depending on the operating state such as sleep-mode, start-up, reset conditions - frequencies, modulation, signal delays, filters, control loops - power-up and power-down sequences, accuracy and precision of signal acquisition or signal processing time - computing resources such as memory space and CPU clock tolerances - maximum abrasive wear and shearing forces for e.g. pins or soldering joints - requirements resulting from lessons learned - safety related requirements derived from the technical safety concept |
ID | Name | Characteristics |
17-03 | Stakeholder requirements | Purpose/objectives defined Includes issues/requirements from (contract) reviews Identifies any: - time schedule/constraints - required feature and functional characteristics - necessary performance considerations/constraints - necessary internal/external interface considerations/constraints - required system characteristics/constraints - human engineering considerations/constraints - security considerations/constraints - environmental considerations/constraints - operational considerations/constraints - maintenance considerations/constraints - installation considerations/constraints - support considerations/constraints - design constraints - safety/reliability considerations/constraints - quality requirements/expectations |
17-05 | Requirements for documented information | Requirements for content and structure, storage and control - Identifies documentation specific meta data, such as date, author information, review and approval status or others - Identifies requirements on documentation structure, e.g. table of content or figures or other formal aspects - May be provided by documentation templates - May be based on tool specific templates - Defines the storage location such as data repository, tool, versioning system - Requirements for versioning - Requirements for baselining - Distribution of the documents - Maintenance and disposal of the documents - May be specific for certain types of documents |
17-08 | Interface requirements specification | Defines relationships between two products, process or process tasks Defines criteria and format for what is common to both Defines critical timing dependencies or sequence ordering Description of the physical interfaces of each system component like: - bus interfaces (CAN, MOST, LIN, Flexray etc.) - transceiver (type, manufacturer, etc.) - analogue interfaces - digital interfaces (PWM, I/O) - additional interfaces (IEEE, ISO, Bluetooth, USB, etc.) Identification of the software interfaces of software components and other software item in terms of: - inter-process communication mechanisms - bus communication mechanisms |
ID | Name | Characteristics |
17-11 | Software requirements specification | Identifies standards to be used Identifies any software structure considerations/constraints Identifies the required software elements Identifies the relationship between software elements Consideration is given to: - any required software performance characteristics - any required software interfaces - any required security characteristics required - any database design requirements - any required error handling and recovery attributes - any required resource consumption characteristics |
17-12 | System requirements specification | System requirements include: functions and capabilities of the system; business, organizational and user requirements; safety, security, human-factors engineering (ergonomics), interface, operations, and maintenance requirements; design constraints and qualification requirements. Identifies the required system overview Identifies any interrelationship considerations/constraints between system elements Identifies any relationship considerations/constraints between the system elements and the software Identifies any design considerations/constraints for each required system element, including: - memory/capacity requirements - hardware interface requirements - user interface requirements - external system interface requirements - performance requirements - command structures - security/data protection characteristics - application parameter settings - manual operations - reusable components Describes the operation capabilities Describes environmental capabilities Documentation requirements Reliability requirements Logistical Requirements Describes security requirements Diagnosis requirements |
17-54 | Requirement Attribute | Meta-attributes that support structuring and definition of release scopes of requirements. Can be realized by means of tools. Note: usage of requirements attributes may further support analysis of requirements. |
ID | Name | Characteristics |
17-55 | Resource needs | Identification of required resources for process performance Staff including competencies, skills and authorities needs Material, equipment, and infrastructure Time and budget Note: Needs are derived from Work Breakdown structure and schedule |
17-57 | Special Characteristics | Special Characteristics in terms of relevant standards such as IATF 16949, VDA 6.x Guidelines, ISO 26262. Special Characteristics according to IATF 16949:2016-10 [15], Chapters 8.3.3.3, are product characteristics or production process parameters that may have an impact on safety or compliance with official regulations, the fit, the function, the performance or further processing of the product. Special characteristics shall be verifiable according to VDA vol. 1 Note: A typical method for identifying and rate special characteristics is an FMEA. |
17-58 | Hardware requirement | Specifies - an expectation of hardware functions and capabilities (e.g. nonfunctional requirements), or one of its interfaces - from a black-box perspective - that is verifiable, does not imply a design or implementation decision, is unambiguous, and does not introduce contradictions to other requirements. A requirement that implies, or represents, a design or implementation decision is called “Design Constraint”. Hardware requirements specify particular desired characteristics of the hardware and can include - lifetime and mission profile, lifetime robustness - maximum price - storage and transportation requirements - functional behaviour of analog or digital circuits and logic - quiescent current, voltage impulse responsiveness to crank, start- stop, drop-out, load dump - temperature, maximum hardware heat dissipation - power consumption depending on the operating state such as sleep-mode, start-up, reset conditions - frequencies, modulation, signal delays, filters, control loops - power-up and power-down sequences, accuracy and precision of signal acquisition or signal processing time - computing resources such as memory space and CPU clock tolerances - maximum abrasive wear and shearing forces for e.g. pins or soldering joints - requirements resulting from lessons learned - safety related requirements derived from the technical safety concept |
ID | Name | Characteristics |
18-00 * | Standard | Identification of to whom/what they apply Expectations for conformance are identified Conformance to requirements can be demonstrated Provisions for tailoring or exception to the requirements are included |
18-06 | Product release criteria | Defines expectations for product release: - release type and status - required elements of the release - product completeness including documentation - adequacy and coverage of testing - limit for open defects - change control status |
18-07 | Quality criteria | Defines the expectations for documented information and process performance Including thresholds/tolerance levels, required measurements, required checkpoints Defines what is an adequate documented information (required elements, completeness expected, accuracy, etc.) Defines what constitutes the completeness of the defined tasks Defines what constitutes the performance of the defined tasks Establishes expected performance attributes |
18-51 | Verification criteria | Each requirement is verifiable or can be assessed Verification criteria define the qualitative and quantitative criteria for verification of a requirement. Verification criteria demonstrate that a requirement can be verified within agreed constraints. (Additional Requirement to 17-00 Requirements specification) |
18-52 | Escalation path | Defined mechanisms to report and confirm escalation relevant issues Identifies stakeholders to be included in the escalation path Identifies levels of escalation |
18-53 | Configuration item selection criteria | Identify types of items to be subject to configuration control |
18-54 | Problem status model | Defines approach to track status of problems, including - states such as “open”, “in review”, “in implementation”, “closed”, “rejected”, “cancelled”, … - transitions between states with conditions and authorities |
18-55 | Problem classification | Defines criteria for alert notification to be initiated and urgent problem resolution activities to be authorized. - criteria may be based on priority, impact, urgency, etc. - identifies associated alert notifications, and urgent problem resolution authorization definitions |
18-56 | Change request status model | Defines approach to track status of change requests - states such as “open”, “in review”, “in implementation”, “closed”, “rejected”, “cancelled” … - transitions between states with conditions and authorities, e.g for approval |
ID | Name | Characteristics |
18-57 | Change analysis criteria | Defines analysis criteria, such as - resource requirements - scheduling issues - risks - benefits |
18-58 | Process performance quality criteria | Established performance attributes and evaluation criteria used to evaluate the achievement of strategic process performance goals Quality criteria include e.g., - activity/work package completeness criteria (e.g., definition of done), - lifecycle criteria (entry/exit), - frequency of tasks performance, - process achievement goals for project milestones Related measurements for process performance monitoring |
18-59 | Review and approval criteria for documented information | Specifies for each type of documented information review and ap- proval needs - If and when a review is required - Who shall review it - Who shall approve it - Criteria for approval |
18-60 | Quality criteria for documented information | Establishes what is an adequate work product: - required elements - completeness expected - accuracy - etc. |
19-00 | Strategy | Identifies what needs and objectives or goals there are to be satisfied Establishes the options and approach for satisfying the needs, objectives, or goals Establishes the evaluation criteria against which the strategic options are evaluated Identifies any constraints/risks and how these will be addressed |
19-01 | Process performance strategy | Process scope Needs, objectives, and goals to be satisfied Options, approach, and methods to perform the process activities Assumptions and constraints (given implicitly by e.g., budget, resources) References to relevant regulatory requirements, standards and customer requirements Risks of the chosen strategy/approach and appropriate mitigation measures Deliverables (relevant input to / outputs of affected parties, supplier and customer) |
ID | Name | Characteristics |
19-05 | Reuse strategy | Identify the goals for reuse Identify the commitment for creating reusable components Determine which product lines and type of artifacts should be supported with reuse Identify system and hardware/software/product elements which can be reused within the organization Identify the reuse repository and tools |
19-50 | ML data quality approach | The ML data quality approach Defines Quality criteria (see 18-07) e.g., the relevant data sources, reliability and consistency of labelling, completeness against ML data requirements Describes analysis activities of the data Describes activities to ensure the quality of the data to avoid issues e.g., data bias, bad labeling |
20-00 | Template | Defines the attributes associated with a work product to be created as a consequence of a process execution Identifies technical elements typically associated with this product type Defines expected form and style |
21-00 | Work product | Defines the attributes associated with an artifact from a process execution: - key elements to be represented in the work product |