ISO/IEC TS 30103:2015

TECHNICAL ISO/IEC TS
SPECIFICATION 30103
First edition
2015-09-15
Software and Systems Engineering —
Lifecycle Processes — Framework for
Product Quality Achievement
Ingénierie du logiciel et des systèmes — Processus du cycle de vie —
Cadre pour la réalisation de la qualité du produit
Reference number
©
ISO/IEC 2015
© ISO/IEC 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
1.1 Application . 1
1.2 Audience . 2
1.3 Limitations . 2
2 Motivation. 2
3 Terms, definitions and abbreviated terms . 3
4 Quality achievement concepts. 4
4.1 Overview of quality achievement . 4
4.2 Guiding principles and approach . 5
4.3 Localization of quality responsibility . 6
4.3.1 Establishing system element requirements . 6
4.3.2 Identification of process instances . 8
4.4 Creation of process instance descriptions . 8
4.4.1 Establishment of success criteria . 8
4.4.2 Identification of detailed activities and tasks . 9
4.4.3 Process instance descriptions .10
4.5 Consistency with institutional knowledge .11
4.6 Maintenance of content consistency .12
5 Required background concepts .13
5.1 System and Software Concepts .13
5.2 Life cycle concepts .13
5.3 Process concepts .14
5.4 Organizational concepts .14
5.5 Information Item Concepts .14
5.6 Notion of technical management .14
6 Context of application .14
6.1 Relationship to other standards.14
6.2 Organizational context .16
6.3 Stakeholder context .16
6.4 Stage context .16
6.5 Process context .16
6.6 Information item context .17
7 Potential process augmentations .17
7.1 Project planning process .17
7.2 Project assessment and control process .17
8 Guidelines for process augmentations .17
8.1 Project planning process .17
8.2 Project assessment and control process .18
9 Potential information item augmentations .18
9.1 Process Instance Descriptions .18
9.2 Consistency tracker .18
10 Guidelines for information item augmentations .19
10.1 Process instance descriptions .19
10.2 Consistency tracker .19
Annex A (informative) Example: Establishing System Element Requirements.20
Annex B (informative) Example: Creation of Process Instance Descriptions.23
Annex C (informative) Example: Consistency Tracker .27
© ISO/IEC 2015 – All rights reserved iii

Annex D (informative) Example: Process View for Specific Requirement.28
Annex E (informative) Theoretical Foundations .34
Annex F (informative) Example Set of Mutual Consistency Relationships .37
Bibliography .38
iv © ISO/IEC 2015 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 7, Software
and Systems Engineering.
© ISO/IEC 2015 – All rights reserved v

Introduction
[1]
This Technical Specification provides guidance on the application of ISO/IEC/IEEE 15288:2008
life cycle processes with specific reference to addressing quality in projects that deliver systems and
software products and services. It focuses on a systematic approach to achieving quality, involving the
development of certain information items, the inter-relationships between these information items
and the maintenance and mutual consistency management of these information items. In particular,
it describes how to develop detailed specifications of the collection of process instances needed to
produce a specific product or system and achieve its quality goals. It describes how the guidance in
life cycle process standards may be applied in conjunction with other standards (such as the ISO/IEC
[12]
25000 SQuaRE series of standards that address the specification, measurement and evaluation of
product quality) to achieve quality during the development of a specific system.
Application of life cycle processes to develop a system involves the production of, among others, a
collection of information items such as stakeholder requirements, system requirements, designs, plans,
and technical strategies, as well as a collection of artefacts including the various system elements and
enabling systems. The guidance in this Technical Specification is based on the following principles:
— Localization of quality responsibility: Requirements should be established for each system
element and enabling system, derived from the overall system requirements; the set of process
instances needed to develop each system element or enabling system should be identified; their
responsibilities towards quality are demarcated by the outcomes defined for the corresponding life
cycle process in ISO/IEC/IEEE 15288;
— Creation of process instance descriptions: For each process instance, success criteria should be
established based on the outcomes defined for the corresponding life cycle process, the characteristics
and requirements of the particular system element, and requirements and constraints arising
from product decisions made in other process instances; the set of specific tasks and associated
competencies needed to achieve these success criteria should be identified, particularly for system
elements with significant quality risk;
— Consistency with institutional knowledge: Achievement of quality ultimately depends on
correct technical decisions. Relevant institutional knowledge should be systematically identified
and deployed for making product and process decisions, and the resulting information items and
artefacts should be checked for consistency with the applicable bodies of institutional knowledge;
— Maintenance of content consistency: All the information items, including the process instance
specifications themselves, may evolve concurrently throughout the development life cycle. Content
consistency relationships among the various information items and artefacts should be tracked and
managed as these information items and artefacts evolve concurrently.
The Technical Specification is applicable to any project involving the development, enhancement or
re-engineering of systems with hardware, software and human elements. It is particularly useful to
project organizations that operate in multiple application domains where the set of critical quality
characteristics varies widely across projects, requiring a more systematic and detailed approach to
planning the achievement of quality during the development stage of the system life cycle.
This Technical Specification is intended to provide guidance for two-party situations and may be
equally applied where the two parties are from the same organization. This Technical Specification
can also be used by a single party as self-imposed tasks. This Technical Specification can also serve
as guidance in multi-party situations, where high risks are inherent in the supply and integration of
complex systems, and procurement can involve several suppliers, organizations or contracting parties.
vi © ISO/IEC 2015 – All rights reserved

TECHNICAL SPECIFICATION ISO/IEC TS 30103:2015(E)
Software and Systems Engineering — Lifecycle Processes
— Framework for Product Quality Achievement
1 Scope
1.1 Application
This Technical Specification provides guidance on
[1]
— applying processes from ISO/IEC/IEEE 15288:2008 in conjunction with other standards
to contribute to achieving quality of systems and software products and services during the
development stage of the life cycle (6.4),
— the information items that should be produced through the implementation of the relevant
processes (6.5), and
— the new information items (Clauses 9 and 10).
The scope of this Technical Specification is to indicate how to apply the life cycle processes in ISO/IEC/
IEEE 15288:2008 to achieve quality in the context of a specific product. It is independent of any tailoring
that may be made to modify the generic process descriptions to suit the needs of a particular context.
Even after any applicable tailoring, there is a need to apply the resulting process guidance and
determine the specific detailed activities, tasks and associated success criteria for each of the process
instances needed to deliver the target system. That is the focus of the framework described in this
Technical Specification.
This Technical Specification is applicable to
— those who use or plan to use ISO/IEC/IEEE 15288:2008 on projects dealing with man-made systems,
software-intensive systems, software products, and services related to those systems and products,
regardless of project scope, product(s), service(s), methodology, size or complexity,
[5]
— those who use or plan to use ISO/IEC/IEEE 15289 on projects dealing with man-made systems,
software-intensive systems, software products, and services related to those systems and products,
regardless of project scope, product(s), methodology, size or complexity,
— anyone performing technical processes and tasks,
— those who are responsible for the technical management of projects concerned with the
development of systems,
— those responsible for performing ISO/IEC/IEEE 15288:2008 life cycle processes at a project level,
— organizations and individuals subcontracting a project management effort,
— anyone developing systems engineering management documentation to complete technical planning
aspects of their project processes,
— anyone performing systems engineering activities,
— project managers responsible for staffing projects and identifying competency development needs,
— anyone developing information items during the application of project and technical processes, and
— anyone performing project and technical processes to aid in ensuring that the information items
developed during these processes conform to ISO/IEC/IEEE 15289.
© ISO/IEC 2015 – All rights reserved 1

1.2 Audience
The guidance in this Technical Specification is intended to be used in the development and maintenance
stages of the life cycle by all organizations and projects that develop or maintain systems and software
products and services. It is of particular value to organizations that work in a variety of application
domains, where the set of critical quality characteristics and approaches to achieve them vary widely
across projects.
1.3 Limitations
The achievement of quality ultimately depends on the competent performance of technical and
management tasks. While this Technical Specification provides guidance on a systematic approach to
quality achievement, including identification of needed competencies, the use of the approach alone is
not sufficient to guarantee achievement of quality.
This Technical Specification provides guidance on developing detailed specifications of the collection of
process instances needed to develop the product or service including the artefact-specific tasks within
each process instance, but it does not address sequencing and information flow issues among these
[8]
tasks and processes. The area of situational method engineering addresses the problem of organizing
the collection of tasks into a network with defined information flow patterns.
Tradeoffs among quality attributes are intentionally not addressed. Tradeoffs are part of the enactment
of requirements, design, planning and other processes. Any iteration needed to address tradeoffs is part
of concurrent elaboration. Consistency relationships must hold among information items and artefacts
after tradeoffs have been made. Guidance on tradeoffs is not provided to avoid over-prescription.
The approach described herein is applicable to design and realization of services and service delivery
systems. However, the achievement of service quality also depends on management of quality during
interactive service delivery, and this approach does not address that aspect of service quality.
2 Motivation
ISO/IEC/IEEE 15288:2008 establishes a common framework for describing the life cycle of systems
created by humans. It defines a set of processes and associated terminology. These processes can be
applied at a project level and guidance is provided on the outcomes, activities and tasks needed to
achieve quality.
These processes are intentionally defined to be product-agnostic so that they can be widely applicable
[2]
to all projects involving systems and software products and services. ISO/IEC TR 24748-1 ,
[3] [11]
ISO/IEC TR 24748-2 and ISO/IEC/IEEE 29148 provide guidance on the application of these life
cycle processes to a specific system, indicating that multiple recursive instances of each life cycle
process may be needed corresponding to system elements at each hierarchical level of the system, and
that multiple iterative instances may be needed to deal with dependencies and changes.
When applying the guidance from these standards to develop a specific system, there are challenges that
can potentially lead to gaps in quality achievement which may not be detected until late in the life cycle.
— All the specific tasks needed to develop each artefact associated with each system element and
enabling system must be identified. While the list of activities and tasks in each life cycle process
provides a starting point, the specific tasks to be performed depend on the requirements and
characteristics of the target system element. Any omissions in identifying the right set of specific
tasks will lead to defects that may not be detected until late in the life cycle.
— The product decisions made in various process instances need to be mutually consistent. The
decisions in some information items and artefacts impose requirements and constraints on others.
Mutual consistency relationships among deliverables must be maintained as they evolve during the
concurrent enactment of the various process instances. Gaps arise if changes are not propagated
consistently among artefacts.
2 © ISO/IEC 2015 – All rights reserved

— Quality achievement depends on the right technical decisions being taken. There is considerable
institutional knowledge from standards and other sources that can guide these technical decisions,
but there are often gaps in identification and application of the relevant technical knowledge.
This Technical Specification closes these potential gaps, describing in detail how the life cycle processes
may be used to achieve quality for a specific system.
3 Terms, definitions and abbreviated terms
3.1
concurrent elaboration
life cycle process instances are enacted concurrently during the project, and the information items and
artefacts produced by these process instances evolve concurrently
Note 1 to entry: This is referred to as concurrent elaboration of information items.
3.2
content consistency
semantic consistency among the contents of information items
3.3
information item
separately identifiable body of information that is produced, stored, and delivered for human use
[SOURCE: ISO/IEC/IEEE 15289]
3.4
institutional knowledge
knowledge from accepted sources, including standards, academic sources, domain and industry bodies
of knowledge and organizational knowledge
3.5
instantiation
identification, for each instance of a life cycle process, of the success criteria, artefact-specific activities
and tasks needed to achieve the process outcomes, and the competencies needed to perform these
tasks, based on the characteristics and requirements of the target system element
Note 1 to entry: This is referred to as instantiation of the life cycle processes for a specific system, product or service.
3.6
locality of quality responsibility
assignment of responsibility for specific quality-related requirements or decompositions thereof to a
particular process instance
3.7
process instance
single specific and identifiable execution of a process
[SOURCE: ISO/IEC 33001:2015, 3.2.17]
Note 1 to entry: It is the result of instantiation of life cycle processes for a specific system, product or service.
3.8
quality responsibility
responsibility for achievement of a quality requirement or decomposition thereof
© ISO/IEC 2015 – All rights reserved 3

3.9
success criteria
set of conditions to be satisfied by a process instance at completion
Note 1 to entry: Information items and artefacts produced by the process instance must meet the success criteria.
Success criteria are established based on the outcomes of the corresponding life cycle process, requirements of
the system element to which the process instance contributes, and requirements and constraints arising from
decisions in other process instances.
4 Quality achievement concepts
4.1 Overview of quality achievement
Figure 1 shows an overview of the relationships between the process and product decisions related
to quality achievement in a project. Product decisions for a project include, among others, the system
requirements, design, realization technologies, as well as verification, integration, validation, transition
and measurement strategies. Process decisions include identification of the specific tasks needed
to achieve quality for the specific system, as well as the practices, tools and technical management
approach. The process decisions are influenced by previous product decisions, and in turn generate
further product decisions.
The figure indicates the life cycle process standards that provide guidance on process decisions, and
some of the standards that provide guidance on product decisions. There are also other standards
that provide guidance on product and process decisions related to particular quality characteristics or
application domains, such as security, safety and automotive standards.
Process decisions Product decisions
Stakeholder
25010,
Quality
requirements
characteristics
deinition
Requirements System
analysis requirements
Architectural Architecture
design description
Implementation
Veriication &
& integration
validation strategy
and enabling
Veriication,
systems
validation &
assurance
Transition strategy
Transition
2502x,
Measurement &
2504x
Measurement evaluation strategy
“Produce”“Inluence”
Figure 1 — Overview of quality achievement
4 © ISO/IEC 2015 – All rights reserved
12207 15288
It should be noted that the lines in the above diagram represent informational and generative
relationships, not control flows. Life cycle processes are typically enacted concurrently and iteratively,
so that the various product-related decisions and the related process decisions evolve continuously
throughout the project. In general, it cannot be assumed either that the process decisions are all frozen
prior to enactment of that process, or that information items and artefacts are produced sequentially. In
complex projects, all of these evolve continuously and concurrently, and the consistency relationships
among them must be managed.
4.2 Guiding principles and approach
The approach to quality achievement described herein incorporates four principles.
— Localization of quality responsibility: Quality requirements should be established for each
system element and enabling system (herein referred to generically as artefacts), based on the
overall system requirements and the architectural design; the responsibility for meeting these
requirements should be further distributed among the collection of process instances that together
produce the system element, in accordance with the outcomes defined for the corresponding life
cycle processes.
— Creation of process instance descriptions: For each process instance, its responsibilities towards
meeting the requirements of the system element should be captured in the form of success criteria.
The detailed activities and tasks needed to achieve the success criteria, and the competencies to
perform them should be identified, especially for system elements with significant quality risk.
— Consistency with institutional knowledge: Achievement of quality ultimately depends on
correct technical decisions. Relevant institutional knowledge should be systematically identified
and deployed for making product and process decisions, and the resulting information items and
artefacts should be checked for consistency with the applicable bodies of institutional knowledge.
— Maintenance of content consistency: Content consistency relationships among the information
items and artefacts (i.e. mutual consistency of product decisions) should be tracked and managed
as they are concurrently elaborated during project enactment.
The principles establish each process instance as a locality of quality responsibility with defined
success criteria that reflect quality requirements, along with the complementary concepts of ensuring
consistency of decisions across localities and systematic application of institutional knowledge to
process and product decisions. The creation of detailed descriptions of process instances is referred to
as instantiation of the life cycle processes to the particular system element.
The resulting approach is shown in Figure 2.
© ISO/IEC 2015 – All rights reserved 5

Institutional
Information lows
knowledge
Establish requirements based Identify the set of process
For each
on overall system requirements instances needed to deliver
system
and design decisions the system element
element
Establish success criteria based on
For each
the life cycle process outcomes, the Identify detailed activities and
process
requirements of the target system tasks needed to achieve the
instance
element and relevant product success criteria
decisions in other processes
Identify consistency relationships Monitor gaps in mutual
For the set of
among the information items and consistency and consistency
information
artefactsproduced by the process with institutional knowledge
items and
instances during concurrent elaboration
artefacts
Figure 2 — Approach to quality achievement
The application of these principles should be tuned to the complexity of the system, development
context, criticality of quality characteristics and identified technical risks to achieve the best balance
between the benefits conferred by the systematic approach and the effort required to implement the
approach. There are several dimensions of flexibility in the application of the approach, for each of
which choices need to be made based on identified risks and other contextual factors:
— the granularity of system elements to which the approach is applied;
— whether to drill all system requirements down to the lowest level of the system hierarchy, or only
those requirements that are critical to the particular system element;
— the set of process instances selected for detailed instantiation, and the level of detail needed in the
description, based on identified risks;
— the set of content consistency relationships to be tracked and managed.
The theoretical foundations underlying these principles are discussed in the informational Annex
[9]
E. This approach is similar to the concepts of Quality by Design and aligned with the “Right First
[28]
Time” concept .
4.3 Localization of quality responsibility
4.3.1 Establishing system element requirements
The system requirements and architecture description identify the collection of system elements that
need to be developed, typically by decomposing the system-of-interest hierarchically into lower level
system elements.
NOTE 1 These system elements may be modules, components, services, features or updates and changes to
existing system elements (in the case of incremental development or re-engineering).
6 © ISO/IEC 2015 – All rights reserved

Recursive instances of the Requirements Analysis and Architectural Design processes decompose
the overall system requirements to establish the requirements for each lower level system element.
Requirements relating to quality characteristics should be hierarchically decomposed and allocated.
Depending on the nature of the quality characteristic and the decomposition, a requirement may
be directly assigned to a single system element, assigned to each of several system elements, or
decomposed and distributed among multiple system elements.
NOTE 2 In incremental development, the allocated requirements may reflect the changes in characteristics
needed for each system element, rather than the overall characteristics of the element.
The granularity to which requirements are drilled down depends on the tradeoffs between the cost
of establishing requirements for lower level elements and the benefits of more granular quality
management. This tradeoff may be managed at the level of individual requirements, so that more
critical requirements are drilled down deeper in the system hierarchy.
In this Technical Specification, the approach to quality achievement is illustrated with the example
of adding barcode scanning capabilities to a hospital Blood Bag Inventory System. Figure 3 shows an
example hierarchical decomposition and some requirements for each system element.
Figure 3 — Example (partial) system element requirements
Annex A describes the example problem in more detail, and indicates the approach for determining the
requirements for each system element from the overall system requirements.
In addition to system elements, the development of the system-of-interest may also need enabling
systems e.g. testbeds, deployment setup, swing hardware for transition etc. Requirements must also
be established for each enabling system by application of the Architectural Design and Requirements
processes in conjunction with the relevant Technical Process, i.e. Integration, Verification, Validation or
Transition process.
© ISO/IEC 2015 – All rights reserved 7

4.3.2 Identification of process instances
For each system element or enabling system (referred to generically as artefacts herein), the collection
of life cycle process instances needed to develop the artefact should be identified. This is based on the
type of the artefact (e.g. hardware, software, service), and the realization approach (e.g. development,
acquisition, adaptation of existing system elements or assets, integration from lower level system
elements). For example, a system element to be acquired needs a recursive instance of the acquisition
process, while system elements to be developed need instances of the Architectural Design and
Implementation processes. Note that for software elements, ISO/IEC/IEEE 12207:2008 may be used to
identify the collection of recursive process instances.
NOTE ISO/IEC TR 24748-1 also includes the concept of iterative process instances, wherein a process is
applied iteratively to refine the information items and artefacts produced. For the purposes of this Technical
Specification, iterative instances are subsumed by the concept of concurrent elaboration, according to which all
process instances are assumed (in principle) to operate possibly concurrently throughout the project, resulting
in continuous evolution of the set of information items and artefacts produced.
Annex B identifies a set of recursive process instances for the example problem.
ISO/IEC/IEEE 15288:2008 identifies the outcomes for each life cycle process. The responsibilities for
each process towards quality can be inferred from these outcomes. The quality responsibilities of
each process instance may be established by identifying success criteria for the process instance in
accordance with the outcomes.
4.4 Creation of process instance descriptions
4.4.1 Establishment of success criteria
The success criteria for a process instance include the following:
— The outcomes for the life cycle process, applied to the requirements and critical quality characteristics
of the particular artefact. Outcomes that are independent of the target artefact characteristics are
carried forward without change;
— Additional “checklist” criteria or practices based on institutional knowledge, reflecting
considerations specific to the particular artefact type;
EXAMPLE The success criteria for the Bar Code System Requirements Analysis process instance may include
a checklist item to establish requirements on the material for the barcode sticker.
— Requirements and constraints based on decisions in other process instances.
EXAMPLE Applicable architecture conformance constraints and support for verification may be added as
success criteria for Implementation Process instances.
[11]
For example, the Requirements Analysis process identifies the following outcomes :
a)  The required characteristics, attributes, and functional and performance requirements for a product solu-
tion are specified;
b)  Constraints that will affect the architectural design of a system and the means to realize it are specified;
c)  The integrity and traceability of system requirements to stakeholder requirements is achieved;
d)  A basis for verifying that the system requirements are satisfied is defined.
For the Bar Code System in the example problem, it is known from institutional knowledge and the
system requirements that availability, reliability, scanning accuracy and operator ergonomics are
important quality characteristics. This leads to establishment of the following success criteria for the
Bar Code System Requirements Analysis process:
a1) the target availability, reliability and accuracy for the barcode system are specified;
8 © ISO/IEC 2015 – All rights reserved

a2) scanner characteristics needed to support operator ergonomics are specified;
b1) constraints on integration of the barcode scanner with the inventory system are specified;
b2) constraints on the barcode system arising from the physical infrastructure are specified;
b3) fault modes that may affect the functioning of the barcode system are identified;
b4) constraints on the material for barcode stickers are identified;
c) the integrity and traceability of barcode system requirements to barcode stakeholder requirements
and/or overall system requirements is achieved;
d) procedures for verifying the barcode system availability, reliability and accuracy, and that it meets
operator ergonomics requirements, are defined;
e) scanning accuracy requirements are established for each deployment scenario: manual entry,
initial operational phase, stabilized operations.
These success criteria are derived based on institutional knowledge about the types of constraints
relevant to the system element (in this case, a physical device such as a barcode scanner) and about the
requirements analysis outcomes relevant to a particular quality attribute (in this case, that reliability
and availability requirements need an accompanying fault modes identification). The establishment
of success criteria provides an opportunity to use knowledge about the domain and characteristics
of the system element to pull in the relevant institutional knowledge and establish detailed quality
responsibilities for each process instance.
It should be noted that outcome c) does not lead to the identification of new success criteria because it is
largely independent of the specific artefact. Success criteria supplement the life cycle process outcomes
with more detailed identification of quality responsibilities, where applicable.
The success criteria may be augmented based on product decisions made in other process instances,
such as requirements for supporting features, technology and strategy decisions, measurement choices,
risk mitigation strategies and conformance constraints. Success criterion e) is derived based on the
establishment in the Transition process of three deployment scenarios: a manual operations scenario
where operators enter barcodes manually based on the stickers, an initial operational phase during
which operators are still gaining familiarity with the system and a stabilized operations scenario
where they are fully familiar with the proper use of the system.
Success criteria capture internal and external quality requirements that relate to the behaviour of the
[13]
system and its elements . They can also be used to capture quality-in-use requirements that relate
to emergent properties of the interaction between the system and its environment, including users.
Monitoring quality-in-use success criteria requires validation activities and is part of monitoring the
consistency relationship between the system requirements and stakeholder needs.
4.4.2 Identification of detailed activities and tasks
Life cycle processes identify generic activities and tasks needed to achieve the outcomes. Using this
guidance, projects should identify the specific tasks needed to achieve the success criteria for each
particular process instance. For example, the Requirements Process instance for the Bar Code System
uses the task guidance provided in the ISO/IEC/IEEE 15288, Requirements Process:
Define necessary implementation constraints that are introduced by stakeholder requirements or are
unavoidable solution limitations.
To identify the following specific task within the process instance:
Identify API support needed for verification of scanning correctness.
© ISO/IEC 2015 – All rights reserved 9

The detailed activities and tasks needed to achieve the success criteria for each process instance are
identified based on the following:
— Activities and tasks in the life cycle process definition;
— Institutional knowledge about practices relevant to the particular application domain and target
quality characteristics. Product decisions about technologies, methods, architectural and design
patterns etc. may have associated guidance relating to specific activities and
...