Spicepocketguide Druckversion 20190112

Automotive SPICE®
Process Assessment Model
V 3.1
Automotive SPICE®
Automotive SPICE® is a registered trademark of the Verband der Automobilindustrie e.V. (VDA).
For further information about Automotive SPICE®

Cover Photo: Designed by welcomia / Freepik
visit: www.automotivespice.com.
Derivative works
You may not alter, transform, or build upon this work without the prior consent of both
the SPICE User Group and the VDA Quality Management Center. Such consent may be given
provided ISO copyright is not infringed.
The detailed descriptions contained in this document may be incorporated as

part of any tool or other material to support the performance of process assess-
ments, so that this process assessment model can be used for its intended purpose,
provided that any such material is not offered for sale.
All distribution of derivative works shall be made at no cost to the recipient.

N HOW TO USE THE POCKET GUIDE
The purpose of this pocket guide is to provide a selection of widely used processes and the most
important model components of Automotive SPICE® Process Assessment Model v3.1 in a handy
and handsome size to you.
This pocket guide contains all processes from the so called VDA scope, plus few additional
processes. This means, all processes as known as being required by OEMs today, are included.
In addition we added a selection of work product characteristics.
The full content of Automotive SPICE® Process Assessment Model v3.1, can be found here:
http://www.automotivespice.com.
To allow a smart access to important information, we developed a system of colored flags. Best
is, to start with the table of content where you find the colored flags the very first time. You
can use the page numbers, or instead just use the pocket guide as a flip-book, to find the right
page within a second. All process names are written down at the right side of each page using
the same color as the flags. This supports you as well to find the information you are looking
for very fast.
We appreciate your improvement suggestions. Please send them to info@processfellows.de.
Be sure, we will consider them as soon as we print the next edition.
N TABLE OF CONTENT
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Capability Levels and Process Attributes . . . . . . . . . 8
Rating Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Capability Level Rating . . . . . . . . . . . . . . . . . . . . . . . 10
Example of an Assessment Result . . . . . . . . . . . . . . . 11

5
Project Management 14 MAN.3
Risk Management 17 MAN.5
Quality Assurance 20 SUP.1
Verification 23 SUP.2
Joint Review 25 SUP.4
Documentation 28 SUP.7
Configuration Management 31 SUP.8
Problem Resolution Management 34 SUP.9
Change Request Management 37 SUP.10
Requirements Elicitation 40 SYS.1
System Requirements Analysis 43 SYS.2
System Architectural Design 46 SYS.3
System Integration and Integration Test 49 SYS.4
System Qualification Test 53 SYS.5
Software Requirements Analysis 56 SWE.1
Software Architectural Design 59 SWE.2
SW Detailed Design & Unit Construction 62 SWE.3
Software Unit Verification 65 SWE.4
Software Integration and Integration Test 68 SWE.5
Software Qualification Test 72 SWE.6
Supplier Monitoring 75 ACQ.4
Reuse Program Management 77 REU.2
Product Release 79 SPL.2
Process Capability Indicators (CL 1&2) 83 CL 1&2
Process Capability Indicators (CL 3) 86 CL 3
Work Product Characteristics 95 WPC

NNOverview
Overviewof
ofAutomotive SPICE®®V3.1
Automotive SPICE V3.1
Acquisition Process
Acquisition Process System
System Engineering ProcessGroup
Engineering Process Group(SYS)
(SYS) Management
Management Process
Process
Group
Group(ACQ)
(ACQ) Group
Group (MAN)
(MAN)
ACQ.3
ACQ.3 SYS.1
SYS.1 MAN.3 #
MAN.3 #
Contract Agreement
Contract Agreement Requirements
RequirementsElicitation
Elicitation Project
Project Management
Management
ACQ.4
ACQ.4 # # SYS.2
SYS.2 # SYS.5
SYS.5 ## MAN.5
MAN.5
System
SystemRequirements
Requirements
Supplier Monitoring
Supplier Monitoring Analysis
Analysis SystemQualification
System Qualification Test
Test RiskRisk Management
Management
ACQ.11
ACQ.11 SYS.3
SYS.3 ## SYS.4
SYS.4 ## MAN.6
MAN.6
System Architectural
System Architectural System
SystemIntegration
Integrationandand
Technical
Technical Requirements
Requirements Design Integration Measurement
Measurement
Design IntegrationTest
Test
ACQ.12
ACQ.12
Legal
Legal andand Administrative
Administrative
Requirements Software Engineering
Software EngineeringProcess
ProcessGroup
Group(SWE)
(SWE)
Requirements
SWE.1 # SWE.6
SWE.6 # #
Project
ACQ.13
ACQ.13
Requirements
SWE.1
SoftwareAnalysis
#
Software Requirements
Requirements Software Qualification
Software
# #
Project Requirements TestQualification # o#pe e
Analysis Test
ACQ.14
ACQ.14
SWE.2
SWE.2
Software Architectural#
# SWE.5
SoftwareSWE.5
Integration #
# # #A Sc Scop
Request for Proposals
Request for Proposals SoftwareDesign
Architectural
Design
Software
and Integration
Integration Test
and Integration Test # # VD VDA
ACQ.15 SWE.3 # SWE.4 #
ACQ.15 SoftwareSWE.3 #
Detailed Design SWE.4 #
Supplier Qualification Software
and UnitDetailed Design Software Unit Verification
Construction
Supplier Qualification and Unit Construction Software Unit Verification Reuse Process Group
Reuse Process Group
(REU)
(REU)
Supply Process Group Supporting Process Group (SUP) REU.2
Supply Process
(SPL) Group Supporting Process Group (SUP) REU.2
Reuse Program
(SPL) Management
Reuse Program
SPL.1 SUP.1 # SUP.2 SUP.4 SUP.7 Management
Process Improvement
SPL.1
Supplier Tendering SUP.1
Quality Assurance# SUP.2
Verification JointSUP.4
Review SUP.7
Documentation Process Group (PIM)
Process Improvement
Supplier Tendering Quality Assurance Verification Joint Review Documentation Process Group (PIM)
SPL.2 SUP.8 # SUP.9 # SUP.10 # PIM.3
Configuration
SUP.8 # Problem Resolution #
SUP.9 Change Request
SUP.10 #
Product
SPL.2Release Management Management Management Process Improvement
PIM.3
Configuration Problem Resolution Change Request
Product Release Management Management Management Process Improvement
Primary Life Cycle Processes Supporting Life Cycle Processes Organizational Life Cycle Processes
Primary Life Cycle Processes Supporting Life Cycle Processes Organizational Life Cycle Processes
N Bidirectional Traceability and Consistency
Stakeholder
Requirements
SYS.2 BP6
SYS.2 BP7
System System Qualification System Qualification
Requirements SYS.5 BP5 Test Specification Test Results
SYS.3 BP6 SYS.5 BP6 SYS.5 BP5
SYS.3 BP7
SWE.1 BP6 System System Integration System Integration
SWE.1 BP7 Architecture SYS.4 BP7 Test Specification Test Results
SWE.1 BP6 SYS.4 BP8 SYS.4 BP7
SWE.1 BP7
Software Software Qualification Software Qualification
Requirements SWE.6 BP5 Test Specification Test Results
SWE.2 BP7 SWE.6 BP6 SWE.6 BP5
SWE.2 BP8
Software Software Integration Software Integration
Architecture SWE.5 BP7 Test Specification Test Results
SWE.3 BP5 SWE.3 BP5 SWE.5 BP8 SWE.5 BP7
SWE.3 BP6 SWE.3 BP6
Software Unit Test Specification Unit Test Results
Detailed Design SWE.4 BP5
SWE.3 BP5 SWE.4 BP6 SWE.4 BP5
SWE.3 BP6
Static Verification
Software Units Results
SWE.4 BP5
Change Request
To affected work products N = bidirectional traceability
SUP.10 BP8 N = consistency
A
N
N Capability
Capability Levels
Levels and
and Process
Process Attributes
Attributes
PA.5.1
PA.5.1 Process
Process innovation
5
innovation The
PA.5.2 The previously
previously described
described predictable
predictable process
process is
is now
now con-
con-
PA.5.2 Process
Process innovation
innovation tinually Innovating
Innovating
implementation tinually improved
improved to
to respond
respond to
to organizational
organizational change.
change.
implementation
The
The previously
described established
established process
process now
now
operates
operates predictively
predictively within
within defined
defined limits
limits to
to achieve
achieve its
its
PA.4.1
PA.4.1
PA.4.2
PA.4.2
Quantitative
Quantitative analysis
Quantitative
analysis
Quantitative control
control
process
process outcomes.
outcomes. Quantitative
identified,
Quantitative management
measurement data
management needs
are collected and
needs are
are
analyzed
identified, measurement data are collected and analyzed
to
to identify
identify assignable
assignable causes
causes of
of variation.
variation. Corrective
Corrective
Predictable
Predictable 4
action
action is
is taken
taken to
to address
address assignable
assignable causes
causes of
of variation.
variation.
The
The previously
described managed
managed process
process is
is now
PA.3.1
PA.3.1
PA.3.2
PA.3.2
Process
Process definition
Process
definition
Process deployment
deployment
implemented
implemented using
achieving
achieving its
using aa defined
its process
defined process
process outcomes.
outcomes.
process that
that is
now
is capable
capable of
of Established
Established 3
PA.2.1 Performance
PA.2.1 Performance The previously
The previously described
described performed
performed process
process isis now
now
PA.2.2
management
management
PA.2.2 Work
Work product
product
management
implemented
implemented in
and
and adjusted)
in aa managed
adjusted) and
established,
managed fashion
and its
its work
fashion (planned,
work products
(planned, monitored
products are
monitored
are appropriately
appropriately
Managed
Managed 2
management established, controlled
controlled and
and maintained.
maintained.
PA.1.1
PA.1.1 Process
Process performance
performance
The
The implemented
implemented process
purpose
purpose
process achieves
achieves its
its process
process Performed
Performed 1
The
The process
process is
process
is not
not implemented,
process purpose.
purpose.
implemented, or
or fails
fails to
to achieve
achieve its
its Incomplete
Incomplete 0
N Rating scale
Not achieved There is little or no evidence of achievement of the 0% - 15%

N defined process attribute in the assessed process.
Partially There is some evidence of an approach to, and some >15% - 50%
P achieved achievement of, the defined process attribute in the
assessed process. Some aspects of achievement of the
process attribute may be unpredictable.
Largely There is evidence of a systematic approach to, and sig- >50% - 85%
L achieved nificant achievement of, the defined process attribute
in the assessed process. Some weaknesses related to
this process attribute may exist in the assessed process.
Fully achieved There is evidence of a complete and systematic >85% - 100%
F approach to, and full achievement of, the defined
process attribute in the assessed process. No significant
weaknesses related to this process attribute exist in
the assessed process.
N Capability Level Rating
A
PROCESS ATTRIBUTE
Capability
PA 1.1 PA 2.1 PA 2.2 PA 3.1 PA 3.2 PA 4.1 PA 4.2 PA 5.1 PA 5.2
Level Rating
F F F F F F F L F L F Innovating 5
F F F F F L F L F Predictable 4
F F F L F L F Established 3
F L F L F Managed 2
L F Performed 1
N P Incomplete 0
N Example of Assessment Result
Capability Level 1 2 3 4 5
Process Attribute PA PA PA PA PA PA PA PA PA
Process 1.1 2.1 2.2 3.1 3.2 4.1 4.2 5.1 5.2 CL
MAN.3 Project Management L F L L P 1
SUP.1 Quality Assurance L P L F P 1
SUP.8 Configuration Management L L L N N 1
SUP.9 Problem Resolution Management N N N L N 0
SUP.10 Change Request Management P P N L N 0
SYS.2 System Requirements Analysis F F F F F 3
SYS.3 System Architectural Design F F L F F 2
SWE.1 Software Requirements Analysis F L L F L 2
SWE.2 Software Architectural Design L L L L L 1
SWE.3 SW Detailed Design & Unit Construction L L P L L 1
SWE.4 Software Unit Verification P P P P P 0
SWE.5 Software Integration and Integration Test L P P L P 1
SWE.6 Software Qualification Test L P L L P 1
SYS.4 System Integration and Integration Test L L L F L 1
SYS.5 System Qualification Test F L F F L 2
„Develop a passion for learning.
If you do, you will
never cease to grow.”
Anthony J. D‘Angelo
N Automotive SPICE®
N Project Management
Photo credit: Matej Kastelic / shutterstock.com
N Functional Safety (ISO 26262)

N Organizational Change
N Application Lifecycle Management
Discover our training catalogue on www.processfellows.de!

YOUR PROCESS EXCELLENCE
IS OUR PASSION!
„They always say time changes things, but you actually have to change them yourself” (Andy Warhol)
What do you need to change?

N To work compliant to ISO 262626 (Functional Safety)?
N To achieve the next level in Automotive SPICE®?
N To improve your project effectiveness and efficiency?
rocess Fellows are accompanying your change for process excellence with inter
P
nationally recognized experts:
N Process Fellows are analyzing your current situation with methods like
gap analysis and assessments.
N Process Fellows are guiding you into the right direction via consulting.
N Process Fellows are leading the change with personal
coaching, trainings and regular reviews.
System and Software Engineering processes, methods and tools,

these are our daily business!
14
N MAN.3 PROJECT MANAGEMENT
# PROCESS PURPOSE
The purpose of the Project Management Process is to identify, establish, and control the activities and
resources necessary for a project to produce a product, in the context of the project’s requirements and
constraints.
# PROCESS OUTCOMES
As a result of successful implementation of this process:
O1 the scope of the work for the project is defined; O5 plans for the execution of the project are develo-
O2 the feasibility of achieving the goals of the pro- ped, implemented and maintained;
PROJECT MANAGEMENT
ject with available resources and constraints is O6 progress of the project is monitored and repor-
evaluated; ted; and
O3 the activities and resources necessary to complete O7 corrective action is taken when project goals are
the work are sized and estimated; not achieved, and recurrence of problems identi-
O4 interfaces within the project, and with other pro- fied in the project is prevented.
jects and organizational units, are identified and
monitored;
# OUTPUT WORK PRODUCTS

08-12 Project plan [O1,3,4,5] 14-06 Schedule [O3,5]
13-04 Communication record [O4,6] 14-09 Work breakdown structure [O3,4,5]
13-16 Change request [O7] 14-50 Stakeholder groups list [O4]
13-19 Review record [O2,7] 15-06 Project status report [O4,6]
14-02 Corrective action register [O7]
# BASE PRACTICES
PROJECT MANAGEMENT
BP 1: Define the scope of work. [O1]
Identify the project‘s goals, motivation and boundaries.
BP 2: Define project life cycle. [O2]
Define the life cycle for the project, which is appropriate to the scope, context, magnitude and complexity
of the project.
N1: This typically means that the project life cycle and the customer‘s development process are consistent
with each other.
BP 3: Evaluate feasibility of the project. [O2]
Evaluate the feasibility of achieving the goals of the project in terms of technical feasibility within constraints
with respect to time, project estimates, and available resources.
BP 4: Define, monitor and adjust project activities. [O3,5,7]
Define, monitor and adjust project activities and their dependencies according to defined project life cycle
and estimations. Adjust activities and their dependencies as required.
N2: A structure and a manageable size of the activities and related work packages support an adequate
progress monitoring.
N3: Project activities typically cover engineering, management and supporting processes.
BP 5: Define, monitor and adjust project estimates and resources. [O2,3,7]
Define, monitor and adjust project estimates of effort and resources based on project‘s goals, project risks,
motivation and boundaries.
N4: Appropriate estimation methods should be used.
N5: Examples of necessary resources are people, infrastructure (such as tools, test equipment, communica-
tion mechanisms...) and hardware/materials.
N6: Project risks (using MAN.5) and quality criteria (using SUP.1) may be considered.
N7: Estimations and resources typically include engineering, management and supporting processes.
MAN.3
15
16
BP 6: Ensure required skills, knowledge, and experience. [O3,7]
Identify the required skills, knowledge, and experience for the project in line with the estimates and make
sure the selected individuals and teams either have or acquire these in time.
N8: Typically, trainings are provided in the case of deviations from required skills and knowledge trainings.
BP 7: Identify, monitor and adjust project interfaces and agreed commitments. [O4,7]
Identify and agree interfaces of the project with other (sub-) projects, organizational units and other affec-
ted stakeholders and monitor agreed commitments.
N9: Project interfaces relate to engineering, management and supporting processes.
BP 8: Define, monitor and adjust project schedule. [O3,5,7]
Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept
continuously updated during lifetime of the project.
N10: This relates to all engineering, management and supporting processes.
PROJECT MANAGEMENT
BP 9: Ensure consistency. [O3,4,5,7]
Ensure that estimates, skills, activities, schedules, plans, interfaces, and commitments for the project are
consistent across affected parties.
BP 10: Review and report progress of the project. [O6,7]
Regularly review and report the status of the project and the fulfillment of activities against estimated effort
and duration to all affected parties. Prevent recurrence of problems identified.
N11: Project reviews may be executed at regular intervals by the management. At the end of a project, a
project review contributes to identifying e.g. best practices and lessons learned.

RISK MANAGEMENT
N MAN.5 RISK MANAGEMENT
# PROCESS PURPOSE
The purpose of the Risk Management Process is to identify, analyze, treat and monitor the risks continuously.
# PROCESS OUTCOMES
O1 the scope of the risk management to be perfor- O5 risk measures are defined, applied, and assessed
med is determined; to determine changes in the status of risk and
O2 appropriate risk management strategies are defi- the progress of the treatment activities; and
ned and implemented; O6 appropriate treatment is taken to correct or
O3 risks are identified as they develop during the avoid the impact of risk based on its priority,
conduct of the project; probability, and consequence or other defined
O4 risks are analyzed and the priority in which to risk threshold.
apply resources to treatment of these risks is
determined;

07-07 Risk measure [O5] 14-02 Corrective action register [O6]
08-14 Recovery plan [O4,6] 14-08 Tracking system [O5,6]
08-19 Risk management plan [O1,2,3,4,5,6] 15-08 Risk analysis report [O4]
08-20 Risk mitigation plan [O3,4,5,6] 15-09 Risk status report [O4,5]
13-20 Risk action request [O1,2,6]
MAN.5
17
18
# BASE PRACTICES
BP1: Establish risk management scope. [O1]
Determine the scope of risk management to be performed for the project, in accordance with organizational
risk management policies.
N1: Risks may include technical, economic and timing risks.
BP2: Define risk management strategies. [O2]
Define appropriate strategies to identify risks, mitigate risks and set acceptability levels for each risk or set of
risks, both at the project and organizational level.
BP3: Identify risks. [O2,3]
Identify risks to the project both initially within the project strategy and as they develop during the conduct
of the project, continuously looking for risk factors at any occurrence of technical or managerial decisions.
N2: Examples of risk areas that are typically analyzed for potential risk reasons or risks factors include: cost,
schedule, effort, resource, and technical.
N3: Examples of risk factors may include: unsolved and solved trade-offs, decisions of not implementing a
RISK MANAGEMENT
project feature, design changes, lack of expected resources.
BP4: Analyze risks. [O4]
Analyze risks to determine the priority in which to apply resources to mitigate these risks.
N4: Risks are normally analyzed to determine their probability, consequence and severity.
N5: Different techniques may be used to analyze a system in order to understand if risks exist, for example,
functional analysis, simulation, FMEA, FTA etc.
BP5: Define risk treatment actions. [O5,6]
For each risk (or set of risks) define, perform and track the selected actions to keep/reduce the risks to
acceptable level.
BP6: Monitor risks. [O5,6]
RISK MANAGEMENT
For each risk (or set of risks) define measures (e.g. metrics) to determine changes in the status of a risk and to
evaluate the progress of the of mitigation activities. Apply and assess these risk measures.
N6: Major risks may need to be communicated to and monitored by higher levels of management.
BP7: Take corrective action. [O6]
When expected progress in risk mitigation is not achieved, take appropriate corrective action to reduce or
avoid the impact of risk.
N7: Corrective actions may involve developing and implementing new mitigation strategies or adjusting the
existing strategies.
MAN.5
19
20
N SUP.1 QUALITY ASSURANCE
# PROCESS PURPOSE
The purpose of the Quality Assurance Process is to provide independent and objective assurance that work
products and processes comply with predefined provisions and plans and that non-conformances are resol-
ved and further prevented.
# PROCESS OUTCOMES
O1 a strategy for performing quality assurance is O4 conformance of work products, processes and
developed, implemented, and maintained; activities with relevant requirements is verified,
O2 quality assurance is performed independently documented, and communicated to the relevant
QUALITY ASSURANCE
and objectively without conflicts of interest; parties;
O3 non-conformances of work products, processes, O5 authority to escalate non-conformances to ap-
and process activities with relevant requirements propriate levels of management is established;
are identified, recorded, communicated to the and
relevant parties, tracked, resolved, and further O6 management ensures that escalated non-confor-
prevented; mances are resolved.

08-13 Quality plan [O1,2] 13-19 Review record [O2,3,4]
13-04 Communication record [O3,4,5] 14-02 Corrective action register [O3,5,6]
13-07 Problem record [O3,5] 18-07 Quality criteria [O1]
13-18 Quality record [O2,3,4]
QUALITY ASSURANCE
# BASE PRACTICES
BP1: Develop a project quality assurance strategy. [O1,2]
Develop a strategy in order to ensure that work product and process quality assurance is performed at pro-
ject level independently and objectively without conflicts of interest.
N1: Aspects of independence may be financial and/or organizational structure.
N2: Quality assurance may be coordinated with, and make use of, the results of other processes such as
verification, validation, joint review, audit and problem management.
N3: Process quality assurance may include process assessments and audits, problem analysis, regular check
of methods, tools, documents and the adherence to defined processes, reports and lessons learned that
improve processes for future projects.
N4: Work product quality assurance may include reviews, problem analysis, reports and lessons learned that
improve the work products for further use.
BP2: Assure quality of work products. [O2,3,4]
Perform the activities according to the quality assurance strategy and the project schedule to ensure that the
work products meet the defined work product requirements and document the results.
N5: Relevant work product requirements may include requirements from applicable standards.
N6: Non-conformances detected in work products may be entered into the problem resolution manage-
ment process (SUP.9) to document, analyze, resolve, track to closure and prevent the problems.
BP3: Assure quality of process activities. [O2,3,4]
Perform the activities according to the quality assurance strategy and the project schedule to ensure that the
processes meet their defined goals and document the results.
N7: Relevant process goals may include goals from applicable standards.
N8: Problems detected in the process definition or implementation may be entered into a process improve-
ment process (PIM.3) to describe, record, analyze, resolve, track to closure and prevent the problems.
SUP.1
21
22
BP4: Summarize and communicate quality assurance activities and results. [O3,4]
Regularly report performance, deviations, and trends of quality assurance activities to relevant parties for
information and action according to the quality assurance strategy.
BP5: Ensure resolution of non-conformances. [O3,6]
Deviations or non-conformance found in process and product quality assurance activities should be analyzed,
tracked, corrected, and further prevented.
BP6: Implement an escalation mechanism. [O5,6]
Establish and maintain an escalation mechanism according to the quality assurance strategy that ensures
that quality assurance may escalate problems to appropriate levels of management and other relevant stake-
holders to resolve them.
QUALITY ASSURANCE
VERIFICATION
N SUP.2 VERIFICATION
# PROCESS PURPOSE
The purpose of the Verification Process is to confirm that each work product of a process or project properly
reflects the specified requirements.
# PROCESS OUTCOMES
O1 a verification strategy is developed, implemen- O4 defects are identified, recorded and tracked; and
ted and maintained; O5 results of the verification activities are made
O2 criteria for verification of all required work pro- available to the customer and other involved
ducts are identified; parties.
O3 required verification activities are performed;

13-04 Communication record [O5] 14-02 Corrective action register [O4]
13-07 Problem record [O3,4,5] 18-07 Quality criteria [O2]
13-25 Verification results [O2,3,4,5] 19-10 Verification strategy [O1]
SUP.2
23
24
# BASE PRACTICES
BP1: Develop a verification strategy. [O1]
Develop and implement a verification strategy, including verification activities with associated methods,
techniques, and tools; work product or processes under verification; degrees of independence for verification
and schedule for performing these activities.
N1: Verification strategy is implemented through a plan.
N2: Software and system verification may provide objective evidence that the outputs of a particular phase
of the software development life cycle (e.g. requirements, design, implementation, testing) meet all of
the specified requirements for that phase.
N3: Verification methods and techniques may include inspections, peer reviews (see also SUP.4), audits,
walkthroughs and analysis.
BP2: Develop criteria for verification. [O2]
Develop the criteria for verification of all required technical work products.
BP3: Conduct verification. [O3]
Verify identified work products according to the specified strategy and to the developed criteria to confirm
that the work products meet their specified requirements. The results of verification activities are recorded.
BP4: Determine and track actions for verification results. [O4]
VERIFICATION
Problems identified by the verification should be entered into the problem resolution management process
(SUP.9) to describe, record, analyze, resolve, track to closure and prevent the problems.
BP5: Report verification results. [O5]
Verification results should be reported to all affected parties.
JOINT REVIEW
N SUP.4 JOINT REVIEW
# PROCESS PURPOSE
The purpose of the Joint Review Process is to maintain a common understanding with the stakeholders of
the progress against the objectives of the agreement and what should be done to help ensure development
of a product that satisfies the stakeholders. Joint reviews are at both project management and technical
levels and are held throughout the life of the project.
# PROCESS OUTCOMES
O1 management and technical reviews are held O3 review results are made known to all affected
based on the needs of the project; parties;
O2 the status and products of an activity of a process O4 action items resulting from reviews are tracked
are evaluated through joint review activities bet- to closure; and
ween the stakeholders; O5 problems are identified and recorded.
N1: Joint review should be performed at specific milestones during project/product development. The scope
and the goals of joint review may be different dependent on project/product development phase (for
example, in the early stage of a project joint review may be „conceptual“ in order to analyze the customer
requirements; in later stages joint review may be concerned with the implementation).
N2: Joint review should be performed to verify different aspects (for example: hardware resources utiliza-
tion; the introduction of new requirements and new technologies; modification to the working team
structure; technology changes).
SUP.4
25
26
13-04 Communication record [O3] 14-02 Corrective action register [O3,4,5]
13-05 Contract review record [O1,2,3] 14-08 Tracking system [O3,4,5]
13-07 Problem record [O3,5] 15-01 Analysis report [O3,5]
13-09 Meeting support record [O1,2] 15-13 Assessment / audit report [O1,2]
13-19 Review record [O1,2,3,4,5] 15-16 Improvement opportunity [O3,4]
# BASE PRACTICES
BP1: Define review elements. [O1]
Based on the needs of the project, identify the schedule, scope and participants of management and tech
nical reviews, agree all resources required to conduct the reviews (this includes personnel, location and faci-
lities) and establish review criteria for problem identification, resolution and agreement.
BP2: Establish a mechanism to handle review outcomes. [O3]
Establish mechanisms to ensure that review results are made available to all affected parties, that problems
detected during the reviews are identified and recorded and that action items raised are recorded for action.
BP3: Prepare joint review. [O1]
Collect, plan, prepare and distribute review material as appropriate in preparation for the review.
JOINT REVIEW
N1: The following items may be addressed: Scope and purpose of the review; Products and problems to be re-
viewed; Entry and exit criteria; Meeting agenda; Roles and participants; Distribution list; Responsibilities;
Resource and facility requirements; Used tools (checklists, scenario for perspective based reviews etc.).
BP4: Conduct joint reviews. [O1,2]
Conduct joint management and technical reviews as planned. Record the review results.
JOINT REVIEW
BP5: Distribute the results. [O3]
Document and distribute the review results to all the affected parties.
BP6: Determine actions for review results. [O4]
Analyze the review results, propose actions for resolution and determine the priority for actions.
BP7: Track actions for review results. [O4]
Track actions for resolution of identified problems in a review to closure.
BP8: Identify and record problems. [O5]
Identify and record the problems detected during the reviews according to the established mechanism.
SUP.4
27
28
N SUP.7 DOCUMENTATION
# PROCESS PURPOSE
The purpose of the Documentation Process is to develop and maintain the recorded information produced
by a process.
# PROCESS OUTCOMES
O1 a strategy identifying the documentation to be O4 the content and purpose of all documentation is
produced during the life cycle of the product or specified, reviewed and approved;
service is developed; O5 documentation is developed and made available
O2 the standards to be applied for the development in accordance with identified standards; and
of the documentation are identified; O6 documentation is maintained in accordance with
O3 documentation to be produced by the process or defined criteria.
DOCUMENTATION
project is identified;

08-26 Documentation plan [O1,2] 14-01 Change history [O5,6]
13-01 Acceptance record [O4,5] 14-11 Work product list [O3]
13-19 Review record [O4,5]
# BASE PRACTICES
DOCUMENTATION
BP1: Develop a documentation management strategy. [O1]
Develop a documentation management strategy which addresses where, when and what should be docu-
mented during the life cycle of the product/service.
N1: A documentation management strategy may define the controls needed to approve documentation for
adequacy prior to issue; to review and update as necessary and re-approve documentation; to ensure
that changes and the current revision status of documentation are identified; to ensure that relevant
versions of documentation are available at points of issue; to ensure that documentation remain legible
and readily identifiable; to ensure the controlled distribution of documentation; to prevent unintended
use of obsolete documentation; and may also specify the levels of confidentiality, copyright or disclai-
mers of liability for the documentation.
BP2: Establish standards for documentation. [O2]
Establish standards for developing, modifying and maintaining documentation.
BP3: Specify documentation requirements. [O2]
Specify requirements for documentation such as title, date, identifier, version history, author(s), reviewer,
authorizer, outline of contents, purpose, and distribution list.
BP4: Identify the relevant documentation to be produced. [O3]
For any given development life cycle, identify the documentation to be produced.
BP5: Develop documentation. [O4,5]
Develop documentation at required process points according to established standards and policy, ensuring
the content and purpose is reviewed and approved as appropriate.
BP6: Check documentation. [O5]
Review documentation before distribution, and authorize documentation as appropriate before distribution
or release.
SUP.7
29
30
N2: The documentation intended for use by system and software users should accurately describe the system
and software and how it is to be used in clear and useful manner for them.
N3: Documentation should be checked through verification or validation process.
BP7: Distribute documentation. [O5]
Distribute documentation according to determined modes of distribution via appropriate media to all affec-
ted parties, confirming delivery of documentation, where necessary.
BP8: Maintain documentation. [O6]
Maintain documentation in accordance with the determined documentation strategy.
N4: If the documentation is part of a product baseline or if its control and stability are important, it should
be modified and distributed in accordance with process SUP.8 Configuration Management.
DOCUMENTATION
CONFIGURATION MANAGEMENT
N SUP.8 CONFIGURATION MANAGEMENT
# PROCESS PURPOSE
The purpose of the Configuration Management Process is to establish and maintain the integrity of all work
products of a process or project and make them available to affected parties.
# PROCESS OUTCOMES
O1 a configuration management strategy is develo- O4 modifications and releases are made available to
ped; affected parties;
O2 all configuration items generated by a process O5 the status of the configuration items and modifi-
or project are identified, defined and baselined cations is recorded and reported;
according to the configuration management O6 the completeness and consistency of the base
strategy; lines is ensured; and
O3 modifications and releases of the configuration O7 storage of the configuration items is controlled.
items are controlled;

06-02 Handling and storage guide [O3,4,5,7] 13-10 Configuration management record [O2,5,7]
08-04 Configuration management plan [O1,2,7] 14-01 Change history [O3]
08-14 Recovery plan [O1,7] 16-03 Configuration management system [O1,3,4]
13-08 Baseline [O2,3,4,5,6]
SUP.8
31
32
# BASE PRACTICES
BP1: Develop a configuration management strategy. [O1]
Develop a configuration management strategy, including
• responsibilities;
• tools and repositories;
• criteria for configuration items;
• naming conventions;
• access rights;
• criteria for baselines;
• merge and branch strategy;
• the revision history approach for configuration items
N1: The configuration management strategy typically supports the handling of product/software variants
which may be caused by different sets of application parameters or by other causes.
N2: The branch management strategy specifies in which cases branching is permissible, whether authoriza-
tion is required, how branches are merged, and which activities are required to verify that all changes
have been consistently integrated without damage to other changes or to the original software.
BP2: Identify configuration items. [O2]
Identify and document configuration items according to the configuration management strategy.
N3: Configuration control is typically applied for the products that are delivered to the customer, designated
internal work products, acquired products, tools and other configuration items that are used in creating
and describing these work products.
BP3: Establish a configuration management system. [O1,2,3,4,6,7]
Establish a configuration management system according to the configuration management strategy.
BP4: Establish branch management. [O1,3,4,6,7]
Establish branch management according to the configuration management strategy where applicable for
parallel developments that use the same base.
BP5: Control modifications and releases. [O3,4,5]
Establish mechanisms for control of the configuration items according to the configuration management
strategy, and control modifications and releases using these mechanisms.
BP6: Establish baselines. [O2]
Establish baselines for internal purposes and for external delivery according to the configuration manage-
ment strategy.
N4: For baseline issues refer also to the product release process SPL.2.
BP7: Report configuration status. [O5]
Record and report status of configuration items to support project management and other relevant processes.
N5: Regular reporting of the configuration status (e.g. how many configuration items are currently under
work, checked in, tested, released, etc.) supports project management activities and dedicated project
phases like software integration.
BP8: Verify the information about configured items. [O6]
Verify that the information about configured items, and their baselines is complete and ensure the consis-
tency of baselines.
N6: A typical implementation is performing baseline and configuration management audits.
BP9: Manage the storage of configuration items and baselines. [O4,5,6,7]
Ensure the integrity and availability of configuration items and baselines through appropriate scheduling
and resourcing of storage, archiving (long term storage) and backup of the used CM systems.
N7: Backup, storage and archiving may need to extend beyond the guaranteed lifetime of available storage
media. Relevant configuration items affected may include those referenced in note 2 and note 3. Avai-
lability may be specified by contract requirements.
SUP.8
33
34
N SUP.9 PROBLEM RESOLUTION MANAGEMENT
# PROCESS PURPOSE
PROBLEM RESOLUTION MANAGEMENT

The purpose of the Problem Resolution Management Process is to ensure that problems are identified,
analyzed, managed and controlled to resolution.
# PROCESS OUTCOMES
O1 a problem resolution management strategy is O4 problem resolution is initiated;
developed; O5 problems are tracked to closure; and
O2 problems are recorded, uniquely identified and O6 the status of problems and their trend are
classified; known.
O3 problems are analyzed and assessed to identify
an appropriate solution;

08-27 Problem management plan [O1] 15-05 Evaluation report [O3]
13-07 Problem record [O2,3,4,5] 15-12 Problem status report [O6]
15-01 Analysis report [O3]
# BASE PRACTICES

BP1: Develop a problem resolution management strategy. [O1]
Develop a problem resolution management strategy, including problem resolution activities, a status model
for the problems, alert notifications, responsibilities for performing these activities and an urgent resolution
strategy. Interfaces to affected parties are defined and definitions are maintained.
N1: Problem resolution activities can be different during the product life cycle, e.g. during prototype con
struction and series development.
BP2: Identify and record the problem. [O2]
Each problem is uniquely identified, described and recorded. Supporting information should be provided to
reproduce and diagnose the problem.
N2: Supporting information typically includes the origin of the problem, how it can be reproduced, environ-
mental information, by whom it has been detected, etc.
N3: Unique identification supports traceability to changes made.
BP3: Record the status of problems. [O6]
A status according to the status model is assigned to each problem to facilitate tracking.
BP4: Diagnose the cause and determine the impact of the problem. [O2,3]
Investigate the problem and determine its cause and impact in order to categorize the problem and to
determine appropriate actions.
N4: Problem categorization (e.g. A, B, C, light, medium, severe) may be based on severity, impact, criticality,
urgency, relevance for the change process, etc.
BP5: Authorize urgent resolution action. [O4]
If according to the strategy a problem requires an urgent resolution, authorization shall be obtained for
immediate action also according to the strategy.
SUP.9
35
36
BP6: Raise alert notifications. [O4]
If according to the strategy the problem has a high impact on other systems or other affected parties, an alert
notification needs to be raised also according to the strategy.
BP7: Initiate problem resolution. [O4]

Initiate appropriate actions according to the strategy to resolve the problem including review of those
actions, or initiate a change request.
N5: Appropriate actions may include the initiating of a change request. See SUP.10 for managing of change
requests.
N6: The implementation of process improvements (to prevent problems) is done in the process improve-
ment process (PIM.3).The implementation of generic project management improvements (e.g. lessons
learned) are part of the project management process (MAN.3). The implementation of generic work
product related improvements are part of the quality assurance process (SUP.1).
BP8: Track problems to closure. [O5,6]
Track the status of problems to closure including all related change requests. A formal acceptance has to be
authorized before closing the problem.
BP9: Analyze problem trends. [O6]
Collect and analyze problem resolution management data, identify trends, and initiate project related
actions, according to the strategy.
N7: Collected data typically contains information about where the problems occurred, how and when they
were found, what their impacts were, etc.
CHANGE REQUEST MANAGEMENT
N SUP.10 CHANGE REQUEST MANAGEMENT
# PROCESS PURPOSE
The purpose of the Change Request Management Process is to ensure that change requests are managed,
tracked and implemented.
# PROCESS OUTCOMES
O1 a change request management strategy is deve- O6 changes are approved and prioritized on the ba-
loped; sis of analysis results and availability of resources;
O2 requests for changes are recorded and identified; O7 approved changes are implemented and tracked
O3 dependencies and relationships to other change to closure;
requests are identified; O8 the status of all change requests is known; and
O4 criteria for confirming implementation of change O9 bi-directional traceability is established between
requests are defined; change requests and affected work products.
O5 requests for change are analyzed, and resource
requirements are estimated;

08-28 Change management plan [O1] 13-19 Review record [O7]
13-16 Change request [O2,3,4,5,6,7] 13-21 Change control record [O8,9]
SUP.10
37
38
# BASE PRACTICES
BP1: Develop a change request management strategy. [O1]
Develop a change request management strategy, including change request activities, a status model for the
change requests, analysis criteria, and responsibilities for performing these activities. Interfaces to affected
parties are defined and maintained.
N1: A status model for change requests may contain: open, under investigation, approved for implementa-

tion, allocated, implemented, fixed, closed, etc.
N2: Typical analysis criteria are: resource requirements, scheduling issues, risks, benefits, etc.
N3: Change request activities ensure that change requests are systematically identified, described, recorded,
analyzed, implemented, and managed.
N4: The change request management strategy may cover different proceedings across the product life cycle,
e.g. during prototype construction and series development.
BP2: Identify and record the change requests. [O2,3]
Each change request is uniquely identified, described, and recorded according to the strategy, including the
initiator and reason of the change request.
BP3: Record the status of change requests. [O8]
A status according to the status model is assigned to each change request to facilitate tracking.
BP4: Analyze and assess change requests. [O3,4,5,9]
Change requests are analyzed according to the strategy including their dependencies to affected work pro-
ducts and other change requests. Assess the impact of the change requests and establish criteria for confir-
ming implementation.
BP5: Approve change requests before implementation. [O6]
Change requests are prioritized based on analysis results and availability of resources before implementation
and approved according to the strategy.
N5: A Change Control Board (CCB) is a common mechanism used to approve change requests.
N6: Prioritization of change requests may be done by allocation to releases.
BP6: Review the implementation of change requests. [O7,8]
The implementation of change requests is reviewed before closure to ensure that their criteria for confirming
implementation are satisfied, and that all relevant processes have been applied.
BP7: Track change requests to closure. [O7,8]
Change requests are tracked until closure. Feedback to the initiator is provided.
BP8: Establish bidirectional traceability. [O9]
Establish bidirectional traceability between change requests and work products affected by the change re-
quests. In case that the change request is initiated by a problem, establish bidirectional traceability between
change requests and the corresponding problem reports.
N7: Bidirectional traceability supports consistency, completeness and impact analysis.
SUP.10
39
40
N SYS.1 REQUIREMENTS ELICITATION
# PROCESS PURPOSE
The purpose of the Requirements Elicitation Process is to gather, process, and track evolving stakeholder
needs and requirements throughout the lifecycle of the product and/or service so as to establish a require-
ments baseline that serves as the basis for defining the needed work products.
# PROCESS OUTCOMES
REQUIREMENTS ELICITATION
O1 continuing communication with the stakeholder O4 a mechanism is established for continuous moni-
is established; toring of stakeholder needs;
O2 agreed stakeholder requirements are defined O5 a mechanism is established for ensuring that
and baselined; customers can easily determine the status and
O3 a change mechanism is established to evaluate disposition of their requests; and
and incorporate changes to stakeholder require- O6 changes arising from changing technology and
ments into the baselined requirements based on stakeholder needs are identified, the associated
changing stakeholder needs; risks assessed and their impact managed.

08-19 Risk management plan [O6] 13-21 Change control record [O3,4]
08-20 Risk mitigation plan [O6] 15-01 Analysis report [O2,3,6]
13-04 Communication record [O1,4] 17-03 Stakeholder Requirements [O1,2]
13-19 Review record [O4,5]
# BASE PRACTICES
BP1: Obtain stakeholder requirements and requests. [O1,4]
Obtain and define stakeholder requirements and requests through direct solicitation of customer input and
through review of customer business proposals (where relevant), target operating and hardware environ-
ment, and other documents bearing on customer requirements.
N1: Requirements elicitation may involve the customer and the supplier.
N2: The agreed stakeholder requirements and evaluation of any change may be based on feasibility studies
and/or cost and time analyzes.
N3: The information needed to keep traceability for each customer requirement has to be gathered and
documented.
BP2: Understand stakeholder expectations. [O2]
Ensure that both supplier and customer understand each requirement in the same way.
N4: Reviewing the requirements and requests with the customer supports a better understanding of custo-
mer needs and expectations. Refer to the process SUP.4 Joint Review.
BP3: Agree on requirements. [O2]
Obtain an explicit agreement from all relevant parties to work on these requirements.
BP4: Establish stakeholder requirements baseline. [O2,3]
Formalize the stakeholder‘s requirements and establish them as a baseline for project use and monitoring
against stakeholder needs. The supplier should determine the requirements not stated by the stakeholder
but necessary for specified and intended use and include them in the baseline.
BP5: Manage stakeholder requirements changes. [O3,6]
Manage all changes made to the stakeholder requirements against the stakeholder requirements baseline
to ensure enhancements resulting from changing technology and stakeholder needs are identified and that
SYS.1
41
42
those who are affected by the changes are able to assess the impact and risks and initiate appropriate change
control and mitigation actions.
N5: Requirements change may arise from different sources as for instance changing technology and stake-
holder needs, legal constraints.
N6: An information management system may be needed to manage, store and reference any information
gained and needed in defining agreed stakeholder requirements.
BP6: Establish customer-supplier query communication mechanism. [O5]
Provide means by which the customer can be aware of the status and disposition of their requirements
changes and the supplier can have the ability to communicate necessary information, including data, in a
customer-specified language and format.
N7: Any changes should be communicated to the customer before implementation in order that the impact,
in terms of time, cost and functionality can be evaluated.
N8: This may include joint meetings with the customer or formal communication to review the status for
their requirements and requests; Refer to the process SUP.4 Joint Review.
N9: The formats of the information communicated by the supplier may include computer-aided design data
and electronic data exchange.
SYSTEM REQUIREMENTS ANALYSIS
N SYS.2 SYSTEM REQUIREMENTS ANALYSIS
# PROCESS PURPOSE
The purpose of the System Requirements Analysis Process is to transform the defined stakeholder require-
ments into a set of system requirements that will guide the design of the system.
# PROCESS OUTCOMES
O1 a defined set of system requirements is estab O5 the system requirements are updated as needed;
lished; O6 consistency and bidirectional traceability are
O2 system requirements are categorized and ana established between stakeholder requirements
lyzed for correctness and verifiability; and system requirements;
O3 the impact of system requirements on the opera- O7 the system requirements are evaluated for cost,
ting environment is analyzed; schedule and technical impact; and
O4 prioritization for implementing the system O8 the system requirements are agreed and commu-
requirements is defined; nicated to all affected parties.

13-04 Communication record [O8] 15-01 Analysis report [O2,3,4,7]
13-19 Review record [O6] 17-08 Interface requirements specification [O1,3]
13-21 Change control record [O1] 17-12 System requirements specification [O1,5]
13-22 Traceability record [O6] 17-50 Verification criteria [O2]
SYS.2
43
44
# BASE PRACTICES
BP1: Specify system requirements. [O1,5,7]
Use the stakeholder requirements and changes to the stakeholder requirements to identify the required
functions and capabilities of the system. Specify functional and non-functional system requirements in a
system requirements specification.
N1: Application parameter influencing functions and capabilities are part of the system requirements.

N2: For changes to the stakeholder‘s requirements SUP.10 applies.
BP2: Structure system requirements. [O2,4]
Structure the system requirements in the system requirements specification by e.g.
• grouping to project relevant clusters,
• sorting in a logical order for the project,
• categorizing based on relevant criteria for the project,
• prioritizing according to stakeholder needs.
N3: Prioritizing typically includes the assignment of functional content to planned releases. Refer to
SPL.2.BP1.
BP3: Analyze system requirements. [O1,2,7]
Analyze the specified system requirements including their interdependencies to ensure correctness, technical
feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the
technical impact.
N4: The analysis of impact on cost and schedule supports the adjustment of project estimates. Refer to
MAN.3.BP5.
BP4: Analyze the impact on the operating environment. [O3,7]
Identify the interfaces between the specified system and other elements of the operating environment. Ana-
lyze the impact that the system requirements will have on these interfaces and the operating environment.
BP5: Develop verification criteria. [O2,7]
Develop the verification criteria for each system requirement that define the qualitative and quantitative
measures for the verification of a requirement.
N5: Verification criteria demonstrate that a requirement can be verified within agreed constraints and is
typically used as the input for the development of the system test cases or other verification measures
that ensures compliance with the system requirements.
N6: Verification which cannot be covered by testing is covered by SUP.2.
Establish bidirectional traceability between stakeholder requirements and system requirements.
N7: Bidirectional traceability supports coverage, consistency and impact analysis.
BP7: Ensure consistency. [O6]
Ensure consistency between stakeholder requirements and system requirements.
N8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
BP8: Communicate agreed system requirements. [O8]
Communicate the agreed system requirements and updates to system requirements to all relevant parties.
SYS.2
45
46
N SYS.3 SYSTEM ARCHITECTURAL DESIGN
# PROCESS PURPOSE
The purpose of the System Architectural Design Process is to establish a system architectural design and
identify which system requirements are to be allocated to which elements of the system, and to evaluate the
system architectural design against defined criteria.
SYSTEM ARCHITECTURAL DESIGN

# PROCESS OUTCOMES
O1 a system architectural design is defined that O5 consistency and bidirectional traceability are
identifies the elements of the system; established between system requirements and
O2 the system requirements are allocated to the ele- system architectural design; and
ments of the system; O6 the system architectural design is agreed and
O3 the interfaces of each system element are defi- communicated to all affected parties.
ned;
O4 the dynamic behavior of the system elements is
defined;

04-06 System architectural design [O1,2,3,4,5] 13-22 Traceability record [O5]
13-04 Communication record [O6] 17-08 Interface requirements specification [O3]
13-19 Review record [O5]
# BASE PRACTICES

BP1: Develop system architectural design. [O1]
Develop and document the system architectural design that specifies the elements of the system with respect
to functional and non-functional system requirements.
N1: The development of system architectural design typically includes the decomposition into elements
across appropriate hierarchical levels.
BP2: Allocate system requirements. [O2]
Allocate the system requirements to the elements of the system architectural design.
BP3: Define interfaces of system elements. [O3]
Identify, develop and document the interfaces of each system element.
BP4: Describe dynamic behavior. [O4]
Evaluate and document the dynamic behavior of the interaction between system elements.
N2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibra
tion, diagnosis, etc.).
BP5: Evaluate alternative system architectures. [O1]
Define evaluation criteria for the architecture. Evaluate alternative system architectures according to the
defined criteria. Record the rationale for the chosen system architecture.
N3: Evaluation criteria may include quality characteristics (modularity, maintainability, expandability, scala-
bility, reliability, security realization and usability) and results of make-buy-reuse analysis.
Establish bidirectional traceability between system requirements and elements of the system architectural
design.
SYS.3
47
48
N4: Bidirectional traceability covers allocation of system requirements to the elements of the system archi-
tectural design.
BP7: Ensure consistency. [O1,2,5,6]
Ensure consistency between system requirements and the system architectural design.
N7: System requirements typically include system architectural requirements. Refer to BP5.

BP8: Communicate agreed system architectural design. [O6]
Communicate the agreed system architectural design and updates to system architectural design to all rele-
vant parties.
N SYS.4 SYSTEM INTEGRATION AND INTEGRATION TEST
SYSTEM INTEGRATION & INTEGRATION TEST

# PROCESS PURPOSE
The purpose of the System Integration and Integration Test Process is to integrate the system items to produ-
ce an integrated system consistent with the system architectural design and to ensure that the system items
are tested to provide evidence for compliance of the integrated system items with the system architectural
design, including the interfaces between system items.
# PROCESS OUTCOMES
O1 a system integration strategy consistent with the O5 test cases included in the system integration
project plan, the release plan and the system test specification are selected according to the
architectural design is developed to integrate system integration test strategy and the release
the system items; plan;
O2 a system integration test strategy including the O6 system item interactions are tested using the
regression test strategy is developed to test the selected test cases and the results of system inte-
system item interactions; gration testing are recorded;
O3 a specification for system integration test accor O7 consistency and bidirectional traceability bet-
ding to the system integration test strategy is ween the elements of the system architectural
developed that is suitable to provide evidence design and test cases included in the system
for compliance of the integrated system items integration test specification and bidirectional
with the system architectural design, including traceability between test cases and test results is
the interfaces between system items; established; and
O4 system items are integrated up to a complete O8 results of the system integration test are summa-
integrated system according to the integration rized and communicated to all affected parties.
strategy;
SYS.4
49
50

08-50 Test specification [O3,5] 13-19 Review record [O7]
08-52 Test plan [O1,2] 13-22 Traceability record [O7]
11-06 System [O4] 13-50 Test result [O6,8]
13-04 Communication record [O8]
# BASE PRACTICES
BP1: Develop system integration strategy. [O1]
Develop a strategy for integrating the system items consistent with the project plan and the release plan.
Identify system items based on the system architectural design and define a sequence for integrating them.
BP2: Develop system integration test strategy including regression test strategy. [O2]
Develop a strategy for testing the integrated system items following the integration strategy. This includes a
regression test strategy for re-testing integrated system items if a system item is changed.
BP3: Develop specification for system integration test. [O3]
Develop the test specification for system integration test including the test cases for each integration step
of a system item according to the system integration test strategy. The test specification shall be suitable to
provide evidence for compliance of the integrated system items with the system architectural design.
N1: The interface descriptions between system elements are an input for the system integration test cases.
N2: Compliance to the architectural design means that the specified integration tests are suitable to prove
that the interfaces between the system items fulfill the specification given by the system architectural
design.
N3: The system integration test cases may focus on
• the correct signal flow between system items
• the timeliness and timing dependencies of signal flow between system items
• the correct interpretation of signals by all system items using an interface
• the dynamic interaction between system items
N4: The system integration test may be supported using simulation of the environment (e.g. Hardware-
in-the-Loop simulation, vehicle network simulations, digital mock-up).
BP4: Integrate system items. [O4]
Integrate the system items to an integrated system according to the system integration strategy.
N5: The system integration can be performed step wise integrating system items (e.g. the hardware ele-
ments as prototype hardware, peripherals (sensors and actuators), the mechanics and integrated soft-
ware) to produce a system consistent with the system architectural design.
BP5: Select test cases. [O5]
Select test cases from the system integration test specification. The selection of test cases shall have sufficient
coverage according to the system integration test strategy and the release plan.
BP6: Perform system integration test. [O6]
Perform the system integration test using the selected test cases. Record the integration test results and logs.
N6: See SUP.9 for handling of non-conformances.
Establish bidirectional traceability between elements of the system architectural design and test cases inclu-
ded in the system integration test specification.
Establish bidirectional traceability between test cases included in the system integration test specification
and system integration test results.
SYS.4
51
52

Ensure consistency between elements of the system architectural design and test cases included in the system
integration test specification.
BP9: Summarize and communicate results. [O8]
Summarize the system integration test results and communicate them to all affected parties.
N9: Providing all necessary information from the test case execution in a summary enables other parties to
judge the consequences.
SYSTEM QUALIFICATION TEST
N SYS.5 SYSTEM QUALIFICATION TEST
# PROCESS PURPOSE
The purpose of the System Qualification Test Process is to ensure that the integrated system is tested to
provide evidence for compliance with the system requirements and that the system is ready for delivery.
# PROCESS OUTCOMES
O1 a system qualification test strategy including re- O4 the integrated system is tested using the selected
gression test strategy consistent with the project test cases and the results of system qualification
plan and release plan is developed to test the in- test are recorded;
tegrated system; O5 consistency and bidirectional traceability are
O2 a specification for system qualification test of the established between system requirements and
integrated system according to the system quali- test cases included in the system qualification
fication test strategy is developed that is suitable test specification and between test cases and test
to provide evidence for compliance with the sys- results; and
tem requirements; O6 results of the system qualification test are
O3 test cases included in the system qualification test summarized and communicated to all affected
specification are selected according to the system parties.
qualification test strategy and the release plan;

08-52 Test plan [O1] 13-22 Traceability record [O5]
13-04 Communication record [O6] 13-50 Test result [O4,6]
SYS.5
53
54
# BASE PRACTICES
BP1: Develop system qualification test strategy including regression test strategy. [O1]
Develop a strategy for system qualification test consistent with the project plan and the release plan. This
includes a regression test strategy for re-testing the integrated system if a system item is changed.
BP2: Develop specification for system qualification test. [O2]
Develop the specification for system qualification test including test cases based on the verification criteria
according to the system qualification test strategy. The test specification shall be suitable to provide evidence
for compliance of the integrated system with the system requirements.

Select test cases from the system qualification test specification. The selection of test cases shall have suffi-
cient coverage according to the system qualification test strategy and the release plan.
BP4: Test integrated system. [O4]
Test the integrated system using the selected test cases. Record the system qualification test results and logs.
Establish bidirectional traceability between system requirements and test cases included in the system
qualification test specification. Establish bidirectional traceability between test cases included in the system
qualification test specification and system qualification test results.
Ensure consistency between system requirements and test cases included in the system qualification test
specification.
Summarize the system qualification test results and communicate them to all affected parties.
SYS.5
55
56
N SWE.1 SOFTWARE REQUIREMENTS ANALYSIS
# PROCESS PURPOSE
SOFTWARE REQUIREMENTS ANALYSIS

The purpose of the Software Requirements Analysis Process is to transform the software related parts of the
system requirements into a set of software requirements.
# PROCESS OUTCOMES
O1 the software requirements to be allocated to the O6 consistency and bidirectional traceability are
software elements of the system and their inter- established between system requirements and
faces are defined; software requirements; and consistency and bi-
O2 software requirements are categorized and ana- directional traceability are established between
lyzed for correctness and verifiability; system architectural design and software re
O3 the impact of software requirements on the ope- quirements;
rating environment is analyzed; O7 the software requirements are evaluated for
O4 prioritization for implementing the software cost, schedule and technical impact; and
requirements is defined; O8 the software requirements are agreed and com-
O5 the software requirements are updated as nee- municated to all affected parties.
ded;

13-04 Communication record [O8] 15-01 Analysis report [O2,3,4,7]
13-19 Review record [O6] 17-08 Interface requirements specification [O1,3]
13-21 Change control record [O5,7] 17-11 Software requirements specification [O1]
13-22 Traceability record [O1,6] 17-50 Verification criteria [O2]
BP1: Specify software requirements. [O1,5,7]
Use the system requirements and the system architecture and changes to system requirements and architec-
ture to identify the required functions and capabilities of the software. Specify functional and non-functio-
nal software requirements in a software requirements specification.
N1: Application parameter influencing functions and capabilities are part of the system requirements.
N2: In case of software development only, the system requirements and the system architecture refer to a
given operating environment (see also note 5). In that case, stakeholder requirements should be used as
the basis for identifying the required functions and capabilities of the software as well as for identifying
application parameters influencing software functions and capabilities.
BP2: Structure software requirements. [O2,4]
Structure the software requirements in the software requirements specification by e.g.
• grouping to project relevant clusters,
• sorting in a logical order for the project,
• categorizing based on relevant criteria for the project,
• prioritizing according to stakeholder needs.
N3: Prioritizing typically includes the assignment of software content to planned releases. Refer to SPL.2.BP1.
BP3: Analyze software requirements. [O2,7]
Analyze the specified software requirements including their interdependencies to ensure correctness, tech-
nical feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and
the technical impact.
N4: The analysis of impact on cost and schedule supports the adjustment of project estimates. Refer to
MAN.3.BP5.
BP4: Analyze the impact on the operating environment. [O3,7]
Analyze the impact that the software requirements will have on interfaces of system elements and the ope-
rating environment.
SWE.1
57
58
N5: The operating environment is defined as the system in which the software executes (e.g. hardware,
operating system, etc.).
BP5: Develop verification criteria. [O2,7]
Develop the verification criteria for each software requirement that define the qualitative and quantitative
measures for the verification of a requirement.

N6: Verification criteria demonstrate that a requirement can be verified within agreed constraints and is
typically used as the input for the development of the software test cases or other verification measures
that should demonstrate compliance with the software requirements.
N7: Verification which cannot be covered by testing is covered by SUP.2.
Establish bidirectional traceability between system requirements and software requirements. Establish bidi-
rectional traceability between the system architecture and software requirements.
N8: Redundancy should be avoided by establishing a combination of these approaches that covers the pro-
ject and the organizational needs.
Ensure consistency between system requirements and software requirements. Ensure consistency between
the system architecture and software requirements.
N11: In case of software development only, the system requirements and system architecture refer to a given
operating environment (see also note 2). In that case, consistency and bidirectional traceability have to
be ensured between stakeholder requirements and software requirements.
BP8: Communicate agreed software requirements. [O8]
Communicate the agreed software requirements and updates to software requirements to all relevant par-
ties.
SOFTWARE ARCHITECTURAL DESIGN
N SWE.2 SOFTWARE ARCHITECTURAL DESIGN
# PROCESS PURPOSE
The purpose of the Software Architectural Design Process is to establish an architectural design and to iden-
tify which software requirements are to be allocated to which elements of the software, and to evaluate the
software architectural design against defined criteria.
# PROCESS OUTCOMES
O1 a software architectural design is defined that O5 consistency and bidirectional traceability are es-
identifies the elements of the software; tablished between software requirements and
O2 the software requirements are allocated to the software architectural design; and
elements of the software; O6 the software architectural design is agreed and
O3 the interfaces of each software element are defi- communicated to all affected parties.
ned;
O4 the dynamic behavior and resource consumption
objectives of the software elements are defined;

04-04 Software architectural design [O1,2,3,4,5] 13-22 Traceability record [O5]
13-04 Communication record [O6] 17-08 Interface requirement specification [O3]
13-19 Review record [O5]
SWE.2
59
60
# BASE PRACTICES
BP1: Develop software architectural design. [O1]
Develop and document the software architectural design that specifies the elements of the software with
respect to functional and non-functional software requirements.
N1: The software is decomposed into elements across appropriate hierarchical levels down to the software

components (the lowest level elements of the software architectural design) that are described in the
detailed design.
BP2: Allocate software requirements. [O2]
Allocate the software requirements to the elements of the software architectural design.
BP3: Define interfaces of software elements. [O3]
Identify, develop and document the interfaces of each software element.
Evaluate and document the timing and dynamic interaction of software elements to meet the required
dynamic behavior of the system.
N2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibra
tion, diagnosis, etc.), processes and process intercommunication, tasks, threads, time slices, interrupts,
etc.
N3: During evaluation of the dynamic behavior the target platform and potential loads on the target should
be considered.
BP5: Define resource consumption objectives. [O4]
Determine and document the resource consumption objectives for all relevant elements of the software
architectural design on the appropriate hierarchical level.
N4: Resource consumption is typically determined for resources like Memory (ROM, RAM, external / internal
EEPROM or Data Flash), CPU load, etc.
BP6: Evaluate alternative software architectures. [O1,2,3,4,5]
Define evaluation criteria for the architecture. Evaluate alternative software architectures according to the
defined criteria. Record the rationale for the chosen software architecture.
N5: Evaluation criteria may include quality characteristics (modularity, maintainability, expandability, scala-
bility, reliability, security realization and usability) and results of make-buy-reuse analysis.
Establish bidirectional traceability between software requirements and elements of the software architec-
tural design.
N6: Bidirectional traceability covers allocation of software requirements to the elements of the software
architectural design.
BP8: Ensure consistency. [O1,2,5,6]
Ensure consistency between software requirements and the software architectural design.
BP9: Communicate agreed software architectural design. [O6]
Communicate the agreed software architectural design and updates to software architectural design to all
relevant parties.
SWE.2
61
62
SWE.3 SOFTWARE DETAILED DESIGN
& UNIT CONSTRUCTION
SW DETAILED DESIGN & UNIT CONSTRUCTION

# PROCESS PURPOSE
The purpose of the Software Detailed Design and Unit Construction Process is to provide an evaluated detai-
led design for the software components and to specify and to produce the software units.
# PROCESS OUTCOMES
O1 a detailed design is developed that describes and consistency and bidirectional traceability are
software units; established between software detailed design
O2 interfaces of each software unit are defined; and software units;
O3 the dynamic behavior of the software units is O5 the software detailed design and the relation-
defined; ship to the software architectural design is ag-
O4 consistency and bidirectional traceability are es- reed and communicated to all affected parties;
tablished between software requirements and and
software units; and consistency and bidirectional O6 software units defined by the software detailed
traceability are established between software ar- design are produced.
chitectural design and software detailed design;

04-05 Software detailed design [O1,2,3] 13-19 Review record [O4]
11-05 Software unit [O6] 13-22 Traceability record [O4]
# BASE PRACTICES

BP1: Develop software detailed design. [O1]
Develop a detailed design for each software component defined in the software architectural design that
specifies all software units with respect to functional and non-functional software requirements.
BP2: Define interfaces of software units. [O2]
Identify, specify and document the interfaces of each software unit.
Evaluate and document the dynamic behavior of and the interaction between relevant software units.
N1: Not all software units have dynamic behavior to be described.
BP4: Evaluate software detailed design. [O1,2,3,4]
Evaluate the software detailed design in terms of interoperability, interaction, criticality, technical comple
xity, risks and testability.
N2: The results of the evaluation can be used as input for software unit verification.
Establish bidirectional traceability between software requirements and software units. Establish bidirectional
traceability between the software architectural design and the software detailed design. Establish bidirectio-
nal traceability between the software detailed design and software units.
N3: Redundancy should be avoided by establishing a combination of these approaches that covers the pro-
ject and the organizational needs.
Ensure consistency between software requirements and software units. Ensure consistency between the soft-
ware architectural design, the software detailed design and software units.
SWE.3
63
64
BP7: Communicate agreed software detailed design. [O5]
Communicate the agreed software detailed design and updates to the software detailed design to all rele-

vant parties.
BP8: Develop software units. [O6]
Develop and document the executable representations of each software unit according to the software
detailed design.
SOFTWARE UNIT VERIFICATION
N SWE.4 SOFTWARE UNIT VERIFICATION
# PROCESS PURPOSE
The purpose of the Software Unit Verification Process is to verify software units to provide evidence for
compliance of the software units with the software detailed design and with the non-functional software
requirements.
# PROCESS OUTCOMES
O1 a software unit verification strategy including O3 software units are verified according to the soft-
regression strategy is developed to verify the ware unit verification strategy and the defined
software units; criteria for software unit verification and the
O2 criteria for software unit verification are develo- results are recorded;
ped according to the software unit verification O4 consistency and bidirectional traceability are
strategy that are suitable to provide evidence for established between software units, criteria for
compliance of the software units with the soft- verification and verification results; and
ware detailed design and with the non-functio- O5 results of the unit verification are summarized
nal software requirements; and communicated to all affected parties.

08-50 Test specification [O2] 13-22 Traceability record [O4]
08-52 Test plan [O1] 13-25 Verification results [O3,5]
13-19 Review record [O3,4] 15-01 Analysis report [O3]
SWE.4
65
66
# BASE PRACTICES
BP1: Develop software unit verification strategy including regression strategy. [O1]
Develop a strategy for verification of the software units including regression strategy for re-verification if a
software unit is changed. The verification strategy shall define how to provide evidence for compliance of
the software units with the software detailed design and with the non-functional requirements.
N1: Possible techniques for unit verification include static/dynamic analysis, code reviews, unit testing etc.
BP2: Develop criteria for unit verification. [O2]
Develop criteria for unit verification that are suitable to provide evidence for compliance of the software

units, and their interactions within the component, with the software detailed design and with the non-func-
tional requirements according to the verification strategy. For unit testing, criteria shall be defined in a unit
test specification.
N2: Possible criteria for unit verification include unit test cases, unit test data, static verification, coverage
goals and coding standards such as the MISRA rules.
N3: The unit test specification may be implemented e.g. as a script in an automated test bench.
BP3: Perform static verification of software units. [O3]
Verify software units for correctness using the defined criteria for verification. Record the results of the static
verification.
N4: Static verification may include static analysis, code reviews, checks against coding standards and guide-
lines, and other techniques.
BP4: Test software units. [O3]
Test software units using the unit test specification according to the software unit verification strategy.
Record the test results and logs.
Establish bidirectional traceability between software units and static verification results. Establish bidirectio-
nal traceability between the software detailed design and the unit test specification. Establish bidirectional
traceability between the unit test specification and unit test results.
Ensure consistency between the software detailed design and the unit test specification.
Summarize the unit test results and static verification results and communicate them to all affected parties.
judge the consequences. SWE.4
67
68
SWE.5 SOFTWARE INTEGRATION &
INTEGRATION TEST
# PROCESS PURPOSE
SW INTEGRATION & INTEGRATION TEST

The purpose of the Software Integration and Integration Test Process is to integrate the software units into
larger software items up to a complete integrated software consistent with the software architectural design
and to ensure that the software items are tested to provide evidence for compliance of the integrated soft-
ware items with the software architectural design, including the interfaces between the software units and
between the software items.
# PROCESS OUTCOMES
O1 a software integration strategy consistent with the interfaces between the software units and
the project plan, release plan and the software between the software items;
architectural design is developed to integrate O4 software units and software items are integrated
the software items; up to a complete integrated software according
O2 a software integration test strategy including the to the integration strategy;
regression test strategy is developed to test the O5 Test cases included in the software integration
software unit and software item interactions; test specification are selected according to the
O3 a specification for software integration test ac- software integration test strategy, and the re-
cording to the software integration test strategy lease plan;
is developed that is suitable to provide evidence O6 integrated software items are tested using the
for compliance of the integrated software items selected test cases and the results of software
with the software architectural design, including integration test are recorded;
O7 consistency and bidirectional traceability are es- O8
results of the software integration test are
tablished between the elements of the software summarized and communicated to all affected
architectural design and the test cases included parties.
in the software integration test specification and
between test cases and test results; and

01-03 Software item [O4] 13-19 Review record [O7]
01-50 Integrated software [O4] 13-22 Traceability record [O7]
08-50 Test specification [O3,5] 13-50 Test result [O6,8]
08-52 Test plan [O1,2] 17-02 Build list [O4,7]
SWE.5
69
70
# BASE PRACTICES
BP1: Develop software integration strategy. [O1]
Develop a strategy for integrating software items consistent with the project plan and release plan. Identify
software items based on the software architectural design and define a sequence for integrating them.

BP2: Develop software integration test strategy including regression test strategy. [O2]
Develop a strategy for testing the integrated software items following the integration strategy. This includes
a regression test strategy for re-testing integrated software items if a software item is changed.
BP3: Develop specification for software integration test. [O3]
Develop the test specification for software integration test including the test cases according to the software
integration test strategy for each integrated software item. The test specification shall be suitable to provide
evidence for compliance of the integrated software items with the software architectural design.
N1: Compliance to the architectural design means that the specified integration tests are suitable to prove
that the interfaces between the software units and between the software items fulfill the specification
given by the software architectural design.
N2: The software integration test cases may focus on
• the correct dataflow between software items
• the timeliness and timing dependencies of dataflow between software items
• the correct interpretation of data by all software items using an interface
• the dynamic interaction between software items
• the compliance to resource consumption objectives of interfaces
BP4: Integrate software units and software items. [O4]
Integrate the software units to software items and software items to integrated software according to the
software integration strategy.
Select test cases from the software integration test specification. The selection of test cases shall have suffi-
cient coverage according to the software integration test strategy and the release plan.
BP6: Perform software integration test. [O6]
Perform the software integration test using the selected test cases. Record the integration test results and
logs.
N5: The software integration test may be supported by using hardware debug interfaces or simulation
environments (e.g. Software-in-the-Loop-Simulation).
Establish bidirectional traceability between elements of the software architectural design and test cases
included in the software integration test specification. Establish bidirectional traceability between test cases
included in the software integration test specification and software integration test results.
Ensure consistency between elements of the software architectural design and test cases included in the soft-
ware integration test specification.
Summarize the software integration test results and communicate them to all affected parties.
SWE.5
71
72
N SWE.6 SOFTWARE QUALIFICATION TEST
# PROCESS PURPOSE
The purpose of the Software Qualification Test Process is to ensure that the integrated software is tested to
provide evidence for compliance with the software requirements.
# PROCESS OUTCOMES
SOFTWARE QUALIFICATION TEST

O1 a software qualification test strategy including O4 the integrated software is tested using the selec-
regression test strategy consistent with the pro- ted test cases and the results of software qualifi-
ject plan and release plan is developed to test the cation test are recorded;
integrated software; O5 consistency and bidirectional traceability are es-
O2 a specification for software qualification test of tablished between software requirements and
the integrated software according to the soft- software qualification test specification inclu-
ware qualification test strategy is developed that ding test cases and between test cases and test
is suitable to provide evidence for compliance results; and
with the software requirements; O6 results of the software qualification test are
O3 test cases included in the software qualifica- summarized and communicated to all affected
tion test specification are selected according to parties.
the software qualification test strategy and the
release plan;

08-52 Test plan [O1] 13-22 Traceability record [O5]
# BASE PRACTICES
BP1: Develop software qualification test strategy including regression test strategy. [O1]
Develop a strategy for software qualification testing consistent with the project plan and the release plan.
This includes a regression test strategy for re-testing the integrated software if a software item is changed.
BP2: Develop specification for software qualification test. [O2]
Develop the specification for software qualification test including test cases based on the verification criteria,
according to the software test strategy. The test specification shall be suitable to provide evidence for com-
pliance of the integrated software with the software requirements.
Select test cases from the software test specification. The selection of test cases shall have sufficient coverage
according to the software test strategy and the release plan.
BP4: Test integrated software. [O4]
Test the integrated software using the selected test cases. Record the software test results and logs.
Establish bidirectional traceability between software requirements and test cases included in the software
qualification test specification. Establish bidirectional traceability between test cases included in the soft-
ware qualification test specification and software qualification test results.
SWE.6
73
74
Ensure consistency between software requirements and test cases included in the software qualification test
specification.
Summarize the software qualification test results and communicate them to all affected parties.

SUPPLIER MONITORING
N ACQ.4 SUPPLIER MONITORING
# PROCESS PURPOSE
The purpose of the Supplier Monitoring Process is to track and assess the performance of the supplier against
agreed requirements.
# PROCESS OUTCOMES
O1 joint activities, as agreed between the customer O3 performance of the supplier is monitored against
and the supplier, are performed as needed; the agreements; and
O2 all information, agreed upon for exchange, is O4 changes to the agreement, if needed, are nego-
communicated regularly between the supplier tiated between the customer and the supplier
and customer; and documented in the agreement.

02-01 Commitment / agreement [O4] 13-16 Change request [O4]
13-01 Acceptance record [O3] 13-19 Review record [O2]
13-04 Communication record [O1,2] 14-02 Corrective action register [O4]
13-09 Meeting support record [O1] 15-01 Analysis report [O3]
13-14 Progress status record [O2]
ACQ.4
75
76
# BASE PRACTICES
BP1: Agree on and maintain joint processes, [O1,2,4]
Joint interfaces, and information to be exchanged. Establish and maintain an agreement on information to
be exchanged and on joint processes and joint interfaces, responsibilities, type and frequency of joint activi-
ties, communications, meetings, status reports and reviews.
N1: Joint processes and interfaces usually include project management, requirements management, change
management, configuration management, problem resolution, quality assurance and customer accep-
tance.
N2: Joint activities to be performed should be mutually agreed between the customer and the supplier.
N3: The term customer in this process refers to the assessed party. The term supplier refers to the supplier of
the assessed party.
BP2: Exchange all agreed information. [O1,2,3]
Use the defined joint interfaces between customer and supplier for the exchange of all agreed information.
SUPPLIER MONITORING
N4: Agreed information should include all relevant work products.
BP3: Review technical development with the supplier. [O1,3,4]
Review development with the supplier on the agreed regular basis, covering technical aspects, problems and
risks and also track open items to closure.
BP4: Review progress of the supplier. [O1,3,4]
Review progress of the supplier regarding schedule, quality, and cost on the agreed regular basis. Track open
items to closure and perform risk mitigation activities.
BP5: Act to correct deviations. [O4]
Take action when agreed objectives are not achieved to correct deviations from the agreed project plans and
to prevent reoccurrence of problems identified. Negotiate changes to objectives and document them in the
agreements.
REUSE PROGRAM MANAGEMENT
N REU.2 REUSE PROGRAM MANAGEMENT
# PROCESS PURPOSE
The purpose of the Reuse Program Management Process is to plan, establish, manage, control, and monitor
an organization’s reuse program and to systematically exploit reuse opportunities.
# PROCESS OUTCOMES
As a result of successful implementation of this O5 reuse proposals are evaluated to ensure the
process: reuse product is suitable for the proposed appli-
O1 the reuse strategy, including its purpose, scope, cation;
goals and objectives, is defined; O6 reuse is implemented according to the reuse
O2 each domain is assessed to determine its reuse strategy;
potential; O7 feedback, communication, and notification
O3 the domains in which to investigate reuse mechanisms are established, that operate bet-
opportunities, or in which it is intended to ween affected parties; and
practice reuse, are identified; O8 the reuse program is monitored and evaluated.
O4 the organization‘s systematic reuse capability is
assessed;

04-02 Domain architecture [O2] 13-04 Communication record [O7]
04-03 Domain model [O2] 15-07 Reuse evaluation report [O5,6,8]
08-17 Reuse plan [O5,6] 15-13 Assessment / audit report [O3,4]
09-03 Reuse policy [O1] 19-05 Reuse strategy [O1]
12-03 Reuse proposal [O4]
REU.2
77
78
# BASE PRACTICES
BP1: Define organizational reuse strategy. [O1]
Define the reuse program and necessary supporting infrastructure for the organization.
BP2: Identify domains for potential reuse. [O2]
Identify set(s) of systems and their components in terms of common properties that can be organized into a
collection of reusable assets that may be used to construct systems in the domain.
REUSE PROGRAM MANAGEMENT

BP3: Assess domains for potential reuse. [O3]
Assess each domain to identify potential use and applications of reusable components and products.
BP4: Assess reuse maturity. [O4]
Gain an understanding of the reuse readiness and maturity of the organization, to provide a baseline and
success criteria for reuse program management.
BP5: Evaluate reuse proposals. [O5]
Evaluate suitability of the provided reusable components and product(s) to proposed use.
BP6: Implement the reuse program. [O6]
Perform the defined activities identified in the reuse program.
BP7: Get feedback from reuse. [O7,8]
Establish feedback, assessment, communication and notification mechanism that operate between affected
parties to control the progress of reuse program.
N1: Affected parties may include reuse program administrators, asset managers, domain engineers, develo-
pers, operators, and maintenance groups.
BP8: Monitor reuse. [O6,8]
Monitor the implementation of the reuse program periodically and evaluate its suitability to actual needs.
N2: The quality requirements for re-use work products should be defined.
PRODUCT RELEASE
N SPL.2 PRODUCT RELEASE
# PROCESS PURPOSE
The purpose of the Product Release Process is to control the release of a product to the intended customer.
# PROCESS OUTCOMES
O1 the contents of the product release are determi- O5 release approval is effected against defined
ned; criteria;
O2 the release is assembled from configured items; O6 the product release is made available to the
O3 the release documentation is defined and produ- intended customer; and
ced; O7 confirmation of release is obtained.
O4 the release delivery mechanism and media are
determined;

08-16 Release plan [O1,3] 13-06 Delivery record [O6,7]
11-03 Product release information [O1,3,4,6] 13-13 Product release approval record [O5]
11-04 Product release package [O2,3,6] 15-03 Configuration status report [O2]
11-07 Temporary solution [O6] 18-06 Product release criteria [O5,7]
SPL.2
79
80
# BASE PRACTICES
BP1: Define the functional content of releases. [O1,3]
Establish a plan for releases that identifies the functionality to be included in each release.
N1: The plan should point out which application parameters influencing the identified functionality are
effective for which release.
BP2: Define release products. [O1]
The products associated with the release are defined.
N2: The release products may include programming tools where these are stated. In automotive terms a
release may be associated with a sample e.g. A, B, C.
BP3: Establish a product release classification and numbering scheme. [O2]
A product release classification and numbering scheme are established based upon the intended purpose
and expectations of the release(s).
N3: A release numbering implementation may include
• the major release number
• the feature release number
PRODUCT RELEASE
• the defect repair number
• the alpha or beta release
• the iteration within the alpha or beta release
BP4: Define the build activities and build environment. [O2]
A consistent build process is established and maintained.
N4: A specified and consistent build environment should be used by all parties.
PRODUCT RELEASE
BP5: Build the release from configured items. [O2]
The release is built from configured items to ensure integrity.
N5: Where relevant the software release should be programmed onto the correct hardware revision before
release.
BP6: Communicate the type, service level and duration of support for a release. [O3]
The type, service level and duration of support for a release are identified and communicated.
BP7: Determine the delivery media type for the release. [O4]
The media type for product delivery is determined in accordance with the needs of the customer.
N6: The media type for delivery may be intermediate (placed on an adequate media and delivered to custo-
mer), or direct (such as delivered in firmware as part of the package) or a mix of both. The release may
be delivered electronically by placement on a server. The release may also need to be duplicated before
delivery.
BP8: Identify the packaging for the release media. [O4]
The packaging for different types of media is identified.
N7: The packaging for certain types of media may need physical or electronic protection for instance specific
encryption techniques.
BP9: Define and produce the product release documentation/release notes. [O3]
Ensure that all documentation to support the release is produced, reviewed, approved and available.
BP10: Ensure product release approval before delivery. [O5]
Criteria for the product release are satisfied before release takes place.
Ensure consistency between software release number, paper label and EPROM-Label (if relevant).
SPL.2
81
82
BP12: Provide a release note. [O6]
A release is supported by information detailing key characteristics of the release.
N8: 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 work
arounds.
BP13: Deliver the release to the intended customer. [O6,7]
The product is delivered to the intended customer with positive confirmation of receipt.
N9: Confirmation of receipt may be achieved by hand, electronically, by post, by telephone or through a
distribution service provider.
N10: These practices are typically supported by the SUP.8 Configuration Management Process.
PRODUCT RELEASE
PROCESS CAPABILITY INDICATORS (CL 1&2)
N PROCESS CAPABILITY INDICATORS (CL 1&2)
# PROCESS CAPABILITY LEVEL 1: PERFORMED PROCESS

PA 1.1 Process performance process attribute
GP 1.1.1 Achieve the process outcomes.
Achieve the intent of the base practices. Produce work products that evidence the process outcomes.
# PROCESS CAPABILITY LEVEL 2: MANAGED PROCESS

PA 2.1 Performance management process attribute
GP 2.1.1 Identify the objectives for the performance of the process.
Performance objectives are identified based on process requirements. The scope of the pro-
cess performance is defined. Assumptions and constraints are considered when identifying the
performance objectives.
N1: Performance objectives may include: (1) timely production of artifacts meeting the defined
quality criteria, (2) process cycle time or frequency (3) resource usage; and (4) boundaries of
the process.
N2: At minimum, process performance objectives for resources, effort and schedule should be stated.
GP 2.1.2 Plan the performance of the process to fulfill the identified objectives.
Plan(s) for the performance of the process are developed. The process performance cycle is de-
fined. Key milestones for the performance of the process are established. Estimates for process
performance attributes are determined and maintained. Process activities and tasks are defined.
Schedule is defined and aligned with the approach to performing the process. Process work
product reviews are planned.
CL 1&2
83
84
GP 2.1.3 Monitor the performance of the process against the plans.
The process is performed according to the plan(s). Process performance is monitored to ensure

planned results are achieved and to identify possible deviations
GP 2.1.4 Adjust the performance of the process.
Process performance issues are identified. Appropriate actions are taken when planned results and
objectives are not achieved. The plan(s) are adjusted, as necessary. Rescheduling is performed as
necessary.
GP 2.1.5 Define responsibilities and authorities for performing the process.
Responsibilities, commitments and authorities to perform the process are defined, assigned and
communicated. Responsibilities and authorities to verify process work products are defined and
assigned. The needs for process performance experience, knowledge and skills are defined.
GP 2.1.6 Identify, prepare, and make available resources to perform the process according
to plan.
The human and infrastructure resources, necessary for performing the process are identified made
available, allocated and used. The individuals performing and managing the process are prepared
by training, mentoring, or coaching to execute their responsibilities. The information necessary to
perform the process is identified and made available.
GP 2.1.7 Manage the interfaces between involved parties.
The individuals and groups involved in the process performance are determined. Responsibilities
of the involved parties are assigned. Interfaces between the involved parties are managed. Com-
munication is assured between the involved parties. Communication between the involved parties
is effective.
PA 2.2 Performance management process attribute
GP 2.2.1 Define the requirements for the work products.
The requirements for the work products to be produced are defined. Requirements may include
defining contents and structure. Quality criteria of the work products are identified. Appropriate
review and approval criteria for the work products are defined.
GP 2.2.2 Define the requirements for documentation and control of the work products.
Requirements for the documentation and control of the work products are defined. Such requi-
rements may include requirements for (1) distribution, (2) identification of work products and
their components and (3) traceability. Dependencies between work products are identified and
understood. Requirements for the approval of work products to be controlled are defined.
GP 2.2.3 Identify, document and control the work products.
The work products to be controlled are identified. Change control is established for work pro-
ducts. The work products are documented and controlled in accordance with requirements. Ver
sions of work products are assigned to product configurations as applicable. The work products
are made available through appropriate access mechanisms. The revision status of the work pro-
ducts may readily be ascertained.
GP 2.2.4 Review and adjust work products to meet the defined requirements.
Work products are reviewed against the defined requirements in accordance with planned arran-
gements. Issues arising from work product reviews are resolved.
CL 1&2
85
86
N PROCESS CAPABILITY INDICATORS (CL 3)
PROCESS CAPABILITY INDICATORS (CL 3)

# PROCESS CAPABILITY LEVEL 3: ESTABLISHED PROCESS
PA 3.1 Process definition process attribute
GP 3.1.1 Define and maintain the standard process that will support the deployment of the
defined process.
A standard process is developed and maintained that includes the fundamental process elements.
The standard process identifies the deployment needs and deployment context. Guidance and/
or procedures are provided to support implementation of the process as needed. Appropriate
tailoring guideline(s) are available as needed.
GP 3.1.2 Determine the sequence and interaction between processes so that they work as an
integrated system of processes.
The standard process’s sequence and interaction with other processes are determined. Deploy-
ment of the standard process as a defined process maintains integrity of processes.
GP 3.1.3 Identify the roles and competencies, responsibilities, and authorities for performing
the standard process.
Process performance roles are identified. Competencies for performing the process are identified.
Authorities necessary for executing responsibilities are identified.
GP 3.1.4 Identify the required infrastructure and work environment for performing the standard
process.
Process infrastructure components are identified (facilities, tools, networks, methods, etc.). Work
environment requirements are identified.
GP 3.1.5 Determine suitable methods and measures to monitor the effectiveness and suitability
of the standard process.
Methods and measures for monitoring the effectiveness and suitability of the process are deter-
mined. Appropriate criteria and data needed to monitor the effectiveness and suitability of the
process are defined. The need to conduct internal audit and management review is established.
Process changes are implemented to maintain the standard process.
PA 3.2 Process deployment process attribute
GP 3.2.1 Deploy a defined process that satisfies the context specific requirements of the use of
the standard process.
The defined process is appropriately selected and/or tailored from the standard process. Confor-
mance of defined process with standard process requirements is verified.
GP 3.2.2 Assign and communicate roles, responsibilities and authorities for performing the defi-
ned process.
The roles for performing the defined process are assigned and communicated. The responsibilities
and authorities for performing the defined process are assigned and communicated.
GP 3.2.3 Ensure necessary competencies for performing the defined process.
Appropriate competencies for assigned personnel are identified.
Suitable training is available for those deploying the defined process.
GP 3.2.4 Provide resources and information to support the performance of the defined process.
Required human resources are made available, allocated and used. Required information to
perform the process is made available, allocated and used.
CL 3
87
88
GP 3.2.5 Provide adequate process infrastructure to support the performance of the defined
process.
Required infrastructure and work environment is available. Organizational support to effectively

manage and maintain the infrastructure and work environment is available. Infrastructure and
work environment is used and maintained.
GP 3.2.6 Collect and analyze data about performance of the process to demonstrate its suitability
and effectiveness.
Data required to understand the behavior, suitability and effectiveness of the defined process are
identified. Data is collected and analyzed to understand the behavior, suitability and effectiveness
of the defined process. Results of the analysis are used to identify where continual improvement
of the standard and/or defined process can be made.
N1: Data about process performance may be qualitative or quantitative.
# PROCESS CAPABILITY LEVEL 4: PREDICTABLE PROCESS

PA 4.1 Quantitative analysis process attribute
GP 4.1.1 Identify business goals.
Business goals are identified that are supported by the quantitatively measured process.
GP 4.1.2 Establish process information needs.
Stakeholders of the identified business goals and the quantitatively measured process, and their
information needs are identified, defined and agreed.
GP 4.1.3 Derive process measurement objectives from process information needs.
The process measurement objectives to satisfy the established process information needs are
derived.
GP 4.1.4 Identify measurable relationships between process elements.
Identify the relationships between process elements, which contribute to the derived measure-
ment objectives.
GP 4.1.5 Establish quantitative objectives.
Establish quantitative objectives for the identified measurable process elements and their rela-
tionships. Agreement with process stakeholders is established.
CL 4
89
90
GP 4.1.6 Identify process measures that support the achievement of the quantitative objectives.
Detailed measures are defined to support monitoring, analysis and verification needs of the
quantitative objectives. Frequency of data collection is defined. Algorithms and methods to create

derived measurement results from base measures are defined, as appropriate. Verification mecha-
nism for base and derived measures is defined.
N1: Typically, the standard process definition is extended to include the collection of data for
process measurement.
GP 4.1.7 Collect product and process measurement results through performing the defined pro-
cess.
Data collection mechanism is created for all identified measures. Required data is collected within
the defined frequency, and recorded. Measurement results are analyzed, and reported to the
identified stakeholders.
N2: A product measure can contribute to a process measure, e.g. the productivity of testing charac-
terized by the number of defects found in a given timeframe in relation to the product defect
rate in the field.
PA 4.2 Quantitative control process attribute
GP 4.2.1 Select analysis techniques.
Analysis methods and techniques for control of the process measurements are defined.
GP 4.2.2 Establish distributions that characterize the process performance.
Expected distributions and corresponding control limits for measurement results are defined.
GP 4.2.3 Determine assignable causes of process variation.
Each deviation from the defined control limits is identified and recorded. Determine assignable
causes of these deviations by analyzing collected data using the defined analysis techniques. All
deviations and assigned causes are recorded.
GP 4.2.4 Identify and implement corrective actions to address assignable causes.
Corrective actions are determined, recorded, and implemented to address assignable causes of
variation. Corrective action results are monitored and evaluated to determine their effectiveness.
GP 4.2.5 Establish separate distributions for analyzing the process
Separate distributions are used to quantitatively understand the variation of process performance
under the influence of assignable causes.
CL 4
91
92

# PROCESS CAPABILITY LEVEL 5: INNOVATING PROCESS
PA 5.1 Process innovation process attribute
GP 5.1.1 Define the process innovation objectives for the process that support the relevant
business goals.
New business visions and goals are analyzed to give guidance for new process objectives and
potential areas of process innovation.
GP 5.1.2 Analyze data of the process to identify opportunities for innovation.
Common causes of variation in process performance are identified and analyzed to get a quanti-
tative understanding of their impact. Identify opportunities for innovation based on the quanti-
tative understanding of the analyzed data.
GP 5.1.3 Analyze new technologies and process concepts to identify opportunities for inno
vation.
Industry best practices, new technologies and process concepts are identified and evaluated.
Feedback on opportunities for innovation is actively sought. Emergent risks are considered in
evaluating improvement opportunities.
GP 5.1.4 Define and maintain an implementation strategy based on innovation vision and
objectives.
Commitment to innovation is demonstrated by organizational management including the process
owner(s) and other relevant stakeholders. Define and maintain an implementation strategy to
achieve identified opportunities for innovation and objectives. Based on implementation strategy
process changes are planned, prioritized based on their impact on defined innovations. Measures
that validate the results of process changes are defined to determine the expected effectiveness
of the process changes and the expected impact on defined business objectives.
PA 5.2 Process innovation implementation process attribute
GP 5.2.1 Assess the impact of each proposed change against the objectives of the defined and
standard process.
Objective priorities for process innovation are established. Specified changes are assessed against
product quality and process performance requirements and goals. Impact of changes to other
defined and standard processes is considered.
GP 5.2.2. Manage the implementation of agreed changes.
A mechanism is established for incorporating accepted changes into the defined and standard pro-
cess(es) effectively and completely. The factors that impact the effectiveness and full deployment
of the process change are identified and managed, such as:
• Economic factors (productivity, profit, growth, efficiency, quality, competition, resources, and
capacity);
• Human factors (job satisfaction, motivation, morale, conflict/cohesion, goal consensus, participa-
tion, training, span of control);
• Management factors (skills, commitment, leadership, knowledge, ability, organizational culture
and risks);
• Technology factors (sophistication of system, technical expertise, development methodology,
need of new technologies).
Training is provided to users of the process. Process changes are effectively communicated to all
affected parties. Records of the change implementation are maintained.
CL 5
93
94
GP 5.2.3 Evaluate the effectiveness of process change.
Performance and capability of the changed process are measured and evaluated against process
objectives and historical data. A mechanism is available for documenting and reporting analysis

results to management and owners of standard and defined process. Measures are analyzed to
determine whether the process performance has improved with respect to common causes of
variations. Other feedback is recorded, such as opportunities for further innovation of the predic-
table process.
WORK PRODUCT CHARACTERISTICS
N WORK PRODUCT CHARACTERISTICS
This list is a subset of work product characteristics of Automotive SPICE® v3.1, selected based upon our own prio-
ritization. The full list of work product characteristics can be retrieved as part of the official Process Assessment
Model.
01-00 Configuration item

• Item which is maintained under configuration file, system
control: - responsible owner
- may include components, subsystems, libraries, - date when placed under configuration control
test cases, compilers, data, documentation, - status information (i.e., development, base
physical media, and external interfaces lined, released)
• Version identification is maintained - relationship to lower level configured items
• Description of the item is available including the: - identification of the change control records
- type of item - identification of change history
- associated configuration management library,
01-03 Software item

• Integrated software consisting of: - describes and identifies software elements
- source code - describes and identifies configuration files
- software elements - describes and identifies executable code
- executable code - describes software life-cycle status
- configuration files - describes archive and release criteria
• Documentation, which: - describes compilation of software units
- describes and identifies source code - describes building of software item
WPC
95
96
01-51 Application Parameter
• Name • Means of data application (e.g. flashing inter-
• Description faces)
• Value domain, threshold values, characteristic • If necessary a grouping/a categorization:
curves - name of the category/group/file name
• Owner - description

• Actual value or characteristic curve applied
04-00 Design
• Describes the overall product/system structure - any required performance characteristics
• Identifies the required product/system elements - any required interfaces
• Identifies the relationship between the elements - any required security characteristics
• Consideration is given to:
04-02 Domain architecture

• Identified domain model(s) tailored from • Identification of the domain representation
• Identified asset specifications standard
• Definition of boundaries and relationships with • Provides an overview of the functions, features
other domains (Domain Interface Specification) capabilities and concepts in the domains
• Identification of domain vocabulary
04-03 Domain model

• Must provide a clear explanation and description, • Identification of the management and structures
on usage and properties, for reuse purposes used in the model
04-04 Software architectural design
• Describes the overall software structure or configurations are derived
• Describes the operative system including task • Describes the dynamic behavior of the software
structure (startup, shutdown, software update, error hand-
• Identifies inter-task/inter-process communication ling and recovery, etc.)
• Identifies the required software elements • Describes which data is persistent and under
• Identifies own developed and supplied code which conditions
• Identifies the relationship and dependency bet- • Consideration is given to:
ween software elements - any required software performance characteris-
• Identifies where the data (such as application tics
parameters or variables) are stored and which - any required software interfaces
measures (e.g. checksums, redundancy) are taken - any required security characteristics
to prevent data corruption - any database design requirements
• Describes how variants for different model series
04-05 Software detailed design

• Provides detailed design (could be represented • Describes the tasks with cycle time and priority
as a prototype, flow chart, entity relationship • Establishes required data naming conventions
diagram, pseudo code, etc.) • Defines the format of required data structures
• Provides format of input / output data • Defines the data fields and purpose of each
• Provides specification of CPU, ROM, RAM, required data element
EEPROM and Flash needs • Provides the specifications of the program struc-
• Describes the interrupts with their priorities ture
WPC
97
98
04-06 System architectural design
• Provides an overview of all system design - settings for system parameters (such as applica-
• Describes the interrelationship between system tion parameters or global variables)
elements - manual operations
• Describes the relationship between the system - reusable components
elements and the software • Mapping of requirements to system elements

• Specifies the design for each required system • Description of the operation modes of the system
element, consideration is given to aspects like: components (startup, shutdown, sleep mode,
- memory / capacity requirements diagnosis mode, etc.)
- hardware interfaces requirements • Description of the dependencies among the
- user interfaces requirements system components regarding the operation
- external system interface requirements modes
- performance requirements • Description of the dynamic behaviour of the
- commands structures system and the system components
- security / data protection characteristics
06-02 Handling and storage guide

• Defines the tasks to perform in handling and - storage environment required
storing products including: - the protection media to use
- providing for master copies of code and docu- - packing materials required
mentation - what items need to be stored
- disaster recovery - assessments to be done on stored product
- addressing appropriate critical safety and secu- • Provides retrieval instructions
rity issues
• Provides a description of how to store the pro-
duct including:
08-00 Plan
As appropriate to the application and purpose: - maintenance disposition for the plan
• Identifies what objectives or goals there are to be • Method / approach to accomplish plan
satisfied • Identifies:
• Establishes the options and approach for satis - task ownership, including tasks performed by
fying the objectives, or goals other parties (e.g. supplier, customer)
• Identification of the plan owner - quality criteria
• Includes: - required work products
- the objective and scope of what is to be accom- • Includes resources to accomplish plan objectives:
plished - time
- assumptions made - staff (key roles and authorities e.g. sponsor)
- constraints - materials / equipment
- risks - budget
- tasks to be accomplished • Includes contingency plan for non-completed
- schedules, milestones and target dates tasks
- critical dependencies • Plan is approved
08-04 Configuration management plan

• Defines or references the procedures to control • Includes management records and status reports
changes to configuration items that show the status and history of controlled
• Defines measurements used to determine the items
status of the configuration management activi- • Specifies the location and access mechanisms for
ties the configuration management library
• Defines configuration management audit criteria • Storage, handling and delivery (including archi-
• Approved by the configuration management val and retrieval) mechanisms specified
function
• Identifies configuration library tools or mechanism
WPC
99
100
08-12 Project plan
• Defines: • Milestones and target dates
- work products to be developed - estimates
- life cycle model and methodology to be used - quality criteria
- customer requirements related to project - processes and methods to employ
management - contingency actions

- project resources
08-13 Quality plan

• Objectives / goal for quality prior to requiring corrective actions
• Defines the activities/tasks required to ensure • Defines quality measurements and timing of the
quality collection
• References related work products • Specifies mechanism to feed collected quality
• References any regulatory requirements, stan- record back into process impacted by poor quality
dards, customer requirements • Defines the approach to guaranteeing objectivity
• Identifies the expected quality criteria • Approved by the quality responsible organiza-
• Specifies the monitoring timeframe and quality tion/function:
checkpoints for the defined life cycle and associa- - identifies escalations opportunities and chan-
ted activities planned nels
• Defines the methods of assuring quality - defines the cooperation with customer and
• Identifies the quality criteria for work products supplier QA
and process tasks
• Specifies the threshold/tolerance level allowed
08-16 Release plan
• Identifies the functionality to be included in each hardware, software, documentation etc.)
release • Mapping of the customer requests, requirements
• Identifies the associated elements required (i.e., satisfied to particular releases of the product
08-17 Reuse plan

• Defines the policy about what items to be reused • Identifies reusable components:
• Defines standards for construction of reusable - directory of component
objects: - description of components
- defines the attributes of reusable components - applicability of their use
- quality / reliability expectations - method to retrieve and use them
- standard naming conventions - restrictions for modifications and usage
• Defines the reuse repository (library, CASE tool, • Method for using reusable components
file, data base, etc.) • Establishes goal for reusable components
08-18 Review plan

• Defines: • Identification of:
- what to be reviewed - procedures for conducting review
- roles and responsibilities of reviewers - review inputs and outputs
- criteria for review (check-lists, requirements, - expertise expected at each review
standards) - review records to keep
- expected preparation time - review measurements to keep
- schedule for reviews - resources, tools allocated to the review
101
WPC
102
08-19 Risk management plan
• Project risks identified and prioritized - risk mitigator
• Mechanism to track the risk - work around
• Threshold criteria to identify when corrective - corrective actions activities / tasks
action required - monitoring criteria
• Proposed ways to mitigate risks: - mechanisms to measure risk

08-20 Risk mitigation plan
• Planned risk treatment activities and tasks: • Treatment control measures:
- describes the specifics of the risk treatment - defines the measures that will be used to eva-
selected for a risk or combination of risks found luate the effectiveness of the risk treatment
to be unacceptable • Treatment cost
- describes any difficulties that may be found in • Interfaces among parties involved:
implementing the treatment - describes any coordination among stakeholders
• Treatment schedule or with the project‘s master plan that must oc-
• Treatment resources and their allocation cur for the treatment to be properly implemen-
• Responsibilities and authority: ted
- describes who is responsible for ensuring that • Environment / infrastructure:
the treatment is being implemented and their - describes any environmental or infrastructure
authority 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 requirements for documents
• Defines the documentation activities during the • Review and authorization practices
life cycle of the software product or service • Distribution of the documents
• Identifies any applicable standards and templates • Maintenance and disposal of the documents
08-27 Problem management plan

• Defines problem resolution activities including correction of the problem
identification, recording, description and classifi- • Defines problem tracking
cation • Mechanism to collect and distribute problem
• Problem resolution approach: evaluation and resolutions
08-28 Change management plan

• Defines change management activities including • Defines approach to track status of change
identification, recording, description, analysis requests
and implementation • Defines verification and validation activities
• Change approval and implication review
08-50 Test specification

• Test Design Specification - identification of required system elements
• Test Case Specification (hardware elements, wiring elements, settings
• Test Procedure Specification for parameters (such as application parameters
• Identification of test cases for regression testing or global variables), data bases, etc.))
• Additionally for system integration: - necessary sequence or ordering identified for
integrating the system elements
103
WPC
104
08-52 Test plan
• Test Plan according to ISO29119-3 - identifies any constraints/risks and how these
• Context will be addressed
- project/test sub-process - test design techniques
- test item(s) - test completion criteria
- test scope - test ending criteria

- assumptions and constraints - test start, abort and re-start criteria
- stakeholder - metrics to be collected
- testing communication - test data requirements
• Test strategy - retesting and regression testing
- identifies what needs there are to be satisfied - suspension and resumption criteria
- establishes the options and approach for satis- - deviations from the Organizational Test Strategy
fying the needs (black-box and/or whitebox- • Test data requirements
testing, boundary class test determination, • Test environment requirements
regression testing strategy, etc.) • Test sub-processes
- establishes the evaluation criteria against which • Test deliverables
the strategic options are evaluated • Testing activities and estimates
09-03 Reuse policy

• Identification of reuse requirements • Identification of the name of the reuse sponsor
• Establishes the rules of reuse • Identification of the reuse program participants
• Documents the reuse adoption strategy including • Identification of the reuse steering function
goals and objectives • Identification of reuse program support functions
• Identification of the reuse program
10-00 Process description
• A detailed description of the process / procedure - input / output work products
which includes: - links between input and outputs work products
- tailoring of the standard process (if applicable) • Identifies process entry and exit criteria
- purpose of the process • Identifies internal and external interfaces to the
- outcomes of the process process
- task and activities to be performed and orde- • Identifies process measures
ring of tasks • Identifies quality expectations
- critical dependencies between task activities • Identifies functional roles and responsibilities
- expected time required to execute task • Approved by authorized personnel
11-03 Product release information

• Coverage for key elements (as appropriate to the - associated documentation list
application): • New/changed parameter information (e.g. for
• Description of what is new or changed (including application parameters or global variables) and/
features removed) or commands
• System information and requirements • Backup and recovery information
• Identification of conversion programs and in • List of open known problems, faults, warning in-
structions formation, etc.
• Release numbering implementation may include: • Identification of verification and diagnostic pro-
- the major release number cedures
- the feature release number • Technical support information
- the defect repair number • Copyright and license information
- the alpha or beta release; and the iteration • The release note may include an introduction,
within the alpha or beta release the environmental requirements, installation
• Identification of the component list (version procedures, product invocation, new feature
identification included): identification and a list of defect resolutions,
- hardware / software / product elements, libra- known defects and workarounds
ries, etc.
105
WPC
106
11-04 Product release package
• Includes the hardware / software / product - application parameter definitions defined
• Includes associated release elements such as: - command language defined
- system hardware / software / product elements - installation instructions
- associated customer documentation - release letter

11-05 Software unit
• Follows established coding standards (as appro- - variables defined
priate to the language and application): - data types defined
- commented - classes and inheritance structures defined
- structured or optimized - objects defined
- meaningful naming conventions • Entity relationships defined
- parameter information identified • Database layouts are defined
- error codes defined • File structures and blocking are defined
- error messages descriptive and meaningful • Data structures are defined
- formatting - indented, levels • Algorithms are defined
• Follows data definition standards (as appropriate • Functional interfaces defined
to the language and application):
11-06 System
• All elements of the product release are included - application parameters defined
• Any required hardware - commands defined
• Integrated product - data loaded or converted
• Customer documentation
• Fully configured set of the system elements:
12-03 Reuse proposal
• Identifies the project name nent including specific requirements (hardware,
• Identifies the project contact software, resource and other reuse components)
• Identifies the reuse goals and objectives • Identifies the person who will be approving the
• Identifies the list of reuse assets reuse proposal
• Identifies the issues / risks of reusing the compo-
13-04 Communication record

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

• Identifies the name of submitted and associated • Identifies the status of the reported problem
contact details • Identifies the target release(s) in which the
• Identifies the group / person(s) responsible for problem will be fixed
providing a fix • Identifies the expected closure date
• Includes a description of the problem • Identifies any closure criteria
• Identifies classification of the problem (criticality, • Identifies re-review actions
urgency, relevance etc.)
107
WPC
108
13-08 Baseline
• Identifies the name of submitted and associated • Is unique and may not be changed
contact details N: This should be established before a release to
• Identifies a state of one or a set of work products identify consistent and complete delivery
and artifacts which are consistent and complete
• Basis for next process steps

13-16 Change request
• Identifies purpose of change • Impacted system(s)
• Identifies request status (e.g., open, allocated, • Impact to operations of existing system(s) defined
implemented, closed) • Impact to associated documentation defined
• Identifies requester contact information • Criticality of the request, due date
13-19 Review record

• Provides the context information about the - time spent in the review
review: - reviewers, roles and expertise
- what was reviewed • Review findings:
- lists reviewers who attended - non-conformances
- status of the review - improvement suggestions
• Provides information about the coverage of the • Identifies the required corrective actions:
review: - risk identification
- check-lists - prioritized list of deviations and problems dis
- review criteria covered
- requirements - the actions, tasks to be performed to fix the
- compliance to standards problem
• Records information about: - ownership for corrective action
- the readiness for the review - status and target closure dates for identified
- preparation time spent for the review problems
13-21 Change control record
• Used as a mechanism to control change to baseli- - identification of change requester
ned products / products in official project release - identification of party responsible for the
libraries change
• Record of the change requested and made to - identification of status of the change
a baselined product (work products, software, • Linkage to associated customer requests, internal
customer documentation, etc.): change requests, etc.
- identification of system, documents impacted • Appropriate approvals
with change • Duplicate requests are identified and grouped
13-22 Traceability record

• All requirements (customer and internal) are to requirements to associated work products
be traced throughout all phases of the life cycle
• Identifies a mapping of requirements to life cycle N: this may be included as a function of another
work products defined work product (example: A CASE tool for
• Provides the linkage of requirements to work design decomposition may have a mapping abi
product decomposition lity as part of its features)
• Provides forward and backwards mapping of
13-25 Verification results

• Verification check-list • Risk analysis
• Passed items of verification • Recommendation of actions
• Failed items of verification • Conclusions of verification
• Pending items of verification • Signature of verification
• Problems identified during verification
109
WPC
110
13-50 Test result
• Level Test Log - information about the test execution (date,
• Anomaly Report tester name etc.)
• Level Test Report (Summary) Additionally where necessary:
- test cases not passed • Level Interim Test Status Report
- test cases not executed • Master Test Report (Summary)

14-02 Corrective action register
• Identifies the initial problem • Identifies the open date and target closure date
• Identifies the ownership for completion of defi- • Contains a status indicator
ned action • Indicates follow up audit actions
• Defines a solution (series of actions to fix problem)
14-06 Schedule
• Identifies the tasks to be performed • Identifies task completion status, vs. planned
• Identifies the expected and actual start and com- date
pletion date for required tasks against progress/ • Has a mapping to scheduled resource data
completion of tasks N: A schedule is consistent with the work break-
• Allows for the identification of critical tasks and down structure, see 14-09
task dependencies
14-09 Work breakdown

• Defines tasks to be performed, and their amend- • Documents the critical dependencies between
ments defined work products
• Documents ownership for tasks structure N: A work breakdown structure may be integrated
• Documents critical dependencies between tasks into/part of the schedule, see 14-06
• Documents inputs and output work products
14-11 Work product list
• Identifies: - work product status
- name of work product - when approved
- work product reference ID - reference to approval source
- work product revision - file reference
- when updated
14-50 Stakeholder groups list

• Identifies: - representative(s) for each stakeholder group
- relevant stakeholder groups - information needs of each stakeholder group
- weight/importance of each stakeholder group
15-00 Report
• A work product describing a situation that: - identifies considerations / constraints
- includes results and status - provides evidence / verification
- identifies applicable / associated information
15-01 Analysis report

• What was analyzed - potential risks
• Who did the analysis • Aspects of correctness to analyze include:
• The analysis criteria used: - completeness
- selection criteria or prioritization scheme used - understandability
- decision criteria - testability
- quality criteria - verifiability
• Records the results: - feasibility
- what was decided / selected - validity
- reason for the selection - consistency
- assumptions made - adequacy of content
111
WPC
112
15-03 Configuration status report
• Identification of the number of items under management items lost and reason for their loss
configuration management • Identification of problem and issues related to
• Identification of risks associated to configuration configuration management
management • Identification of receiving parties
• Identification of the number of configuration • Identification of baselines made

15-05 Evaluation report
• States the purpose of evaluation - evaluation instrument (check-list, tool) used
• Method used for evaluation • Records the result:
• Requirements used for the evaluation - data
• Assumptions and limitations - identifies the required corrective and preven
• Identifies the context and scope information tive actions
required: - improvement opportunities, as appropriate
- date of evaluation
- parties involved
- context details
15-06 Project status report
• A report of the current status of the project - expected future expenditure
• Schedule: - contingency plans to achieve budget goals
- planned progress (established objectives/goals) • Quality goals:
or completion (dates/deadlines) of tasks against - actual quality measures
- actual progress of tasks - reasons for variance from planned quality
- reasons for variance from planned progress measures
- threats to continued progress - contingency plans to achieve quality goals
- contingency plans to maintain progress
• Resources (human resources, infrastructure, hard- • Project issues:
ware/materials, budget): - issues which may affect the ability of the project
- planned expenditure against actual expenditure to achieve its goals.
- reasons for variance between planned and - contingency plans to overcome threats to
actual expenditure project goals
15-07 Reuse evaluation report

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

• Identifies the risks analyzed - assumptions made
• Records the results of the analysis: - constraints
- potential ways to mitigate the risk
113
WPC
114
15-09 Risk status report
• Identifies the status of an identified risk: - changes in priority
- related project or activity - duration of mitigation, when started
- risk statement - risk mitigation activities in progress
- condition - responsibility
- consequence - constraints

15-12 Problem status report
• Presents a summary of problem records • Status of problem solving
- by problem categories / classification - development of solved vs. open problems
15-13 Assessment/ audit report

• States the purpose of assessment - assessment team
• Method used for assessment - attendees
• Requirements used for the assessment - scope / coverage
• Assumptions and limitations - assessees‘ information
• Identifies the context and scope information re- - assessment instrument (check-list, tool) used
quired: • Records the result:
- date of assessment - data
- organizational unit assessed - identifies the required corrective actions
- sponsor information - improvement opportunities
15-16 Improvement opportunity

• Identifies what the problem is ming the improvement
• Identifies what the cause of a problem is • Identifies the penalty for not making the impro-
• Suggests what could be done to fix the problem vement
• Identifies the value (expected benefit) in perfor-
16-03 Configuration management system
• Supports the configuration management strategy • Ability to report configuration status
• Correct configuration of products • Has to cover all relevant tools
• Can recreate any release or test configuration
17-00 Requirement specification
• Each requirement is identified • Includes statutory and regulatory requirements
• Each requirement is unique • Includes issues / requirements from (contract)
• Each requirement is verifiable or can be assessed reviews
(see 17-50)
17-02 Build list
• Identification of aggregates of the software bases, job control languages, etc.)
application system • Necessary sequence ordering identified for
• Identification of required system elements (appli- compiling the software release
cation parameter settings, macro libraries, data • Input and output source libraries identified
17-03 Stakeholder requirements
• Purpose / objectives defined - human engineering considerations / constraints
• Includes issues / requirements from (contract) - security considerations / constraints
reviews - environmental considerations / constraints
• Identifies any: - operational considerations / constraints
- time schedule / constraints - maintenance considerations / constraints
- required feature and functional characteristics - installation considerations / constraints
- necessary performance considerations / cons- - support considerations / constraints
traints - design constraints
- necessary internal / external interface conside- - safety / reliability considerations / constraints
rations / constraints - quality requirements / expectations
- required system characteristics / constraints
115
WPC
116
17-08 Interface requirements specification
• Defines relationships between two products, - analogue Interfaces
process or process tasks - digital Interfaces (PWM, etc.)
• Defines criteria and format for what is common - additional Interfaces (IEEE, ISO, Bluetooth, USB,
to both etc.
• Defines critical timing dependencies or sequence • Identification of the software interfaces of soft-

ordering ware components and other software item in
• Description of the physical interfaces of each terms of
system component like - inter-process communication mechanisms
- bus interfaces (CAN, MOST, LIN, Flexray etc.) - bus communication mechanisms
- transceiver (type, manufacturer, etc.)
17-11 Software requirements specification

• Identifies standards to be used - any required security characteristics required
• Identifies any software structure considerations / - any database design requirements
constraints - any required error handling and recovery attri-
• Identifies the required software elements butes
• Identifies the relationship between software - any required resource consumption characteris-
elements tics
• Consideration is given to:
- any required software performance characteristics
- any required software interfaces
17-12 System requirements specification
• System requirements include: functions and - hardware interfaces requirements
capabilities of the system; business, organiza- - user interfaces requirements
tional and user requirements; safety, security, - external system interface requirements
human-factors engineering (ergonomics), inter- - performance requirements
face, operations, and maintenance requirements; - commands structures
design constraints and qualification require- - security / data protection characteristics
ments. (ISO/IEC 12207) - application parameter settings
• Identifies the required system overview - manual operations
• Identifies any interrelationship considerations / - reusable components
constraints between system elements • Describes the operation capabilities
• Identifies any relationship considerations / cons- • Describes environmental capabilities
traints between the system elements and the • Documentation requirements
software • Reliability requirements
• Identifies any design considerations / constraints • Logistical Requirements
for each required system element, including: • Describes security requirements
- memory / capacity requirements • Diagnosis requirements
17-50 Verification Criteria

• Each requirement is verifiable or can be assessed ment can be verified within agreed constraints.
• Verification criteria define the qualitative and (Additional Requirement to 17-00 Requirements
quantitative criteria for verification of a require- specification)
ment.
• Verification criteria demonstrate that a require-
117
WPC
118
18-01 Acceptance criteria
• Defines expectations for acceptance like e.g.: - documents
- interfaces - meetings
- schedules - joint reviews
- messages

18-06 Product release criteria
• Defines expectations for product release: - adequacy and coverage of testing
- release type and status - limit for open defects
- required elements of the release - change control status
- product completeness including documentation
18-07 Quality criteria

• Defines expectations for quality: - establishes life cycle transition criteria and the
- establishes what is an adequate work product entry and exit requirements for each process
(required elements, completeness expected, and/or activity defined
accuracy, etc.) - establishes expected performance attributes
- identifies what constitutes the completeness of - establishes product reliability attributes
the defined tasks
19-00 Strategy
• Identifies what needs and objectives or goals are the strategic options are evaluated
to be satisfied • Identifies any constraints / risks and how these
• Establishes the options and approach for satis will be addressed
fying the needs, objectives, or goals
• Establishes the evaluation criteria against which
19-05 Reuse strategy
• Identify the goals for reuse • Identify system and hardware / software / pro-
• Identify the commitment for creating reusable duct elements which can be reused within the
components organization
• Determine which product lines and type of arte- • Identify the reuse repository and tools
facts should be supported with reuse
19-10 Verification strategy

• Verification methods, techniques, and tools • Establishes the evaluation criteria against which
• Work product or processes under verification the strategic options are evaluated
• Degrees of independence for verification • Identifies any constraints / risks and how these
• Schedule for performing the activities above will be addressed
• Identifies what needs there are to be satisfied • Verification ending criteria
• Establishes the options and approach for satisfy- • Verification start, abort and re-start criteria
ing the need
119
WPC
Process Fellows GmbH I Schlegelleithe 8 I 91320 Ebermannstadt I GERMANY
Phone: +49 9194 3719-957 I Fax: +49 9194 3719-579
Website: www.processfellows.de I E-Mail: info@processfellows.de
120

Spicepocketguide Druckversion 20190112

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Spicepocketguide Druckversion 20190112

Uploaded by

Copyright:

Available Formats

Automotive SPICE®

Process Assessment Model

For further information about Automotive SPICE®

The detailed descriptions contained in this document may be incorporated as

All distribution of derivative works shall be made at no cost to the recipient.

Capability Levels and Process Attributes . . . . . . . . . 8

Capability Level Rating . . . . . . . . . . . . . . . . . . . . . . . 10

Example of an Assessment Result . . . . . . . . . . . . . . . 11

Risk Management 17 MAN.5

Quality Assurance 20 SUP.1

Joint Review 25 SUP.4

Configuration Management 31 SUP.8

Problem Resolution Management 34 SUP.9

Change Request Management 37 SUP.10

Requirements Elicitation 40 SYS.1

System Requirements Analysis 43 SYS.2

System Architectural Design 46 SYS.3

System Integration and Integration Test 49 SYS.4

System Qualification Test 53 SYS.5

Software Requirements Analysis 56 SWE.1

Software Architectural Design 59 SWE.2

SW Detailed Design & Unit Construction 62 SWE.3

Software Unit Verification 65 SWE.4

Software Integration and Integration Test 68 SWE.5

Software Qualification Test 72 SWE.6

Supplier Monitoring 75 ACQ.4

Reuse Program Management 77 REU.2

Product Release 79 SPL.2

Process Capability Indicators (CL 1&2) 83 CL 1&2

Process Capability Indicators (CL 3) 86 CL 3

Process Capability Indicators (CL 4) 89 CL 4

Process Capability Indicators (CL 5) 92 CL 5

Work Product Characteristics 95 WPC

Not achieved There is little or no evidence of achievement of the 0% - 15%

N Functional Safety (ISO 26262)

Discover our training catalogue on www.processfellows.de!

What do you need to change?

System and Software Engineering processes, methods and tools,

# OUTPUT WORK PRODUCTS

# OUTPUT WORK PRODUCTS

# OUTPUT WORK PRODUCTS

# OUTPUT WORK PRODUCTS

# OUTPUT WORK PRODUCTS

# OUTPUT WORK PRODUCTS

PROBLEM RESOLUTION MANAGEMENT

# OUTPUT WORK PRODUCTS

PROBLEM RESOLUTION MANAGEMENT

PROBLEM RESOLUTION MANAGEMENT

# OUTPUT WORK PRODUCTS

CHANGE REQUEST MANAGEMENT

# OUTPUT WORK PRODUCTS

# OUTPUT WORK PRODUCTS

SYSTEM REQUIREMENTS ANALYSIS

SYSTEM ARCHITECTURAL DESIGN

# OUTPUT WORK PRODUCTS

SYSTEM ARCHITECTURAL DESIGN

SYSTEM ARCHITECTURAL DESIGN

SYSTEM INTEGRATION & INTEGRATION TEST

SYSTEM INTEGRATION & INTEGRATION TEST

SYSTEM INTEGRATION & INTEGRATION TEST

# OUTPUT WORK PRODUCTS

SYSTEM QUALIFICATION TEST

SOFTWARE REQUIREMENTS ANALYSIS