Annex B

Work product characteristics

Work product 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. Work products are defined using the schema in table B.1. Work products 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.

 

Table B.1 - Structure of WPC tables

 

 

Work product identifier

An identifier number for the work product which is used to reference the work product.
Work product name Provides an example of a typical name associated with the work product characteristics. This name is provided as an identifier of the type of work product the practice or process might produce. Organizations may call these work products by different names. The name of the work product in the organization is not significant. Similarly, organizations may have several equivalent work products which contain the characteristics defined in one work product type. The formats for the work products can vary. It is up to the assessor and the organizational unit coordinator to map the actual work products produced in their organization to the examples given here.

Work product characteristics

Provides examples of the potential characteristics associated with the work product types. The assessor may look for these in the samples provided by the organizational unit.

 

Work Products (with the ID nn-00) are sets of characteristics that would be expected to be evident in work products of generic types as a result of achievement of an attribute. The generic work products form the basis for the classification of specific work products defined as process performance indicators.
Specific work product 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 work products denoted with * are not used in the Automotive SPICE Process Assessment Model but are included for completeness.

 

Table B.2 - Work product characteristics

 

 

WP ID

WP Name

WP 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
item
  • Integrated software consisting of:
    • source code
    • software elements
    • executable code
    • configuration files
  • Documentation, which:
    • describes and identifies source code
    • describes and identifies software elements
    • describes and identifies configuration files
    • describes and identifies executable code
    • describes software life-cycle status
    • describes archive and release criteria
    • describes compilation of software units
    • describes building of software item
 

01-50

Integrated

Software

  • An aggregate of software items
  • A set of executables for a specific ECU configuration and possibly associated documentation and data
  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
  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
  • Result of applying a measure
 

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
03-06

Process

performance

data

  • 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
*

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
 

04-02

Domain

architecture

  • Identified domain model(s) tailored from
  • Identified asset specifications
  • Definition of boundaries and relationships with other domains (Domain Interface Specification)
  • Identification of domain vocabulary
  • Identification of the domain representation standard
  • Provide an overview of the functions, features capabilities 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

architectural

design

  • Describes the overall software structure
  • Describes the operative system including task structure
  • Identifies inter-task/inter-process communication
  • Identifies the required software elements
  • Identifies own developed and supplied code
  • Identifies the relationship and dependency between software elements
  • Identifies where the data (such as application parameters or variables) are stored and which measures (e.g. checksums, redundancy) are taken to prevent data corruption
  • Describes how variants for different model series or configurations are derived
  • Describes the dynamic behavior of the software (Start-up, shutdown, software update, error handling and recovery, etc.)
  • Describes which data is persistent and under which conditions
  • Consideration is given to:
    • any required software performance characteristics
    • any required software interfaces
    • any required security characteristics required
    • any database design requirements
 

04-05

Software

detailed

design

  • Provides detailed design (could be represented as a prototype, flow chart, entity relationship diagram, pseudo code, etc.)
  • Provides format of input / output data
  • Provides specification of CPU, ROM, RAM, EEPROM and Flash needs
  • Describes the interrupts with their priorities
  • Describes the tasks with cycle time and priority
  • Establishes required data naming conventions
  • Defines the format of required data structures
  • Defines the data fields and purpose of each required data element
  • Provides the specifications of the program structure
  04-06

System

architectural

design

  • Provides an overview of all system design
  • Describes the interrelationship between system elements
  • Describes the relationship between the system elements and the software
  • Specifies the design for each required system element, consideration is given to things like:
    • memory / capacity requirements
    • hardware interfaces requirements
    • user interfaces requirements
    • external system interface requirements
    • performance requirements
    • commands structures
    • security / data protection characteristics
    • settings for system parameters (such as application parameters or global variables)
    • manual operations
    • reusable components
  • Mapping of requirements to system elements
  • Description of the operation modes of the system components (startup, shutdown, sleep mode, diagnosis mode, etc.)
  • Description of the dependencies among the system components regarding the operation modes
  • Description of the dynamic behaviour of the system and the system components
 

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

06-00

User

documentation

Takes account of:

  • Identifies:
    • external documents
    • internal documents
    • current site distribution and maintenance list maintained
  • Documentation kept synchronized with latest product release
  • Addresses technical issues
  06-01 Customer manual Takes account of:
  • audience and task profiles
  • the environment in which the information will be used
  • convenience to users
  • the range of technical facilities, including resources and the product, available for developing and delivering on-screen documentation
  • information characteristics
  • cost of delivery and maintainability
Includes information needed for operation of the system, including but not limited to:
  • product and version information
  • instructions for handling the system
  • initial familiarisation information
  • long examples
  • structured reference material, particularly for advanced features of the software
  • checklists
  • guides to use input devices
 

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
  • Courses listings and availability

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 work flow
  • 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
 

07-02

Field

measure

  • 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)
    • customers requests for help
    • performance trends
    • problem reports
    • enhancements requested
 

07-03

Personnel

performance

measure

  • Real time measures of personnel performance or expected service level
  • Identifies aspects such as:
    • capacity
    • throughput
    • operational performance
    • operational service
    • availability
  07-04

Process

measure

  • Measures 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

measure

  • 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

measure

Measures quality attributes of the work products defined:

  • functionality
  • reliability
  • usability
  • efficiency
  • maintainability
  • portability
  • Measures quality attributes of the "end customer" product quality and reliability
  • NOTE: Refer ISO/IEC 9126 for detailed information on measurement of product quality.

 

07-07

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
  07-08

Service

level

measure

  • Real time measures taking while a system is operational, it measures the system's performance or expected service level
  • Identifies things like:
    • capacity
    • throughput
    • operational performance
    • operational service
    • service outage time
    • up time
    • job run time

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
 

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

  • 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 timeframe 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
  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
 

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-26

Documentation

plan

  • Identifies documents to be produced
  • Defines the documentation activities during the life cycle of the software product or service
  • Identifies any applicable standards and templates
  • Defines requirements for documents
  • Review and authorization practices
  • Distribution of the documents
  • Maintenance and disposal of the documents
 

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
 

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-51

Technology

monitoring

plan

No requirements additional to Plan (Generic)

 

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
*

09-00

Policy
  • Authorized
  • Available to all personnel impacted by the policy
  • Establishes practices / rules to be adhered to
 

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

  • A detailed description of the process / procedure which includes:
    • tailoring of the standard process (if applicable)
    • purpose of the process
    • outcomes of the process
    • task and activities to be performed and ordering of tasks
    • critical dependencies between task activities
    • expected time required to execute task
    • input / output work products
    • links between input and outputs work products
  • Identifies process entry and exit criteria
  • Identifies internal and external interfaces to the process
  • Identifies process measures
  • Identifies quality expectations
  • Identifies functional roles and responsibilities
  • Approved by authorized personnel
 

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)
 

11-03

Product
release
information
  • 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

  • Follows established coding standards (as appropriate to the language and application):
    • commented
    • structured or optimized
    • meaningful naming conventions
    • parameter information identified
    • error codes defined
    • error messages descriptive and meaningful
    • formatting - indented, levels
  • Follows data definition standards (as appropriate to the language and application):
    • variables defined
    • data types defined
    • classes and inheritance structures defined
    • objects defined
  • Entity relationships defined
  • Database layouts are defined
  • File structures and blocking are defined
  • Data structures are defined
  • Algorithms are defined
  • Functional interfaces defined
  11-06

System

  • All elements of the product release are included
  • Any required hardware
  • Integrated product
  • Customer documentation
  • Fully configured set of the system elements:
    • application parameters defined
    • commands defined
    • data loaded or converted
 

11-07

Temporary

solution

  • Problem identification
  • Release and system information
  • Temporary solution, target date for actual fix identified
  • Description of the solution:
    • limitations, restriction on usage
    • additional operational requirements
    • special procedures
    • applicable releases
  • Backup / recovery information
  • Verification procedures
  • Temporary installation instructions
12-00

Proposal

  • Defines the proposed solution
  • Defines the proposed schedule
  • Identifies the coverage identification of initial proposal:
    • identifies the requirements that would be satisfied
    • identifies the requirements that could not be satisfied, and provides a justification of variants
  • Defines the estimated price of proposed development, product, or service
 

12-01

Request

for

proposal

  • 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 resubmitted of the response
    • requirements with regard to the format of response
 

12-03

Reuse
proposal
  • Identifies the project name
  • Identifies the project contact
  • 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 approving the reuse proposal
 

12-04

Supplier
proposal
response
  • Defines the suppliers proposed solution
  • Defines the suppliers proposed delivery schedule
  • Identifies the coverage identification of initial proposal:
    • identifies the requirements that would be satisfied
    • identifies the requirements that could not be satisfied, and provides a justification of variants
  • Defines the estimated price of proposed development, product, or service
  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

record

  • All forms of interpersonal communication, including:
    • letters
    • faxes
    • e-mails
    • voice recordings
    • podcast
    • blog
    • videos
    • forum
    • live chat
    • wikis
    • photo protocol
    • meeting support record
 

13-05

Contract

review

record

  • Scope of contract and requirements
  • Possible contingencies or risks
  • Alignment of the contract 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
  • Customer ability to meet contractual obligations.
 

13-06

Delivery

record

  • Record of items shipped / delivered electronically to customer
  • Identification of:
    • who it was sent to
    • address where delivered
    • the date delivered
  • Record receipt of delivered product
  13-07 Problem
record
  • Identifies the name of submitted and associated contact details
  • Identifies the group / person(s) responsible for providing a fix
  • Includes a description of the problem
  • Identifies classification of the problem (criticality, urgency, relevance etc.)
  • Identifies the status of the reported problem
  • Identifies the target release(s) in which the problem will be fixed
  • Identifies the expected closure date
  • Identifies any closure criteria
  • Identifies re-review actions
  13-08 Baseline
  • Identifies the name of submitted and associated contact details
  • Identifies a state of one or a set of work products and artifacts which are consistent and complete
  • Basis for next process steps
  • 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 work products / items and modifications
  • Identifies items under configuration control
  • Identifies activities performed e.g. backup, storage, archiving, handling and delivery of configured items
  • Supports consistency of the product
 

13-13

Product

release

approval

record

  • 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
  • Record of supplier approval
  13-14 Progress
status
record
  • Record of the status of a plan(s) (actual against planned) such as:
    • status of actual tasks against planned tasks
    • status of actual results against established objectives / goals
    • status of actual resource 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 request status (e.g., open, allocated, implemented, closed)
  • 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
  13-17

Customer

request

  • Identifies request purpose, such as:
    • new development
    • enhancement
    • internal customer
    • operations
    • documentation
    • informational
  • Identifies request status information, such as:
    • date opened
    • current status
    • date assigned and responsible owner
    • date verified
    • date closed
  • Identifies priority / severity of the request
  • Identifies customer information, such as:
    • company / person initiating the request
    • contact information and details
    • system site configuration information
    • impacted system(s)
    • impact to operations of existing systems
    • criticality of the request
    • expected customer response / closure requirements
  • Identifies needed requirements / standards
  • Identifies information sent with request (i.e., RFPs, dumps, etc.)
  13-18

Quality

record

  • Identifies what information to keep
  • 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
 

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
 

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:
    • 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
 

13-22

Traceability

record

  • All requirements (customer and internal) are to be traced
  • Identifies a mapping of requirements to life cycle work products
  • Provides the linkage of requirements to work product decomposition
  • 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 check-list
  • Passed items of validation
  • Failed items of validation
  • Pending items of validation
  • Problems identified during validation
  • Risk analysis
  • Recommendation of actions
  • Conclusions of validation
  • Signature of validation
 

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)
*

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 analyses
    • 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 module, etc.):
    • description of change
    • version information about changed object
    • date of change
    • change requester information
    • change control record information

14-02

Corrective

action

register

  • 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-05

Preferred

suppliers

register

  • Subcontractor or supplier history
  • List of potential subcontractor / suppliers
  • Qualification information
  • Identification of their qualifications
  • Past history information when it exists
 

14-06

Schedule

  • Identifies the tasks to be performed
  • dentifies the expected and actual start and completion date for required tasks against progress/completion of tasks
  • Allows for the identification of critical tasks and task dependencies
  • Identifies task completion status, vs. planned date
  • Has a mapping to scheduled resource data

    NOTE: A schedule is consistent with the work breakdown structure, see 14-09

 

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
 

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

    NOTE: A work breakdown structure may be integrated into/part of the schedule, see 14-06

 

14-11

Work

product

list

  • Identifies:
    • name of work product
    • work product reference ID
    • work product revision
    • when updated
    • work product status
    • when approved
    • reference to approval source
    • file reference
 

14-50

Stakeholder

groups

list

  • Identifies:
    • relevant stakeholder groups
    • weight/importance of each stakeholder group
    • representative(s) for each stakeholder group
    • information needs of each stakeholder group
* 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
 

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

evaluation

report

  • Identification of reuse opportunities
  • Identification of investment in Reuse
  • Identification of current skills and experience
  • Identification of reuse infrastructure
  • The evaluation report must represent current status in implementation of the reuse program
 

15-08

Risk

analysis

report

  • Identifies the risks analyzed
  • Records the results of the analysis:
    • potential ways to mitigate the risk
    • assumptions made
    • constraints
  15-09

Risk

status

report

  • 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
  • Status of problem solving
    • development of solved vs. open problems
 

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
    • assessees' 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
  15-18

Process

performance

report

No requirements additional to Evaluation report (Generic)

  15-21

Supplier

evaluation

report

No requirements additional to Evaluation report (Generic)

*

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 strategy
  • 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
 

17-00

Requirement
specification
  • Each requirement is identified
  • Each requirement is unique
  • Each requirement is verifiable or can be assessed (see 17-50)
  • Includes statutory and regulatory requirements
  • Includes issues / requirements from (contract) reviews
 

17-02

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
 

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

Documentation

requirements

  • Purpose / objectives defined
  • Proposed contents (coverage) defined
  • Intended audience defined
  • Identification of supported hardware / software / product release, system information
  • Identification of associated hardware / software / product requirements and designs satisfied by document
  • Identification of style, format, media standards expected definition of the intended distribution requirement
  • Includes storage requirements
 

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, etc.)
    • 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
 

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. (ISO/IEC 12207)
  • 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 interfaces requirements
    • user interfaces requirements
    • external system interface requirements
    • performance requirements
    • commands 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-50

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-00

Standard

  • Identification of 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-01

Acceptance

criteria

  • Defines expectations for acceptance like e.g.:
    • interfaces
    • schedules
    • messages
    • documents
    • meetings
    • joint reviews
  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 expectations for quality:
    • establishes what is an adequate work product (required elements, completeness expected, accuracy, etc.)
    • identifies what constitutes the completeness of the defined tasks
    • establishes life cycle transition criteria and the entry and exit requirements for each process and/or activity defined
    • establishes expected performance attributes
    • establishes product reliability attributes
 

18-50

Supplier

qualification

criteria

  • Expectations for conformance, to be fulfilled by competent suppliers, are identified
  • Links from the expectations to national/international/domains-specific standards/laws/regulations are described
  • Conformance to requirements can be demonstrated by the potential suppliers or assessed by the acquiring organisation
  • Provisions for tailoring or exception to the requirements are included
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-05

Reuse
strategy
  • Identify the goals for reuse
  • Identify the commitment for creating reusable components
  • Determine which product lines and type of artefacts 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-10

Verification

strategy

  • Verification methods, techniques, and tools
  • Work product or processes under verification
  • Degrees of independence for verification
  • Schedule for performing the above activities
  • Identifies what needs there are to be satisfied
  • Establishes the options and approach for satisfying the need
  • Establishes the evaluation criteria against which the strategic options are evaluated
  • Identifies any constraints / risks and how these will be addressed
  • Verification ending criteria
  • Verification start, abort and re-start criteria
 

19-11

Validation

strategy

  • Validation methods, techniques, and tools
  • Work products under validation
  • Degrees of independence for validation
  • Schedule for performing the above activities
  • Identifies what needs there are to be satisfied
  • Establishes the options and approach for satisfying the need
  • Establishes the evaluation criteria against which the strategic options are evaluated
  • Identifies any constraints / risks and how these will be addressed
 

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 artefact from a process execution:
    • key elements to be represented in the work product

(*) The generic work products denoted with * are not used in the Automotive SPICE Process Assessment Model but are included for completeness.