PA2.2 Work Product Management

Linked Knowledge Nuggets:
arrow_forward "Sustainable Implementation of Best Practices to achieve ASPICE Level 2"

person Author: Alexander Feulner
Achieving Automotive SPICE Level 2 is not an overnight task, and ensuring its sustainability presents an additional challenge. Key obstacles and best practices must be addressed to establish Level 2 in a structured and lasting manner. This includes identifying common weaknesses in Level 1 and 2 assessments, shedding light on typical pitfalls organizations encounter. Implementing best practices helps bridge these gaps by standardizing workflows and enhancing process adherence. A well-defined roadmap for the early adoption of Level 2 aspects facilitates a smoother transition and long-term stability. However, organizations often struggle with process improvements due to resistance to change and integration complexities. Successfully overcoming these challenges requires a strategic approach, continuous monitoring, and a strong commitment to process maturity. Here you find a presentation of "strategic" level 2 wokrshops to enhances sustainable implementation.

• school Sustainable Implementation of Best Practices to achieve ASPICE Level 2.pdf
  

arrow_forward "Why do I need Configuration Management at Capability Level 2?"

person Author: Process Fellows
Without proper CM, teams risk working on outdated or inconsistent data. Even simple setups (e.g. Git with branching rules) can meet ASPICE, if consistently used and documented. CM ensures reliability and trust in project data.

• A1 Requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) for the work products of the process are defined.
• A2 Requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) for storage and control of the work products are defined.
• A3 The work products are appropriately identified, stored, and controlled.
• A4 The work products are reviewed and adjusted as necessary to meet requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.).

GP2.2.1 Define the requirements for the work products. ( A1 )

The requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) for the content and structure of the work products to be produced are defined.
Quality criteria for the work products are identified.
Appropriate review and approval criteria for the work products are defined.
Note 1: Possible sources of documentation requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) may be e.g., best practices or lessons learned from other projects, standards, organization requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.), customer requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.), etc. Note 2: There may be types of work products for which no review or approval is required, thus then there would be no need to define the corresponding criteria.

Linked Knowledge Nuggets:
arrow_forward "Examples of work product quality criteria and where they can be found"

person Author: Process Fellows
Examples of work product quality criteria:

• Quality attributes like consistency to input, completeness, correctness, traceability, verifiability, etc.. These attributes are often included as part of review checklists to guide structured evaluations of work products.
• The "Definition of Done" (DoD) supports as well the idea of work product quality criteria. DoD is a shared understanding within a team of what it means for a (work) product to be considered complete (remark: DoD is not only used for work products, but as well for tasks or user stories). It is a list of criteria that must be met before work can be marked as “done.”
• Work product quality attributes are not limited to checklists. They can also be found within guidelines, standards, or best practices documents, providing broader context and ensuring consistent application across teams and processes.

arrow_forward "How long should a review take?"

person Author: Process Fellows
Keep your reviews focused. Aim for a maximum duration of 60 to 90 minutes, especially for detailed specifications. It is better to review fewer points thoroughly than to review everything superficially. In other words, a best practice is to review extensive documents iteratively in smaller steps. Track the efficiency of the reviews as a process metric.

arrow_forward "Rethinking review culture – beyond the checkbox"

person Author: Process Fellows
Reviews are not a formality — they’re quality gates. Encourage teams to approach them as knowledge-sharing and risk-reduction rituals. Use structured checklists, timebox the sessions, and vary the review focus (structure, content, traceability). Create value, not just evidence.

arrow_forward "Work Product vs. Document – Why it’s not the same?"

person Author: Process Fellows
In ASPICE, a work product is any tangible result – not necessarily a document. A user story in Jira? A valid work product. The format is secondary – the purpose, content and traceability matter.

GP2.2.2 Define the requirements for storage and control of the work products. ( A2 )

Requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) for the storage and control of the work products are defined, including their identification and distribution.
Note 3: Possible sources for the identification of requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) for storage and control may be e.g., legal requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.), data policies, best practices from other projects, tool related requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.), etc.
Note 4: Examples for work product storage are files in a file system (System = A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.), ticket in a tool, Wiki entry, paper documents etc.
Note 5: Where status of a work product is required in base practices, this should be managed via a defined status model.

Linked Knowledge Nuggets:
arrow_forward "Examples of criteria for configuration items"

person Author: Process Fellows
The following criteria may serve as exemplary criteria to select relevant work products to be subject to configuration management:

• Uniqueness and Identifiability: The item must be uniquely identifiable (e.g., through a name, ID, or version number).
• Change Impact: Changes to the item can affect system properties, functionality, compliance, or other CIs.
• Need for Control: The item requires formal control to ensure consistency, traceability, and integrity.
• Reusability: The item is reused across multiple systems, projects, or releases.
• Compliance or Regulatory Requirement: The item is subject to audits, standards, or legal requirements (e.g., medical device documentation, safety-critical software).
• Customer or Stakeholder Deliverable: The item is part of what is delivered to the customer or required by stakeholders.
• Baseline Inclusion: The item is intended to be part of a configuration baseline, meaning it must be formally approved and controlled.
• Versioning Requirement: The item evolves over time and needs version tracking to manage changes.
• Dependency Relationships: The item has dependencies or is depended upon by other items, making its configuration critical.

arrow_forward "Grouping of configuration items"

person Author: Process Fellows
Configuration items can be composed of multiple related work products instead of just a single work product. This allows organizations to group related work products under a single CI for traceability and control, while avoiding unnecessary overhead by not treating every work product as a CI. An example of this could be a requirements specification consisting of many individual requirements.

arrow_forward "Levels of configuration management"

person Author: Process Fellows
Not every file is automatically considered a Configuration Item (CI). To determine which item should be managed as a CI, clear criteria should be defined. These criteria help identify what qualifies for configuration management. As a result, different levels or degrees of configuration management may be established, depending on the importance, complexity, or impact of the items being managed.
Examples:

1. Level 1: Archiving Only: No version control, no formal change process.
   Purpose: The item is stored for reference or traceability.
   Examples: Meeting minutes, internal memos.
2. Level 2: Version Control: Each change creates a new version; changes are tracked and documented.
   Purpose: The item is actively maintained and updated over time.
   Examples: Specifications, plans, user manuals, source code.
3. Level 3: Baseline Inclusion: Changes require formal approval; baselines are used for configuration audits and traceability.
   Purpose: The item is part of a formally approved configuration baseline.
   Examples: Requirements baselines, software releases.

GP2.2.3 Identify, store and control the work products. ( A3 )

The work products to be controlled are identified.
Change control is established for work products.
Versioning and baselining of the work products is performed in accordance with the requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) for storage and control of the work products.
The work products including the revision status are made available through appropriate mechanisms.

Linked Knowledge Nuggets:
arrow_forward "Configuration Management system"

person Author: Process Fellows
There is no universal tool for managing all Configuration Items. Configuration Items may be stored across multiple repositories, depending on their type, lifecycle phase, or organizational structure. This should be viewed as a "repository landscape", where each repository serves a specific purpose.
To ensure clarity and traceability:

• Clearly define where each Configuration Item is stored.
• Document the relationships and dependencies between the tools and repositories involved.
• Also define the interdependencies between Configuration Items that span across different systems or repositories.

GP2.2.4 Review and adjust work products. ( A4 )

The work products are reviewed against the defined requirements (Requirement = A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.) and criteria.
Resolution of issues arising from work products reviews is ensured.

Linked Knowledge Nuggets:
arrow_forward "How long should a review take?"

person Author: Process Fellows
Keep your reviews focused. Aim for a maximum duration of 60 to 90 minutes, especially for detailed specifications. It is better to review fewer points thoroughly than to review everything superficially. In other words, a best practice is to review extensive documents iteratively in smaller steps. Track the efficiency of the reviews as a process metric.

arrow_forward "Rethinking review culture – beyond the checkbox"

person Author: Process Fellows
Reviews are not a formality — they’re quality gates. Encourage teams to approach them as knowledge-sharing and risk-reduction rituals. Use structured checklists, timebox the sessions, and vary the review focus (structure, content, traceability). Create value, not just evidence.

arrow_forward "Why are reviews not a waste of time?"

person Author: Process Fellows
Reviews prevent defects, align understanding, and improve quality. They don’t need to be long – just focused and regular. Invest the time here and save more time in testing ,managing defects, implementing bugfixes and re-testing.