iso/iec/ieee 12207, systems and software engineering --...

Systems and software engineering — Software life cycle processesIngénierie des systèmes et du logiciel — Processus du cycle de vie du logiciel

INTERNATIONAL STANDARD

ISO/IEC/IEEE

12207

Reference numberISO/IEC/IEEE 12207:2017(E)

First edition2017-11

© ISO/IEC 2017© IEEE 2017

Authorized licensed use limited to: Burapha University provided by UniNet. Downloaded on January 08,2018 at 04:42:14 UTC from IEEE Xplore. Restrictions apply.

© ISO/IEC 2017 – All rights reservedii © IEEE 2017 – All rights reserved

ISO/IEC/IEEE 12207:2017(E)

COPYRIGHT PROTECTED DOCUMENT

© ISO/IEC 2017, Published in Switzerland© IEEE 2017All 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 or IEEE at the address below or ISO’s member body in the country of the requester.

ISO copyright office Institute of Electrical and Electronics Engineers, IncCh. de Blandonnet 8 • CP 401 3 Park Avenue, New YorkCH-1214 Vernier, Geneva, Switzerland NY 10016-5997, USATel. +41 22 749 01 11 Fax +41 22 749 09 47 [email protected] [email protected] www.ieee.org



iii©ISO/IEC2017–Allrightsreserved©IEEE2017–Allrightsreserved

Contents Page

Foreword ......................................................................................................................................................................................... vi

Introduction ................................................................................................................................................................................. vii

1 Scope .................................................................................................................................................................................. 11.1 Overview ........................................................................................................................................................................... 11.2 Purpose ............................................................................................................................................................................. 11.3 Field of application ........................................................................................................................................................ 11.4 Limitations ....................................................................................................................................................................... 2

2 Normative references ................................................................................................................................................... 2

3 Terms, definitions, and abbreviated terms ........................................................................................................... 23.1 Terms and definitions .................................................................................................................................................. 23.2 Abbreviated terms ...................................................................................................................................................... 11

4 Conformance ................................................................................................................................................................. 114.1 Intended usage ............................................................................................................................................................. 114.2 Full conformance ......................................................................................................................................................... 124.2.1 Full conformance to outcomes ................................................................................................................................ 124.2.2 Full conformance to tasks ........................................................................................................................................ 124.3 Tailored conformance ............................................................................................................................................... 12

5 Key concepts and application .................................................................................................................................. 135.1 Introduction .................................................................................................................................................................. 135.2 Software system concepts ........................................................................................................................................ 135.2.1 Software systems ......................................................................................................................................................... 135.2.2 Software system structure ....................................................................................................................................... 135.2.3 Enabling systems ......................................................................................................................................................... 155.2.4 Life cycle processes for the software system ..................................................................................................... 165.3 Organization and project concepts ........................................................................................................................ 165.3.1 Organizations ............................................................................................................................................................... 165.3.2 Organization and project-level adoption ............................................................................................................ 175.4 Life cycle concepts ...................................................................................................................................................... 175.4.1 Software life cycle stages .......................................................................................................................................... 175.4.2 Life cycle model for the software system ............................................................................................................ 175.5 Process concepts ......................................................................................................................................................... 195.5.1 Criteria for processes ................................................................................................................................................. 195.5.2 Description of processes ........................................................................................................................................... 195.5.3 General characteristics of processes .................................................................................................................... 195.5.4 Tailoring ......................................................................................................................................................................... 195.6 Process groups ............................................................................................................................................................. 195.6.1 Introduction .................................................................................................................................................................. 195.6.2 Agreement processes ................................................................................................................................................. 215.6.3 Organizational project-enabling processes ........................................................................................................ 225.6.4 Technical Management processes ......................................................................................................................... 225.6.5 Technical processes ................................................................................................................................................... 225.7 Process application .................................................................................................................................................... 225.8 Process reference model .......................................................................................................................................... 23

6 Software life cycle processes ................................................................................................................................... 246.1 Agreement processes ................................................................................................................................................. 246.1.1 Acquisition process .................................................................................................................................................... 246.1.2 Supply process ............................................................................................................................................................. 276.2 Organizational Project-Enabling processes ....................................................................................................... 286.2.1 Life cycle model management process ................................................................................................................. 296.2.2 Infrastructure Management process .................................................................................................................... 306.2.3 Portfolio Management process ............................................................................................................................... 316.2.4 Human Resource Management process ............................................................................................................... 33



iv©ISO/IEC2017–Allrightsreserved

©IEEE2017–Allrightsreserved

6.2.5 Quality Management process ................................................................................................................................... 346.2.6 Knowledge Management process ........................................................................................................................... 366.3 Technical Management processes .......................................................................................................................... 376.3.1 Project Planning process ........................................................................................................................................... 386.3.2 Project assessment and control process .............................................................................................................. 406.3.3 Decision Management process ................................................................................................................................ 436.3.4 Risk Management process ........................................................................................................................................ 446.3.5 Configuration Management process ...................................................................................................................... 466.3.6 Information Management process ......................................................................................................................... 506.3.7 Measurement process ................................................................................................................................................ 526.3.8 Quality Assurance process ........................................................................................................................................ 536.4 Technical processes .................................................................................................................................................... 556.4.1 Business or Mission Analysis process ................................................................................................................... 566.4.2 Stakeholder Needs and Requirements Definition process ............................................................................ 596.4.3 System/Software requirements definition process ......................................................................................... 636.4.4 Architecture Definition process .............................................................................................................................. 666.4.5 Design Definition process ......................................................................................................................................... 716.4.6 System Analysis process ............................................................................................................................................ 746.4.7 Implementation process ........................................................................................................................................... 756.4.8 Integration process ..................................................................................................................................................... 796.4.9 Verification process .................................................................................................................................................... 826.4.10 Transition process....................................................................................................................................................... 856.4.11 Validation process ....................................................................................................................................................... 896.4.12 Operation process ....................................................................................................................................................... 926.4.13 Maintenance process .................................................................................................................................................. 956.4.14 Disposal process .......................................................................................................................................................... 99

Annex A(normative) Tailoring process ........................................................................................................................... 102A.1 Introduction ............................................................................................................................................................... 102A.2 Tailoring process ...................................................................................................................................................... 102A.2.1 Purpose ........................................................................................................................................................................ 102A.2.2 Outcomes ..................................................................................................................................................................... 102A.2.3 Activities and tasks .................................................................................................................................................. 102

Annex B(informative)Examples of process information items ............................................................................... 104

Annex C(informative)Process Reference Model for assessment purposes ......................................................... 107C.1 Introduction ............................................................................................................................................................... 107C.2 Conformance with ISO/IEC 33004 ....................................................................................................................... 107C.2.1 General ......................................................................................................................................................................... 107C.2.2 Requirements for process reference models .................................................................................................. 107C.2.3 Process descriptions ................................................................................................................................................ 108C.3 The process reference model ............................................................................................................................... 108

Annex D(informative)Process integration and process constructs ........................................................................ 109D.1 Introduction ............................................................................................................................................................... 109D.2 Process constructs and their usage .................................................................................................................... 109

Annex E(informative)Process views ................................................................................................................................ 111E.1 Introduction ............................................................................................................................................................... 111E.2 The process view concept ...................................................................................................................................... 111E.3 Process viewpoint .................................................................................................................................................... 111E.4 Process view for specialty engineering ............................................................................................................. 112E.5 Process view for interface management ........................................................................................................... 114E.6 Process view for software assurance (Information security) .................................................................... 116

Annex F(informative)Software system architecture modelling .............................................................................. 120F.1 Introduction ............................................................................................................................................................... 120F.2 Views, models and model kinds used in software system architecture ................................................. 120F.2.1 Functional model ...................................................................................................................................................... 120F.2.2 Static model ................................................................................................................................................................ 121F.2.3 Data model .................................................................................................................................................................. 121F.2.4 Behavioral model ...................................................................................................................................................... 121F.2.5 Temporal model ........................................................................................................................................................ 121F.2.6 Structural model ....................................................................................................................................................... 121



v©ISO/IEC2017–Allrightsreserved©IEEE2017–Allrightsreserved

F.2.7 Network model .......................................................................................................................................................... 121F.3 Other model considerations .................................................................................................................................. 121

Annex G(informative) Application of software life cycle processes to a system of systems ........................... 123G.1 Introduction ................................................................................................................................................................ 123G.2 SoS characteristics and types ................................................................................................................................ 123G.3 SE processes applied to systems of systems ..................................................................................................... 124G.3.1 General ......................................................................................................................................................................... 124G.3.2 Agreement processes ............................................................................................................................................... 124G.3.3 Organizational project enabling processes ...................................................................................................... 124G.3.4 Technical management processes ....................................................................................................................... 125G.3.5 Technical processes ................................................................................................................................................. 125

Annex H(informative) Application of Agile ..................................................................................................................... 127

Annex I(informative) Process Mapping from ISO/IEC/IEEE 12207:2008 ............................................................. 129

Bibliography ............................................................................................................................................................................... 143

List of Illustrations

Figure 1 —Software system and software system element relationship ................................................................. 14

Figure 2 —Example of software system-of-interest structure ..................................................................................... 14

Figure 3 —Software system-of-interest, its operational environment and enabling systems .......................... 15

Figure 4 —Software life cycle processes ............................................................................................................................. 21

Table B.1 — Sample information items by process ....................................................................................................... 104

Figure D.1 — ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015 process constructs ......................... 110

Table G.1 — System of Systems types ................................................................................................................................ 123

Table I.1 — Comparison of processes in ISO/IEC/IEEE 12207:2017 and the previous edition ...................... 129

Table I.2 — Comparison of process outcomes in ISO/IEC/IEEE 12207:2017 and software-related outcomes in the previous edition ........................................................................................................................ 131



vi©ISO/IEC2017–Allrightsreserved


Foreword

ISO(theInternationalOrganizationforStandardization)andIEC(theInternationalElectrotechnicalCommission)form the specialized system for worldwide standardization. National bodies that are members of ISO or IECparticipate in the development of International Standards through technical committees established by therespective organization to deal with particular fields of technical activity. ISO and IEC technical committeescollaborateinfieldsofmutualinterest.Otherinternationalorganizations,governmentalandnon‐governmental,inliaisonwith ISO and IEC, also take part in thework. In the field of information technology, ISO and IEC haveestablishedajointtechnicalcommittee,ISO/IECJTC1.

IEEEStandardsdocumentsaredevelopedwithintheIEEESocietiesandtheStandardsCoordinatingCommitteesof the IEEE Standards Association (IEEE‐SA) Standards Board. The IEEE develops its standards through aconsensusdevelopmentprocess,approvedbytheAmericanNationalStandards Institute,whichbringstogethervolunteers representing varied viewpoints and interests to achieve the final product. Volunteers are notnecessarilymembersof the Institute and servewithout compensation.While the IEEEadministers theprocessandestablishesrulestopromotefairnessintheconsensusdevelopmentprocess,theIEEEdoesnotindependentlyevaluate,test,orverifytheaccuracyofanyoftheinformationcontainedinitsstandards.

Theproceduresusedtodevelopthisdocumentandthose intendedfor its furthermaintenancearedescribed inthe ISO/IEC Directives, Part1. In particular, the different approval criteria needed for the different types ofdocument should be noted. This document was drafted in accordance with the editorial rules of theISO/IECDirectives,Part2(seewww.iso.org/directives).

Attention is drawn to thepossibility that some of the elements of this documentmay be the subject of patentrights.ISO,IEC,andIEEEshallnotbeheldresponsibleforidentifyinganyorallsuchpatentrights.DetailsofanypatentrightsidentifiedduringthedevelopmentofthedocumentwillbeintheIntroductionand/orontheISOlistofpatentdeclarationsreceived(seewww.iso.org/patents).

Anytradenameusedinthisdocumentisinformationgivenfortheconvenienceofusersanddoesnotconstituteanendorsement.

ForanexplanationonthemeaningofISOspecifictermsandexpressionsrelatedtoconformityassessment,aswellasinformationaboutISO’sadherencetotheWorldTradeOrganization(WTO)principlesintheTechnicalBarrierstoTrade(TBT)seethefollowingURLwww.iso.org/iso/foreword.html.

ThisdocumentwaspreparedbyJointTechnicalCommitteeISO/IECJTC1,Information technology,SubcommitteeSC7, Systems and software engineering, in cooperation with the IEEE Computer Society Systems and SoftwareEngineering Standards Committee, under the Partner Standards Development Organization cooperationagreementbetweenISOandIEEE.

This first editionof ISO/IEC/IEEE12207cancelsandreplaces ISO/IEC12207:2008 (secondedition),whichhasbeentechnicallyrevised.

ChangesinthisrevisionofISO/IEC/IEEE12207weredevelopedinconjunctionwithacorrespondingrevisionofISO/IEC/IEEE 15288:2015, Systems and software engineering – System life cycle processes. The purpose of theserevisions is to accomplish the harmonization of the structures and contents of the two documents, whilesupportingtherequirementsoftheengineeringandassessmentcommunities.

Thisdocumentwasdevelopedwiththefollowinggoals:

— provideacommonterminologybetweentherevisionofISO/IEC/IEEE15288andISO/IEC/IEEE12207;

— where applicable, provide common process names and process structure between the revision ofISO/IEC/IEEE15288andISO/IEC/IEEE12207;and

— enable the user community to evolve towards fully harmonized standards, while allowing backwardcompatibility.

Thisrevisionisintendedtoachieveafullyharmonizedviewofthesystemandsoftwarelifecycleprocesses.


http://www.iso.org/directives�

http://www.iso.org/patents�

http://www.iso.org/iso/foreword.html�


vii©ISO/IEC2017–Allrightsreserved©IEEE2017–Allrightsreserved

Introduction

Thecomplexityofsoftwaresystemshasincreasedtoanunprecedentedlevel.Thishasledtonewopportunities,but also to increased challenges for the organizations that create and utilize systems. These challenges existthroughoutthe lifecycleofasystemandatall levelsofarchitecturaldetail.Thisdocumentprovidesacommonprocessframeworkfordescribingthelifecycleofsystemscreatedbyhumans,adoptingaSoftwareEngineeringapproach.SoftwareEngineeringisaninterdisciplinaryapproachandmeanstoenabletherealizationofsuccessfulsoftwaresystems. It focusesondefiningstakeholderneedsandrequired functionalityearly in thedevelopmentcycle,documentingrequirements,andperformingdesignsynthesisandsystemvalidationwhileconsideringthecompleteproblem. It integratesall thedisciplinesand specialtygroups intoa teameffort forminga structureddevelopmentprocessthatproceedsfromconcepttoproductiontooperationandmaintenance.Itconsidersboththebusinessandthetechnicalneedsofallstakeholderswiththegoalofprovidingaqualityproductthatmeetstheneeds of users and other applicable stakeholders. This life cycle spans the conception of ideas through to theretirement of a system. It provides the processes for acquiring and supplying systems. It helps to improvecommunicationandcooperationamongthepartiesthatcreate,utilizeandmanagemodernsoftwaresystemsinorder that they can work in an integrated, coherent fashion. In addition, this framework provides for theassessmentandimprovementofthelifecycleprocesses.

Theprocessesinthisdocumentformacomprehensivesetfromwhichanorganizationcanconstructsoftwarelifecyclemodelsappropriatetoitsproductsandservices.Anorganization,dependingonitspurpose,canselectandapplyanappropriatesubsettofulfillthatpurpose.

Thisdocumentcanbeusedinoneormoreofthefollowingmodes:

a) By an organization— to help establish an environment of desired processes. These processes can besupported by an infrastructure of methods, procedures, techniques, tools and trained personnel. Theorganization may then employ this environment to perform and manage its projects and progresssoftware systems through their life cycle stages. In this mode, this document is used to assessconformanceofadeclared,establishedenvironmenttoitsprovisions.

b) By a project — to help select, structure and employ the elements of an established environment toprovideproductsandservices.Inthismode,thisdocumentisusedintheassessmentofconformanceoftheprojecttothedeclaredandestablishedenvironment.

c) Byanacquirerandasupplier—tohelpdevelopanagreementconcerningprocessesandactivities.Viathe agreement, the processes and activities in this document are selected, negotiated, agreed to andperformed.Inthismode,thisdocumentisusedforguidanceindevelopingtheagreement.

d) By process assessors— to serve as a process referencemodel for use in the performance of processassessmentsthatmaybeusedtosupportorganizationalprocessimprovement.


INTERNATIONAL STANDARD ISO/IEC/IEEE 12207:2017(E)

1©ISO/IEC2017–Allrightsreserved©IEEE2017–Allrightsreserved

Systems and software engineering — Software life cycle processes

1 Scope

1.1 Overview

Thisdocumentestablishesacommonframeworkforsoftwarelifecycleprocesses,withwell‐definedterminology,that can be referenced by the software industry. It contains processes, activities, and tasks that are applicableduring theacquisition, supply,development, operation,maintenanceordisposalof softwaresystems,products,and services. These life cycle processes are accomplished through the involvement of stakeholders, with theultimategoalofachievingcustomersatisfaction.

This document applies to the acquisition, supply, development, operation,maintenance, anddisposal (whetherperformed internally or externally to an organization) of software systems, products and services, and thesoftware portion of any system, Software includes the software portion of firmware. Those aspects of systemdefinitionneededtoprovidethecontextforsoftwareproductsandservicesareincluded.

Thisdocumentalsoprovidesprocessesthatcanbeemployedfordefining,controlling,andimprovingsoftwarelifecycleprocesseswithinanorganizationoraproject.

Theprocesses,activities,andtasksof thisdocumentcanalsobeappliedduringtheacquisitionofasystemthatcontains software, either alone or in conjunction with ISO/IEC/IEEE 15288:2015, Systems and software engineering—System life cycle processes.

In the context of this document and ISO/IEC/IEEE 15288, there is a continuumof human‐made systems fromthose thatuse littleornosoftware to those inwhichsoftware is theprimary interest. It is rare toencounteracomplexsystemwithoutsoftware,andallsoftwaresystemsrequirephysicalsystemcomponents(hardware)tooperate, either as part of the software system‐of‐interest or as an enabling systemor infrastructure. Thus, thechoice of whether to apply this document for the software life cycle processes, or ISO/IEC/IEEE 15288:2015,Systems and software engineering—System life cycle processes, depends on the system‐of‐interest. Processes inboth documents have the same process purpose and process outcomes, but differ in activities and tasks toperformsoftwareengineeringorsystemsengineering,respectively.

1.2 Purpose

Thepurposeofthisdocumentistoprovideadefinedsetofprocessestofacilitatecommunicationamongacquirers,suppliersandotherstakeholdersinthelifecycleofasoftwaresystem.

This document is written for acquirers, suppliers, developers, integrators, operators, maintainers, managers,quality assurancemanagers, and users of software systems, products, and services. It can be used by a singleorganization inaself‐imposedmodeor inamulti‐partysituation.Partiescanbe fromthesameorganizationorfromdifferentorganizationsandthesituationcanrangefromaninformalagreementtoaformalcontract.

The processes in this document can be used as a basis for establishing business environments, e.g., methods,procedures,techniques,toolsandtrainedpersonnel.AnnexAprovidesnormativedirectionregardingthetailoringofthesesoftwarelifecycleprocesses.

1.3 Field of application

This document applies to the full life cycle of software systems, products, and services, including conception,development, production, utilization, support and retirement, and to their acquisition and supply, whetherperformed internallyor externally toanorganization.The life cycleprocessesof thisdocument canbeappliedconcurrently,iterativelyandrecursivelytoasoftwaresystemandincrementallytoitselements.



2©ISO/IEC2017–Allrightsreserved


There is awide variety of software systems in terms of their purpose, domain of application, complexity, size,novelty,adaptability,quantities, locations, lifespansandevolution.Thisdocumentdescribes theprocesses thatcomprise the life cycle ofman‐made software systems. It therefore applies to one‐of‐a‐kind software systems,softwaresystemsforwidecommercialorpublicdistribution,andcustomized,adaptablesoftwaresystems.Italsoapplies to a complete stand‐alone software systemand to software systems that are embeddedand integratedintolarger,morecomplexandcompletesystems.

Thisdocumentprovidesaprocessreferencemodelcharacterizedintermsoftheprocesspurposeandtheprocessoutcomes that result fromthesuccessfulexecutionof theactivity tasks.AnnexB listsexamplesofartifactsandinformation items that may be associated with various processes. This document can therefore be used as areference model to support process assessment as specified in ISO/IEC 33002:2015. AnnexC providesinformationregardingtheuseofthesoftwarelifecycleprocessesasaprocessreferencemodel.AnnexDdescribestheprocessconstructsforuseintheprocessreferencemodel.AnnexIprovidesthecorrespondencebetweenthisdocumentandISO/IEC/IEEE12207:2008atthelevelofprocessnameandprocessoutcome.

1.4 Limitations

This document does not prescribe a specific software life cycle model, development methodology, method,modellingapproach,ortechnique.Theusersofthisdocumentareresponsibleforselectingalifecyclemodelfortheprojectandmappingtheprocesses,activities,andtasksinthisdocumentintothatmodel.Thepartiesarealsoresponsible forselectingandapplyingappropriatemethodologies,methods,modelsandtechniquessuitable fortheproject.

Thisdocumentdoesnotestablishamanagementsystemorrequiretheuseofanymanagementsystemstandard.However,itisintendedtobecompatiblewiththequalitymanagementsystemspecifiedbyISO9001,theservicemanagementsystemspecifiedbyISO/IEC20000‐1(IEEEStd20000‐1),andtheinformationsecuritymanagementsystemspecifiedbyISO/IEC27000.

Thisdocumentdoesnotdetailinformationitemsintermsofname,format,explicitcontentandrecordingmedia.ISO/IEC/IEEE15289addressesthecontentforlifecycleprocessinformationitems(documentation).

2 Normative references

Therearenonormativereferencesinthisdocument.

3 Terms, definitions, and abbreviated terms

3.1 Terms and definitions

Forthepurposesofthisdocument,thefollowingtermsanddefinitionsapply.

ISOandIECmaintainterminologicaldatabasesforuseinstandardizationatthefollowingaddresses:

— IECElectropedia:availableathttp://www.electropedia.org— ISOOnlinebrowsingplatform:availableathttp://www.iso.org/obp— IEEEStandardsDictionaryOnline:availableathttp://ieeexplore.ieee.org/xpls/dictionary.jsp

Definitions for other terms typically can be found in ISO/IEC/IEEE 24765, System and software engineering —Vocabulary,availableat<www.computer.org/sevocab>.

3.1.1 acquirer stakeholderthatacquiresorprocuresaproductorservicefromasupplier

Note1toentry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser orinternal/organizationalsponsor.


http://www.electropedia.org/�

http://www.iso.org/obp�

http://ieeexplore.ieee.org/xpls/dictionary.jsp�



3.1.2 acquisition processofobtainingasystem,productorservice

3.1.3 activity setofcohesivetasksofaprocess

3.1.4 agile development software development approach based on iterative development, frequent inspection and adaptation, andincremental deliveries, in which requirements and solutions evolve through collaboration in cross‐functionalteamsandthroughcontinualstakeholderfeedback

[SOURCE:ISO/IEC/IEEE26515:2011]

3.1.5 agreement mutualacknowledgementoftermsandconditionsunderwhichaworkingrelationshipisconducted

EXAMPLE Contract,memorandumofagreement.

3.1.6 architecture <system> fundamental concepts or properties of a system in its environment embodied in its elements,relationships,andintheprinciplesofitsdesignandevolution


3.1.7 architecture framework conventions,principlesandpracticesforthedescriptionofarchitecturesestablishedwithinaspecificdomainofapplicationand/orcommunityofstakeholders

EXAMPLE1 GeneralisedEnterpriseReferenceArchitectureandMethodologies(GERAM)[ISO15704] isanarchitectureframework.

EXAMPLE2 ReferenceModelofOpenDistributedProcessing(RM‐ODP) [ISO/IEC10746]isanarchitectureframework.


3.1.8 architecture view workproductexpressingthearchitectureofasystemfromtheperspectiveofspecificsystemconcerns


3.1.9 architecture viewpoint workproductestablishingtheconventions for theconstruction, interpretationanduseofarchitectureviews toframespecificsystemconcerns


3.1.10 audit independent examination of awork product or set ofwork products to assess compliancewith specifications,standards,contractualagreements,orothercriteria


http://www.iso.org/iso/en/CatalogueListPage.CatalogueList�




3.1.11 baseline formallyapprovedversionofaconfigurationitem,regardlessofmedia,formallydesignatedandfixedataspecifictimeduringtheconfigurationitem’slifecycle

[SOURCE:IEEEStd828‐2012]

3.1.12 business process partiallyorderedsetofenterpriseactivitiesthatcanbeexecutedtoachievesomedesiredend‐resultinpursuitofagivenobjectiveofanorganization

3.1.13 concept of operations verbal and/or graphic statement, in broad outline, of an organization’s assumptions or intent in regard to anoperationorseriesofoperations

Note1toentry: The conceptofoperations frequently is embodied in long‐range strategicplans andannual operationalplans. In the latter case, the concept of operations in the plan covers a series of connected operations to be carried outsimultaneouslyor in succession.The concept isdesigned to give anoverall pictureof theorganizationoperations. See alsooperationalconcept(3.1.28).

Note2toentry: It provides the basis for bounding the operating space, system capabilities, interfaces and operatingenvironment.

[SOURCE:ANSI/AIAAG‐043A‐2012e]

3.1.14 concern <system>interestinasystemrelevanttooneormoreofitsstakeholders

Note1toentry: A concern pertains to any influence on a system in its environment, including developmental,technological,business,operational,organizational,political,economic,legal,regulatory,ecologicalandsocialinfluences.


3.1.15 configuration item itemoraggregationofhardware,software,orboth,thatisdesignatedforconfigurationmanagementandtreatedasasingleentityintheconfigurationmanagementprocess

EXAMPLE Software, firmware, data, hardware, humans, processes (e.g., processes for providing service to users),procedures(e.g.,operatorinstructionsandusermanuals),facilities,services,materials,andnaturallyoccurringentities

3.1.16 customer organizationorpersonthatreceivesaproductorservice

EXAMPLE Consumer,client,user,acquirer,buyer,orpurchaser.

Note1toentry: Acustomercanbeinternalorexternaltotheorganization.

3.1.17 design, verb <process>todefinethearchitecture,systemelements,interfaces,andothercharacteristicsofasystemorsystemelement

[SOURCE:ISO/IEC/IEEE24765:2010,modified,changed‘components’to‘systemelement’]

3.1.18 design, noun resultoftheprocessin3.1.17




Note1toentry: Information, including specification of system elements and their relationships, that is sufficientlycompletetosupportacompliantimplementationofthearchitecture

Note2toentry: Designprovides thedetailed implementation‐level physical structure, behavior, temporal relationships,andotherattributesofsystemelements.

3.1.19 design characteristic designattributesordistinguishingfeaturesthatpertaintoameasurabledescriptionofaproductorservice

3.1.20 enabling system systemthatsupportsasystem‐of‐interestduringitslifecyclestagesbutdoesnotnecessarilycontributedirectlytoitsfunctionduringoperation

EXAMPLE Aconfigurationmanagementsystemusedtocontrolsoftwareelementsduringsoftwaredevelopment.

Note1toentry: Eachenablingsystemhasalifecycleofitsown.Thisdocumentisapplicabletoeachenablingsystemwhen,initsownright,itistreatedasasystem‐of‐interest.

3.1.21 environment <system>contextdeterminingthesettingandcircumstancesofallinfluencesuponasystem


3.1.22 facility physicalmeansorequipmentforfacilitatingtheperformanceofanaction,e.g.,buildings,instruments,tools

3.1.23 incident anomalousorunexpectedevent,setofevents,condition,orsituationatanytimeduringthelifecycleofaproject,product,service,orsystem

3.1.24 information item separatelyidentifiablebodyofinformationthatisproduced,stored,anddeliveredforhumanuse


3.1.25 infrastructure hardware and software environment to support computer system and software design, development, andmodification

3.1.26 life cycle evolutionofasystem,product,service,projectorotherhuman‐madeentityfromconceptionthroughretirement

3.1.27 life cycle model frameworkofprocessesandactivitiesconcernedwiththelifecycle,whichcanbeorganizedintostages,actingasacommonreferenceforcommunicationandunderstanding

3.1.28 operational concept verbal andgraphic statementof an organization’s assumptionsor intent in regard to an operationor series ofoperationsofasystemorarelatedsetofsystems

Note1toentry: Theoperationalconceptisdesignedtogiveanoverallpictureoftheoperationsusingoneormorespecificsystems,orsetofrelatedsystems,intheorganization’soperationalenvironmentfromtheusers’andoperators’perspective.Seealsoconceptofoperations(3.1.13).





[SOURCE:ANSI/AIAAG‐043A‐2012e]

3.1.29 operator individualororganizationthatperformstheoperationsofasystem

Note1toentry: The role of operator and the role of user can be vested, simultaneously or sequentially, in the sameindividualororganization.

Note2toentry: Anindividualoperatorcombinedwithknowledge,skillsandprocedurescanbeconsideredasanelementofthesystem.

Note3toentry: An operator can perform operations on a system that is operated, orwithin a system that is operated,dependingonwhetherornotoperatinginstructionsareplacedwithinthesystemboundary.

3.1.30 organizationgroupofpeopleandfacilitieswithanarrangementofresponsibilities,authoritiesandrelationships

EXAMPLE company,corporation,firm,enterprise,institution,charity,soletrader,association,orpartsorcombinationthereof.

Note1toentry: An identified part of an organization (even as small as a single individual) or an identified group oforganizations canbe regarded as an organization if it has responsibilities, authorities and relationships.A bodyof personsorganizedforsomespecificpurpose,suchasaclub,union,corporation,orsociety,isanorganization.

3.1.31 party organizationenteringintoanagreement

Note1toentry: Inthisdocument,theagreeingpartiesarecalledtheacquirerandthesupplier.

3.1.32 problem difficulty, uncertainty, or otherwise realized and undesirable event, set of events, condition, or situation thatrequiresinvestigationandcorrectiveaction

3.1.33 process setofinterrelatedorinteractingactivitiesthattransformsinputsintooutputs

3.1.34 process outcome observableresultofthesuccessfulachievementoftheprocesspurpose

3.1.35 process purpose high‐levelobjectiveofperformingtheprocessandthelikelyoutcomesofeffectiveimplementationoftheprocess

Note1toentry: Thepurposeofimplementingtheprocessistoprovidebenefitstothestakeholders.

3.1.36 product resultofaprocess

Note1toentry: Therearefouragreedgenericproductcategories:hardware(e.g.,enginemechanicalpart);software(e.g.,computer program procedures, and possibly associated documentation and data); services (e.g., transport); and processedmaterials(e.g., lubricant).Hardwareandprocessedmaterialsaregenerallytangibleproducts,whilesoftwareorservicesaregenerallyintangible.

3.1.37 project endeavourwith defined start and finish criteria undertaken to create a product or service in accordancewithspecifiedresourcesandrequirements




Note1toentry: AprojectissometimesviewedasauniqueprocesscomprisingcoordinatedandcontrolledactivitiesandcomposedofactivitiesfromtheTechnicalManagementprocessesandTechnicalprocessesdefinedinthisdocument.

3.1.38 <project> portfolio collectionofprojectsthataddressesthestrategicobjectivesoftheorganization

3.1.39 qualification processofdemonstratingwhetheranentityiscapableoffulfillingspecifiedrequirements

3.1.40 quality assurance partofqualitymanagementfocusedonprovidingconfidencethatqualityrequirementswillbefulfilled

[SOURCE:ISO9000:2015]

3.1.41 quality characteristic inherentcharacteristicofaproduct,processorsystemrelatedtoarequirement

Note1toentry: Critical quality characteristics commonly include those related to health, safety, security assurance,reliability,availabilityandsupportability.

3.1.42 quality management coordinatedactivitiestodirectandcontrolanorganizationwithregardtoquality

3.1.43 release particularversionofaconfigurationitemthatismadeavailableforaspecificpurpose

EXAMPLE Testrelease.

3.1.44 requirement statementthattranslatesorexpressesaneedanditsassociatedconstraintsandconditions

[SOURCE:ISO/IEC/IEEE29148:2011,modified,NOTEhasbeenremoved.]

3.1.45 resource assetthatisutilizedorconsumedduringtheexecutionofaprocess

Note1toentry: Resourcesincludethosethatarereusable,renewableorconsumable.

EXAMPLE diverse entities suchas funding, personnel, facilities, capital equipment, tools, andutilities suchaspower,water,fuelandcommunicationinfrastructures.

3.1.46 retirement withdrawalof active supportby theoperationandmaintenanceorganization,partialor total replacementbyanewsystem,orinstallationofanupgradedsystem

3.1.47 risk effectofuncertaintyonobjectives

Note1toentry: Aneffect isadeviation fromtheexpected—positiveornegative.Apositiveeffect isalsoknownasanopportunity.

Note2toentry: Objectivescanhavedifferentaspects(suchasfinancial,healthandsafety,andenvironmentalgoals)andcanapplyatdifferentlevels(suchasstrategic,organization‐wide,project,productandprocess).





Note3toentry: Riskisoftencharacterizedbyreferencetopotentialeventsandconsequences,oracombinationofthese.

Note4toentry: Riskisoftenexpressedintermsofacombinationoftheconsequencesofanevent(includingchangesincircumstances)andtheassociatedlikelihoodofoccurrence.

Note5toentry: Uncertaintyisthestate,evenpartial,ofdeficiencyofinformationrelatedtounderstandingorknowledgeofanevent,itsconsequence,orlikelihood.

[SOURCE:ISOGuide73:2009,definition1.1]

3.1.48 safety expectationthatasystemdoesnot,underdefinedconditions,leadtoastateinwhichhumanlife,health,property,ortheenvironmentisendangered

3.1.49 security protection against intentional subversion or forced failure; a composite of four attributes – confidentiality,integrity,availability,andaccountability–plusaspectsofafifth,usability,allofwhichhavetherelated issueoftheirassurance

[SOURCE:NATOAEP‐67]

3.1.50 service performanceofactivities,work,orduties

Note1toentry: Aserviceisself‐contained,coherent,discrete,andcanbecomposedofotherservices.

Note2toentry: Aserviceisgenerallyanintangibleproduct.

3.1.51 software element systemelementthatissoftware

3.1.52 software engineering applicationofasystematic,disciplined,quantifiableapproachtothedevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware

3.1.53 software item sourcecode,objectcode,controlcode,controldata,oracollectionoftheseitems

Note1toentry: A software item can be viewed as a system element of this document and of ISO/IEC 15288:2015.Softwareitemsaretypicallyconfigurationitems.

3.1.54 software product setofcomputerprograms,procedures,andpossiblyassociateddocumentationanddata

Note1toentry: Asoftwareproductisasoftwaresystemviewedastheoutput(product)resultingfromaprocess.

3.1.55 software system systemforwhichsoftwareisofprimaryimportancetothestakeholders

Note1toentry: In the most general case, a software system is comprised of hardware, software, people, and manualprocedures.

Note2toentry: Inasoftwaresystem,softwareistheleadingdriverinmeetingsystemrequirements.




3.1.56 software system element memberofasetofelementsthatconstituteasoftwaresystem

Note1toentry: Asoftwaresystemelementcan includeoneormoresoftwareunits,softwareelements,hardwareunits,hardwareelements,services,andothersystemelementsandsystems.

Note2toentry: Asoftwaresystemelementcanbeviewedasasystemelement.

3.1.57 software unit atomic‐levelsoftwarecomponentofthesoftwarearchitecturethatcanbesubjectedtostandalonetesting

Note1toentry: Somesoftwareunitsareseparatelycompilablepiecesofcode.

[SOURCE:ISO26262‐1:2011,modified,Note1toentryadded.]

3.1.58 stage periodwithinthelifecycleofanentitythatrelatestothestateofitsdescriptionorrealization

Note1toentry: As used in this document, stages relate to major progress and achievement milestones of the entitythroughitslifecycle.

Note2toentry: Stagesoftenoverlap.

3.1.59 stakeholder individualororganizationhavingaright,share,claim,orinterestinasystemorinitspossessionofcharacteristicsthatmeettheirneedsandexpectations

EXAMPLE End users, end user organizations, supporters, developers, producers, trainers, maintainers, disposers,acquirers,supplierorganizationsandregulatorybodies.

Note1toentry: Somestakeholderscanhaveintereststhatopposeeachotheroropposethesystem.

3.1.60 supplier organization or an individual that enters into an agreement with the acquirer for the supply of a product orservice

Note1toentry: Othertermscommonlyusedforsupplierarecontractor,producer,seller,orvendor.

Note2toentry: Theacquirerandthesuppliersometimesarepartofthesameorganization.

3.1.61 system combinationofinteractingelementsorganizedtoachieveoneormorestatedpurposes

Note1toentry: Asystemissometimesconsideredasaproductorastheservicesitprovides.

Note2toentry: Inpractice,theinterpretationofitsmeaningisfrequentlyclarifiedbytheuseofanassociativenoun,e.g.,aircraft system or database management system. Alternatively, the word “system” is substituted simply by a context‐dependentsynonym,e.g.,aircraftordatabase,thoughthispotentiallyobscuresasystemprinciplesperspective.

Note3toentry: A system can include the associated equipment, facilities, material, software, firmware, technicaldocumentation, servicesandpersonnel required foroperationsand support to thedegreenecessary foruse in its intendedenvironment.

Note4toentry: Seeforcomparison:enablingsystem,system‐of‐interest,systemofsystems.

3.1.62 system element memberofasetofelementsthatconstituteasystem





EXAMPLE Hardware,software,data,humans,processes(e.g.,processesforprovidingservicetousers),procedures(e.g.,operatorinstructions),facilities,materials,andnaturallyoccurringentitiesoranycombination.

Note1toentry: Asystemelementisadiscretepartofasystemthatcanbeimplementedtofulfillspecifiedrequirements.

3.1.63 system-of-interest SOI systemwhoselifecycleisunderconsideration

3.1.64 system of systems SoS setofsystemsthatintegrateorinteroperatetoprovideauniquecapabilitythatnoneoftheconstituentsystemscanaccomplishonitsown

Note1toentry: Eachconstituentsystemisausefulsystembyitself,havingitsownmanagement,goals,andresources,butcoordinateswithintheSoStoprovidetheuniquecapabilityoftheSoS.

3.1.65 systems engineering interdisciplinary approach governing the total technical and managerial effort required to transform a set ofstakeholderneeds,expectations,andconstraintsintoasolutionandtosupportthatsolutionthroughoutitslife.

3.1.66 task required, recommended, or permissible action, intended to contribute to the achievement of one or moreoutcomesofaprocess

3.1.67 technical management applicationoftechnicalandadministrativeresourcestoplan,organizeandcontrolengineeringfunctions

3.1.68 trade-off decision‐makingactionsthatselectfromvariousrequirementsandalternativesolutionsonthebasisofnetbenefittothestakeholders

3.1.69 traceability degreetowhicharelationshipcanbeestablishedamongtwoormorelogicalentities,especiallyentitieshavingapredecessor‐successorormaster‐subordinaterelationshiptooneanother,suchasrequirements,systemelements,verifications,ortasks

EXAMPLE Softwarefeaturesandtestcasesaretypicallytracedtosoftwarerequirements.

3.1.70 user individualorgroupthatinteractswithasystemorbenefitsfromasystemduringitsutilization

Note1toentry: The role of user and the role of operator are sometimes vested, simultaneously or sequentially, in thesameindividualororganization.

[SOURCE:ISO/IEC25010:2011,modified,Note1toentryadded.]

3.1.71 validation confirmation, through theprovisionof objective evidence, that the requirements for a specific intendeduse orapplicationhavebeenfulfilled

Note1toentry: Asystemisabletoaccomplishitsintendeduse,goalsandobjectives(i.e.,meetstakeholderrequirements)intheintendedoperationalenvironment.Therightsystemwasbuilt.




Note2toentry: Inalifecyclecontext,validationinvolvesthesetofactivitiesforgainingconfidencethatasystemisabletoaccomplishitsintendeduse,goalsandobjectivesinanenvironmentliketheoperationalenvironment.

3.1.72 verification confirmation,throughtheprovisionofobjectiveevidence,thatspecifiedrequirementshavebeenfulfilled

Note1toentry: Verification is a set of activities that compares a system or system element against the requiredcharacteristics. This includes, but is not limited to specified requirements, design, descriptions, and the system itself. Thesystemwasbuiltright.

[SOURCE:ISO9000:2015,modified,Note1toentryadded.]

3.2 Abbreviated terms

CCB ConfigurationControlBoard

CM ConfigurationManagement

COTS Commercial‐Off‐The‐Shelf

FCA FunctionalConfigurationAudit

FOSS FreeandOpenSourceSoftware

GUI GraphicalUserInterface

NDI Non‐DevelopmentalItems

QA QualityAssurance

PCA PhysicalConfigurationAudit

PESTEL Political,Economic,Social,Technological,Environmental,andLegal

PMI ProjectManagementInstitute

PMP ProjectManagementPlan

PRM ProcessReferenceModel

SCM SoftwareConfigurationManagement

SDP SoftwareDevelopmentPlan

SEMP SystemsEngineeringManagementPlan

SOI System‐of‐Interest

SoS SystemofSystems

SWOT Strengths,Weaknesses,Opportunities,Threats

WBS WorkBreakdownStructure

4 Conformance

4.1 Intended usage

TherequirementsinthisdocumentarecontainedinClause6andAnnexA.Thisdocumentprovidesrequirementsforanumberofprocessessuitableforusageduringthelifecycleofasoftwaresystemorproduct.Itisrecognizedthat particular projects or organizationsmay not need to use all of the processes provided by this document.Therefore,implementationofthisdocumenttypicallyinvolvesselectinganddeclaringasetofprocessessuitableto the organization or project. There are twoways that an implementation can be claimed to conform to theprovisionsofthisdocument—fullconformanceandtailoredconformance.

Therearetwocriteriaforclaimingfullconformance.Achievingeithercriterionsufficesforconformance,althoughthechosencriterion(orcriteria)shallbestatedintheclaim.Claiming“fullconformancetotasks”assertsthatalloftherequirementsoftheactivitiesandtasksofthedeclaredsetofprocessesareachieved.Alternatively,claiming“full conformance to outcomes” asserts that all of the required outcomes of the declared set of processes are





achieved.Fullconformancetooutcomespermitsgreaterfreedomintheimplementationofconformingprocessesandcanbeusefulforimplementingprocessestobeusedinthecontextofaninnovativelifecyclemodel.

NOTE1 Optionsforconformanceareprovidedforneededflexibilityintheapplicationofthisdocument.Eachprocesshasasetofobjectives(phrasedas“outcomes”)andasetofactivitiesandtasksthatrepresentonewaytoachievetheobjectives.

NOTE2 Userswhoimplementtheactivitiesandtasksofthedeclaredsetofprocessescanassertfullconformancetotasksof theselectedprocesses.Someusers,however,mighthave innovativeprocessvariants thatachieve theobjectives (i.e., theoutcomes) of thedeclared set of processeswithout implementing all of the activities and tasks. Theseusers can assert fullconformanceto theoutcomesof thedeclaredsetofprocesses.Thetwocriteria—conformanceto taskandconformancetooutcome—arenecessarilynotequivalentsincespecificperformanceofactivitiesandtaskscanrequire,insomecases,ahigherlevelofcapabilitythanjusttheachievementofoutcomes.

NOTE3 When thisdocument isused tohelpdevelopanagreementbetweenanacquirer anda supplier, clauses of thisdocumentcanbeselectedforincorporationintheagreementwithorwithoutmodification.Inthiscase,itismoreappropriatefortheacquirerandsuppliertoclaimcompliancewiththeagreementthanconformancewiththisdocument.

NOTE4 Anorganization(forexample,national,industrialassociation,company)imposingthisdocument,asaconditionoftrade,canspecifyandmakepublic theminimumsetof requiredprocesses,outcomes,activities,and tasks,whichconstitutesuppliers’compliancewiththeconditionsoftrade.

NOTE5 Requirementsofthisdocumentaremarkedbytheuseoftheverb“shall”.Recommendationsaremarkedbytheuseof theverb “should".Permissionsaremarkedby theuseof theverb “may”.However,despite theverb that isused, therequirementsforconformanceareselectedasdescribedpreviously.

4.2 Full conformance

4.2.1 Full conformance to outcomes

Aclaimoffullconformancedeclaresthesetofprocessesforwhichconformanceisclaimed.Fullconformancetooutcomes is achieved by demonstrating that all of the outcomes of the declared set of processes have beenachieved. In this situation, theprovisions for activities and tasks of thedeclared set of processes are guidanceratherthanrequirements,regardlessoftheverbformthatisusedintheprovision.

One intendeduse of this document is to facilitate process assessment and improvement. For this purpose, theobjectivesofeachprocessarewrittenintheformof‘outcomes’compatiblewiththeprovisionsofISO/IEC33002.Thatstandardprovidesfortheassessmentoftheprocessesofthisdocument,providingabasisforimprovement.Usersintendingprocessassessmentandimprovementmayusetheprocessoutcomeswritteninthisdocumentasthe“processreferencemodel”requiredbyISO/IEC33002.

4.2.2 Full conformance to tasks

Aclaimoffullconformancedeclaresthesetofprocessesforwhichconformanceisclaimed.Fullconformancetotasks isachievedbydemonstratingthatallof therequirementsoftheactivitiesandtasksofthedeclaredsetofprocesseshavebeenachieved.Inthissituation,theprovisionsfortheoutcomesofthedeclaredsetofprocessesareguidanceratherthanrequirements,regardlessoftheverbformthatisusedintheprovision.

NOTE Aclaimoffullconformancetotaskscanbeappropriateincontractualsituationswhereanacquireroraregulatorrequiresdetailedunderstandingofthesuppliers’processes.

4.3 Tailored conformance

Whenthisdocumentisusedasabasisforestablishingasetofprocessesthatdonotqualifyforfullconformance,theclausesofthisdocumentareselectedormodifiedinaccordancewiththetailoringprocessprescribedinAnnexA.Thetailoredtext,forwhichtailoredconformanceisclaimed,isdeclared.Tailoredconformanceisachievedbydemonstratingthattheoutcomes,activities,andtasks,astailored,havebeenachieved.




5 Key concepts and application

5.1 Introduction

Thisclauseisincludedtohighlightandtohelpexplainessentialconceptsonwhichthisdocumentisbased.

NOTE Further elaboration of these concepts can be found in ISO/IEC TS 24748‐1, ISO/IEC TR 24748‐2, and ISO/IECTR24748‐3ontheapplicationoflifecyclemanagement.

5.2 Software system concepts

5.2.1 Software systems

Thesoftwaresystemsconsideredinthisdocumentarehuman‐made,createdandutilizedtoprovideproductsorservices in defined environments for the benefit of users and other stakeholders. These software systems canincludethefollowingsystemelements:hardware,software,data,humans,processes(e.g.,processesforprovidingservice to users), procedures (e.g., operator instructions), facilities, services,materials and naturally occurringentities.Asviewedbytheuser,theyarethoughtofasproductsorservices.

Thisdocumentapplies to systems forwhich software isofprimary importance to the stakeholders. It isbaseduponthegeneralprinciplesofsystemsengineeringandsoftwareengineering.Itisafundamentalpremiseofthisdocument that software always exists in the context of a system. Since software does not operate withouthardware, the processor upon which the software is executed can be considered as part of the system.Alternatively,hardwareorserviceshostingthesoftwaresystemandhandlingcommunicationswithothersystemscanalsobeviewedasenablingsystemsorexternalsystemsintheoperatingenvironment.

The perception and definition of a particular software system, its architecture, and its elements depend on astakeholder’s interests and responsibilities. One stakeholder’s system‐of‐interest can be viewed as a systemelement in another stakeholder’s system‐of‐interest. Furthermore, a system‐of‐interest can be viewed as beingpartoftheenvironmentforanotherstakeholder’ssystem‐of‐interest.

Thefollowingarekeypointsregardingthecharacteristicsofsystems‐of‐interest:

a) definedboundariesencapsulatemeaningfulneedsandpracticalsolutions;

b) thereisahierarchicalorotherrelationshipbetweensystemelements;

c) anentityatanylevelinthesystem‐of‐interestcanbeviewedasasystem;

d) asystemcomprisesanintegrated,definedsetofsubordinatesystemelements;

e) humanscanbeviewedasbothusersexternaltoasystemandassystemelements(i.e.,operators)withinasystem;and

f) asystemcanbeviewedinisolationasanentity,i.e.,aproduct;orasacollectionoffunctionscapableofinteractingwithitssurroundingenvironment,i.e.,asetofservices.

Whatever theboundaries chosen todefine the system, the concepts in thisdocumentaregeneric andpermitapractitionertocorrelateoradaptindividualinstancesoflifecyclestoitssystemprinciples.

5.2.2 Software system structure

Thelifecycleprocessesinthisdocumentaredescribedinrelationtoasoftwaresystemthatiscomposedofasetof interacting system elements (including software elements), each of which can be implemented to fulfill itsrespectivespecifiedrequirements(Figure1).Responsibility for the implementationofanysystemelementmaythereforebedelegatedtoanotherpartythroughanagreement.





Figure 1 — Software system and software system element relationship

The relationship between the software system and its complete set of system elements can typically berepresented showing relationships between the elements – often depicted as a hierarchy for the simplest ofsystems‐of‐interest. Decomposition is one approach to some software activities. Other approaches include theobject‐orientedapproach,wherethesystemelementsarelaidoutinaflat(non‐hierarchical)descriptionsuchasinanetworkdiagram.Formorecomplexsoftwaresystems‐of‐interest,aprospectivesystemelementmayneedtobeconsideredasasystem(thatinturniscomprisedofsystemelements)beforeacompletesetofsystemelementscanbedefinedwithconfidence(Figure2).Inthismanner,theappropriatesystemlifecycleprocessesareappliedrecursively to a system‐of‐interest to resolve its structure to the pointwhere understandable andmanageablesoftwaresystemelementscanbeimplemented(created,adapted,acquired,orreused).

Figure 2 —Example of software system-of-interest structure

WhileFigures1and2implyahierarchicalrelationship,inrealitythereareanincreasingnumberofsystemsthat,from one or more aspects, are not hierarchical, such as networks and other distributed systems. Annex Gdiscussestheconceptofasystemofsystems(SoS).

Software System-of-

Interest

Software System

System

System Element

System Element

System Element

System

Software System

Software System

Software System

Software Element

Software Element

Software Element

System Element

System Element

Software Element

System Software Element

System Element

System Element

Software Element

System Element

Software Element




NOTE Decomposition is an activity fundamental to many software activities. Not all decompositions imply thedesignation of new software system elements and the corresponding recursive application of the activity. Designation of adecomposed construct as an element is necessary only when it is appropriate to apply distinct requirements, design, orimplementationactivitiestoitsdevelopment.Oneexampleofanappropriatesituationiswhentheelementistobedevelopedbyadistinctorganization.Anotherexample iswhenmanagementdeterminesthat it isappropriatetodistinctlymonitorthestatusofthedevelopmentorcustomizationoftheelement.

5.2.3 Enabling systems

Throughoutthelifecycleofasystem‐of‐interest,essentialservicesarerequiredfromsystemsthatarenotdirectlya part of the operational environment of the system‐of‐interest, e.g., modelling system, training system,maintenancesystem.Eachofthesesystemsenablesapart,e.g.,astageofthelifecycleofthesystem‐of‐interesttobe conducted. Termed “enabling systems”, they facilitate progression of the system‐of‐interest through its lifecycle.

Therelationshipbetweentheservicesdeliveredtotheoperationalenvironmentbythesystem‐of‐interestandtheservicesdeliveredbytheenablingsystemstothesystem‐of‐interestisshowninFigure3.Enablingsystemscanbeseen tocontribute indirectly to theservicesprovidedby thesystem‐of‐interest.The interrelationshipsbetweenthe system‐of‐interest and the enabling systems can be bidirectional or a one‐way relationship. In addition tointeractingwith enabling systems, the system‐of‐interest can also interactwithother systems in the operatingenvironment,shownasSystemsA,B,andC.Requirementsforinterfaceswithenablingsystemsandothersystemsintheoperationalenvironmentareincludedintherequirementsforthesystem‐of‐interest.

Figure 3 —Software system-of-interest, its operational environment and enabling systems

Duringastageinthesoftwarelifecycle,therelevantenablingsystemsandthesystem‐of‐interestareconsideredtogether.Since theyare interdependent, theycanalsobeviewedasasystem.Whenasuitableenablingsystemdoesnot alreadyexist, theproject that is responsible for the system‐of‐interest canbedirectly responsible for

System B inoperationalenvironment

Software system Ain operationalenvironment

Enabling softwaresystem

X

Enabling system

Y

Enabling softwaresystem

Z

Software system-of-interest

Interaction withsystems comprising theoperational environment

Interaction with enabling

systems

Software system Cin operationalenvironment





creating andusing the enabling system.Creating the enabling system canbe viewed as a separate project andsubsequentlyasanothersystem‐of‐interest.

Furtherelaborationof theseconceptscanbe found in ISO/IEC/IEEE24748(allparts)ontheapplicationof lifecycleprocesses.

NOTE Enablingsystemsinsoftwaredevelopmentincludesoftwaredevelopmentandtestenvironmentsfortargetplatforms.

5.2.4 Life cycle processes for the software system

In the software system, the requirements, architecture, and design processes at the system level result in anallocation of the system requirements to various elements. The software system‐of‐interest is implementedprimarily by analyzing the software system requirements, architecture, and design and determining whichfunctionswillbeimplementedinsoftwareorbyotherelements,implementingthesoftwareandotherelements,andintegratingtheelementsasasoftwaresystem.Therefore,asoftwareproductorservicecanbetreatedasanelementofasoftwaresystem.

Insomecases,thearchitecturaldefinitionofasoftwaresystemcanindicatethatitisappropriatetoconsideritascomprising a set of distinct subordinate elements. In turn, each of the software elements can be treated as adistinct software system as described previously. In these cases, this documentmay be applied recursively toprocureordevelopthesubordinateelements.

This document has a strong relationship with ISO/IEC/IEEE 15288:2015, Systems and Software Engineering--System Life Cycle Processes, and ismoreapplicable tosoftwaresystems.Toaccount for situations inwhichbothISO/IEC/IEEE15288:2015andISO/IEC/IEEE12207:2017areapplied(e.g.,adevelopmentofasystemcontainingsoftware,orthedevelopmentofasoftwaresystemcontaininghardware),theirprocessstructuresareharmonizedto be identical. The processes of this document directly correspond to processes of ISO/IEC/IEEE 15288withspecializationforsoftwareproductsandservices.

In the casewhere the systemnon‐software elementshaveprimary importance, an organizationmaydecide toapplyISO/IEC/IEEE15288toperformtheappropriatelifecycleprocesses,activitiesandtasks.Foreachsoftwareelementofthesystem,theorganizationmayapplythisdocumenttocreate,adapt,acquire,orreusethesoftwareelements.

5.3 Organization and project concepts

5.3.1 Organizations

When an organization, as a whole or a part, enters into an agreement, it is sometimes called a “party” to theagreement.Partiescanbefromthesameorganizationorfromseparateorganizations.Anorganizationcanbeassmallasasingleindividual,iftheindividualisassignedresponsibilitiesandauthorities.

In informal terms, theorganization that is responsible for executing aprocess is sometimes referred toby thename of that process. For example, the organization executing theAcquisition process is sometimes called the“acquirer”.Otherexamplesincludesupplier,implementer,maintainer,andoperator.

Afewothertermsareappliedtoorganizationsinthisdocument:“user”canbetheorganizationorindividualsthatdirectlyengagewithorbenefit fromtheutilizationof theproductorservice; “customer”refers to theuserandacquirercollectively;and“stakeholder”referstoanindividualororganizationwithaninterestinthesystem.

Theprocessesandorganizationsareonlyrelatedfunctionally.Thisdocumentdoesnotdictateorimplyastructurefor an organization, nor does it specify that particular processes are to be executed by particular parts of theorganization. It is the responsibility of the organization that implements this document to define a suitablestructurefortheorganizationandassignappropriaterolesfortheexecutionofprocesses.

Theprocessesinthisdocumentformacomprehensivesettoservevariousorganizations.Anorganization,smallor large, depending on its business purpose or its acquisition strategy, can select an appropriate set of theprocesses(andassociatedactivitiesandtasks)tofulfillthatpurpose.Anorganizationcanperformoneprocessormorethanoneprocess.




Thisdocumentisintendedtobeappliedbyanorganizationinternallyorexternallybytwoormoreorganizations.Whenappliedinternally,thetwoagreeingpartiestypicallyactunderthetermsofanagreementthatmayvaryinformalityunderdifferentcircumstances.Whenappliedexternally,thetwoagreeingpartiestypicallyactunderthetermsofacontract.Thisdocumentusestheterm“agreement”toapplytoeithersituation.

Forthepurposeofthisdocument,anyprojectisassumedtobeconductedwithinthecontextofanorganization.Thisisimportant,becauseaprojectisdependentuponvariousoutcomesproducedbythebusinessprocessesofthe organization, e.g., employees to staff the project and facilities to house the project. For this purpose, thisdocumentprovidesasetof“OrganizationalProject‐Enabling”processes.Theseprocessesarenotassumedtobeadequate to operate a business; instead the processes, considered as a collection, are intended to state theminimumsetofdependenciesthattheprojectplacesupontheorganization.

5.3.2 Organization and project-level adoption

Modernbusinessesstrivetodeveloparobustsetoflifecycleprocessesthatareappliedrepeatedlytotheprojectsand services of the business. Therefore, this document is intended to be useful for adoption at either theorganization level or at the project level. An organization can adopt the document and supplement it withappropriateprocedures,practices,toolsandpolicies. Inturn,aprojectoftheorganizationtypicallyconformstotheorganization’sprocessesratherthanconformingdirectlytothisdocument.

Insomecases,projectsmaybeexecutedbyanorganizationthatdoesnothaveanappropriatesetofprocessesadopted at the organizational level. Such a project may apply the provisions of this document directly to theproject.

5.4 Life cycle concepts

5.4.1 Software life cycle stages

Lifecyclesvaryaccordingtothenature,purpose,useandprevailingcircumstancesofthesoftwaresystem.Usingstages concurrently and indifferentorders can lead to life cycle formswithdistinctly different characteristics.Eachstagehasadistinctpurposeandcontributiontoplanningandexecutingthewholelifecycleofthesoftwaresystem.Per ISO/IECTS24748‐1, the typical system life cycle stages include concept,development,production,utilization,support,andretirement.Useofthesetermstodefinestagesisnotnormative.Acommonsetofstagesforasoftwaresystemisconceptexploration,development,sustainment,andretirement,withtransitionsbetweenstagesforthesystemasawholeandforitselements.

Thestagesrepresentthemajorlifecycleperiodsassociatedwithasoftwaresystemandtheyrelatetothestateofthe software system description or the software system itself. The stages describe the major progress andachievementmilestonesofthesoftwaresystemthroughitslifecycle.Theygiverisetotheprimarydecisiongatesof the life cycle. These decision gates are used by organizations to understand and manage the inherentuncertainties and risks associatedwith costs, schedule and functionalitywhen creating or utilizing a softwaresystem.Usingstagesthusprovidesorganizationswithaframeworkwithinwhichorganizationmanagementhashigh‐level visibility and control of project and technical processes. Organizations define and employ stagesdifferentlytosatisfycontrastingbusinessandriskmitigationstrategies.

Thelifecycleprocessesdefinedinthisdocumentarenotalignedtoanyspecificstageinasoftwarelifecycle.Allofthelifecycleprocessesinvolveplanning,performance,andevaluationactivitiesthatshouldbeconsideredforuseateverystage.

Furtherelaborationoftheseconceptscanbe foundinISO/IEC/IEEE24748(allparts),ontheapplicationof lifecyclemanagement.

5.4.2 Life cycle model for the software system

Every software system has a life cycle. A life cycle can be described using an abstract functional model thatrepresentstheconceptualizationofaneedforthesystem,itsrealization,utilization,evolutionanddisposal.

Asoftwaresystemprogressesthroughitslifecycleastheresultofactions,performedandmanagedbypeopleinorganizations, usingprocesses for execution of these actions. Thedetail in the life cyclemodel is expressed intermsoftheseprocesses,theiroutcomes,relationshipsandsequence.





Thisdocumentdoesnotprescribeanyparticularlifecyclemodel.Insteaditdefinesasetofprocesses,termedlifecycle processes, which can be used in the definition of the system’s life cycle. Also, this document does notprescribe any particular sequence of processes within the life cycle model. The sequence of the processes isdetermined by project objectives and by selection of the life cycle model. Often, the development stage issubdividedmorefinelyandindifferentways.

Oneoft‐citedsetofsoftwaredevelopmentstagesareelicitation,requirements,design,construction,andtesting‐the predictive or “waterfall” model. If the stages are considered as sequential, then each stage is required toproducecorrectresultsbeforeproceedingtothenextstage.Inpractice,thisisextremelydifficulttoachieveunlesstherequirementsareknownwellandtheinitialcostestimatesareaccurate.Inperformingawaterfall,onerisksperformingextensivereworkthatdoesnotproperlyfallwithinanyoftheplannedstages,henceprobablydoesnotfallwithinanybudget.

NOTE1 Winston Royce, commonly recognized as an early analyst of life cycle processmodels, described the need forreworkstagesratherthanthe“waterfall”(atermthathedidnotuse).Unfortunately,thereworkstagesweredroppedfromthe“waterfall”modelasitwaspopularlyunderstood.

Todealwiththeissuesofincompletelyknownrequirementsandinaccurateestimates,anumberofothertypesofmodelshavebeenproposed: incremental, spiral, iterative, and evolutionary (adaptive).These life cyclemodelscan incorporateagile techniquesandmethods.Thesemodelscan typically involverepeatedperformanceof thelifecycleprocessesandstagesduringthelifecycle,e.g.,fordifferentincrementsofthesoftwareproduct,formoreprecisehandlingofexceptionstocommonfunctions,orforrequirementsthatwerenotfullydefinedattheoutset.Thesemodels can be applied across stages, such as development and utilization or deployment. Use of thesemodelscanaffectsoftwarereleasestrategiesandacquisitionstrategiesforsoftwareservices.

EXAMPLE Softwareelementscanbedevelopedincrementally,andthenheldforblockoperationalreleaseataconvenienttimeintheorganization’sbusinesscycle.

The“incrementaldevelopment”modelincludesinitialplanning,initialrequirementsanalysis,initialarchitecturaldefinition, and initial validation, but allocates design, implementation, verification (and sometimes delivery)activities to a series of stages, each of which provides a portion of the intended functionality. The approachprovidesforsomeflexibilitytorespondtoinaccuratecostorscheduleestimatesbymovingfunctionalitytolaterincrements.

The“spiral”variationonincrementaldevelopmentalproposesorderingthedevelopmentoffunctionalitybasedonrisk,with the riskiestproblemsconsidered in theearly increments.Thisprovides someprotectionagainstcostsurprisesoccurringlateinthedevelopmentcycle.

The“iterativedevelopment”modelperformsinitialplanningandthenconsistsofacyclicprocessofprototyping,testing,analyzingandrefiningtherequirementsandthesolution.“Iterative”modelsrepeatedlyperformthelifecycle processes to deliver prioritized system functions sooner, with refined ormore complex elements of thesystemcominginlateriterations.

The“evolutionarymodel” is intendedtodealwithincompleteknowledgeofrequirements. Itprovidesfor initialplanningandinitialarchitecturedefinition,butallocatesrequirementsanalysis,design,construction,verification,validationanddeliverytoaseriesofstages.Deliveredcapabilitiesthatdonotmeetuserneedscanbereworkedinsubsequentstagesoftheevolution.

“Agile”methodsactuallycanbeappliedwithinavarietyofmodels.WhileAgilemethodsarecommoninexecutinganevolutionary lifecyclemodel, theycanbeused inother lifecyclemodelsatvariousstages.Whatthemethodshave incommonisanemphasisoncontinuous inspectionandcollaboration intherapidproductionofworkingsoftwareinanenvironmentwherechanges, includingchangestorequirements,areexpected.AnnexHprovidesinformationontheapplicationofthisdocumentinanagilecontext.

NOTE2 Selectingthenameofatypeofmodeldoesnotsatisfytherequirementtodefineamodelcomprisedofstages,withdefinedpurposeandoutcomesaccomplishedviatheprocessesofthisdocument.

NOTE3 ISO/IECTS24748‐1, ISO/IECTR24748‐2, ISO/IECTR24748‐3, and ISO/IEC/IEEE24748‐4provide additionaldetailregardinglifecyclemodelsandstages.ThemodelsdescribedinthisclauseapplynotonlytosoftwaresystemsbutalsotoothersystemsasdescribedinISO/IEC/IEEE15288:2015.




5.5 Process concepts

5.5.1 Criteria for processes

Thedeterminationofthelifecycleprocessesinthisdocumentisbaseduponthreebasicprinciples:

1) Eachlifecycleprocesshasstrongrelationshipsamongitsoutcomes,activitiesandtasks.

2) Thedependenciesamongtheprocessesarereducedtothegreatestfeasibleextent.

3) Aprocessiscapableofexecutionbyasingleorganizationinthelifecycle.

5.5.2 Description of processes

Eachprocessofthisdocumentisdescribedintermsofthefollowingattributes:

a) Thetitleconveysthescopeoftheprocessasawhole.

b) Thepurposedescribesthegoalsofperformingtheprocess.

c) Theoutcomesexpresstheobservableresultsexpectedfromthesuccessfulperformanceoftheprocess.

d) Theactivitiesaresetsofcohesivetasksofaprocess.

e) The tasks are requirements, recommendations, or permissible actions intended to support theachievementoftheoutcomes.

Theprocesses andprocess groups in thisdocument are identical in theirpurpose andoutcomeswith those inISO/IEC/IEEE15288:2015,System and software engineering – System life cycle processes,withoneexception: theSystem/SoftwareRequirementsDefinitionprocessof thisdocument is renamed fromtheSystemRequirementsDefinition process of ISO/IEC/IEEE 15288:2015. To emphasize this harmonization of systems and softwaresystemprocesses,theprocesspurposesandoutcomesarepresentedinboxesinClause6.

Software‐specificactivities,tasks,andworkproductsareappliedtoachievetheoutcomesoftheprocessesinthisdocument.AnnexEprovidesadditionalprocessviews.

AdditionaldetailregardingthisformofprocessdescriptioncanbefoundinISO/IECTR24774.

5.5.3 General characteristics of processes

Inadditiontothebasicattributesdescribedintheprevioussubclause,processesmaybecharacterizedbyotherattributescommontoallprocesses.ISO/IEC33020:2015identifiescommonprocessattributesthatcharacterizesix levels of achievementwithin ameasurement framework forprocess capability.AnnexC includes the listofprocessattributesthatcontributetotheachievementofhigherlevelsofprocesscapabilityasdefinedinISO/IEC33020:2015.

5.5.4 Tailoring

Annex A, which is normative, defines the basic activities needed to perform tailoring. Note that tailoringmaydiminishtheperceivedvalueofaclaimofconformancetothisdocument.This isbecauseit isdifficult forotherorganizationstounderstandtheextenttowhichtailoringmayhavedeleteddesirableprovisions.Anorganizationasserting a single‐party claim of conformance to this document may find it advantageous to claim fullconformancetoasmallerlistofprocessesratherthantailoredconformancetoalargerlistofprocesses.

5.6 Process groups

5.6.1 Introduction

Thisdocument groups the activities that canbeperformedduring the life cycleof a software system into fourprocess groups. Each of the life cycle processes within those groups is described in terms of its purpose and





desiredoutcomeswithasetofrelatedactivitiesandtasksthatcanbeperformedtoachievethoseoutcomes.ThefourprocessgroupsandtheprocessesincludedineachgrouparedepictedinFigure4asfollows:

a) Agreementprocesses;

b) OrganizationalProject‐EnablingProcesses;

c) TechnicalManagementProcesses;and

d) TechnicalProcesses.

The processes described in this document are not intended to preclude or discourage the use of additionalprocesses thatorganizations finduseful.Theorderof thesubclauses inwhich theprocessesaredefined in thisdocumentdoesnotdeterminetheorderinwhichtheprocessesareperformedduringthesystemlifecycleoranyofitsstages.Adescriptionofeachprocessgroupisprovidedinthefoursubclausesthatfollow.




Figure 4 —Software life cycle processes

5.6.2 Agreement processes

Organizations are producers and users of software systems. One organization (acting as an acquirer) can taskanother(actingasasupplier)forproductsorservices.Thisisachievedusingagreements.Agreementsallowbothacquirersandsupplierstorealizevalueandsupportbusinessstrategiesfortheirorganizations.

TheAgreementprocessesareorganizationalprocessesthatapplyoutsideofthespanofaproject’slife,aswellasforaproject’slifespan.Generally,organizationsactsimultaneouslyorsuccessivelyasbothacquirersandsuppliersofsoftwaresystems.TheAgreementprocessescanbeusedwithlessformalitywhentheacquirerandthesupplierare in the same organization. Similarly, they can be used within the organization to agree on the respective

Information Management Process

(Clause 6.3.2)

Project

Processes

Human Resource

Project Portfolio

Infrastructure

(Clause 6.2.1)

Project - Enabling

Software Life Cycle Processes

Information Management Process

(Clause 6.3.2)

Project

Processes

Project Portfolio

(Clause 6.2.3)

Infrastructure

Life Cycle Model

Technical Processes

Measurement Process (6.3.7)

Information Management Process (6.3.6)

Configuration Management Process (6.3.5)

Risk Management Process (6.3.4)

Decision Management Process (6.3.3)

Project Assessment and Control Process (6.3.2)

Project Planning Process (6.3.1)

Technical Management Processes

Quality Management Process (6.2.5)

Human Resource Management Process (6.2.4)

Portfolio Management Process (6.2.3)

Life Cycle Model Management Process (6.2.1)

Infrastructure Management Process (6.2.2)

Organizational Project-Enabling

Processes

Supply Process (6.1.2)

Agreement Processes

Knowledge Management Process (6.2.6)

Quality Assurance Process (6.3.8)

Architecture Definition Process (6.4.4)

Design Definition Process (6.4.5)

Stakeholder Needs andRequirements Definition Process

(6.4.2)

Maintenance Process (6.4.13)

Operation Process (6.4.12)

Validation Process (6.4.11)

Transition Process (6.4.10)

Verification Process (6.4.9)

Integration Process (6.4.8)

Implementation Process (6.4.7)

System Analysis Process (6.4.6)

Disposal Process (6.4.14)

Business or Mission Analysis Process (6.4.1)

Acquisition Process (6.1.1)

Systems/Software Requirements Definition Process (6.4.3)





responsibilities of organization, project and technical functions. Figure4 lists the processes contained in thisprocessgroup.

5.6.3 Organizational project-enabling processes

TheOrganizationalProject‐Enablingprocessesareconcernedwithprovidingtheresourcestoenabletheprojectto meet the needs and expectations of the organization’s stakeholders. The Organizational Project‐Enablingprocessesaretypicallyconcernedatastrategiclevelwiththemanagementandimprovementoftheorganization’sbusinessorundertaking,withtheprovisionanddeploymentofresourcesandassets,andwithitsmanagementofrisksincompetitiveoruncertainsituations.TheOrganizationalProject‐Enablingprocessesapplyoutsidethespanofaproject’slife,aswellasduringaproject’slifespan.

TheOrganizationalProject‐Enablingprocesses establish the environment inwhichprojects are conducted.Theorganization establishes the processes and life cycle models to be used by projects; establishes, redirects, orcancelsprojects;providesresourcesrequired, includinghumanandfinancial;andsetsandmonitorsthequalitymeasures for software systemsandotherdeliverables that aredevelopedbyprojects for internal andexternalcustomers.

TheOrganizationalProject‐Enablingprocessescreateastrongbusinessimageformanyorganizationsandimplycommercialandprofit‐makingmotives.Nevertheless, theOrganizationalProject‐Enablingprocessesareequallyrelevanttonon‐profitorganizations,sincetheyarealsoaccountabletostakeholders,areresponsibleforresources,andencounterriskintheirundertakings.Thisdocumentcanbeappliedtonon‐profitorganizationsaswellastoprofit‐makingorganizations.Figure4liststheprocessescontainedinthisprocessgroup.

5.6.4 Technical Management processes

The Technical Management processes are concerned with managing the resources and assets allocated byorganization management and with applying them to fulfill the agreements into which the organization ororganizationsenter.TheTechnicalManagementprocessesrelatetothetechnicaleffortofprojects,inparticulartoplanningintermsofcost,timescalesandachievements,tothecheckingofactionstohelpensurethattheycomplywith plans and performance criteria and to the identification and selection of corrective actions that recovershortfallsinprogressandachievement.Theseprocessesareusedtoestablishandperformtechnicalplansfortheproject, manage information across the technical team, assess technical progress against the plans for thesoftwaresystem,products,orservices,controltechnicaltasksthroughtocompletion,andaidindecision‐making.

NOTE1 Technicalmanagementis‘theapplicationoftechnicalandadministrativeresourcestoplan,organizeandcontrolengineeringfunctions’.(ISO/IEC/IEEE24765:2010)

Typically, several projects will co‐exist in any one organization. The Technical Management processes can beemployedatacorporateleveltomeetinternalneeds.Figure4liststheprocessescontainedinthisprocessgroup.

NOTE2 TechnicalManagementprocessesareappliedduringtheperformanceofeachTechnicalprocess.

5.6.5 Technical processes

The Technical processes are concerned with technical actions throughout the life cycle. Technical processestransformtheneedsofstakeholdersintoaproductorservice.Byapplyingthatproductoroperatingthatservice,technicalprocesses,providesustainableperformance,whenandwhereneededinordertomeetthestakeholderrequirementsandachievecustomersatisfaction.TheTechnicalprocessesareappliedinordertocreateanduseasoftwaresystem,whetheritisintheformofamodelorisanoperationalproduct.TheTechnicalprocessesapplyat any level in a hierarchy of software system structure and at any stage in the life cycle. Figure4 lists theprocessescontainedinthisprocessgroup.

5.7 Process application

Thelifecycleprocessesdefinedinthisdocumentcanbeusedbyanyorganizationwhenacquiring,using,creating,orsupplyingasoftwaresystem.Theycanbeappliedatanylevelinasystem’shierarchyandatanystageinthelifecycle.

Thefunctionstheseprocessesperformaredefinedintermsofspecificpurposes,outcomesandthesetofactivitiesandtasksthatconstitutetheprocess.




EachlifecycleprocessinFigure4canbeinvoked,asrequired,atanytimethroughoutthelifecycle.Theorderthatthe processes are presented in this document does not imply any prescriptive order in their use. However,sequentialrelationshipsareintroducedbythedefinitionofalifecyclemodel.Thedetailedpurposeandtimingofuse of these processes throughout the life cycle are influenced by multiple factors, including social, trading,organizational and technical considerations, each of which can vary during the life of a software system. Anindividualsoftware lifecycle is thuscreatedthroughaselectionandapplicationofprocessesthatwillnormallypossessconcurrent,iterative,recursiveandtime‐dependentcharacteristics.

Concurrent use of processes can exist within a project (e.g., when design actions and preparatory actions forbuildingasoftwaresystemareperformedatthesametime),andbetweenprojects(e.g.,whensystemelementsaredesignedatthesametimeunderdifferentprojectresponsibilities).

Whentheapplicationofthesameprocessorsetofprocessesisrepeatedonthesamesystem,theapplicationisreferred to as iterative. The iterative use of processes is important for the progressive refinement of processoutputs, e.g., the interaction between successive verification actions and integration actions can incrementallybuild confidence in the conformance of the product. Iteration is not only appropriate but also expected. Newinformation is createdby the applicationof aprocess or set of processes. Typically, this information takes theform of questions with respect to requirements, analyzed risks or opportunities. Such questions should beresolvedbeforecompletingtheactivitiesofaprocessorsetofprocesses.

Therecursiveuseofprocesses, i.e., therepeatedapplicationof thesameprocessorsetofprocessesapplied tosuccessivelevelsofsystemelements inasystem’sstructure, isakeyaspectoftheapplicationofthisdocument.Theoutputsofprocessesatanylevel,whetherinformation,artifactsorservices,areinputstotheprocessesusedatthelevelbelow(e.g.,duringtopdowndesign)oratthelevelabove(e.g.,duringsoftwaresystemrealization).Theoutcomesfromoneapplicationareusedasinputstothenextlower(orhigher)systeminthesystemstructuretoarriveatamoredetailedormaturesetofoutcomes.Suchanapproachaddsvaluetosuccessivesystemsinthesystemstructure.

The changing nature of the influences on the software system (e.g., operational environment changes, newopportunities for system element implementation, modified structure and responsibilities in organizations)requirescontinualreviewoftheselectionandtimingofprocessuse.Processuseinthelifecyclecanbedynamic,responding to the many external influences on the software system. The life cycle approach also allows forincorporatingthechangesinthenextstage.Thelifecyclestagesassisttheplanning,executionandmanagementoflifecycleprocessesinthefaceofthiscomplexityinlifecyclesbyprovidingcomprehensibleandrecognizablehigh‐levelpurposeandstructure.Thesetofprocesseswithina lifecyclestageareappliedwith thecommongoalofsatisfyingtheexitcriteriaforthatstageortheentrycriteriaoftheformalprogressreviewswithinthatstage.

Thediscussioninthissectiononiterativeandrecursiveuseofsoftwarelifecycleprocessesisnotmeanttoimplyanyspecifichierarchical,vertical,orhorizontalstructureforthesystem‐of‐interest,enablingsystem,organization,orproject.

Wherejustifiedbyproductqualityrisks,detaileddescriptionsofprocessinstancesinthecontextofthespecificproductmayalsobecreated.Instantiationofprocessesinvolvesidentifyingspecificsuccesscriteriaforaprocessinstance, derived from the product requirements, and identifying the specific activities and tasks needed toachieve thesuccesscriteria,derived fromtheactivitiesand tasks identified in thisdocument.Creatingdetaileddescriptions of process instances enables bettermanagement of product quality risks by establishing the linkbetweentheprocessandthespecificproductrequirements.

Furtherelaborationof theseconceptscanbe found in ISO/IEC/IEEE24748(allparts)ontheapplicationof lifecycleprocesses.

5.8 Process reference model

Annex C defines a process reference model (PRM) at a level of abstraction higher than that of the detailedrequirementscontained inClause6.ThePRM isapplicable toanorganization that isassessing itsprocesses inordertodeterminethecapabilityoftheseprocesses.Thepurposeandoutcomesareastatementofthegoalsoftheperformanceofeachprocess.Thisstatementofgoalspermitsassessmentoftheeffectivenessoftheprocessesinwaysotherthansimpleconformityassessment.

NOTE In this document, the term “process reference model” is used with the same meaning as ISO/IEC 33001:2015:“modelcomprisingdefinitionsofprocesses inadomainofapplicationdescribedintermsofprocesspurposeandoutcomes,togetherwithanarchitecturedescribingtherelationshipsbetweentheprocesses”.





6 Software life cycle processes

6.1 Agreement processes

This subclause specifies the requirements for the establishment of agreements with organizational entitiesexternalandinternaltotheorganization.

TheAgreementprocessesconsistofthefollowing:

a) Acquisitionprocess–usedbyorganizationsforacquiringproductsorservices;and

b) Supplyprocess–usedbyorganizationsforsupplyingproductsorservices.

These processes define the activities necessary to establish an agreement between two organizations. If theAcquisitionprocess is invoked, itprovidesthemeansforconductingbusinesswithasupplier.Thismay includeproductsthataresuppliedforuseasanoperationalsoftwaresystem,servicesinsupportofoperationalactivities,software elements of a system, or elements of a software system being provided by a supplier. If the Supplyprocess is invoked, it provides themeans for an agreement inwhich the result is a product or service that isprovidedtotheacquirer.

NOTE Security isan increasingconcern insystemsandsoftwareengineering.See ISO/IEC27036,Security techniques - Information security for supplier relationships, for requirements and guidance for suppliers and acquirers on how to secureinformationinsupplierrelationships.SpecificaspectsofinformationsecuritysupplierrelationshipsareaddressedinISO/IEC27036‐3:2013andISO/IEC27036‐4(indevelopment).

6.1.1 Acquisition process

6.1.1.1 Purpose

The purpose of the Acquisition process is to obtain a product or service in accordance with the acquirer’srequirements.

NOTE Aspartofthisprocess,theagreementismodifiedwhenachangerequestaffectingthetermsoftheagreementisagreedtobyboththeacquirerandsupplier.

6.1.1.2 Outcomes

AsaresultofthesuccessfulimplementationoftheAcquisitionprocess:

a) Arequestforsupplyisprepared.

b) Oneormoresuppliersareselected.

c) Anagreementisestablishedbetweentheacquirerandsupplier.

d) Aproductorservicecomplyingwiththeagreementisaccepted.

e) Acquirerobligationsdefinedintheagreementaresatisfied.

6.1.1.3 Activities and tasks

TheacquirershallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheAcquisitionprocess.

NOTE1 Theactivitiesandresultingagreement fromthisprocessoftenapply tosuppliers in thesupplychain, includingsubcontractedsuppliers.

NOTE2 IEEEStd1062‐2015,IEEE Recommended Practice for Software Acquisition,containsdetailedactivitiesforsoftwareacquisition alternatives, including custom‐developed, off‐the‐shelf, and software as a service. IEEE Std 1062‐2015 alsoprovides software acquisition guidance for technical data rights and intellectual property considerations, for consideration




whensafetyassuranceorinformationsecurityrequirementsareofconcern,andchecklistsofrelevantissuesfororganizationalconsiderationwhenestablishingsoftwareacquisitionprocesses.

a) Prepare for the acquisition. Thisactivityconsistsofthefollowingtasks:

1) Defineastrategyforhowtheacquisitionwillbeconducted.

NOTE1 Thisstrategydescribesorreferencesthelifecyclemodel,risksandissuesmitigation,ascheduleofmilestones,and selection criteria if the supplier is external to the acquiring organization. It also includes key drivers andcharacteristicsoftheacquisition,suchasresponsibilitiesandliabilities;specificmodels,methods,orprocesses;levelofcriticality;formality;andpriorityofrelevanttradefactors.

NOTE2 TheDecisionManagementprocessandSystemAnalysisprocessareoftenused to support trade‐offs for theacquisitionstrategy.Examplesinclude:determiningamakeorbuydecision,aswellasthesuitabilityofspecificCOTSormodifiedOTSsolutionsandsupplierevaluation.

NOTE3 If the strategy calls for acquisition of specific commercial‐off‐the‐shelf software or open source software,acquisitioncanbe limitedto identifyingthesupplier,acceptingornegotiatingtheconditions inapre‐definedlicenseorleaseormaintenanceagreement,determiningrightstointellectualpropertyanddatarightsinthesoftwaresystem,andagreeingontheprice.

NOTE4 Afactortoconsiderinagreementsbetweensuppliersisdatarightsandlateralaccesstoconstituentdataandintellectual property. As an example, suppliers for one system componentmay need to collaboratewith suppliers foranothercomponentandsharesourcecode.Agreementscanenablethiscollaboration.

2) Preparearequestforthesupplyofaproductorservicethatincludestherequirements.

NOTE1 If a supplier is external to the organization, then the request includes the business practices withwhich asupplierisexpectedtocomplyandthecriteriaforselectingasupplier.

NOTE2 Adefinitionofrequirementsisprovidedtooneormoresuppliers.Therequirementsarethestakeholderorthesystem/software requirements, depending on the type of acquisition approach, andusing the associated requirementsdefinitionprocess.

NOTE3 Theacquirerdevelopstherequirementsbyitselforretainsasuppliertodevelopthem.Iftheacquirerretainsasuppliertodeveloprequirements,theacquirerretainsapprovalauthorityfortherequirementsdevelopedbythesupplier.

b) Advertise the acquisition and select the supplier.Thisactivityconsistsofthefollowingtasks:

1) Communicatetherequestforthesupplyofaproductorservicetopotentialsuppliers;and

2) Selectoneormoresuppliers.

NOTE To obtain competitive solicitations, proposals to supply are evaluated and compared against the selectioncriteriaandranked.Thejustificationforratingeachproposalisdeclaredandsupplierscommonlyareinformedwhytheywereorwerenotselected.

c) Establish and maintain an agreement.Thisactivityconsistsofthefollowingtasks:

NOTE Projectcost,schedule,andperformancearemonitoredthroughtheProjectAssessmentandControlprocess.Anyidentifiedissuesthatrequireagreementmodificationsarereferredtothisactivity.Anyproposalsforchangestosystemelements or information are controlled through the Change Management activity of the Configuration Managementprocess.

1) Developanagreementwiththesupplierthatincludesacceptancecriteria.

NOTE1 Thisagreementrangesinformalityfromawrittencontracttoaverbalagreement.Appropriatetothelevelofformality, the agreement establishes requirements, development and delivery milestones, verification, validation andacceptance conditions, exception‐handling procedures, agreement change management procedures, and paymentschedules,sothatbothpartiesoftheagreementunderstandthebasisforexecutingtheagreement.Otherprovisionsforagreements include rights and restrictions associated with technical data and intellectual property, acceptance testpreparation and test environment details; and the extent of supplier involvement. The agreement identifies processrequirementsthatneedtobeimposedonparticipatingsubcontractors,suchasconfigurationmanagementrequirements,reportingofrisks,andreportingofmeasuresandmeasurementanalysis.





NOTE2 Acceptancecriteria,suchasacceptancetesting,relatetohowtheproductorservicewillsatisfyitsintendeduseinitsoperationalenvironment.AcceptancetestingcanbeperformedusingtheValidationprocess.Exceptionsthatariseduringtheconductoftheagreementorwiththedeliveredproductorserviceareresolvedaccordingtotheproceduresestablishedintheagreement.

2) Identifynecessarychangestotheagreement.

NOTE Inrequestingachangetotheagreement, theacquirerorthesupplierdetails itsspecifications,rationale,andbackground.

3) Evaluateimpactofchangesontheagreement.

NOTE Anychangeisinvestigatedforimpactstoprojectplans,schedule,cost,technicalcapability,andquality.Achangecan be handled within the existing agreement, can require a modification to the agreement, or can require a newagreement.

4) Negotiatetheagreementwiththesupplier.

NOTE Agreement terms are negotiated between the acquirer and supplier. Negotiation occurs for the initialagreement,andasrequiredforanychanges.Changedagreementsarebasedontherequiredchangeandidentifiedimpacts.Details are discussed and changed during negotiation, after which the acquirer and supplier accept the terms of anagreementandtheagreementcommences.Forawrittencontract,thisoccurswhenthecontractissignedorasspecifiedintheagreement.

5) Updatetheagreementwiththesupplier,asnecessary.

NOTE1 The result of the agreement modification is incorporated into the project plans and communicated to allaffectedparties.

NOTE2 Agreements can specify the conditions underwhich the agreementwill be terminated by either party, e.g.,unexpectedchangesinstrategyoravailablefunding,orlackofsatisfactoryprogress.

d) Monitor the agreement. Thisactivityconsistsofthefollowingtasks:

1) Assesstheexecutionoftheagreement.

NOTE1 This includesconfirmationthatallpartiesaremeetingtheirresponsibilitiesaccordingtotheagreement.TheProject Assessment and Control process is used to evaluate projected cost, schedule, performance, and the impact ofundesirableoutcomesontheorganization.Thisinformationiscombinedwithotherassessmentsoftheexecutionofthetermsoftheagreement.Ifexecutionoftheagreementdoesnotresultinanacceptableproductorservice,theacquirerorsuppliercanterminatetheagreementasallowedinitsterms.

NOTE2 AcceptancetestingcanbeperformedusingtheValidationprocess.Exceptionsthatariseduringtheconductofthe agreement or with the delivered product or service are resolved according to the procedures established in theagreement.

2) Providedataneededbythesupplierandresolveissuesinatimelymanner.

e) Accept the product or service. Thisactivityconsistsofthefollowingtasks:

1) Confirmthatthedeliveredproductorservicecomplieswiththeagreement.

NOTE If the agreed requirements are satisfied and the acceptance criteria are met, the supplier has fulfilled itsobligation.Unaddressedexceptions,e.g.,disputesoverconductofacceptancetestingorproductsuitability for intendeduse,areamatterforagreementprovisionsrelatingtodisputes,arbitrationorapplicablelawandregulation.

2) Providepaymentorotheragreedconsideration.

3) Accepttheproductorservicefromthesupplier,orotherparty,asdirectedbytheagreement.

4) Closetheagreement.

NOTE TheprojectisclosedbythePortfolioManagementprocess.




6.1.2 Supply process

6.1.2.1 Purpose

The purpose of the Supply process is to provide an acquirer with a product or service that meets agreedrequirements.

NOTE Aspartof thisprocess, theagreement ismodifiedwhena changerequestaffecting the termsof theagreement isagreedtobyboththeacquirerandsupplier.

6.1.2.2 Outcomes

AsaresultofthesuccessfulimplementationoftheSupplyprocess:

a) Anacquirerforaproductorserviceisidentified.

b) Aresponsetotheacquirer’srequestisproduced.

c) Anagreementisestablishedbetweentheacquirerandsupplier.

d) Aproductorserviceisprovided.

e) Supplierobligationsdefinedintheagreementaresatisfied.

f) Responsibilityfortheacquiredproductorservice,asdirectedbytheagreement,istransferred.


ThesuppliershallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheSupplyprocess.

a) Prepare for the supply.Thisactivityconsistsofthefollowingtasks:

1) Determinetheexistenceandidentityofanacquirerwhohasaneedforaproductorservice.

NOTE ThisisoftengeneratedthroughtheBusinessorMissionAnalysisprocess.Foraproductorservicedevelopedforconsumers,anagent,e.g.,amarketingfunctionwithinthesupplierorganization,oftenrepresentstheacquirer.

2) Defineasupplystrategy.

NOTE This strategy describes or references the life cycle model, risks and issues mitigation, and a schedule ofmilestones. It also includes key drivers and characteristics of the acquisition, such as responsibilities and liabilities;specificmodels,methods,orprocesses;levelofcriticality;formality;andpriorityofrelevanttradefactors.

b) Respond to a request for supply of products or services.Thisactivityconsistsofthefollowingtasks:

1) Evaluatearequestforthesupplyofaproductorservice)todeterminefeasibilityandhowtorespond.

2) Preparearesponsethatsatisfiesthesolicitation.

c) Establish and maintain an agreement.Thisactivityconsistsofthefollowingtasks:

1) Negotiateanagreementwiththeacquirerthatincludesacceptancecriteria.

NOTE Thisagreementrangesinformalityfromawrittencontracttoaverbalagreement.TheSupplierconfirmsthattherequirements,deliverymilestones,andacceptanceconditionsareachievable,thatexceptionhandlingandagreementchangemanagementproceduresandpaymentschedulesareacceptable,andthattheyestablishabasisforexecutingtheagreementwithoutunnecessaryrisks.Issuesarediscussedandresolvedduringnegotiation,afterwhichtheacquirerandsupplieracceptthetermsofanagreementandtheagreementcommences.Foracontract,thisoccurswhenthecontractissigned.





2) Identifynecessarychangestotheagreement.

NOTE In requesting a change to the agreement, the acquirer or the supplier details its specifications, rationale, andbackground.

3) Evaluateimpactofchangesontheagreement.

NOTE Anychangeisinvestigatedforimpactstoprojectplans,schedule,cost,technicalcapability,orquality.Achangecan be handled within the existing agreement, can require a modification to the agreement, or can require a newagreement.

4) Negotiatetheagreementwiththeacquirer,asnecessary.

NOTE Changestoagreementtermsarenegotiatedbetweenthesupplierandacquirer.This includeschangesduetochanging market context. Negotiation occurs for the initial agreement, and as required for any changes. Changedagreementsarebasedontherequiredchangeandidentifiedimpacts.

5) Updatetheagreementwiththeacquirer,asnecessary.

NOTE Theresultoftheagreementmodificationisincorporatedintotheprojectplansandcommunicatedtoallaffectedparties.

d) Execute the agreement. Thisactivityconsistsofthefollowingtasks:

1) Executetheagreementaccordingtotheestablishedprojectplans.

NOTE Asuppliersometimesadopts,oragreestouse,acquirerprocesses.

2) Assesstheexecutionoftheagreement.

NOTE This includes confirmation that all parties aremeeting their responsibilities according to the agreement. TheProject Assessment and Control process is used to evaluate projected cost, schedule, performance, and the impact ofundesirableoutcomesontheorganization.ThechangemanagementactivityoftheConfigurationManagementprocessisusedtocontrolchangestothesystemelements.Thisinformationiscombinedwithotherassessmentsoftheexecutionofthetermsoftheagreement.Ifexecutionoftheagreementdoesnotresultinanacceptableproductorservice,theacquirerorsuppliercanterminatetheagreementasallowedinitsterms.

e) Deliver and support the product or service. Thisactivityconsistsofthefollowingtasks:

1) Delivertheproductorserviceinaccordancewiththeagreementcriteria.

NOTE Asstatedintheagreement,acceptancecriteria,suchasacceptancetesting,relatetohowtheproductorservicewill satisfy its intended use in its operational environment. Unaddressed exceptions, e.g., disputes over conduct ofacceptance testing or product suitability for intended use, are amatter for agreement provisions relating to disputes,arbitrationorapplicablelawandregulation.

2) Provideassistancetotheacquirerinsupportofthedeliveredproductorservice,pertheagreement.

3) Acceptandacknowledgepaymentorotheragreedconsideration.

4) Transfertheproductorservicetotheacquirer,orotherparty,asdirectedbytheagreement.

5) Closetheagreement.

NOTE1 TheprojectisclosedbythePortfolioManagementprocess.

NOTE2 Agreements can specify the conditions underwhich the agreementwill be terminated by either party, e.g.,unexpectedchangesinstrategyoravailablefunding,orlackofsatisfactoryprogress.

6.2 Organizational Project-Enabling processes

The Organizational Project‐Enabling processes help ensure the organization’s capability to acquire and supplyproductsor services through the initiation, supportandcontrolofprojects.Theseprocessesprovide resourcesandinfrastructurenecessarytosupportprojectsandhelpensurethesatisfactionoforganizationalobjectivesand




established agreements. They are not intended to be a comprehensive set of business processes that enablestrategicmanagementoftheorganization’sbusiness.

TheOrganizationalProject‐EnablingProcessesconsistofthefollowing:

a) LifeCycleModelManagementprocess;

b) InfrastructureManagementprocess;

c) PortfolioManagementprocess;

d) HumanResourceManagementprocess;

e) QualityManagementprocess;and

f) KnowledgeManagementprocess.

6.2.1 Life cycle model management process

6.2.1.1 Purpose

ThepurposeoftheLifeCycleModelManagementprocessistodefine,maintain,andassureavailabilityofpolicies,lifecycleprocesses,lifecyclemodels,andproceduresforusebytheorganizationwithrespecttothescopeofthisdocument.

This process provides life cycle policies, processes, models, and procedures that are consistent with theorganization’sobjectives,thataredefined,adapted,improvedandmaintainedtosupportindividualprojectneedswithinthecontextoftheorganization,andthatarecapableofbeingappliedusingeffective,provenmethodsandtools.

6.2.1.2 Outcomes

AsaresultofthesuccessfulimplementationoftheLifeCycleModelManagementprocess:

a) Organizationalpoliciesandproceduresforthemanagementanddeploymentoflifecyclemodelsandprocessesareestablished.

b) Responsibility,accountability,andauthoritywithinlifecyclepolicies,processes,models,andproceduresaredefined.

c) Lifecyclemodelsandprocessesforusebytheorganizationareassessed.

d) Prioritizedprocess,model,andprocedureimprovementsareimplemented.


Theorganization shall implement the following activities and tasks in accordancewith applicable organizationpoliciesandprocedureswithrespecttotheLifeCycleModelManagementprocess.

a) Establish the process. Thisactivityconsistsofthefollowingtasks:

NOTEThe detail of the life cycle implementation within a project is dependent upon the complexity of the work, themethodsused,andtheskillsandtrainingofpersonnelinvolvedinperformingthework.Aprojecttailorspolicies,processes,models, and procedures according to its requirements and needs, while maintaining alignment with regulations andorganizationalpolicies.AnnexAcontainsinformationontailoring.

1) Establish policies and procedures for process management and deployment that are consistent withorganizationalstrategies.





2) Establishtheprocessesthatimplementtherequirementsofthisdocumentandthatareconsistentwithorganizationalstrategies.

3) Define the roles, responsibilities, accountabilities, and authorities to facilitate implementation ofprocessesandthestrategicmanagementoflifecycles.

4) Definebusinesscriteriathatcontrolprogressionthroughthelifecycle.

NOTE Thedecision‐makingcriteriaregardingenteringandexitingeachlifecyclestageandkeymilestonesareestablished.Thesearesometimesexpressedintermsofbusinessachievement.

5) Establish standard life cyclemodels for the organization that are comprised of stages and define thepurposeandoutcomesforeachstage.

NOTE The life cyclemodel comprises one ormore stagemodels, as needed. It is assembled as a sequence ofstagesthatcanoverlaporiterate,asappropriateforthesystem‐of‐interest’sscope,magnitude,complexity,changingneedsandopportunities.StagesareillustratedinISO/IECTS24748‐1usingacommonlyencounteredexampleoflifecyclestages.SpecificexamplesforsystemsandsoftwareareprovidedinISO/IECTR24748‐2andISO/IECTR24748‐3.The lifecycleprocessesandactivitiesareselected, tailoredasappropriateandemployed inastageto fulfill thepurposeandoutcomesofthatstage.

b) Assess the process. Thisactivityconsistsofthefollowingtasks:

NOTEISO/IEC33002:2015providesamoredetailedsetofprocessassessmentactivitiesandtasksthatcanbealignedwiththetasksshownbelow.

1) Monitorprocessexecutionacrosstheorganization.

NOTE Thisincludesmonitoringperformance,analyzingprocessmeasures,andreviewingtrendswithrespecttocompliancewithregulations,organizationalpolicies,businesscriteria,andfeedbackfromtheprojectsregardingtheeffectivenessandefficiencyoftheprocesses.

2) Conductperiodicreviewsofthelifecyclemodelsusedbytheprojects.

NOTE This includes confirming the continuing suitability, adequacy and effectiveness of the life cyclemodelsusedbytheprojectsandmakingimprovementsasappropriate.Thisincludesthestages,processesandachievementcriteriathatcontrolprogressionthroughthelifecycle.

3) Identifyimprovementopportunitiesfromassessmentresults.

NOTE Improvementscanaffectthestages,processes,andachievementcriteriathatcontrolprogressionthroughthelifecycle.

c) Improve the process. Thisactivityconsistsofthefollowingtasks:

1) Prioritizeandplanimprovementopportunities.

2) Implementimprovementopportunitiesandinformrelevantstakeholders.

NOTE ProcessImprovementincludesimprovementstoanyoftheprocessesintheorganization.Lessonslearnedarecapturedandavailable.

6.2.2 Infrastructure Management process

6.2.2.1 Purpose

ThepurposeoftheInfrastructureManagementprocessistoprovidetheinfrastructureandservicestoprojectstosupportorganizationandprojectobjectivesthroughoutthelifecycle.

Thisprocessdefines,providesandmaintainsthefacilities,tools,andcommunicationsandinformationtechnologyassetsneededfortheorganization’sbusinesswithrespecttothescopeofthisdocument.




6.2.2.2 Outcomes

AsaresultofthesuccessfulimplementationoftheInfrastructureManagementprocess:

a) Therequirementsforinfrastructurearedefined.

b) Theinfrastructureelementsareidentifiedandspecified.c) Infrastructureelementsaredevelopedoracquired.d) Theinfrastructureisavailable.


Theorganization shall implement the following activities and tasks in accordancewith applicable organizationpoliciesandprocedureswithrespecttotheInfrastructureManagementprocess.

a) Establish the infrastructure. Thisactivityconsistsofthefollowingtasks:

1) Defineprojectinfrastructurerequirements.

NOTE1 Infrastructure element examples include facilities, tools, hardware, software, services, and standards. Inaddition to the general infrastructure resources common to an organization to support its business processes, anorganization can also provide projects with unique or shared enabling systems to support the project’s technicalprocesses.

NOTE2 Theinfrastructureresourceneedsfortheprojectareconsideredincontextwithotherprojectsandresourceswithin theorganization,aswellaswithin thepoliciesandstrategicplansof theorganization.Businessconstraintsandtimelinesthatinfluenceandcontrolprovisionofinfrastructureresourcesandservicesfortheprojectarealsoevaluated.Projectplansandfuturebusinessneedscontributetotheunderstandingoftheresourceinfrastructurethat isrequired.Physical factors (e.g., facilities), logistics needs, and human factors (including health and safety aspects) are alsoconsidered.

NOTE3 ISO/IEC 27036, Information security for supplier relationships, provides guidance for addressing security ofoutsourcedinfrastructure.

2) Identify, obtain and provide infrastructure resources and services that are needed to implement andsupportprojects.

NOTE An inventory asset registry is often established to track infrastructure elements and support reuse ofinfrastructureassets.

b) Maintain the infrastructure. Thisactivityconsistsofthefollowingtasks:

1) Evaluatethedegreetowhichdeliveredinfrastructureresourcessatisfyprojectneeds.

2) Identify and provide improvements or changes to the infrastructure resources as the projectrequirementschange.

6.2.3 Portfolio Management process

6.2.3.1 Purpose

The purpose of the Portfolio Management process is to initiate and sustain necessary, sufficient and suitableprojectsinordertomeetthestrategicobjectivesoftheorganization.

This process commits the investment of adequate organization funding and resources, and sanctions theauthoritiesneeded to establish selectedprojects. It performscontinuedassessmentofprojects to confirm theyjustify,orcanberedirectedtojustify,continuedinvestment.





Forsoftwaresystems,portfoliomanagementalsocommonlyreferstothemanagementofaproductline(portfolioof assets, products, and enabling systems, or service catalogue) tomeet organizational or customer needs andobjectivesandsupportchangesintechnology.Managementofassetsisachievedthroughmanagementofprojects.

6.2.3.2 Outcomes

AsaresultofthesuccessfulimplementationofthePortfolioManagementprocess:

a) Businessventureopportunities,investmentsornecessitiesarequalifiedandprioritized.

b) Projectsareidentified.

c) Resourcesandbudgetsforeachprojectareallocated.

d) Projectmanagementresponsibilities,accountability,andauthoritiesaredefined.

e) Projectsmeetingagreementandstakeholderrequirementsaresustained.

f) Projectsnotmeetingagreementorsatisfyingstakeholderrequirementsareredirectedorterminated.

g) Projectsthathavecompletedagreementsandsatisfiedstakeholderrequirementsareclosed.


Theorganization shall implement the following activities and tasks in accordancewith applicable organizationpoliciesandprocedureswithrespecttothePortfolioManagementprocess.

a) Define and authorize projects. Thisactivityconsistsofthefollowingtasks:

1) Identifypotentialnewormodifiedcapabilitiesormissions.

NOTE Theorganizationbusinessstrategy,conceptofoperations,orgapanalysisoropportunityanalysis is reviewedforcurrentgaps,problems,oropportunities.AnewcapabilityorenterpriseneedisusuallydeterminedintheBusinessorMissionAnalysisprocess, furtherdefined in theStakeholderNeedsandRequirementsDefinitionprocess,andmanagedthroughthisprocess.

2) Prioritize,selectandestablishnewbusinessopportunities,venturesorundertakings.

NOTE These are usually consistent with the business strategy and action plans of the organization. The potentialprojectsareprioritized,andthresholdsestablished,todeterminewhichprojectswillbeexecuted.Thecharacteristicsofidentified projects are often determined, including stakeholder value, risks and barriers to success, dependencies andinter‐relationships, constraints, resource needs and mutual contention for resources. Each potential project is thenassessedwithrespecttolikelihoodofsuccessandcost‐benefit.TheDecisionManagementandSystemAnalysisprocessesprovidedetailsonperformingananalysisofalternatives.

3) Defineprojects,accountabilitiesandauthorities.

4) Identifytheexpectedgoals,objectives,andoutcomesofeachproject.

5) Identifyandallocateresourcesfortheachievementofprojectgoalsandobjectives.

6) Identifymulti‐projectinterfacesanddependenciestobemanagedorsupportedbyeachproject.

NOTE1 This includes the use or reuse of enabling systems used bymore than one project and the use or reuse ofcommonsystemelements,includingsoftwareelements,bymorethanoneproject.

NOTE2 Understanding each project in the context of the enterprise architecture helps to ensure interfaces andconstraintsareidentified.

7) Specify the project reporting requirements and review milestones that govern the execution of eachproject.




8) Authorizeeachprojecttocommenceexecutionofprojectplans.

NOTE RefertotheProjectPlanningprocess foradditional informationondevelopingprojectplans.Projectplansaremostusefulwhendevelopedandapprovedearlyintheprojectlifecycle.

b) Evaluate the portfolio of projects. Thisactivityconsistsofthefollowingtasks:

1) Evaluateprojectstoconfirmongoingviability.

NOTE Viabilityincludesthefollowingcriteria:

i) Theprojectismakingprogresstowardsachievingestablishedgoalsandobjectives.

ii) Theprojectiscomplyingwithprojectdirectives.

iii) Theprojectisbeingconductedaccordingtoapprovedprojectlifecyclepolicies,processes,andprocedures.

iv) Theproject remainsviable, as indicatedby, forexample, continuingneed for the service,practicableproductimplementation,andacceptableinvestmentbenefits.

2) Act to continue or redirect projects that are satisfactorily progressing or can be expected to progresssatisfactorilybyappropriateredirection.

c) Terminate projects. Thisactivityconsistsofthefollowingtasks:

1) Where agreements permit, act to cancel or suspend projects whose disadvantages or risks to theorganizationoutweighthebenefitsofcontinuedinvestments.

NOTE Capture of lessons learned from canceled or failing projects can be especially useful for organizationalimprovementoruseonotherprojects.

2) Aftercompletionoftheagreementforproductsandservices,acttoclosetheprojects.

NOTE Closureisaccomplishedinaccordancewithorganizationalpoliciesandprocedures,andtheagreement.

6.2.4 Human Resource Management process

6.2.4.1 Purpose

ThepurposeoftheHumanResourceManagementprocessistoprovidetheorganizationwithnecessaryhumanresourcesandtomaintaintheircompetencies,consistentwithbusinessneeds.

Thisprocessprovidesasupplyofskilledandexperiencedpersonnelqualifiedtoperformlifecycleprocessestoachieveorganization,project,andstakeholderobjectives.

6.2.4.2 Outcomes

AsaresultofthesuccessfulimplementationoftheHumanResourceManagementprocess:

a) Skillsrequiredbyprojectsareidentified.

b) Necessaryhumanresourcesareprovidedtoprojects.

c) Skillsofpersonnelaredeveloped,maintainedorenhanced.

d) Conflictsinmulti‐projectresourcedemandsareresolved.






Theorganization shall implement the following activities and tasks in accordancewith applicable organizationpoliciesandprocedureswithrespecttotheHumanResourceManagementprocess:

a) Identify skills. Thisactivityconsistsofthefollowingtasks:

1) Identifyskillneedsbasedoncurrentandexpectedprojects.

2) Identifyandrecordskillsofpersonnel.

b) Develop skills. Thisactivityconsistsofthefollowingtasks:

1) Establishskillsdevelopmentstrategy.

NOTE This plan includes types and levels of training, categories of personnel, schedules, personnel resourcerequirements,andtrainingneeds.

2) Obtainordeveloptraining,educationormentoringresources.

NOTE Theseresources includetrainingmaterialsthataredevelopedbytheorganizationorexternalparties, trainingcoursesthatareavailablefromexternalsuppliers,computerbasedinstruction.

3) Provideplannedskilldevelopment.

4) Maintainrecordsofskilldevelopment.

c) Acquire and provide skills. Thisactivityconsistsofthefollowingtasks:

NOTE Thisincludestherecruitmentandretentionofpersonnelwithexperiencelevelsandskillsnecessarytoproperlystaffprojects;staffassessmentandreview,e.g., theirproficiency,motivation,ability towork ina teamenvironment,aswellastheneedtoberetrained,reassignedorreallocated.

1) Obtainqualifiedpersonnelwhenskilldeficitsareidentified.

NOTE Thisincludesusingoutsourcedresources.

2) Maintainandmanagethepoolofskilledpersonnelnecessarytostaffongoingprojects.

3) Makeprojectassignmentsbasedonprojectandstaff‐developmentneeds.

4) Motivatepersonnel,e.g.,throughcareerdevelopmentandrewardmechanisms.

5) Controlmulti‐projectmanagementinterfacestoresolvepersonnelconflicts.

NOTE This includes conflicts of capacity in organizational infrastructure and supporting services and personnelresourcesamongongoingprojects;orfromprojectpersonnelbeingover‐committed.

6.2.5 Quality Management process

6.2.5.1 Purpose

ThepurposeoftheQualityManagementprocessistoassurethatproducts,servicesandimplementationsofthequalitymanagementprocessmeetorganizationalandprojectqualityobjectivesandachievecustomersatisfaction.

6.2.5.2 Outcomes

AsaresultofthesuccessfulimplementationoftheQualityManagementprocess:

a) Organizational quality management policies, objectives, and procedures are defined andimplemented.




b) Qualityevaluationcriteriaandmethodsareestablished.c) Resources and information are provided to projects to support the operation and monitoring of

projectqualityassuranceactivities.d) Qualityassuranceevaluationresultsaregatheredandanalyzed.e) Qualitymanagementpoliciesandproceduresare improvedbaseduponproject andorganizational

results.


Theorganization shall implement the following activities and tasks in accordancewith applicable organizationpoliciesandprocedureswithrespecttotheQualityManagementprocess.

NOTE RefertoISO9001:2015forinformationandrequirementstoestablishaQualityManagementSystem.

a) Plan quality management. Thisactivityconsistsofthefollowingtasks:

1) Establishqualitymanagementpolicies,objectives,andprocedures.

NOTE1 ISO9004:2009containsguidelinesforperformanceimprovements.

NOTE2 Thepolicies,objectives,andproceduresarebasedonthebusinessstrategyforcustomersatisfactionandriskmanagementconsiderations.

2) Defineresponsibilitiesandauthorityforimplementationofqualitymanagement.

NOTE Resourcesforqualitymanagementareoftenassignedfromdistinctorganizationsforindependencefromprojectmanagement.

3) Definequalityevaluationcriteriaandmethods.

4) Provideresourcesandinformationforqualitymanagement.

b) Evaluate quality management. Thisactivityconsistsofthefollowingtasks:

1) Gatherandanalyzequalityassuranceevaluationresults,inaccordancewiththedefinedcriteria.

2) Assesscustomersatisfaction.

NOTE ISO 10004:2012 contains guidelines for monitoring and measuring customer satisfaction. The quality of thesoftwaresystemisalsodemonstratedbyusersatisfaction.

3) Conduct periodic reviews of project Quality Assurance activities for compliance with the QualityManagementpolicies,objectives,andprocedures.

NOTE Quality evaluation criteria and methods are established. Quality assessments address compliance with theprojectproceduresandproductconformancewithqualitycharacteristics.

4) Monitorthestatusofqualityimprovementsonprocesses,products,andservices.

c) Perform corrective and preventive action.Thisactivityconsistsofthefollowingtasks:

1) Plancorrectiveactionswhenqualitymanagementobjectivesarenotachieved.

2) Plan preventive actionswhen there is a sufficient risk that qualitymanagement objectiveswill not beachieved.

3) Monitorcorrectiveandpreventiveactionstocompletionandinformrelevantstakeholders.





NOTE1 Implementationofcorrectiveandpreventiveactionisperformedinotherrelevantprocesses,suchasLifeCycleModelManagementorProjectAssessmentandControl.

NOTE2 ISO9001:2015,0.3.3andAnnexA.4describepreventiveactiontoeliminatepotentialnonconformitiesaspartofrisk‐basedthinking.

6.2.6 Knowledge Management process

6.2.6.1 Purpose

The purpose of the Knowledge Management process is to create the capability and assets that enable theorganizationtoexploitopportunitiestore‐applyexistingknowledge.

Thisencompassesknowledge,skills,andknowledgeassets,includingsystemelements.

NOTE There‐applicationofexistingknowledgeisknownasknowledgereuseandincludesthereuseofknowledgeaboutorfromsoftwareelements.

6.2.6.2 Outcomes

AsaresultofthesuccessfulimplementationoftheKnowledgeManagementprocess:

a) Ataxonomyfortheapplicationofknowledgeassetsisidentified.

b) Theorganizationalknowledge,skills,andknowledgeassetsaredevelopedoracquired.

c) Theorganizationalknowledge,skills,andknowledgeassetsareavailable.

d) Knowledgemanagementusagedataisgatheredandanalyzed.


Theorganization shall implement the following activities and tasks in accordancewith applicable organizationpoliciesandprocedureswithrespecttotheKnowledgeManagementprocess:

a) Plan knowledge management. Thisactivityconsistsofthefollowingtasks:

1) Definetheknowledgemanagementstrategy.

NOTE1 Thisknowledgemanagementstrategygenerallyincludes:

i) Identifyingdomainsandtheirpotentialforthereapplicationofknowledge.

ii) Plansforobtainingandmaintainingknowledge,skills,andknowledgeassetsfortheirusefullife.

iii) Characterization of the types of knowledge, skills, and knowledge assets to be collected andmaintained.

iv) Criteriaforaccepting,qualifying,andretiringknowledge,skills,andknowledgeassets.

v) Proceduresforcontrollingchangestotheknowledge,skills,andknowledgeassets.

vi) Plans,mechanisms, andprocedures for protection, control, and access to classified or sensitivedataandinformation.

vii) Mechanismsforstorageandretrieval.

NOTE2 Knowledgemanagement includes knowledge shared both internallywithin the organization and knowledgethat is shared outside the organization with designated stakeholders, acquirers, and business partners, subject tointellectualpropertyandnon‐disclosureagreements.




2) Identifytheknowledge,skills,andknowledgeassetstobemanaged.

3) Identifyprojectsthatcanbenefitfromtheapplicationoftheknowledge,skills,andknowledgeassets.

b) Share knowledge and skills throughout the organization.Thisactivityconsistsofthefollowingtasks:

1) Establish and maintain a classification for capturing and sharing knowledge and skills across theorganization.

NOTE Thisclassificationcanincludeexpert,common,anddomainknowledgeandskills,aswellaslessonslearnedfromothertasks.

2) Captureoracquireknowledgeandskills.

3) Shareknowledgeandskillsacrosstheorganization.

c) Share knowledge assets throughout the organization.Thisactivityconsistsofthefollowingtasks:

1) Establishataxonomytoorganizeknowledgeassets.

NOTE1 Thetaxonomyincludesthefollowing:

i) Definitionoftheboundariesofdomainsandtheirrelationshipstoothers.

ii) Domain models capturing essential common and different features, capabilities, concepts, andfunctions.

iii) An architecture for a family of systemswithin the domain, including their common and differentfeatures.

NOTE2 See ISO/IEC 26550 for more information on product line models. Refer to ISO/IEC/IEEE 42010:2011 forrequirementsonarchitectureframeworks,viewpoints,modelkinds,viewsandmodels.

2) Developoracquireknowledgeassets.

NOTE Knowledge assets include system elements or their representations (e.g., reusable code libraries, referencearchitectures)architectureordesignelements(e.g.,architectureordesignpatterns),processes,criteria,orothertechnicalinformation(e.g.,trainingmaterials)relatedtodomainknowledge,andlessonslearned.

3) Shareknowledgeassetsacrosstheorganization.

NOTE Automatedsearchcapabilitiesimproveaccesstoknowledgeassets.

d) Manage knowledge, skills, and knowledge assets.Thisactivityconsistsofthefollowingtasks:

1) Maintainknowledge,skills,andknowledgeassets.

2) Monitorandrecordthereuseofknowledge,skills,andknowledgeassets.

3) Periodicallyreassessthecurrencyoftechnologyandmarketneedsfortheknowledgeassets.

NOTE Assessthebusinessbenefitswhichtheorganizationgainedthroughtheuseofknowledgemanagementpractices.

6.3 Technical Management processes

TheTechnicalManagementprocessesareusedtoestablishandevolveplans,toexecutetheplans,toassessactualachievementandprogressagainsttheplans,andtocontrolexecutionthroughtofulfillment.IndividualTechnicalManagementprocessesmaybeinvokedatanytimeinthelifecycleandatanylevelinahierarchyofprojects,asrequiredbyplansorunforeseenevents.TheTechnicalManagementprocessesareappliedwithalevelofrigorandformalitythatdependsontheriskandcomplexityoftheproject.





Thescopeofatechnicalmanagementprocessisthetechnicalmanagementofaprojectoritsproducts,toincludethesoftwareproductorsystem‐of‐interest.

NOTE ThissetofTechnicalManagementprocessesisperformedsothatsoftwaresystem‐specifictechnicalprocessescanbe conducted effectively. They do not comprise a management system or a comprehensive set of processes for projectmanagement,asthatisnotthescopeofthisdocument.

TheTechnicalManagementprocessesconsistofthefollowing:

a) ProjectPlanningprocess;

b) ProjectAssessmentandControlprocess;

c) DecisionManagementprocess;

d) RiskManagementprocess;

e) ConfigurationManagementprocess;

f) InformationManagementprocess;

g) Measurementprocess;and

h) QualityAssuranceprocess.

Project Planning and Project Assessment and Control processes are key to all management practices. Theseprocessesestablishthegeneralapproachformanagingaprojectoraprocess.Theotherprocessesinthisgroupprovideaspecific focusedsetof tasksforachievingaspecializedmanagementobjective.Theyareallevident inthemanagementofanyundertaking,rangingfromacompleteorganizationdowntoasinglelifecycleprocessandits tasks. In this document, the project has been chosen as the context for describing processes. The sameprocessescanalsobeappliedintheperformanceofservices.

6.3.1 Project Planning process

6.3.1.1 Purpose

ThepurposeoftheProjectPlanningprocessistoproduceandcoordinateeffectiveandworkableplans.

Thisprocessdeterminesthescopeoftheprojectmanagementandtechnicalactivities,identifiesprocessoutputs,tasks and deliverables, establishes schedules for task conduct, including achievement criteria, and requiredresources to accomplish tasks. This is an ongoing process that continues throughout a project, with regularrevisionstoplans.

NOTE The strategiesdefined ineachof theotherprocessesprovide inputsandare integrated in theProjectPlanningprocess.TheProjectAssessmentandControlprocessisusedtoassesswhethertheplansareintegrated,aligned,andfeasible.

6.3.1.2 Outcomes

AsaresultofthesuccessfulimplementationoftheProjectPlanningprocess:

a) Objectivesandplansaredefined.

b) Roles,responsibilities,accountabilities,andauthoritiesaredefined.

c) Resourcesandservicesnecessarytoachievetheobjectivesareformallyrequestedandcommitted.

d) Plansfortheexecutionoftheprojectareactivated.





TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheProjectPlanningprocess.

a) Define the project.Thisactivityconsistsofthefollowingtasks:

1) Identifytheprojectobjectivesandconstraints.

NOTE1 Objectivesandconstraints includeperformanceandotherqualityaspects, cost, timeandcustomerandusersatisfaction.Eachobjectiveis identifiedwithalevelofdetailthatpermitsselection,tailoringandimplementationoftheappropriateprocessesandactivities.

NOTE2 ISO/IEC 15026 Systems and software assurance, ISO/IEC 27001 Information Security Management System andISO/IEC27036,Information Security for Supplier Relationships,provideadditionalguidanceonobjectivesandconstraintsrelatedtoassuranceandsecurity.

2) Definetheprojectscopeasestablishedintheagreement.

NOTE This includes the relevant activities required to satisfy business decision criteria and complete the projectsuccessfully.Aprojectcanhaveresponsibilityforoneormorestagesinthecompletesoftwaresystemlifecycle.ProjectPlanningincludesdefiningappropriateactionsformaintainingprojectplans,performingassessmentsandcontrollingtheproject.

3) Defineandmaintainalifecyclemodelthatiscomprisedofstagesusingthedefinedlifecyclemodelsoftheorganization.

NOTE ISO/IEC TS 24748‐1 provides detailed information regarding life cycle stages and the definition of anappropriatelifecyclemodel.Itdefinesageneralsetofexemplarsystemlifecyclestages,includingConcept,Development,Production, Utilization, Support and Retirement. It also identifies a generic exemplar set of software life cycle stages,including Needs determination, Concept exploration and definition, Demonstration and evaluation,Engineering/development, Production/manufacturing, Deployment/sales, Operations, Maintenance and support, andRetirement.

4) Establish a work breakdown structure (WBS) based on the deliverable products or the evolvingarchitectureofthesoftwaresystem.

NOTE1 Eachelementofthesoftwaresystemarchitecture,andappropriateprocessesandactivities,aredescribedwitha levelofdetail that isconsistentwith identifiedrisks.Related tasks in theworkbreakdownstructurearegrouped forperformance. Project tasks identify work items being developed or produced. The Practice Management Standard forWorkBreakdownStructuresoftheProjectManagementInstitute(PMI)containsadditionaldetailsonWBSs.

NOTE2 Forprojectswithagileor iterativemethods,aWBSelement cancorrespond to theprimary features, fromauserperspective,tobeproducedduringiterations.

5) Defineandmaintaintheprocessesthatwillbeappliedontheproject.

NOTE1 These processes are based on the defined processes of the organization (see Life CycleModelManagementprocess).AnnexAcontainsinformationontailoringthatcanbeusedtoaddressproject‐specificneeds.Thedefinitionofthe processes includes the entry and exit criteria, inputs, process sequence constraints (predecessor/successorrelationships),processconcurrencyrequirements(whatprocessesand tasksare tobeworkedconcurrentlywithotherprocess area tasks or activities), Measures of Effectiveness/Measures of Performance attributes, and scope and costparameters(forcriticallyimportantcostestimation).

NOTE2 Identifying interfaces with other projects or organizational units is addressed through the PortfolioManagementprocess.

b) Plan project and technical management. Thisactivityconsistsofthefollowingtasks:

1) Define and maintain a project schedule based on management and technical objectives and workestimates.

NOTE This includes definition of the duration, relationship, dependencies and sequence of activities, achievementmilestones,resourcesemployedandthereviewsandschedulereservesforriskmanagementnecessarytoachievetimelycompletionoftheproject.





2) Defineachievementcriteriaforthelifecyclestagedecisiongates,deliverydatesandmajordependenciesonexternalinputsoroutputs.

NOTE Thetimeintervalsbetweeninternalreviewsaredefinedinaccordancewithorganizationalpolicyonissuessuchasbusinessandsystemcriticality,scheduleandtechnicalrisks.

3) Definethecostsandplanabudget.

NOTE Budgeted costs are based on the schedule, software size and complexity estimates, labor estimates,infrastructure costs, procurement items, acquired service and enabling system estimates, and budget reserves for riskmanagement.

4) Defineroles,responsibilities,accountabilities,andauthorities.

NOTE Thisincludesdefiningtheprojectorganization,staffacquisitions,andthedevelopmentofstaffskills.Authoritiesinclude,asappropriate,thelegallyresponsiblerolesandindividuals,e.g.,designauthorization,safetyauthorization,andthoseresponsibleforapplicablecertificationsoraccreditations.

5) Definetheinfrastructureandservicesrequired.

NOTE This includes defining the capacity needed, its availability and its allocation to project tasks. Infrastructureincludes facilities, services, tools, communications, and information technology assets. The requirements for enablingsystemsandservicesforeachlifecyclestagearealsospecified.

6) Plantheacquisitionofmaterialsandenablingsystemsandservicessuppliedfromoutsidetheproject.

NOTE1 This includes,asnecessary,plans for solicitation, supplier selection,acceptance, contractadministrationandcontractclosure.Theagreementprocessesareusedfortheplannedacquisitions.

NOTE2 ISO/IEC 27036, Information security for supplier relationships, provides guidance for acquisition ofinfrastructureandservices.

7) Generateandcommunicateaplanforprojectandtechnicalmanagementandexecution,includingreviews.

NOTE1 Technical planning for the software system is often captured in a Systems Engineering Management Plan(SEMP) or a Software Engineering Management Plan or a Software Development Plan (SDP). ISO/IEC/IEEE 24748‐5providesmoredetailonsoftwareengineeringtechnicalmanagementplanningandincludesanannotatedoutlineforanSDP.PlanningfortheprojectisoftencapturedinaProjectManagementPlan.ISO/IEC/IEEE16326providesmoredetailonprojectplanning.

NOTE2 The strategy activities and tasks from each of the other processes provide inputs and are integrated in theProjectPlanningprocess.TheProjectAssessmentandControlprocessisusedtohelpensurethattheplansareintegrated,aligned,andfeasible.

c) Activate the project. Thisactivityconsistsofthefollowingtasks:

1) Obtainapprovaltostarttheproject.

NOTE Approvaltostart(authorizationtoproceed)isprovidedthroughthePortfolioManagementprocess.

2) Submitrequestsandobtaincommitmentsfornecessaryresourcestoperformtheproject.

NOTE Thisincludesaccesstoenablingsystemsorservices.

3) Implementprojectplans.

6.3.2 Project assessment and control process

6.3.2.1 Purpose

The purpose of the Project Assessment and Control process is to assess if the plans are aligned and feasible;determinethestatusoftheproject,technicalandprocessperformance;anddirectexecutiontohelpensurethattheperformanceisaccordingtoplansandschedules,withinprojectedbudgets,tosatisfytechnicalobjectives.




This process evaluates, periodically andatmajor events, theprogress andachievements against requirements,plansandoverallbusinessobjectives.Informationisprovidedformanagementactionwhensignificantvariancesare detected. This process also includes redirecting the project activities and tasks, as appropriate, to correctidentified deviations and variations from other technicalmanagement or technical processes. Redirectionmayincludere‐planningasappropriate.

6.3.2.2 Outcomes

AsaresultofthesuccessfulimplementationoftheProjectAssessmentandControlprocess:

a) Performancemeasuresorassessmentresultsareavailable.

b) Adequacyofroles,responsibilities,accountabilities,andauthoritiesisassessed.

c) Adequacyofresourcesisassessed.

d) Technicalprogressreviewsareperformed.

e) Deviationsinprojectperformancefromplansareinvestigatedandanalyzed.

f) Affectedstakeholdersareinformedofprojectstatus.

g) Correctiveactionisdefinedanddirected,whenprojectachievementisnotmeetingtargets.

h) Projectreplanningisinitiated,asnecessary.

i) Projectactiontoprogress(ornot)fromonescheduledmilestoneoreventtothenextisauthorized.

j) Projectobjectivesareachieved.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheProjectAssessmentandControlprocess.

a) Plan for project assessment and control.Thisactivityconsistsofthefollowingtask:

1) Definetheprojectassessmentandcontrolstrategy.

NOTE The strategy identifies the expected Project Assessment and Control activities, including planned assessmentmethodsandtimeframes,andnecessarymanagementandtechnicalreviews.

b) Assess the project. Thisactivityconsistsofthefollowingtasks:

1) Assessalignmentofprojectobjectivesandplanswiththeprojectcontext.

2) Assessmanagementandtechnicalplansagainstobjectivestodetermineadequacyandfeasibility.

3) Assess project and technical status against appropriate plans to determine actual and projected cost,schedule,andperformancevariances.

4) Assesstheadequacyofroles,responsibilities,accountabilities,andauthorities.

NOTE This includesassessmentof theadequacyofpersonnelcompetencies toperformprojectrolesandaccomplishprojecttasks.Objectivemeasuresareusedwhereverpossible,e.g.,efficiencyofresourceuse,projectachievement.

5) Assesstheadequacyandavailabilityofresources.





NOTE Resources include infrastructure, personnel, funding, time, or other pertinent items. This task includesevaluating the reuse of existing processes and infrastructure resources, and confirming that intra‐organizationalcommitmentsaresatisfied.

6) Assessprogressusingmeasuredachievementandmilestonecompletion.

NOTE Thisincludescollectingandevaluatingdataforlabor,material,servicecosts,andtechnicalperformance,aswellasothertechnicaldataaboutobjectives,suchasaffordability.Thesearecomparedagainstmeasuresofachievement.Thisincludes conducting effectiveness assessments to determine the adequacy of the evolving software system againstrequirements.Italsoincludesthereadinessofenablingsystemstodelivertheirserviceswhenneeded.

7) Conductrequiredmanagementandtechnicalreviews,auditsandinspections.

NOTE Theseareformalorinformal,andareconductedtodeterminereadinesstoproceedtothenextstageofthelifecycleorprojectmilestone,tohelpensurethatprojectandtechnicalobjectivesarebeingmet,ortoobtainfeedbackfromstakeholders.

8) Monitorcriticalprocessesandnewtechnologies.

NOTE Thisincludesidentifyingandevaluatingtechnologymaturityandfeasibilityoftechnologyinsertion.Technologymaturity is the readiness of a technology for operational use, and is oftenmeasured on a scale from low (exists as aconceptonly)tohigh(proveninoperationaluse).

9) Analyzemeasurementresultsandmakerecommendations.

NOTE Measurementresultsareanalyzedtoidentifydeviations,variationsorundesirabletrendsfromplannedvaluesthat includepotential concerns, and tomake appropriate recommendations for corrections orpreventive actions. Thisincludes,whereappropriate,statisticalanalysisofmeasuresthatindicatestrends,e.g.,faultdensitytoindicatequalityofoutputs,distributionofmeasuredparametersthatindicateprocessrepeatability.

10) Recordandprovidestatusandfindingsfromassessmenttasks.

NOTE Thesearegenerallydesignatedintheagreement,policiesandprocedures.

11) Monitorprocessexecutionwithintheproject.

NOTE This includes the analysis of processmeasures and review of trends with respect to project objectives. AnyimprovementactionsidentifiedcanbehandledthroughtheQualityAssuranceprocess,theQualityManagementprocess,ortheLifeCycleModelManagementprocess.

c) Control the project. Thisactivityconsistsofthefollowingtasks:

1) Initiatenecessaryactionsneededtoaddressidentifiedissues.

NOTE1 This task occurs when project or technical achievement is not meeting planned targets. This includespreventive,corrective,andproblemresolutionactions.Actionsgenerallyrequirereplanningorreassignmentofpersonnel,tools and infrastructure assets when inadequacy or unavailability has been detected, or when project or technicalachievement exceeds targets or plan. They often impact the cost, schedule, or technical scope or definition. Actionssometimesrequirechangestotheimplementationandexecutionofthelifecycleprocesses.

NOTE2 Actionsarerecordedandreviewedtoconfirmtheiradequacyandtimeliness.

2) Initiatenecessaryprojectreplanning.

NOTE1 Project replanning is initiated when project objectives or constraints have changed, or when planningassumptionsareshowntobeinvalid.

NOTE2 AnychangethatrequiresachangetotheagreementbetweenacquirerandsupplierinvokestheAcquisitionandSupplyprocesses.

3) Initiatechangeactionswhenthereisacontractualchangetocost,timeorqualityduetotheimpactofanacquirerorsupplierrequest.

NOTE This includes consideration ofmodified terms and conditions for supply or initiating new supplier selection,whichinvokestheAcquisitionandSupplyprocesses.




4) Authorizetheprojecttoproceedtowardthenextmilestoneorevent,ifjustified.

NOTE TheProjectAssessmentandControlprocessisusedtoreachagreementonmilestonecompletion.

6.3.3 Decision Management process

6.3.3.1 Purpose

ThepurposeoftheDecisionManagementprocessistoprovideastructured,analyticalframeworkforobjectivelyidentifying,characterizingandevaluatingasetofalternativesforadecisionatanypointinthelifecycleandselectthemostbeneficialcourseofaction.

This process is used to resolve technical or project issues and respond to requests for decisions encounteredduringthesoftwarelifecycle,inordertoidentifythealternative(s)thatprovidesthepreferredoutcomesforthesituation. The methods most frequently used for Decision Management are the trade study and engineeringanalysis. Each of the alternatives is assessed against the decision criteria (e.g., cost impact, schedule impact,programmatic constraints, regulatory implications, technical performance characteristics, critical qualitycharacteristics,andrisk).Resultsof thesecomparisonsare ranked,viaasuitable selectionmodel, andare thenused to decide on an optimal solution. Key study data (e.g., assumptions and decision rationale) are typicallymaintainedtoinformdecision‐makersandsupportfuturedecision‐making.

NOTE Whenitisnecessarytoperformadetailedassessmentofaparameterforoneofthecriteria,theSystemAnalysisprocesscanbeemployedtoperformtheassessment.

6.3.3.2 Outcomes

AsaresultofthesuccessfulimplementationoftheDecisionManagementprocess:

a) Decisionsrequiringalternativeanalysisareidentified.

b) Alternativecoursesofactionareidentifiedandevaluated.

c) Apreferredcourseofactionisselected.

d) Theresolution,decisionrationaleandassumptionsareidentified.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheDecisionManagementprocess.

a) Prepare for decisions.Thisactivityconsistsofthefollowingtasks:

1) Defineadecisionmanagementstrategy.

NOTE A decision management strategy includes the identification of roles, responsibilities, accountabilities, andauthorities. The strategy considers the need for obtaining information input and for returning a timely decision. Itincludes the identification of decision categories and a prioritization scheme. Decisions often arise as a result of aneffectivenessassessment, a technical trade‐off, aproblemneeding tobe solved, anactionneededasa response to riskexceedingtheacceptablethreshold,oranewopportunityorapprovalforprojectprogressiontothenextlifecyclestage.Organizationorprojectguidelinesdeterminethedegreeofrigorandformalitytoapplytothedecisionanalysis.

2) Identifythecircumstancesandneedforadecision.

NOTE Problemsoropportunities and the alternative coursesof action thatwill resolve their outcomeare recorded,categorizedandreported.

3) Involverelevantstakeholdersinthedecision‐makinginordertodrawonexperienceandknowledge.

NOTE Itisgoodpracticetoidentifythesubjectmatterexpertiseneededfortheanalysisandthedecision.





b) Analyze the decision information. Thisactivityconsistsofthefollowingtasks:

1) Selectanddeclarethedecisionmanagementstrategyforeachdecision.

NOTE Thedegreeofrigorrequiredtoresolvetheseproblemsoropportunitiesisdetermined,aswellasthedataandsystemanalysisneededforevaluatingthealternatives.Definethetimeframetoreachadecision.

2) Determinedesiredoutcomesandmeasurableselectioncriteria.

NOTE The desired value for quantifiable criteria and the threshold value(s) beyond which the attribute will beunsatisfactoryaredetermined,aswellasweightingfactorsforthecriteria.

3) Identifythetradespaceandalternatives.

NOTE If a largenumberof alternatives exist, they arequalitatively screened to reduce alternatives to amanageablenumberforfurtherdetailedsystemsanalysis.Thisscreeningisoftenbasedonqualitativeassessmentsofsuchfactorsasrisk,cost,schedule,andregulatoryimpacts.

4) Evaluateeachalternativeagainstthecriteria.

NOTE TheSystemAnalysisprocess isused,asnecessary, toquantifyspecificcriteria foreachtradealternativetobeevaluated. This includes new design parameters, different architecture characteristics, and range of values for criticalquality characteristics. The System Analysis process assesses the range of parameter variations in order to obtain asensitivityanalysis foreachof thetradealternativesevaluated.Theseresultsareusedtoestablishthe feasibilityof thevarioustradealternatives.

c) Make and manage decisions. Thisactivityconsistsofthefollowingtasks:

1) Determinepreferredalternativeforeachdecision.

NOTE Alternativesareevaluatedquantitatively,usingtheselectioncriteria.Theselectedalternativegenerallyprovidesanoptimizationof,orimprovementin,anidentifieddecision.

2) Recordtheresolution,decisionrationale,andassumptions.

3) Record,track,evaluateandreportdecisions.

NOTE1 This includes records of problems and opportunities and their disposition, as stipulated in agreements ororganizationalproceduresandinamannerthatpermitsauditingandlearningfromexperience.

NOTE2 Thisallowstheorganizationtoconfirmthatproblemshavebeeneffectivelyresolved,thatadversetrendshavebeenreversed,andthatadvantagehasbeentakenofopportunities.

6.3.4 Risk Management process

6.3.4.1 Purpose

ThepurposeoftheRiskManagementprocessistoidentify,analyze,treatandmonitortheriskscontinually.

TheRiskManagementprocessisacontinualprocessforsystematicallyaddressingriskthroughoutthelifecycleofa systemproductor service. It canbe applied to risks related to the acquisition, development,maintenanceoroperationofasystem.

NOTE RiskisdefinedinISOGuide73:2009as“Theeffectofuncertaintyonobjectives”.ThishasanattachedNote1,“Aneffectisadeviationfromtheexpected—positiveand/ornegative”.Apositiveriskiscommonlyknownasanopportunity,andcanbeaddressedwithintheRiskManagementprocess.

6.3.4.2 Outcomes

AsaresultofthesuccessfulimplementationoftheRiskManagementprocess:

a) Risksareidentified.




b) Risksareanalyzed.

c) Risktreatmentoptionsareidentified,prioritized,andselected.

d) Appropriatetreatmentisimplemented.

e) Risksareevaluatedtoassesschangesinstatusandprogressintreatment.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheRiskManagementprocess.

NOTE ISO/IEC/IEEE16085providesamoredetailedsetofriskmanagementactivitiesandtasks. Thisriskmanagementprocess is aligned with ISO 31000:2009 Risk management — Principles and Guidelines, and ISO Guide 73:2009, Risk management — Vocabulary. ISO9001:2015describesplanningforrisksandopportunitiesin6.1.

a) Plan risk management. Thisactivityconsistsofthefollowingtasks:

1) Definetheriskmanagementstrategy.

NOTE Thisincludestheriskmanagementprocessofsupplychainsuppliersanddescribeshowrisksfromsupplierswillberaisedtothenextlevel(s)forincorporationintheprojectriskprocess.

2) DefineandrecordthecontextoftheRiskManagementprocess.

NOTE1 This includes a description of stakeholders’ perspectives, risk categories, and a description (perhaps byreference) of the technical and managerial objectives, assumptions and constraints. The risk categories include therelevanttechnicalareasofthesoftwaresystemandfacilitateidentificationofrisksacrosstheproductlifecycle.Asnotedin ISO31000, theaimof this step is togenerateacomprehensive listof risksbasedon thoseevents thatmightcreate,enhance,prevent,degrade,accelerate,ordelaytheachievementofobjectives.

NOTE2 Opportunities,whichareonetypeofrisk,providepotentialbenefitsforthesoftwaresystemorproject.Eachoftheopportunitiespursuedhasassociatedrisksthatdetractfromtheexpectedbenefit.Thisincludestherisksassociatedwithnotpursuinganopportunity,aswellastheriskofnotachievingtheeffectsoftheopportunity.

b) Manage the risk profile. Thisactivityconsistsofthefollowingtasks:

1) Defineandrecordtheriskthresholdsandconditionsunderwhichalevelofriskmaybeaccepted.

2) Establishandmaintainariskprofile.

NOTE The riskprofile records: the riskmanagement context; a recordof each risk’s state including its likelihoodofoccurrence, consequences, and risk thresholds; the priority of each risk based on risk criteria supplied by thestakeholders;andtheriskactionrequestsalongwiththestatusoftheirtreatment.Theriskprofileisupdatedwhentherearechangesinanindividualrisk’sstate.Thepriorityintheriskprofileisusedtodeterminetheapplicationofresourcesfortreatment.

3) Periodicallyprovidetherelevantriskprofiletostakeholdersbasedupontheirneeds.

c) Analyze risks. Thisactivityconsistsofthefollowingtasks:

1) Identifyrisksinthecategoriesdescribedintheriskmanagementcontext.

NOTE Risks are commonly identified through various analyzes, such as safety, reliability, security, andperformanceanalyzes;technology,architecture,andreadinessassessments;andtradestudies.Theserisksareoftenidentifiedearlyinthelifecycleandcontinueintotheutilization,support,andretirementofthesoftwaresystem.Additionally,risksareoftenidentifiedthroughtheanalysisofmeasurementsoftheevolvingsoftwaresystem.

2) Estimatethelikelihoodofoccurrenceandconsequencesofeachidentifiedrisk.

NOTE Consequencesofarisktypicallyinvolvetechnical,schedule,cost,orqualityimpacts.





3) Evaluateeachriskagainstitsriskthresholds.

4) Foreachriskthatdoesnotmeetitsriskthreshold,defineandrecordrecommendedtreatmentstrategiesandmeasures.

NOTE Risk treatment strategies include, but are not limited to, eliminating the risk, reducing its likelihood ofoccurrenceorseverityofconsequence,oracceptingtherisk.Treatmentsalsoincludetakingorincreasingriskinordertopursueanopportunity.Measuresprovideinformationabouttheeffectivenessofthetreatmentalternatives.

d) Treat risks. Thisactivityconsistsofthefollowingtasks:

1) Identifyrecommendedalternativesforrisktreatment.

2) Implement risk treatment alternatives for which the stakeholders determine that actions should betakentomakeariskacceptable.

3) When the stakeholders accept a risk that does notmeet its threshold, consider it a high priority andmonitor it continually todetermine if future risk treatmentactionsarenecessaryor if itspriorityhaschanged.

4) Oncearisktreatmentisselected,coordinatemanagementaction.

NOTE TheProjectAssessmentandControlprocesscanbeapplied.

e) Monitor risks. Thisactivityconsistsofthefollowingtasks:

1) Continuallymonitorrisksandtheriskmanagementcontextforchangesandevaluatetheriskswhentheirstatehaschanged.

2) Implementandmonitormeasurestoevaluatetheeffectivenessofrisktreatments.

3) Continuallymonitorfortheemergenceofnewrisksandsourcesthroughoutthelifecycle.

6.3.5 Configuration Management process

6.3.5.1 Purpose

ThepurposeofConfigurationManagementistomanageandcontrolsystemelementsandconfigurationsoverthelife cycle. Configuration Management (CM) also manages consistency between a product and its associatedconfigurationdefinition.

Softwareconfigurationmanagement(SCM)appliestoboththesoftwaresystemanditsinterfaces.Thepurposeofinterfacemanagementistoagreewithinterfacepartnersontheexchangeofdatathroughcommunicationsamongsoftwaresystemsandservices.AnnexE(seeE.5)providesanexampleofanInterfaceManagementProcessView.

Softwareconfigurationsarechangedthroughthecontrolledreleaseofanewversion.Thepurposeofareleaseistoauthorizeandeffect theavailabilityofa software feature, function,or system fora specificpurpose,withorwithoutrestrictionstoasubsetofusers.

6.3.5.2 Outcomes

AsaresultofthesuccessfulimplementationoftheConfigurationManagementprocess:

a) Itemsrequiringconfigurationmanagementareidentifiedandmanaged.

b) Configurationbaselinesareestablished.

c) Changestoitemsunderconfigurationmanagementarecontrolled.

d) Configurationstatusinformationisavailable.




e) Requiredconfigurationauditsarecompleted.

f) Systemreleasesanddeliveriesarecontrolledandapproved.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheConfigurationManagementprocess.

NOTE ISO/IEC/IEEE19770providesproceduresandrequirementsforanITassetmanagementsystem.

a) Plan configuration management. Thisactivityconsistsofthefollowingtasks:

1) Defineaconfigurationmanagementstrategy,includingapproachesforthefollowing:

i) Governance of CM, including roles, responsibilities, accountabilities, and authorities, and use ofconfigurationcontrol(changecontrol)boards;and

ii) Considerationofthelevelofriskandimpactinapprovalofconfigurationbaselinesandregularandemergencychangerequests.

NOTE Regularlyscheduledchangestoapplysoftwarepatchesusingapprovedproceduresorcheck‐inandcheck‐outofunit‐testedsoftwareelementsunderdevelopmentaretypicallyperformedautomatically,orreviewedandapproveddailyasamatterofroutine.Incomparison,significantchangestothesoftwaresystemdesignwithmajorimpactonprojectcostand schedule can involve extensive analyzes, consultations with suppliers, stakeholder reviews, and approvals at thehighestlevelsoftheorganization.

iii) CoordinationofCMacrossthesetofacquirer,supplier,andsupplychainorganizationsforthelifeofthesoftwaresystem,ortheextentoftheagreementorproject,asappropriate.

iv) Controlofaccessandchangestoanddispositionofconfigurationitems.

v) Thenecessarybaselinestobeestablished,includingcriteriaoreventsforcommencingconfigurationcontrolandmaintainingbaselinesofevolvingconfigurations.

vi) Controlofsoftwarelicenses,datarights,andotherintellectualpropertyassets.

vii) Frequency,priorities,andcontentofsoftwareversionsandreleases.

viii) The audit strategy and the responsibilities for validating continuous integrity and security of theconfigurationdefinitioninformation.

ix) Change management, including preparing stakeholders and especially users for changes inoperationalsoftwaresystemsandservices.

NOTE1 Forcomplexsoftwaresystems,trade‐offstudiesareperformed,e.g.,toselectanappropriateautomatedtooltosupportSCMneedsandscopeasidentifiedinthestrategy.

NOTE2 AdditionalguidanceregardingconfigurationmanagementactivitiescanbefoundinISO10007,IEEEStd828,andSAEANSI/EIA‐649‐B.

NOTE3 The SWEBOK, Guide to the Software Engineering Body of Knowledge, provides detailed discussion on SCM.ThisknowledgeareaaddressesSCMinthecontextofasystem,SCMprojectandprocessplanning,SCMplanandoutline,tool selection, subcontractor control, surveillance and other audits, software configuration items and relationships,softwarelibraries,andConfigurationManagementprocessactivities.

NOTE4 TheSCMstrategyiscommonlydocumentedinaplan,e.g.,aconfigurationmanagementplan,orsometimesinaproject’s SEMP, SDP, or Project Management Plan (PMP). The strategy planning for Configuration Management iscoordinated through theProjectPlanningprocess. In establishingpoints to establishbaselines and conduct audits, CMplanning is alignedwith the software life cycle. The frequency of recurring SCM activities alignswith the iteration oftechnical processes and stages. SCM planning typically includes deciding when to review Configuration Managementplanning,whatconditionsrequireupdatingtheCMplan,andwhoisauthorizedtochangetheCMplansanditemsheldinconfigurationcontrol.





2) Definethestorage,archiveandretrievalproceduresforconfigurationitems,CMartifacts,andrecords.

NOTE The locations and conditions of storage for software system configuration items, such as source code andexecutablesoftware,areestablishedinaccordancewithdesignatedlevelsofintegrity,securityandsafety.

b) Perform configuration identification.Thisactivityconsistsofthefollowingtasks:

1) Select the software system elements to be uniquely identified as configuration items subject toconfigurationcontrol.

EXAMPLEConfiguration items subject to configuration control in software systems usually include system/softwarerequirementsspecifications,interfacespecifications;productandsystemelements(e.g.,softwareobjects,hardware,andservices) while under development, baseline configurations or software versions established for transition betweenstages and as released for operational use;master (“gold”) copies of source code or executable software for differentplatforms or versions; site‐specific configurations in operational use; and information items, such as agreements,architecturemodels,servicedescriptionsandoperationalprocedures;anditemsinenablingsystems.

NOTE1 Uniqueidentificationcanbeappliedtosoftwarecomponents,versions,ortoindividuallylicensedcopies.Theidentifiers are in accordance with relevant standards and product sector conventions, such that the items underconfiguration control are unambiguously traceable to their supplier and to their specifications or equivalent recordeddescriptions.Informationitemsareoftenidentifiedandmanagedseparatelyfromotherconfigurationitems.

NOTE2 Software configuration identifiers facilitate traceability when more than one developer or maintenanceprogrammerisworkingonthesamesoftwarefunction,sothatvariousbranchesofcodecanbesuccessfullyreassembledandtested.

NOTE3 TheISO/IEC19770standard(multipleparts)providesanITAssetmanagementsystemfortrackingsoftwarelicenses.

2) Identifytheattributesofconfigurationitems.

NOTE1 Attributesreferstoitemstatus,orphysicalorlogicalfeaturesusefulformanagingormaintainingthesoftwaresystem.Appropriateattributescandifferforhardwareandsoftwareconfigurationitems.

NOTE2 Configuration attributes and identifiers can reflect a decomposition of the software system, so thatconfigurationitemsaretrackedatthelevelatwhichchangeneedstobecontrolled.

EXAMPLESoftware from external suppliers can be tracked by its license and maintenance agreement, which caninvolvetrackingtothelocation,numberorsizeofsystemswhereit isusedorthenumberofconcurrentusersallowed.Softwareversionscanbetracedtothestakeholderrequirementswhichtheyimplement.

3) Definebaselinesthroughthelifecycle.

NOTE1 Baselinescapturetheevolvingconfigurationstatesofsoftwaresystemelementsatdesignatedtimesorunderdefinedcircumstances.Thecontentforthebaselinesisdevelopedthroughthetechnicalprocesses,butisformalizedatapointintimethroughtheConfigurationManagementprocess.Baselinesformthebasisforsubsequentchanges.Selectedbaselinestypicallybecomeformalizedbetweenacquirerandsupplier,dependingonthepracticesoftheindustryandthecontractualinvolvementoftheacquirerintheconfigurationmanagementprocess.Therearegenerallythreemajortypesofbaselinesat thesystem level: functionalbaseline,allocatedbaseline,andproductbaseline.Thesevarybydomainorlocalstrategy.

NOTE2 Softwaresystemsdevelopmentoftenentailsestablishingmultipledevelopmentalbaselinestoaddressevolvingsoftware configurationneedsatkeypoints in the life cycle, e.g., toallow for simultaneous controlof softwareversionsduringsoftwaredesign,prototype,integration,andtestreleases.Thiscaninvolvedistributedconfigurationmanagementresponsibilitiesandaccesslimitationsforarchives,e.g.,softwaredevelopmentortestlibrariesandamasterconfigurationsupportlibrary.

4) Obtainacquirerandsupplieragreementtoestablishabaseline.

NOTE TheProjectAssessmentandControlprocessisusedtoreachagreement.Whensoftwareisbeingdevelopedforcommercialorinternaluse,theacquirerorprojectsponsorcanbetheauthoritytoapproveabaseline.

c) Perform configuration change managementThisactivityconsistsofthefollowingtasks:




NOTE Configurationchangemanagementestablishesproceduresandmethodsformanagingchangetoabaselineonceit isestablished.This issometimesreferred toasconfigurationcontrol.Theterm ‘changemanagement’ isalsousedformanagingchangetoorganizationalproceduresandbusinessworkflow.

1) IdentifyandrecordRequestsforChangeandRequestsforVariance.

NOTE Arequestforvarianceisoftenreferredtoasadeviation,waiver,orconcession.

2) Coordinate,evaluate,anddispositionRequestsforChangeandRequestsforVariance.

NOTE1 Evaluationcommonlyincludesanalysisofrationaleandneedversusimpactonthesoftwareandinteroperatingsystems, considering risks and opportunities, quality, users, schedule, and cost. A decision is made on whether toimplementordenythechangerequest.

NOTE2 RequestsforChangeandRequestsforVarianceareoftenundertheformalcontrolofaConfigurationControlBoard(CCB).

3) Trackandmanageapprovedchangestothebaseline,RequestsforChangeandRequestsforVariance.

NOTE1 Thistaskinvolvesprioritization,tracking,scheduling,andclosingchanges.ChangesarethenmadethroughtheTechnicalProcesses.These changesareverifiedorvalidated through theVerificationandValidationprocesses, tohelpensurethattheapprovedchangeshavebeencorrectlyapplied.

NOTE2 Changesandrationalesaretypicallyrecordedwhenapprovedandwhencompleted.

d) Perform release control.Thisactivityconsistsofthefollowingtasks:

1) Identifyandrecordreleaserequests,identifyingthesoftwaresystemelementsinarelease.

NOTE1 The life cycle model helps determine the frequency of iterative or incremental software releases. TheIntegrationprocessisusedtoselectandconfigureareleasepackage,softwareversion,updateorpatch.ThesechangesareverifiedorvalidatedthroughtheVerificationorValidationprocesses.ChangesaremadethroughtheTechnicalprocesses,particularlyTransition.

EXAMPLE Releasesforasoftwaretest,forsoftwareorsystemqualificationorotherformaltests,orfortrial(beta)oroperationaluse.

2) Approvesoftwaresystemreleasesanddeliveries.

NOTE1 Releases often involve prioritization, tracking, scheduling, and closing changes. Approval of a release foroperational use can include acceptance of the verified and validated changes. Criteria for approval of a release oftenincludesrollbackplansorcontingencyplansintheeventofanunsuccessfulrelease.

NOTE2 For software systems, automated version control tools can help ensure that only the correct source codeversionsareaccessed,updated,testedanddocumentedforapprovedchangesbyappropriatepersonnel,andreleased.

3) Track and manage distribution of software system releases to specified environments or softwaredeliveries.

NOTE Mastercopiesorcopiesof incrementalchangestoreleasedsoftwareversionscanbemaintainedforthe lifeofthesystemorprojectinacontrolledenvironment.Softwaresuppliersoftentrackdeliveredcopiesoflicensedsoftwaretotheacquirerinordertoprovideagreedsoftwaremaintenance.Thesoftwaresystemreleaseisstoredanddistributedinaccordancewithagreementandwiththepoliciesoftheorganizationsinvolved.

e) Perform configuration status accounting.Thisactivityconsistsofthefollowingtasks:

1) DevelopandmaintaintheCMstatusinformationforsoftwaresystemelements,baselines,andreleases.

NOTE1 Configuration status accounting provides the data on the status of controlled products needed to makedecisions regarding system elements throughout the product life cycle. For example, software status can include past,current,andplannedprogressionthroughstagesinthelifecycleforsoftwarefunctionsandcompletionofverificationandvalidationactivitiesforsoftwareelements.Configurationstatusinformationpermitsforwardandbackwardtraceabilitytootherconfigurationstates.Configurationstatusrecordsaremaintainedthroughthesoftwareorprojectlifecycleandthenarchivedaccordingtoagreements,relevantlegislationororganizationalpractice.





NOTE2 The recording, retrieval and consolidation of the current configuration status and the status of previousconfigurationstoconfirminformationcorrectness,timeliness,integrityandsecurityismanaged.Auditsareperformedtoverifyconformanceofabaselinetoanarchitectureview,interfacecontroldocuments,softwarelicenseagreements,andotheragreementrequirements.

2) Capture,storeandreportconfigurationmanagementdata.

f) Perform configuration evaluation.Thisactivityconsistsofthefollowingtasks:

1) IdentifytheneedforCMaudits,andscheduletheevents.

2) Verify the product configuration meets the configuration requirements by comparing requirements,constraints, and waivers (variances) with results of formal verification activities, which can involvesamplingmethods.

3) Monitortheincorporationofapprovedconfigurationchanges.

4) Assess whether the software systemmeets functional and performance capabilities identified for thebaseline.

NOTE This is sometimes called a functional configuration audit (FCA),which assures that theproduct configurationmeetsspecifiedrequirements.

5) Assess whether the operational software system elements conform to the approved configurationinformation.

NOTE Thisissometimescalledaphysicalconfigurationaudit(PCA).Forsoftwareitems,criteriaforthePCAcanincludewhetherspecifiedconfigurationitemsareinstalledondesignatedsystemsaccordingtosoftwarelicenseoragreement.

6) RecordtheCMauditresultsanddispositionactionitems.

6.3.6 Information Management process

6.3.6.1 Purpose

ThepurposeoftheInformationManagementprocess is togenerate,obtain,confirm,transform,retain,retrieve,disseminateanddisposeofinformation,todesignatedstakeholders.

Informationmanagementplans, executes, and controls theprovisionof information todesignated stakeholdersthatisunambiguous,complete,verifiable,consistent,modifiable,traceable,andpresentable.Informationincludestechnical,project,organizational,agreement,anduserinformation.Informationisoftenderivedfromdatarecordsoftheorganization,system,process,orproject.

NOTE Managedinformationhasthesequalitycharacteristics:unambiguous,complete,verifiable,consistent,modifiable,traceable,andpresentable.

6.3.6.2 Outcomes

AsaresultofthesuccessfulimplementationoftheInformationManagementprocess:

a) Informationtobemanagedisidentified.

b) Informationrepresentationsaredefined.

c) Informationisobtained,developed,transformed,stored,validated,presented,anddisposedof.

d) Thestatusofinformationisidentified.

e) Informationisavailabletodesignatedstakeholders.





TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheInformationManagementprocess.

NOTE ISO/IEC/IEEE 15289 summarizes requirements for the content of life cycle process information items(documentation)andprovidesguidanceontheirdevelopment.

a) Prepare for information management.Thisactivityconsistsofthefollowingtasks:

1) Definethestrategyforinformationmanagement.

NOTE Informationaboutthesametopiccanbedevelopedindifferentwaysatdifferentpointsinthelifecycleandfordifferentaudiences.

2) Definetheitemsofinformationthatwillbemanaged.

NOTE Thisincludestheinformationthatwillbemanagedduringthesoftwarelifecycleandpossiblymaintainedforadefinedperiodbeyond.Thisisdoneaccordingtoorganizationalpolicy,agreements,orlegislation.

3) Designateauthoritiesandresponsibilitiesforinformationmanagement.

NOTE Due regard is paid to information and data legislation, security and privacy, e.g., ownership, agreementrestrictions, rights of access to data and ownership of data, intellectual property and patents. Where restrictions orconstraintsapply, informationis identifiedaccordingly.Staffmemberswithknowledgeofsuchitemsofinformationareinformedoftheirobligationsandresponsibilities.

4) Definethecontent,formatsandstructureofinformationitems.

NOTE The informationoriginatesand terminates inmany forms (e.g., audiovisual, textual, graphical,numerical)andmediums (e.g., electronic, printed,magnetic, optical). Organization constraints, e.g., infrastructure, inter‐organizationalcommunications, and distributed project workings, are taken into account. Relevant information item standards andconventionsareusedaccordingtopolicy,agreementsandlegislationconstraints.

5) Defineinformationmaintenanceactions.

NOTE Informationmaintenanceincludesstatusreviewsofstoredinformationforintegrity,validityandavailability.Italso includes any needs for replication or transformation to an alternative medium, as necessary, either to retaininfrastructure as technology changes so that archived media can be read or to migrate archived media to newertechnology.

b) Perform information management.Thisactivityconsistsofthefollowingtasks:

1) Obtain,develop,ortransformtheidentifieditemsofinformation.

NOTE Thisincludescollectingthedata,information,orinformationitemsfromappropriatesources(e.g.,resultingfromany life cycleprocess), andwriting, illustrating,or transforming it intousable information for stakeholders. It includesreviewing,validating,andeditinginformationperinformationstandards.

2) Maintaininformationitemsandtheirstoragerecords,andrecordthestatusofinformation.

NOTE1 Informationitemsaremaintainedaccordingtotheirintegrity,securityandprivacyrequirements.Thestatusofinformation items ismaintained,(e.g.,versiondescription,dateof issueorvaliditydate,recordofdistribution,securityclassification).Legibleinformationisstoredandretainedinsuchawaythatitisreadilyretrievable.

NOTE2 The source data and tools used to transform information, alongwith the resulting documentation is placedunder configuration control in accordancewith the ConfigurationManagement process. ISO/IEC/IEEE 26531providesrequirementsforcontentmanagementsystemsusefulforlifecycleinformationanddocumentation.

3) Publish,distributeorprovideaccesstoinformationandinformationitemstodesignatedstakeholders.

NOTE Informationisprovidedtodesignatedstakeholdersinanappropriateform,asrequiredbyagreedschedulesordefined circumstances. Information items include documentation used for certification, accreditation, license orassessmentratings,asrequired.





4) Archivedesignatedinformation.

NOTE Archivingisdoneinaccordancewiththeaudit,knowledgeretention,andprojectclosurepurposes.Themedia,locationandprotectionoftheinformationareselectedinaccordancewiththespecifiedstorageandretrievalperiods,andwithorganizationpolicy,agreementsandlegislation.Arrangementsareputinplacetoretainnecessaryinformationitemsafterprojectclosure.

5) Disposeofunwanted,invalidorunvalidatedinformation.

NOTE Thisisdoneaccordingtoorganizationpolicy,andsecurityandprivacyrequirements.

6.3.7 Measurement process

6.3.7.1 Purpose

The purpose of the Measurement process is to collect, analyze, and report objective data and information tosupporteffectivemanagementanddemonstratethequalityoftheproducts,services,andprocesses.

NOTE Measureshavethesequalitycharacteristics:verifiable,meaningful,actionable,timely,andcost‐effective.

6.3.7.2 Outcomes

AsaresultofthesuccessfulimplementationoftheMeasurementprocess:

a) Informationneedsareidentified.

b) Anappropriatesetofmeasures,basedontheinformationneeds,isidentifiedordeveloped.

c) Requireddataiscollected,verified,andstored.

d) Thedataisanalyzedandtheresultsinterpreted.

e) Informationitemsprovideobjectiveinformationthatsupportsdecisions.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheMeasurementprocess.

NOTE1 ISO/IEC 15939 provides a more detailed set of measurement activities and tasks that are aligned with theactivitiesandtasksinthisdocument.

NOTE2 ISO9001:2015specifiesQualityManagementSystemrequirementsformeasurementandmonitoring.

a) Prepare for measurement. Thisactivityconsistsofthefollowingtasks:

1) Definethemeasurementstrategy.

2) Describethecharacteristicsoftheorganizationthatarerelevanttomeasurement,suchasbusinessandtechnicalobjectives.

3) Identifyandprioritizetheinformationneeds.

NOTE Theinformationneedsarebasedontheorganization’sbusinessobjectives,theprojectobjectives,identifiedrisks,andotheritemsrelatedtoprojectdecisions.Measurementscanrelatetoprojects,processes,products,ordecisions.

4) Selectandspecifymeasuresthatsatisfytheinformationneeds.

NOTE Measuresaredefinedthatareverifiableandcost‐effective.

5) Definedatacollection,analysis,access,andreportingprocedures.




6) DefinecriteriaforevaluatingtheinformationitemsandtheMeasurementprocess.

7) Identifyandplanforthenecessaryenablingsystemsorservicestobeused.

b) Perform measurement. Thisactivityconsistsofthefollowingtasks:

1) Integratemanualorautomatedproceduresfordatageneration,collection,analysisandreportingintotherelevantprocesses.

NOTE Thistaskcaninvolvechangeimpactstootherlifecycleprocessestoaccomplishproceduralintegration.

2) Collect,store,andverifydata.

3) Analyzedataanddevelopinformationitems.

4) Recordresultsandinformthemeasurementusers.

NOTE Themeasurementanalysisresultsarereportedtorelevantstakeholders inatimely,usable fashiontosupportdecisionmakingandassist incorrectiveactions,riskmanagement,and improvements.Resultsarereportedtodecisionprocess participants, technical and management review participants, and product and process improvement process owners.

6.3.8 Quality Assurance process

6.3.8.1 Purpose

The purpose of the Quality Assurance process is to help ensure the effective application of the organization’sQualityManagementprocesstotheproject.

QualityAssurancefocusesonprovidingconfidencethatqualityrequirementswillbefulfilled.Proactiveanalysisoftheprojectlifecycleprocessesandoutputsisperformedtoassurethattheproductbeingproducedwillbeofthedesiredqualityandthatorganizationandprojectpoliciesandproceduresarefollowed.

6.3.8.2 Outcomes

AsaresultofthesuccessfulimplementationoftheQualityAssuranceprocess:

a) Projectqualityassuranceproceduresaredefinedandimplemented.

b) Criteriaandmethodsforqualityassuranceevaluationsaredefined.

c) Evaluations of the project’s products, services, and processes are performed, consistent with qualitymanagementpolicies,procedures,andrequirements.

d) Resultsofevaluationsareprovidedtorelevantstakeholders.

e) Incidentsareresolved.

f) Prioritizedproblemsaretreated

NOTE Outcomesa)throughd)alignwiththeoutcomesoftheQualityManagementprocessactivitiesandtasks.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheQualityAssuranceprocess.

NOTE IEEEStd730‐2014,Software Quality Assurance Processes,providesadditionaldetail.

a) Prepare for quality assurance. Thisactivityconsistsofthefollowingtasks:





1) Define a Quality Assurance strategy. The strategy is consistent with the organizational QualityManagementpoliciesandobjectivesandincludes:

i) Priorities for applyingQuality Assurance resources to processes and tasks that have themostsignificantimpactonthequalityofthedeliveredproductsandservices;

ii) Definedroles,responsibilities,accountabilities,andauthorities;

iii) Evaluation criteria and methods for processes, products, and services, including criteria forproductorserviceacceptance;

iv) Activitiesappropriatetoeachsupplier(includingsubcontractors);

v) Required verification, validation, monitoring, measurement, review, inspection, audit, and testactivitiesspecifictotheproductsorservices;and

vi) Problemresolutionandprocessandproductimprovementactivities.

NOTE Insoftwareprojects,activitiesandtasksthathavesignificantimpactonproductqualityincludeobtainingagreement on new and changed requirements, performance of peer reviews and unit testing, analysis of problemreportsandfeedbackfromusers;validatingcompletionofcorrectiveactionsassignedatprojectmilestonereviews,androotcauseanalysisofdefects.

2) Establishindependenceofqualityassurancefromotherlifecycleprocesses.

NOTE Resources for quality assurance are often assigned from distinct organizations for independence fromprojectmanagement.

b) Perform product or service evaluations. Thisactivityconsistsofthefollowingtasks:

1) Evaluate products and services for conformance to established criteria, contracts, standards, andregulations.

NOTE This task includes verifying if criteria for product or service acceptance are reflected in verification andvalidation activities. Derived system/software quality requirements are usually associatedwith quality characteristicsduring requirements definition processes. ISO/IEC 25010 and ISO/IEC 25030 provide additional information onsystem/softwarequalitycharacteristics.

2) Monitor that verification and validation of the outputs of the life cycle processes are performed todetermineconformancetospecifiedrequirements.

c) Perform process evaluations.Thisactivityconsistsofthefollowingtasks:

1) Evaluateprojectlifecycleprocessesforconformance.

2) Evaluatetoolsandenvironmentsthatsupportorautomatetheprocessforconformance.

3) Evaluatesupplierprocessesforconformancetoprocessrequirements.

NOTE Consideritemssuchasacollaborativesoftwaredevelopmentenvironment,processmeasuresthatsuppliersarerequired toprovide, or a riskprocess that suppliers are required touse.This includes surveillance reviewsofprocessimplementationthroughthesupplychain.

d) Manage QA records and reports.Thisactivityconsistsofthefollowingtasks:

1) Createrecordsandreportsrelatedtoqualityassuranceactivities.

NOTE Create recordsandreports inaccordancewithorganizational, regulatory,andproject requirements,using theinformationmanagementprocess.

2) Maintain,store,anddistributerecordsandreports.

3) Identifyincidentsandproblemsassociatedwithproduct,service,andprocessevaluations.




NOTE Thisincludesthecaptureoflessonslearned.Responsibilitiesforresolutionareidentified.

e) Treat incidents and problems. Thisactivityconsistsofthefollowingtasks:

NOTE1 In the terminology of qualitymanagement, problems are oftendescribed as “non‐conformities”when, if leftuntreated,theycancausetheprojecttofailtomeetitsrequirements.

NOTE2 For additional information and examples of problem categories and priority classifications, see ISO/IEC TS24748‐1:2016,AnnexC.

1) Record,analyzeandclassifyincidents.

2) Identifyselectedincidentstoassociatewithknownerrorsorproblems.

3) Record,analyzeandclassifyproblems.

NOTE Analysisresultsincludepotentialtreatmentoptions.

4) Identifyrootcausesandtreatmentofproblemswherefeasible.

5) Prioritizetreatmentofproblems(problemresolution)andtrackcorrectiveactions.

NOTE ImplementationisdoneintheTechnicalprocessesafterinitiationbytheProjectAssessmentandControlprocess.Organizationalproceduresforproblemescalationcanhelpfocusresourcesonlaggingproblemresolutions.

6) Analyzetrendsinincidentsandproblems.

7) Identifyimprovementsinprocessesandproductsthatmaypreventfutureincidentsandproblems.

NOTE The Risk Management process is used to treat risks and opportunities. The Life Cycle Model Managementprocessisusedtoimprovetheorganization’sprocesses.

8) Informdesignatedstakeholdersofthestatusofincidentsandproblems.

9) Trackincidentsandproblemstoclosure.

6.4 Technical processes

TheTechnicalprocessesareusedtodefinetherequirementsforasoftwaresystem,totransformtherequirementsintoaneffectiveproduct,topermitconsistentreproductionoftheproductwherenecessary,tousetheproducttoprovidetherequiredservices,tosustaintheprovisionofthoseservices,andtodisposeoftheproductwhenitisretiredfromservice.

The Technical processes define the activities that enable organization and project functions to optimize thebenefits and reduce the risks that arise from technical decisions and actions. These activities enable softwaresystems and services to possess the timeliness and availability, cost effectiveness, functionality, reliability,maintainability, producibility, usability, and other qualities required by acquiring and supplying organizations.They also enable products and services to conform to the expectations or legislated requirements of society,includinghealth,safety,security,andenvironmentalfactors.

TheTechnicalprocessesconsistofthefollowing:

a) BusinessorMissionAnalysisprocess;

b) StakeholderNeedsandRequirementsDefinitionprocess;

c) System/SoftwareRequirementsDefinitionprocess;

d) ArchitectureDefinitionprocess;

e) DesignDefinitionprocess;





f) SystemAnalysisprocess;

g) Implementationprocess;

h) Integrationprocess;

i) Verificationprocess;

j) Transitionprocess;

k) Validationprocess;

l) Operationprocess;

m) Maintenanceprocess;and

n) Disposalprocess.

NOTE1 Forsoftwaresystems,theseprocessescanberecursivelyappliedatmoreinclusiveormoredetailedlevelsforsoftwaresystemdefinitionandrealization.

NOTE2 For software systems, these processes are often performed concurrently, iterating between one another toestablish a solution that has satisfactory trade‐offs with respect to requirements, critical performance measures, andcriticalqualitycharacteristics.Atanylevelofabstraction,requirementsandmodelsaremadeconsistentviaiterationsofapplicable technical processes. When requirements and models are not directly capable of being implemented, thetechnicalprocessesareappliedrecursivelyatamoredetailedlevelorthroughdifferentsystemviews.

NOTE3 Theconceptof lifecyclestagesandtheapplicationof theseprocesses inanystagearedescribed indetail inISO/IECTS24748‐1.Ithasacompletesetofexamplestagesandstageoutcomesfortheenactmentoftechnicalprocesseswithinasoftwarelifecycle.

NOTE4 Interfacemanagementisasetofactivitiesthatcutacrosssoftwareengineeringprocesses.Thesecross‐cuttingactivitiesoftheTechnicalandTechnicalManagementprocessesapplyandtrackasaspecificviewoftheprocessesandsoftwaresystem.SeeAnnexE(E.5)foranexampleofanInterfaceManagementprocessview.

NOTE5 ISO/IEC 27002 Code of practice for information security controls and ISO/IEC 27034 Application security,provideguidanceforapplyingsecurityconcernsintheTechnicalprocessesforsoftwaresystems.SeeAnnexE(E.6)forasampleSoftwareAssuranceProcessView.

6.4.1 Business or Mission Analysis process

6.4.1.1 Purpose

The purpose of the Business or Mission Analysis process is to define the business or mission problem oropportunity, characterize the solution space, and determine potential solution class(es) that could address aproblemortakeadvantageofanopportunity.

NOTE1 Business and Mission Analysis is related to the organization encompassing stakeholders concerned by theactivitiesofthesoftwarelifecycle.Thisprocessinteractswiththeorganization’sstrategy,whichisgenerallyoutsidethescopeofISO/IEC/IEEE12207.Theresultsoftheorganization’sstrategicanalysisincludetheorganizationalConceptofOperations,strategic goals and plans, newmarket ormission elements, and identified problems and opportunities. The organization'sstrategy establishes the contextwithinwhich thebusinessormissionanalysis is performed.TheorganizationalConceptofOperationsrelatestotheleadership’sintendedwayofoperatingtheorganization.Itdescribestheorganization’sassumptionsandhow it intends to use, acquire, or supply the system to be developed, existing systems, and possible future systems insupport of an overall operation or series of operations of the business. In the case that the organization is the system‐of‐interest,theorganization’sstrategyispartofthesystemdefinition.

NOTE2 This process has application through the life of the software system solution and can be revisited if there arechangesintheenvironment,needs,orotherdrivers.

NOTE3 Insomedomains,BusinessorMissionAnalysisrelatestotheconceptofidentifyingandanalyzingcapabilitiesthatareneededordesiredbytheorganization.ThisprocessfocusesonthenecessarycapabilitiesandinteractswiththePortfolioManagementprocessforidentifyingthetradespacethatcanaddressthecapability.Theidentifiedproblemsoropportunities




areoftentranslatedintotargetcapabilities.Asapplicablewithinagivendomain,theproblemoropportunityspaceincludesthetargetcapabilities.

6.4.1.2 Outcomes

AsaresultofthesuccessfulimplementationoftheBusinessorMissionAnalysisprocess:

a) Theproblemoropportunityspaceisdefined.

b) Thesolutionspaceischaracterized.c) Preliminaryoperationalconceptsandotherconceptsinthelifecyclestagesaredefined.d) Candidatealternativesolutionclassesareidentifiedandanalyzed.e) Thepreferredcandidatealternativesolutionclass(es)areselected.f) Anyenablingsystemsorservicesneededforbusinessormissionanalysisareavailable.g) Traceability of business or mission problems and opportunities and the preferred alternative

solutionclassesisestablished.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheBusinessorMissionAnalysisprocess.

a) Prepare for Business or Mission Analysis. Thisactivityconsistsofthefollowingtasks:

1) Review identified problems and opportunities in the organization strategy with respect to desiredorganizationgoalsorobjectives.

NOTE Thisincludesproblemsoropportunitieswithrespecttotheorganizationbusinessormission,vision,ConceptofOperations,andotherorganizationstrategicgoalsandobjectives.Thisincludesidentifieddeficienciesorgapsinexistingcapabilities,systems,products,orservices.

2) Definethebusinessormissionanalysisstrategy.

NOTE Thisincludestheapproachtobeusedtoidentifyanddefinetheproblemspace,characterizethesolutionspaceandselectasolutionclass.

3) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportbusinessormissionanalysis.

NOTE Thisincludesidentificationofrequirementsandinterfacesforenablingsystems.Enablingsystemsforbusinessormissionanalysisincludethebusinesssystemsandrepositoriesoftheorganizationorotheraccessibleentities.

4) Obtainoracquireaccesstotheenablingsystemsorservicestobeused.

NOTE TheValidationprocessisusedtoobjectivelyconfirmthattheenablingsystemachievesits intendeduseforitsenablingfunctions.

b) Define the problem or opportunity space.Thisactivityconsistsofthefollowingtasks:

1) Analyzecustomercomplaints,problemsandopportunitiesinthecontextofrelevanttrade‐spacefactors.

NOTE1 This analysis is focused on understanding the scope, basis, or drivers of the problems or opportunities, asopposedtothesynthesisthatisthefocusofsystemanalysisanddecisionmanagementneededfortradestudies.Thefocushereincludeschangesinmissionrequirements,businessopportunities,capabilities,performanceimprovement,orlackofexisting systems, security and safety improvement, factors such as cost and effectiveness, regulation changes, userdissatisfaction,andPESTELfactors(Political,Economic,Social,Technological,Environmental,andLegal).Relevantfactorscanbeidentifiedthroughexternal,internal,orSWOT(Strengths,Weaknesses,OpportunitiesandThreats)analysis.





NOTE2 Theoutputsoftheanalysisareconsideredaspartoftheportfoliomanagementdecisions.

2) Definethemission,business,oroperationalproblemoropportunity.

NOTE This definition includes the context and any key parameters, without regard to a specific solution, since thesolutioncanbeanoperationalchange,achangetoanexistingproductorservice,oranewsystem.

c) Characterize the solution space.Thisactivityconsistsofthefollowingtasks:

1) Definepreliminaryoperationalconceptsandotherconceptsinlifecyclestages.

NOTE1 This involves the identification of major stakeholder groups, such as customers, users, administrations,regulators,andsystemowners,thataredefinedintheStakeholderNeedsandRequirementsDefinitionprocess.

NOTE2 Preliminary life cycle concepts include preliminary acquisition concepts, preliminary deployment concepts,preliminary operational concepts, preliminary support concepts, and preliminary retirement concepts. Operationalconcepts include high level operational modes or states, operational scenarios, potential use cases, or usage within aproposedbusinessstrategy.Theseconceptsenablefeasibilityanalysisandevaluationofalternatives.TheseconceptsarefurtherrefinedwithintheStakeholderNeedsandRequirementsDefinitionprocess.

NOTE3 Theoperatingenvironmentcanhaveknownvulnerabilitiesassociatedwithspecificsecuritythreatsandsafetyhazards.Thesevulnerabilitiesneedtobeunderstoodinassociationwiththeproductunderdevelopment.Thesystemandhumaninterfacesareanelementofthesystemassurancecontextandrelatedvulnerabilitiesareexaminedinthecontextofmission‐criticalthreats.

2) Identifycandidatealternativesolutionclassesthatspanthepotentialsolutionspace.

NOTE These classes can range from simple operational changes to various software system developments ormodifications.Thissolutionspacecanincludetheidentificationofexistingassets,systems,andsoftwareproductssuitablefor reuse, and changes in services that can address theneed for operational or functionalmodifications. This includesdeducing what potential expected services will be needed. The solution space characterization often invokes theArchitectureDefinitionprocess forauserarchitectureviewpoint, resulting inarchitectureviews (e.g., capabilityviews,programviewsandoperationalviews)asproposedbyISO/IEC/IEEE42010.

d) Evaluate alternative solution classes.Thisactivityconsistsofthefollowingtasks:

1) Assesseachalternativesolutionclass.

NOTE1 Each alternative solution class is assessed against defined criteria that are established based on theorganization’s strategy. Feasibility of the solution class is one keydecision criteria. ThePortfolioManagementprocessprovidessomecriteriatobeconsidered.

NOTE2 TheSystemAnalysisprocess isused toassess thevalueof eachcriterion foreachalternative solutionclass.Structured affordability trade‐offs are recommended. Including cost as a criterionwill aid affordability decisions. Theassessmentofalternativescanincludemodeling,simulation,analyticaltechniques,orexpertjudgmenttounderstandtherisks,feasibilityandvalueofthealternativecandidatesolutionclasses.

2) Selectthepreferredalternativesolutionclass(es).

NOTE TheDecisionManagementprocessisusedtoevaluatealternativesandtoguideselection.Selectedalternativesarevalidatedinthecontextoftheorganization’sstrategy.Feedbackonrisks,feasibility,marketfactors,andalternativesisprovidedforuseinupdatingtheorganization’sstrategy.

e) Manage the business or mission analysis.Thisactivityconsistsofthefollowingtasks:

1) Maintaintraceabilityofbusinessormissionanalysis.

NOTE Throughthelifecycle,bidirectionaltraceabilityismaintainedbetweenthebusinessandmissionproblemsandopportunities and the preferred alternative solution classes with the organizational strategy, stakeholder needs andrequirements,andsystemanalysisresultssupportingdecisions.

2) Providekeyartifactsandinformationitemsthathavebeenselectedforbaselines.

NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.Thisprocessidentifiescandidatesforthebaseline,andtheInformationManagementprocesscontrolstheinformationitems.




6.4.2 Stakeholder Needs and Requirements Definition process

6.4.2.1 Purpose

The purpose of the Stakeholder Needs and Requirements Definition process is to define the stakeholderrequirementsforasystemthatcanprovidethecapabilitiesneededbyusersandotherstakeholdersinadefinedenvironment.

It identifies stakeholders, or stakeholder classes, involved with the system throughout its life cycle, and theirneeds. Itanalyzesandtransforms theseneeds intoacommonsetof stakeholderrequirements thatexpress theintended interaction the systemwill havewith its operational environment and that are the reference againstwhich each resultingoperational capability is validated.The stakeholder requirements aredefined consideringthecontextofthesystem‐of‐interestwiththeinteroperatingsystemsandenablingsystems.

NOTE TheSWEBOK, Guide to the Software Engineering Body of Knowledge, SoftwareRequirementsknowledgeareadiscussessoftwarerequirementsfundamentals(e.g.,definition,types,properties,qualitycharacteristics)andother topics, such as stakeholders, requirements elicitation, analysis, andmanagement that provide additionalguidanceforsoftwaresystems.

6.4.2.2 Outcomes

AsaresultofthesuccessfulimplementationoftheStakeholderNeedsandRequirementsDefinitionprocess:

a) Stakeholdersofthesystemareidentified.

b) Required characteristics and context of use of capabilities and concepts in the life cycle stages,includingoperationalconcepts,aredefined.

c) Constraintsonasystemareidentified.d) Stakeholderneedsaredefined.e) Stakeholderneedsareprioritizedandtransformedintoclearlydefinedstakeholderrequirements.f) Criticalperformancemeasuresaredefined.g) Stakeholder agreement that their needs and expectations are reflected adequately in the

requirementsisachieved.h) Anyenablingsystemsorservicesneededforstakeholderneedsandrequirementsareavailable.i) Traceabilityofstakeholderrequirementstostakeholdersandtheirneedsisestablished.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheStakeholderNeedsandRequirementsDefinitionprocess.

a) Prepare for Stakeholder Needs and Requirements Definition.Thisactivityconsistsofthefollowingtasks:

1) Identifythestakeholderswhohaveaninterestinthesoftwaresystemthroughoutitslifecycle.

NOTE This includes individuals and classes of stakeholders who are users, operators, supporters, developers,producers, trainers, maintainers, disposers, acquirer and supplier organizations, parties responsible for externalinterfacing entities, regulatory bodies, and others who have a legitimate interest in the system. Where directcommunication is not practicable (e.g., for consumer products and services), representatives or designated proxystakeholdersareselected.

2) Definethestakeholderneedsandrequirementsdefinitionstrategy.





NOTE Some stakeholders have interests that oppose the acquirer’s interests (e.g., market competitors, hackers,terrorists) or oppose each other.When the stakeholder interests oppose each other, but do not oppose the softwaresystem,thisprocessisintendedtogainconsensusamongthestakeholderclassestoestablishacommonsetofacceptablerequirements.Theintentordesiresofthosethatopposetheacquirers,ordetractorsofthesystem,areaddressedthroughtheRiskManagementprocess,threatanalyzesoftheSystemAnalysisprocess,orthesystem/softwarerequirementsforsecurity,adaptability,orresilience.Inthiscase,thestakeholderneedsarenotsatisfied,butratheraddressedinamannertohelpensuresystemassuranceandintegrityifactionsfromthedetractorsareencountered.

3) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportstakeholderneedsandrequirementsdefinition.

NOTE This includes identification of requirements and interfaces for the enabling systems. Enabling systems forstakeholderneedsandrequirementsdefinitionincludetoolsforfacilitationandrequirementsmanagement.


NOTE TheValidationprocessisusedtoobjectivelyconfirmthattheenablingsystemachievesits intendeduseforitsenablingfunctions.

b) Define stakeholder needs.Thisactivityconsistsofthefollowingtasks:

1) Definecontextofusewithintheconceptofoperationsandthepreliminarylifecycleconcepts.

NOTE Context of use is often captured using a Context of Use Description [ISO/IEC 25063]. Preliminary life cycleconceptsaredevelopedbytheBusinessorMissionAnalysisprocess.

2) Identifystakeholderneeds.

NOTE1 Identificationofstakeholderneedsincludeselicitationofneedsdirectlyfromthestakeholders,identificationofimplicitstakeholderneedsbasedondomainknowledgeandcontextunderstanding,anddocumentedgapsfrompreviousactivities.Needsoftenincludemeasuresofeffectiveness.Functionalanalysisisoftenusedtoaidtheelicitationofneeds.AlsoqualitycharacteristicsofthequalitymodelinISO/IEC25010andqualitymodelapplicationtorequirementsanalysisin ISO/IEC25030areuseful toelicitand identifyqualityrequirementsofnon‐functionalrequirements,whichareoftenimplicitstakeholderneeds.

NOTE2 The SWEBOK, Guide to the Software Engineering Body of Knowledge, Software Requirements knowledge areadiscussessomeadditionaltechniquesforelicitingandclarifyingsoftwarerequirements,suchas,prototyping,observation,userstoriestodeterminerequiredfunctionality,datamining,andanalyzingcompetitors’products.

NOTE3 Stakeholder needs describe the needs, wants, desires, expectations and perceived constraints of identifiedstakeholders. Understanding stakeholder needs for theminimum security and privacy requirements necessary for theoperationalenvironmentminimizesthepotentialfordisruptioninplans,schedules,andperformance.Ifsignificantissuesarelikelytoariserelatingtousersandotherstakeholdersandtheirinvolvementinorinteractionwithasoftwaresystem,recommendationsforidentifyingandtreatinghuman‐systemissuescanbefoundinISOTS18152.

3) Prioritizeanddown‐selectneeds.

NOTE TheDecisionManagement process is typically used to support prioritization. The SystemAnalysis process isusedtoanalyzeneedsforfeasibilityorotherfactors.

4) Definethestakeholderneedsandrationale.

NOTE Needs concentrate on system purpose and behavior, and are described in the context of the operationalenvironmentandconditions.Itisusefultotraceneedstotheirsourcesandrationale.

c) Develop the operational concept and other life cycle concepts. This activity consists of the followingtasks:

NOTE Other life cycle concepts can include acquisition concepts, deployment concepts, support concepts, securityconcepts, and retirement concepts. In this activity, the preliminary life cycle concepts defined within the Business orMissionAnalysisprocessarefurtherdevelopedinthecontextofspecificstakeholderneeds,asassociatedscenariosandinteractionsaredefined.See ISO/IEC/IEEE29148:2011Clauses5and6 formore informationonoperational concepts,andISO/IEC/IEEE29148:2011AnnexAforanannotatedoutlineofaSystemOperationalConcept.




1) Define a representative set of scenarios to identify the required capabilities that correspond toanticipatedoperationalandotherlifecycleconcepts.

NOTE1 Scenarios are used to analyze the operation of the system in its intended environment in order to identifyadditionalneedsorrequirementsthatperhapshavenotbeenexplicitly identifiedbyanyofthestakeholders,e.g., legal,regulatoryandsocialobligationsThecontextofuseofthesystemisidentifiedandanalyzed,includingtheactivitiesthatusers perform to achieve system objectives, the relevant characteristics of the users (e.g., expected training andknowledge, frequency of system use, responsibilities, accessibility concerns), the physical environment (e.g., availablelight, temperature) and any equipment to be used (e.g., protective or communication equipment). The social andorganizationalinfluencesonusersthataffectsystemuseorconstrainitsdesignareanalyzedwhenapplicable.Scenarioscentered on attackers, their environments, tools, techniques, and capabilities are key considerations for operationalconcept development. Scenarios are prioritized in order to reflect theweighted importance of the various operationalneeds.

NOTE2 These scenarios often motivate updates to the operational or other life cycle concepts. Abuse and failurescenarioshighlighttheneedforadditional functionalrequirements(ormorespecificderivedrequirements)tomitigaterisksthatareidentifiedintheabuseorfailurescenarios.

2) Identifythefactorsaffectinginteractionsbetweenusersandthesystem.

i) Anticipatedphysical,mental,andlearnedcapabilitiesoftheusers;

ii) Workplace,environmentandfacilities,includingotherequipmentinthecontextofuse;

iii) Normal,unusual,andemergencyconditions;and

iv) Operatoranduserrecruitment,trainingandculture.

NOTE1 Usabilityrequirementstakeintoaccounthumancapabilitiesandskillslimitations.Wherepossible,applicablestandards,e.g.,ISO9241,andacceptedprofessionalpracticesareused.

NOTE2 Ifusabilityisimportant,usabilityrequirementsareplanned,specified,andimplementedthroughthelifecycleprocesses.Refer to ISOTS18152for informationonhuman‐systemissuesandISO/IEC25060:2010for informationonusability.

d) Transform stakeholder needs into stakeholder requirements. This activity consists of the followingtasks:

1) Identifytheconstraintsonasystemsolution.

NOTE These constraints can result from 1) instances or areas of stakeholder‐defined solution; 2) implementationdecisionsmadeathigherlevelsofsystemhierarchicalstructure;3)requireduseofdefinedenabling,legacy,orinterfacingsystems,systemelements,resources,andstaff;or4)stakeholder‐definedaffordabilityobjectives.Includethosethatareunavoidableconsequencesofexistingagreements,managementdecisionsandtechnicaldecisions.

2) Identifythestakeholderrequirementsandfunctionsthatrelatetocriticalqualitycharacteristics,suchasassurance,safety,security,environment,orhealth.

NOTE1 SeeISO/IEC/IEEE15026foradditionalinformationonsystemandsoftwareassurance.

NOTE2 Identifyingsafetyrisks facilitates the identificationofsafetyrequirementsandfunctions.Safetyrisks includethose associated with methods of operations and support, health and safety, threats to property and environmentalinfluences.Useapplicablestandards,andacceptedprofessionalpractices.Forexample,IEC61508:2010,Functional safety of electrical/electronic/programmable electronic safety-related systems,providesdetailedrequirements.

NOTE3 Identifying security risks facilitates the identification of additional security requirements and functions. Ifwarranted, include applicable areas of system security, such as physical, procedural, communications, computers,programs, data and emissions. This includes access and damage to protected personnel, properties and information,compromiseofsensitiveinformation,anddenialofapprovedaccesstopropertyandinformation.Thisalsoincludestherequired security functions, such as mitigation and containment, referencing applicable standards and acceptedprofessionalpracticeswheremandatoryorrelevant.SeeAnnexE(E.6)foralifecyclesoftwareassuranceview.

NOTE4 SeeISO/IEC25030forfurtherinformationregardingqualitycharacteristicsfromaqualityinuseperspective.





3) Definestakeholderrequirements,consistentwithlifecycleconcepts,scenarios,interactions,constraints,andcriticalqualitycharacteristics.

NOTE1 SeeISO/IEC/IEEE29148:2011Clauses5and6formoreinformationonstakeholderrequirements,andClauses8and9foradescriptionofandanannotatedoutlineforaStakeholderRequirementsSpecification.

NOTE2 Thestakeholderrequirementsarereviewedatkeydecisiontimesinthelifecycletohelpensurethataccountistakenofchangesinneeds.

NOTE3 Thestakeholderrequirementsarerecordedinaformsuitableforrequirementsmanagementthroughthelifecycle. These records establish the stakeholder requirements baseline, and retain changes of need and their originthroughout the software life cycle. These records are the basis for traceability to decisions made by the Business orMissionAnalysisprocessaswellasstakeholderneeds,systemrequirements,andsubsequentsoftwaresystemelements.

NOTE4 Thestakeholderrequirementsarethebasisofthevalidationcriteriaforthesoftwaresystemanditselements.

e) Analyze stakeholder requirements. Thisactivityconsistsofthefollowingtasks:

1) Analyzethecompletesetofstakeholderrequirements.

NOTE1 Stakeholderrequirementsareanalyzedforcharacteristicsofindividualrequirements,aswellascharacteristicsofthesetofrequirements.Potentialanalysischaracteristicsincludethattherequirementsarenecessary,implementation‐free,unambiguous, consistent, complete, singular, feasible, traceable, verifiable, affordable, andbounded. ISO/IEC/IEEE29148providesadditionalinformationoncharacteristicsofrequirements.

NOTE2 The System Analysis process is used to assess feasibility and affordability. The Verification and Validationprocessesareusedinthereviewofstakeholderrequirements.

2) Definecriticalperformancemeasuresthatenabletheassessmentoftechnicalachievement.

NOTE Thisincludesdefiningtechnicalandqualitymeasuresandcriticalperformanceparametersassociatedwitheacheffectivenessmeasure identified in thestakeholder requirements.Thecriticalperformancemeasures (e.g.,measuresofeffectivenessandmeasuresofsuitability)aredefined,analyzedandreviewedtohelpensurestakeholder requirementsare met and to help ensure identification of project cost, schedule or performance risk associated with any non‐compliance.ISO/IEC15939providesaprocesstoidentify,defineanduseappropriatemeasures.INCOSETP‐2003‐020‐01,Technical Measurement, provides information on the selection, definition and implementation of critical performancemeasures.TheISO/IEC25000seriesofstandardsprovidesrelevantqualitymeasures.

3) Feed back the analyzed requirements to applicable stakeholders to validate that their needs andexpectationshavebeenadequatelycapturedandexpressed.

4) Resolvestakeholderrequirementsissues.

NOTE This includes requirements that violate the characteristics for individual requirements or the set ofrequirementsasdefinedinISO/IEC/IEEE29148.

f) Manage the stakeholder needs and requirements definition.Thisactivityconsistsofthefollowingtasks:

1) Obtainexplicitagreementwithdesignatedstakeholdersonthestakeholderrequirements.

NOTE Thisincludesconfirmingthatstakeholderrequirementsareexpressedcorrectly,comprehensibletooriginators,andthattheresolutionofconflictintherequirementshasnotcorruptedorcompromisedstakeholderintentions.

2) Maintaintraceabilityofstakeholderneedsandrequirements.

NOTE Throughthelifecycle,bidirectionaltraceabilityismaintainedbetweenthestakeholderneedsandrequirements,organizational strategy, andbusinessandmissionproblemsandopportunities. Stakeholder requirementsare traced tothe system/software requirements during the System/Software Requirements Definition process. Traceability is oftenmaintainedusinganappropriatedatarepository.


NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.Thisprocess identifiescandidatesforthebaseline,andtheInformationManagementprocesscontrolsthe informationitems.




Forthisprocess,thestakeholderneeds,stakeholderrequirements,andoperationalconceptaretypicalinformationitemsthatarebaselined.

6.4.3 System/Software requirements definition process

6.4.3.1 Purpose

The purpose of the System/Software Requirements Definition process is to transform the stakeholder, user‐orientedviewofdesiredcapabilities intoa technicalviewofasolutionthatmeets theoperationalneedsof theuser.

Thisprocesscreatesasetofmeasurablesystemrequirementsthatspecify,fromthesupplier’sperspective,whatcharacteristics, attributes, and functional and performance requirements the system is to possess, in order tosatisfy stakeholder requirements. As far as constraints permit, the requirements should not imply any specificimplementation.

NOTE1 Fromahigh‐levelviewofthesoftwaresystem,thisprocesscanbeusedtodefinetheoverallrequirementsofthesystem.Asthesoftwaresystemisdecomposedintoelements,eachelement,inturn,istreatedasasystem,function,orsetoffunctionsandthisprocesscanbeusedtofurtherspecifyrequirements.Requirementsanalyzesandtoolssupporttraceabilityofrequirementsbetweenthesoftwaresystemanditselements.

NOTE2 The SWEBOK, Guide to the Software Engineering Body of Knowledge, Software Requirements knowledge areadiscusses software requirementsdefinition, analysis,modelling, specification, validation,management andother topics thatprovideadditionalguidanceforsoftwaresystems.

NOTE3 Thewordingof theoutcomesof theSystem/SoftwareRequirementsDefinitionprocessdiffers slightly fromtheoutcomesintheSystemRequirementsDefinitionprocessofISO/IEC/IEEE15288:2015.Useofthewording“system/softwarerequirements”emphasizetheapplicabilityofthisdocumenttosoftwaresystems,havingsoftwarerequirementsandsystemsrequirements. Thisisintendedtoassistuserswhodefinesystemsrequirementsandsoftwarerequirementshierarchicallyorindifferentstages.

6.4.3.2 Outcomes

AsaresultofthesuccessfulimplementationoftheSystem/SoftwareRequirementsDefinitionprocess:

a) Thesystemorelementdescription,includinginterfaces,functionsandboundaries,forasystemsolutionisdefined.

b) System/software requirements (functional, performance, process, non‐functional, and interface) anddesignconstraintsaredefined.

c) Criticalperformancemeasuresaredefined.

d) Thesystem/softwarerequirementsareanalyzed.

e) Anyenablingsystemsorservicesneededforsystem/softwarerequirementsdefinitionareavailable.

f) Traceabilityofsystem/softwarerequirementstostakeholderrequirementsisdeveloped.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheSystem/SoftwareRequirementsDefinitionprocess.

a) Prepare for System/Software Requirements Definition.Thisactivityconsistsofthefollowingtasks:

1) Definethefunctionalboundaryofthesoftwaresystemorelementintermsofthebehaviorandpropertiesprovided.

NOTE ThefunctionalboundarydefinitionispartlybasedonthecontextofuseandoperationalscenariosdefinedintheframeoftheStakeholderNeedsandRequirementsDefinitionprocess.Thisincludesthesoftwaresystem’sstimuli(input)





anditsresponsestousersandexternalsystems,andananalysisanddescriptionoftherequiredinteractionsbetweenthesoftware system and its operational environment in terms of interface properties and constraints, such as proceduralflows, calling orders, data formats and flows, throughput, and timing. This establishes the expected software systembehavior, expressed in quantitative terms, at its boundary. For software, boundaries are commonly expressed inApplication Program Interfaces (API) and a graphical user interface (GUI) or interface files or services, including dataformats.AnnexE(E.5)providesaninterfacemanagementviewofthelifecycleprocesses.

2) Definethesystem/softwarerequirementsdefinitionstrategy.

NOTE This includes the approach to beused to identify anddefine, andmanage the system/software requirementswiththeselectedlifecyclemodel,e.g.,evolutionary,incrementaloriterative.Manyfactorscaninfluencethestrategy,e.g.,complexity of the software system and information and functions to bemanaged; need for ready access and commonunderstandingbymultiple teammembers;degreeofcollaborative involvementby theacquireroruserrepresentativesthroughoutthedevelopmentstage;whethertheprojectinvolvesanewdevelopment,amodification,re‐useorintegrationof existing systems; and process documentation requirements including period of retention. The life cycle model willinfluence when and how often the system/software requirements definition will be done. Annex H describes theprogressivedevelopmentofrequirementsinprojectsusingagilemethods.

3) Identify and plan for the necessary enabling systems or services needed to support system/softwarerequirementsdefinition.

NOTE This includes identification of requirements and interfaces for the enabling systems. Enabling systems forrequirements definition include tools for facilitation and requirementsmanagement. Tools for software requirementsmanagementwhichareintegratedwithsoftwaredevelopment,test,andCMcansimplifytrackingandexpeditesoftwareconstruction.PlansforenablingsystemsanddescriptionofmodelingtechniquesusedinsupportoftheSystem/SoftwareRequirementsDefinitionprocesscanbeincorporatedintoanSDP.


NOTE TheValidationprocessisusedtoobjectivelyconfirmthattheenablingsystemachievesitsintendeduseforitsenablingfunctions.

b) Define system/software requirements.Thisactivityconsistsofthefollowingtasks:

1) Defineeachfunctionthatthesoftwaresystemorelementisrequiredtoperform.

NOTE1 Softwarefunctionscanbedescribedinusecases,userstories,orscenarios,andinvolvethetransformationofdata and information to achieve user needs (stakeholder requirements). In some cases, functions are derived fromanalysisofcriticalqualitycharacteristics,suchasperformance,securityoravailability(e.g.,systemdiagnosingfunctionorhighlyfrequentdatabackupfunctionforreliability).

NOTE2 Enabling functions that are required to support the system‐of‐interest in achieving its functionality are alsoidentifiedanddefinedconcurrentlywiththefunctionofthesystem‐of‐interest.Thisisnecessarytohelpensurethattheenablingfunctionsinthesystemenvironmentareidentifiedandaccountedfor.

2) Identifyrequiredstatesormodesofoperationofthesoftwaresystem.

NOTE1 States or modes of operation can be modeled and represented in multiple modeling techniques andperspectivestogiveasufficientlycompletedescriptionofthedesiredsystemorelementrequirements.

NOTE2 Conditions for performance of functions often involve interoperability across functions or elements. Forexample,somesoftwarerequirements(e.g.,aperformancetiminglimit)canbeallocatedacrossmultiplesoftwaresystemelements,affectingtreatmentoftherequirementinatestcaseorregressiontest.

3) Definenecessaryimplementationconstraints.

NOTE Forsoftwareelements,thisincludestheimplementationdecisionsthatareallocatedfromarchitecturedefinitionathigherlevelsinthesoftwaresystem,introducedbystakeholderrequirements,orsolutionlimitations.Implementationconstraints include the conditions underwhich the system is to be capable of performing the function, the conditionsunderwhichthesystemistocommenceperformingthatfunction(input)andtheconditionsunderwhichthesystemistoceaseperformingthatfunction(output).

4) Identify requirements that relate to risks, criticality of the software system, or critical qualitycharacteristics.




NOTE1 Non‐functionalrequirementsandcriticalqualitycharacteristics insoftwaresystemscommonlyincludethoserelatedtohealth,safety,securityandsoftwareassurance,reliability,availabilityandsupportability(maintainability),andtime constraints for throughput and performance. The SystemAnalysis process can be used to determine appropriatevaluesforperformancerequirements,consideringtheanticipatedcostofachievingthemandtheir impactonoperationanduseofthesystem.

NOTE2 Analysisanddefinitionofsafetyconsiderations include thoserequirementsrelatingtomethodsofoperationandmaintenance,environmental influences,andriskofpersonnelinjury. Italso includesexpressingeachsafety‐relatedfunctionanditsassociatedintegrity,intermsofthenecessaryriskreductionandallocationtodesignatedsafety‐relatedsystems.Applicablestandardsareusedconcerningfunctionalsafety,e.g., IEC61508,andenvironmentalprotection,e.g.,ISO 14001. Analysis includes security considerations, e.g., those related to compromise and protection of sensitiveinformation, data and material. The security‐related risks are defined, including administrative, personnel, physical,computer, communication, network, emission and environment factors using, as appropriate, applicable securitystandards.RefertoISO/IEC/IEEE15026‐4forsystemandsoftwareassuranceguidance.ISO/IEC27036providesguidancefor information security requirements for the outsourcing of products and services. ISO 25030 provides guidance forexternal system quality factors and characteristics. AnnexE (E.6) provides a software assurance view of the life cycleprocesses.

NOTE3 Forsoftwaresystemsintendedforhumaninteraction,human‐factorsengineering(ergonomics)specificationsareconsidered.Forsystemsthathaveusabilityrequirements,recommendationsforobtainingadesiredlevelofusabilitycanbefoundinISO/FDIS9241‐220,Ergonomics of human-system interaction — Part 220: Processes for enabling, executing and assessing human-centred design within organizations.

5) Definesystem/softwarerequirementsandrequirementsattributes,includingthefollowing:

i) Dataelements,datastructuresandformats,anddatabaseordataretentionrequirements;

ii) Userinterfacesanduserdocumentation(informationforusers)andusertraining;

iii) Interfaceswithothersystemsandservices;

iv) Functions and non‐functional characteristics, including critical quality characteristics and costtargets;

v) Transition of operational processes and data from existing automated and manual systems,migrationapproachandschedule,softwareinstallationandacceptanceoftheproduct;and

vi) Requirementattributes,suchasrationale;priority;traceabilitytosoftwaresystemelements,testcases, and information items; methods of verification; inclusion in approved baselines; andevaluatedrisk.

NOTE1 Requirements definition involves iterative and recursive steps in parallel with other life cycle processes.Dependingon the lifecyclemodel that isbeingemployed, it isuseful tocompare theresources tobespent inassuringinitial correctness of requirements versus the resource needed to evolve requirements based on verification andvalidationresults.

NOTE2 Thesystem/softwarerequirementsandattributesarerecordedwithalevelofdetailandinaformsuitableforrequirementsmanagementthroughthelifecycle.SeeISO/IEC/IEEE29148:2011Clauses5and6formoreinformationonrequirements,andClauses8and9foradescriptionofandanannotatedoutlineforaSystemRequirementsSpecificationandaSoftwareRequirementsSpecification.

c) Analyze system/software requirements. Thisactivityconsistsofthefollowingtasks:

1) Analyzethecompletesetofsystem/softwarerequirements.

NOTE1 Requirementsareanalyzedforcharacteristicsofindividualrequirements,aswellascharacteristicsofthesetofrequirements. Potential analysis characteristics include that the requirements are necessary, implementation‐free,unambiguous, consistent, complete, singular, feasible, traceable, verifiable, affordable, and bounded. The Verificationprocessisusedtodetermineifrequirementsmeettheattributesandcharacteristicsofgoodrequirements.Insomecases,the technicalandeconomic feasibilityofvalidatingandverifyingalternative formulationsof requirements isevaluated.ISO/IEC/IEEE29148providesadditionalinformationoncharacteristicsofrequirements.

NOTE2 TheSystemAnalysisprocess canbeused to assess feasibility, affordability, balance andother requirementscharacteristics. The System Analysis process is used to determine appropriate values for requirement parameters,consideringtheestimatedcost,schedule,andtechnicalperformanceofthesoftwaresystem.





NOTE3 Anticipatingthatsomerequirementscanbeachievedincrementallyorevendeferredorwaived,requirementscanbeprioritized.

2) Definecriticalperformancemeasuresthatenabletheassessmentoftechnicalachievement.

NOTE Thisincludesdefiningtechnicalandqualitymeasuresandcriticalperformanceparametersassociatedwitheacheffectivenessmeasure identified in thesoftwaresystemelementrequirements.Thecriticalperformancemeasures(e.g.,measures of performance and technical performance measures) are analyzed and reviewed to help ensuresystem/software requirements aremet and to help ensure identification of project cost, schedule or performance riskassociatedwithanynon‐compliance.ISO/IEC15939providesaprocesstoidentify,defineanduseappropriatemeasures.INCOSETP‐2003‐020‐01,Technical Measurement,providesinformationontheselection,definitionandimplementationofcriticalperformancemeasures.TheISO/IEC25000seriesofstandardsprovidesrelevantqualitymeasures.

3) Feedbacktheanalyzedrequirementstoapplicablestakeholdersforreview.

NOTE Feedback helps validate that the specified requirements have been adequately captured and expressed.Confirmationismadethattheyareanecessaryandsufficientresponsetostakeholderrequirementsandanecessaryandsufficientinputtootherprocesses,inparticularsoftwarearchitecture,design,andverification.TheValidationprocessisusedtodetermineifthesystem/softwarerequirementsaddresstheusers’needs.

4) Identify and resolve issues, deficiencies, conflicts, and weaknesses within the complete set ofrequirements.

NOTE This includes requirements that are not verifiable, ambiguous, violate the characteristics for individualrequirements,orareinconsistentwithothersinthesetofrequirements.Resolutionof issueswithrequirementscanbeiterativewithincertainlifecyclemodels.

d) Manage system/software requirements. Thisactivityconsistsofthefollowingtasks:

NOTE Maintainingsystem/softwarerequirements includesdefining,recording,andcontrollingthebaseline, typicallyunderformalconfigurationmanagement,alongwithmanagingchangesresultingfromtheapplicationofotherlifecycleprocessessuchasarchitectureordesign.

1) Obtainexplicitagreementonthesystem/softwarerequirements.

NOTE This includes confirming that system/software requirements are expressed correctly, comprehensible tooriginators and implementers, and that the resolution of conflict in the requirements is consistent with stakeholderdecisions.

2) Maintaintraceabilityofthesystem/softwarerequirements.

NOTE Throughthe lifecycle,bidirectionaltraceability ismaintainedbetweenthesystem/softwarerequirementsandthe stakeholder requirements, architectural entities, interface definitions, analysis results, verification methods ortechniques, and allocated, decomposed, and derived requirements. Traceability allows verification that achievablestakeholder requirements are met by one or more system or element requirements, and such requirements meet orcontribute to meeting at least one stakeholder requirement. Traceability is often facilitated by an appropriate datarepositoryorintegrateddevelopmentandtestinfrastructure.


NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.Thisprocess identifiescandidatesforthebaseline,andtheInformationManagementprocesscontrolsthe informationitems,such as requirements specifications. For this process, the system/software requirements are typical artifacts that arebaselined.

6.4.4 Architecture Definition process

6.4.4.1 Purpose

ThepurposeoftheArchitectureDefinitionprocessistogeneratesystemarchitecturealternatives,toselectoneormorealternative(s)thatframestakeholderconcernsandmeetsystemrequirements,andtoexpressthisinasetofconsistentviews.




IterationoftheArchitectureDefinitionprocesswiththeBusinessorMissionAnalysisprocess,System/SoftwareRequirementsDefinitionprocess,DesignDefinitionprocess,andStakeholderNeedsandRequirementsDefinitionprocess is often employed so that there is a negotiated understanding of the problem to be solved and asatisfactorysolutionisidentified.TheresultsoftheArchitectureDefinitionprocessarewidelyusedacrossthelifecycle processes. Architecture definitionmay be applied atmany levels of abstraction, highlighting the relevantdetailthatisnecessaryforthedecisionsatthatlevel.

NOTE1 System architecture deals with fundamental principles, concepts, properties, and characteristics and theirincorporationintothesystem‐of‐interest.Architecturedefinitionhasmoreusesthanasmerelyadriverorpartofdesign.RefertoISO/IEC/IEEE42010:2011formoreinformationaboutarchitecturedescriptionandtheusesandnatureofarchitecture.

NOTE2 The Architecture Definition process supports identification of stakeholders and their concerns. As the processunfolds, insightsaregained into therelationbetweentherequirementsspecified for thesoftwaresystemandtheemergentproperties and behaviors of the system that arise from the interactions and relations between the system elements. Aneffectivearchitecture isasdesign‐agnosticaspossibletoallowformaximumflexibility inthedesigntradespace.Evenforasingle‐productsoftwaresystem,thedesignoftheproductwilllikelychangeovertimewhilethearchitectureremainsconstant.Aneffectivearchitecturealsohighlightsandsupportstrade‐offsfortheDesignDefinitionprocessandpossiblyotherprocesses,suchasPortfolioManagement,ProjectPlanning,System/SoftwareRequirementsDefinition,andVerification.

NOTE3 Architecture Definition can apply to a product line rather than a single software system. A product linearchitecture describes the structural properties for building a group of related systems with common components andinterrelationships.Inproductlinearchitectures,thearchitecturenecessarilyspansseveraldesigns.Thearchitectureservestomake the product line cohesive and helps ensure compatibility and interoperability across the product line. ISO/IEC26550:2013describesestablishingadomainarchitectureforaproductline.

NOTE4 TheSWEBOK (Guide to the Software Engineering Body of Knowledge)SoftwareRequirements,SoftwareDesignandSoftwareEngineeringModelsandMethodsknowledgeareasdiscusskeyaspectsofsoftwarearchitectureinrelationshiptothesystem,aswellaswithrespecttoiterationwithdesign.

6.4.4.2 Outcomes

AsaresultofthesuccessfulimplementationoftheArchitectureDefinitionprocess:

a) Identifiedstakeholderconcernsareaddressedbythearchitecture.

b) Architectureviewpointsaredeveloped.

c) Context,boundaries,andexternalinterfacesofthesystemaredefined.

d) Architectureviewsandmodelsofthesystemaredeveloped.

e) Concepts, properties, characteristics, behaviors, functions, or constraints that are significant toarchitecturedecisionsofthesystemareallocatedtoarchitecturalentities.

f) Systemelementsandtheirinterfacesareidentified.

g) Architecturecandidatesareassessed.

h) Anarchitecturalbasisforprocessesthroughoutthelifecycleisachieved.

i) Alignmentofthearchitecturewithrequirementsanddesigncharacteristicsisachieved.

j) Anyenablingsystemsorservicesneededforarchitecturedefinitionareavailable.

k) Traceabilityofarchitectureelementstostakeholderandsystem/softwarerequirementsisdeveloped.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheArchitectureDefinitionprocess.

a) Prepare for architecture definition.Thisactivityconsistsofthefollowingtasks:





1) Reviewpertinentinformationandidentifykeydriversofthearchitecture.

NOTE1 Keydriversareidentifiedbyreviewing:(a)marketstudies,industryprojections,competitorproductplans,andscientific findings; (b) organizational strategies, organizational‐level concept of operations, organizational policies anddirectives,regulatoryandlegalconstraints,andstakeholderrequirements;(c)missionorbusinessconceptofoperations,system‐of‐interest and related system operational concept, operational environment, technology roadmaps, andsystem/software requirements, and (d)other factors that impact the suitabilityof the software system through its lifecycle. This analysis of key drivers typically builds from the Business or Mission Analysis, Stakeholder RequirementsDefinition,andSystem/softwareRequirementsDefinitionprocesses.

NOTE2 Key drivers of the architecture can include architecture styles and patterns, elements, principles such asreplaceablecomponents,feasibilityofimplementationandintegration;availabilityofCOTSandopensourcecomponents;datasourcesfordata‐intensivesystems;andperformanceimplications.Theeffectofchoosingvariousdesignelementscanbelessenedifthesoftwaresystemisproperlyarchitected.

2) Identifystakeholderconcerns.

NOTE1 Stakeholders are initially identified in the Stakeholder Needs and Requirements process. Additionalstakeholders are usually identified during the Architecture Definition process. Stakeholder concerns related toarchitecture include system integrity concerns that the software system will be compromised intentionally orunintentionallyviaathreatagentorcauseaccidentsasasafetyhazard.Stakeholder.expectationsorconstraintsareoftenassociated with the system’s life cycle stages, such as utilization (e.g., availability, security, effectiveness, usability,interoperabilitywithexistingsystems,availabilityorriskstodatainthesystem),support(e.g.,thesupportabilityofthesystemoveritsprojectedlife‐span,obsolescencemanagement),evolutionofthesoftwaresystemanditsenvironment(e.g.,adaptability, scalability, survivability), production (e.g., distribution, testability), and retirement (e.g., sensitive dataeradicationorretention).

NOTE2 Concernsaffectingsoftwaresystemarchitectureincludedatasourcesandperformanceimplicationsfordata‐intensive systems, and constraints on the use of outsourced, existing, newly developed, proprietary, commerciallyavailable,oropensourcesoftwareelements, includingsoftwarelicensing.Whilesoftwarearchitecture is ideallydesign‐agnostic, the feasibilityof implementingthearchitecture inanaffordablesoftwaresystemisasignificantconstraint formostsystems.

3) DefinetheArchitectureDefinitionroadmap,approach,andstrategy.

NOTE Thisincludestheidentificationofopportunitiestocommunicatewithdesignatedstakeholders,thedefinitionofarchitecture review activities, evaluation approach and criteria, measurement approach, and measurement methods(refertotheMeasurementprocess).Theroadmapshowshowthearchitecturewillevolvetoanenvisionedendstateandoftenhasalongertimeframethanforthecurrentsystem‐of‐interest.Theapproachisthemannerinwhichtheworkwillbeaccomplished,suchashowtoengagewithstakeholders,howtovettheresults,orwheretodothework.Thestrategydealswiththesystematicplanofactionforimplementingtheapproachconsistentwiththeroadmap.

4) Definearchitectureevaluationcriteriabasedonstakeholderconcernsandkeyrequirements.

5) Identify and plan for the necessary enabling systems or services needed to support the ArchitectureDefinitionprocess.

NOTE This includes identification of requirements and interfaces for the enabling systems and services. Enablingsystems for architecture definition can include tools for collaboration and architecture development, and architecturereuserepositoriesforartifactssuchasarchitecturepatterns,models,andreferencearchitectures.


NOTE TheValidationprocessisusedtoobjectivelyconfirmthattheenablingsystemachievesits intendeduseforitsenablingfunctions.TheInfrastructureManagementprocesssupportsreuseofenablingsystems.

b) Develop architecture viewpoints.Thisactivityconsistsofthefollowingtasks:

1) Select,adapt,ordevelopviewpointsandmodelkindsbasedonstakeholderconcerns.

2) Establishoridentifypotentialarchitectureframework(s)tobeusedindevelopingmodelsandviews.

NOTE Somearchitecture frameworks identifystakeholdersandtheirconcerns,andrelevantviewpoints thataddressthoseconcerns,whileotherarchitectureframeworksaremoregeneralintheirguidance.Viewpointsspecifythekindsofmodelstobeusedandhowtheresultingmodelscanbeusedtogeneratearchitectureviews.RefertoISO/IEC/IEEE42010formoreinformationonarchitectureframeworkandarchitecturedescriptionpractices.




3) Capturerationaleforselectionofframework(s),viewpointsandmodelkinds.

4) Selectordevelopsupportingmodellingtechniquesandtools.

NOTE BoththeSWEBOKandISO/IECTR24748‐3describemodelingtechniquesthatsupportArchitectureDefinitionandDesignDefinitionofsoftwareelements.

c) Develop models and views of candidate architectures.Thisactivityconsistsofthefollowingtasks:

1) Definethesoftwaresystemcontextandboundariesintermsofinterfacesandinteractionswithexternalentities.

NOTE This task is mainly based on the outcomes of the Business or Mission Analysis process, and is performedconcurrently with the Stakeholder Needs and Requirements Definition process. It consists of identifying the entitiesexternal to the software system (i.e., existing andprojected systems, products, and services that constitute the systemcontext) anddefining theboundaries of the software system (i.e., interactionswith these external entities through theinterfaces that cross the boundaries). The external entities include the necessary enabling systems. The ArchitectureDefinitionprocessdefinesinterfacestotheextentneededtosupportessentialarchitecturaldecisionsandunderstanding.TheseinterfacedefinitionsarethenrefinedbytheDesignDefinitionprocess.

2) Identifyarchitecturalentitiesandrelationshipsbetweenentitiesthataddresskeystakeholderconcernsandcriticalsoftwaresystemrequirements.

NOTE Architecture is not necessarily concernedwith all requirements, but rather onlywith those system/softwarerequirements that drive the architecture. On the other hand, the Design Definition process addresses and takes intoaccountalltherequirements.Sometimes,throughtheArchitectureDefinitionprocesstherewillberequirementsthataredeemed to be inappropriate, unaffordable, or unsuitable. These are requirements issues that are resolved throughiterationoftheSystem/SoftwareRequirementsDefinitionprocess.Itisalsoimportantthatthearchitectureaddresseskeystakeholderconcernssincenotallofthesewillbecapturedinrequirements.

3) Allocateconcepts,properties,characteristics,behaviors,functions,orconstraintsthataresignificanttoarchitecturedecisionsofthesoftwaresystemtoarchitecturalentities.

NOTE Theitemsbeingallocatedcanbephysical,logical,orconceptual.

4) Select,adapt,ordevelopmodelsofthecandidatearchitecturesofthesoftwaresystem.

NOTE It is common to use models in architecture definition. The models used are those that best address keystakeholder concerns.Refer to ISO/IEC/IEEE42010 forhow this canbedone.Historically, it hasbeencommon touselogicalandphysicalmodelsinarchitecturedefinition.InformationonlogicalandothermodelsisprovidedinAnnexF.

5) Compose views from the models in accordance with identified viewpoints to express how thearchitectureaddressesstakeholderconcernsandmeetsstakeholderandsystem/softwarerequirements.

6) Harmonizethearchitecturemodelsandviewswitheachother.

NOTE Correspondence rules from frameworks are oneway to establishharmonybetween views. See ISO/IEC/IEEE42010.

d) Relate the architecture to design.Thisactivityconsistsofthefollowingtasks:

1) Identify software system elements that relate to architectural entities and the nature of theserelationships.

NOTE Sometimes the software systemelements are initially notional untilDesignDefinitionhas occurred since thisdependsontheactualdesign(s)tobedone.Sometimesa“referencearchitecture”iscreatedusingthesenotionalsystemelementsasameanstoconveyarchitecturalintentandtocheckfordesignfeasibility.

2) Definetheinterfacesandinteractionsamongthesoftwaresystemelementsandexternalentities.

NOTE This isdefinedat levelofdetailnecessary toconvey thearchitectural intentandcanbe furtherrefined in theDesignDefinitionprocess.

3) Partition,alignandallocaterequirementstoarchitecturalentitiesandsystemelements.





4) Mapsoftwaresystemelementsandarchitecturalentitiestodesigncharacteristics.

5) Defineprinciplesforthesoftwaresystemdesignandevolution.

EXAMPLE Principles can include interoperability, use of selected design patterns, ease of replacing and upgradingsystemelements,orsecuritylevels.

e) Assess architecture candidates.Thisactivityconsistsofthefollowingtasks:

1) Assesseachcandidatearchitectureagainstconstraintsandrequirements.

2) Assesseachcandidatearchitectureagainststakeholderconcernsusingevaluationcriteria.

NOTE TheSystemAnalysisprocessandtheRiskManagementprocesscanbeusedtosupportthistask.

3) Selectthepreferredarchitecture(s)andcapturekeydecisionsandrationale.

NOTE TheDecisionManagementprocesscanbeusedtosupportthistask.

4) Establishthearchitecturebaselineoftheselectedarchitecture.

NOTE Thearchitecturebaselineiscomposedofmodels,viewsandotherrelevantarchitecturedescriptions.

f) Manage the selected architecture.Thisactivityconsistsofthefollowingtasks:

1) Formalize the architecture governance approach and specify governance‐related roles andresponsibilities,accountabilities,andauthoritiesrelatedtodesign,quality,security,andsafety.

2) Obtainexplicitacceptanceofthearchitecturebystakeholders.

NOTE The Validation process is used to confirm that the architecture models and views reflect stakeholderrequirements, that stakeholder concerns are addressed, and to help ensure that future iterations of software systemarchitecturebetteraddressstakeholderconcerns.

3) Maintain concordance and completeness of the architectural entities and their architecturalcharacteristics.

NOTE Theentitiestobecheckedarenotonlytechnical.Thesearealso,forexample,legal,economical,organizationalandoperationalentitiesthatarenormallypartofstakeholderrequirementsandconcerns.

4) Organize, assess and control evolution of the architecturemodels and views to help ensure that thearchitecturalintentismetandthearchitecturalvisionandkeyconceptsarecorrectlyimplemented.

5) Maintainthearchitecturedefinitionandevaluationstrategy.

NOTE This includes updating the architecture based upon technological (e.g., obsolescence), implementation, oroperationalexperience.Thisincludesthemanagementofexternalandinternalinterfacesthataredefinedatthislevelofsoftwaresystemdecomposition.

6) Maintaintraceabilityofthearchitecture.

NOTE Throughoutthelifecycle,traceabilityisoftenmaintainedamongthearchitecturalentitiesorelements(models,views, and viewpoints), the requirements (including allocated, decomposed, and derived) and stakeholder concerns,softwaresystemdesign,interfacedefinitions,analysisresults,andverificationmethodsortechniques.


NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.Thisprocessidentifiescandidatesforthebaseline.TheInformationManagementprocesscontrolstheinformationitems,suchasarchitecturedescriptions(architecturemodels,architectureviews,evaluations,andtraceability).




6.4.5 Design Definition process

6.4.5.1 Purpose

The purpose of the Design Definition process is to provide sufficient detailed data and information about thesystemanditselementstoenabletheimplementationconsistentwitharchitecturalentitiesasdefinedinmodelsandviewsofthesystemarchitecture.

For software systems, design activities typically iterate with activities in System/Software RequirementsDefinition and Architecture Definition. Design definition is typically applied iteratively and incrementally todevelopadetaileddesign, includingsoftwareelements, interfaces,databases,anduserdocumentation.Softwaredesign is usually concurrent with software implementation, integration, verification, and validation. Annex Hdiscusses software design using agilemethods. During design and implementation, further process applicationrefinesallocationofevolvingrequirementsamongsoftwareelements.

NOTE1 TheDesignDefinitionprocessisdrivenbyrequirementsthathavebeenvettedthroughthearchitectureandmoredetailed analyzes of feasibility. Architecture focuses on suitability, viability, and desirability, whereas design focuses oncompatibility with technologies and other design elements and feasibility of implementation and integration. An effectivearchitectureisasdesign‐agnosticaspossibletoallowformaximumflexibilityinthedesigntradespace.

NOTE2 This process provides feedback to the software system architecture to consolidate or confirm the allocation,partitioningandalignmentofarchitecturalentities.

6.4.5.2 Outcomes

AsaresultofthesuccessfulimplementationoftheDesignDefinitionprocess:

a) Designcharacteristicsofeachsystemelementaredefined.

b) System/softwarerequirementsareallocatedtosystemelements.

c) Designenablersnecessaryfordesigndefinitionareselectedordefined.

d) Interfacesbetweensystemelementscomposingthesystemaredefinedorrefined.

e) Designalternativesforsystemelementsareassessed.

f) Designartifactsaredeveloped.

g) Anyenablingsystemsorservicesneededfordesigndefinitionareavailable.

h) Traceability of the design characteristics to the architectural entities of the system architecture isestablished.

NOTE Designdefinitionconsidersapplicabletechnologiesandtheircontributiontothesystemsolution.Designprovidesthe ‘implement‐to’ level of the definition, such as drawings, state diagrams, stories, and detailed design descriptions. Forsoftwareelements,thisprocesscanresult inadetaileddesigndescriptionthatcanbeverifiedagainstrequirementsandthesoftware architecture. Even if the software design is not fully specified in a formal description, it is sufficiently detailed topermitsoftwareimplementation(construction)andtestplanning.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheDesignDefinitionprocess.

NOTE The SWEBOK, Guide to the Software Engineering Body of Knowledge, provides detailed discussion on softwaredesign.Thisknowledgeareaaddressesfundamentals,keyissues,designstrategiesandmethods,anddesignnotations.

a) Prepare for software system design definition. Thisactivityconsistsofthefollowingtasks:





1) Definethedesigndefinitionstrategy,consistentwiththeselectedlifecyclemodelandanticipateddesignartifacts.

NOTEThesoftwaredesignstrategycanincludeinitialorincrementaldecompositionintosystemelements;creationofvarious views of automated procedures, data structures and control systems; selection of design patterns, orprogressivelymoredetaileddefinitionofobjectsandtheirrelationships.

2) Selectandprioritizedesignprinciplesanddesigncharacteristics.

NOTEDesignprinciplesincludecontrollingideassuchasabstraction,modularizationandencapsulation,separationofinterfaceandimplementation,concurrency,andpersistenceofdata.Securityconsiderationsincludetheprincipleofleastprivilege, layereddefenses, restricted access to system services, andother considerations tominimize anddefend thesystemattacksurface.Designcharacteristics include,forexample,availability, faulttoleranceandresilience,scalability,usability,capacityandperformance,testability,portability,andaffordability.

3) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportdesigndefinition.

NOTEThisincludesidentificationofrequirementsandinterfacesfortheenablingsystems.Enablingsystemsfordesigndefinition include selection of software and systemplatforms, programming languages, design notations and tools forcollaborationanddesigndevelopment,designreuserepositories(forproductlines,designpatterns,anddesignartifacts),anddesignstandards.


NOTETheValidationprocessisusedtoobjectivelyconfirmthattheenablingsystemachievesitsintendeduseforitsenablingfunctions.

b) Establish designs related to each software system element.Thisactivityconsistsofthefollowingtasks:

1) Transformarchitecturalanddesigncharacteristicsintothedesignofsoftwaresystemelements.

NOTE Characteristics apply to physical and logical system elements, such as database structures, provisions formemoryandstorage,softwareprocessesandcontrols,externalinterfacessuchasuserinterfaces,orservices.ISO9241‐210provideshumancentreddesign/ergonomicdesignguidelines.

2) Defineandprepareorobtainthenecessarydesignenablers.

NOTE Design enablers include models, equations, algorithms, calculations, formal expressions and values ofparameters,patterns,andheuristics,whichareassociatedwithdesigncharacteristicsusingadequaterepresentationsuchas drawings, logical diagrams, flowcharts, coding conventions, logic patterns, informationmodels, business rules, userprofiles, scenarios, use cases or user stories, and tables ofmetrics and their values, e.g., function points or user storypoints.

3) Examinedesignalternativesandfeasibilityofimplementation.

NOTE1 For the software system and software elements, typically reuse, adaptation, outsourced service, or newdevelopmentareexamined.

NOTE2 Assess the feasibility of realizing design characteristics. If warranted by assessment results, examine otheralternative design options or perform trade‐offs in the architecture or requirements when design characteristics areimpracticaltoimplement.

4) Refineordefinetheinterfacesamongthesoftwaresystemelementsandwithexternalentities.

NOTE Interfaces are identified and defined in the Architecture Definition process (see 6.4.4) to the level or extentneeded for the architecture intent andunderstanding.Theseare refined in theDesignDefinitionprocessbasedon thedesign characteristics, interfaces, and interactions of software elements with other elements composing the softwaresystemandwithexternalentities.Additionalinterfacesaresometimesidentifiedanddefinedthatwerenotaddressedinthearchitecturedefinition.

5) Establishthedesignartifacts.

NOTE This task formalizes the design characteristics of the software system elements through dedicated artifacts,dependingontheimplementationtechnology.Examplesofartifactsincludeprototypes,datamodels,pseudocode,entity‐relationship diagrams, use cases, user role and privilege matrixes, interface specifications, service descriptions, and




procedures.Designartifacts aredeveloped, obtained, ormodified for selectedalternatives.Thedata is associatedwithdetailedacceptablemarginsforimplementation(ifrelevantatthisprocessortaskiteration).

c) Assess alternatives for obtaining software system elements. Thisactivityconsistsofthefollowingtasks:

1) Determinetechnologiesrequiredforeachelementcomposingthesoftwaresystem.

NOTE Severaltechnologiesaresometimesusedforagivensoftwaresystemelement,e.g.,internetpresence,embeddedsystems,adaptationofopensourcesoftware,humanoperatorroles.

2) Identifycandidatealternativesforthesoftwaresystemelements.

NOTE Alternatives includenewlydesignedandconstructeditems;adaptationsofexistingproduct lines,components,objects,orservices;oracquisitionorreuseofNon‐DevelopedItems(NDI).NDIincludeCOTS(Commercial‐Off‐The‐Shelf)orFOSS(FreeandOpenSourceSoftware)packagesorelements,reuseofapreviousdesign,orexistingassets,includingacquirerprovideditems.

3) Assess each candidate alternative against criteria developed from expected design characteristics andelementrequirementstodeterminesuitabilityfortheintendedapplication.

NOTE Amake‐or‐buydecisionandresulting implementationand integrationapproach typically involve trade‐offsofthe design criteria, including cost. Design choices commonly consider enabling systems required to test the candidatealternative(test‐drivendesignanddevelopment)andsustainabilityoverthesystemlife,includingmaintenancecosts.TheMaintenanceprocesscanbeusedtodeterminethesuitabilityofthedesignforlong‐termmaintenanceandsustainability.

4) Choosethepreferredalternativesamongcandidatedesignsolutionsforthesoftwaresystemelements.

NOTE The SystemAnalysis process canbeused for analyzes and assessments to support theDecisionManagementprocessinperformingtheselection.DesignreviewsareconductedusingtheValidationprocess.

d) Manage the design. Thisactivityconsistsofthefollowingtasks:

1) Capturethedesignandrationale.

NOTE Commonlycapturedinformationincludesthesoftwaresystemelementsandaffiliatedrequirementsanddesigndata,e.g.,forsoftwareelements,internalandexternalinterfaces,datastructures,implementationandtestrequirements,unitaggregationdataforintegration,andtestcases.Rationaletypicallyincludesinformationaboutmajorimplementationoptionsandenablers.Theresultantdesigniscontrolledinaccordancewiththestrategy.

2) Establishtraceabilitybetweenthedetaileddesignelements,thesystem/softwarerequirements,andthearchitecturalentitiesofthesoftwaresystemarchitecture.

NOTE1 This task facilitatesproviding feedbacktotheArchitectureDefinitionprocess forpotentialmodifications, forexample, to modify the allocation of software system elements in order to obtain the expected architecturalcharacteristics;orpossiblytomodifytheexpectedarchitecturalcharacteristicduetofactorsdiscoveredduringthedesignprocess,ortomakestakeholdersawareofthepotentialimpacts.

NOTE2 Throughthelifecycle,bidirectionaltraceabilityismaintainedbetweenthedesignandtheverificationmethodsor techniques, and software system element requirements. Allocations and design properties are assigned to softwareelements,softwareunitsandaffiliatedartifacts,atadetailedenoughleveltopermitsoftwaretestingandimplementation,includingconstruction.

3) Determinethestatusofthesoftwaresystemandelementdesign.

NOTE1 TheMeasurementprocess isused toestablishmeasures for thecompletenessandqualityof thedesignas itprogresses. The Verification and Validation processes are invoked to verify and validate the detailed design andimplementation

NOTE2 Thisincludesperiodicassessmentofthedesigncharacteristicsincaseofevolutionofthesoftwaresystemandof its architecture, aswell as forecastingpotential obsolescenceof components and technologies, their replacementbyothers over time in the life cycle of the software system, and the consequences for the design definition. The RiskManagementprocessistypicallyappliedtoevaluaterisksinthedesignstrategy,initialdesign,andtheevolvingdesign.






NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselinesforartifacts such as designmodels. This process identifies candidates for the baseline, and the InformationManagementprocesscontrolstheinformationitems,suchasdesigndescriptionsandspecifications.

6.4.6 System Analysis process

6.4.6.1 Purpose

ThepurposeoftheSystemAnalysisprocess istoprovidearigorousbasisofdataandinformationfortechnicalunderstandingtoaiddecision‐makingacrossthelifecycle.

The SystemAnalysis process applies to thedevelopment of inputsneeded for any technical assessment. It canprovideconfidenceintheutilityandintegrityofsystemrequirements,architecture,anddesign.Systemanalysiscovers a wide range of differing analytic functions, levels of complexity, and levels of rigor. It includesmathematical analysis, modelling, simulation, experimentation, and other techniques to analyze technicalperformance, system behavior, feasibility, affordability, critical quality characteristics, technical risks, life cyclecosts,andtoperformsensitivityanalysisofthepotentialrangeofvaluesforparametersacrossalllifecyclestages.It is used for awide range of analytical needs concerning operational concepts, determination of requirementvalues, resolution of requirements conflicts, assessment of alternative architectures or system elements, andevaluationofengineeringstrategies(integration,verification,validation,andmaintenance).Formalityandrigorofthe analysiswill depend on the criticality of the information need orwork product supported, the amount ofinformation/dataavailable,thesizeoftheproject,andtheschedulefortheresults.

NOTE TheSystemAnalysisprocesscanbeemployedfortheentiresoftwaresystemoranyelement.ThisprocessisoftenusedinconjunctionwiththeDecisionManagementprocess.

6.4.6.2 Outcomes

AsaresultofthesuccessfulimplementationoftheSystemAnalysisprocess:

a) Systemanalyzesneededareidentified.

b) Systemanalysisassumptionsandresultsarevalidated.

c) Systemanalysisresultsareprovidedfordecisions.

d) Anyenablingsystemsorservicesneededforsystemanalysisareavailable.

e) Traceabilityofthesystemanalysisresultsisestablished.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheSystemAnalysisprocess.

a) Define the system analysis strategy and prepare for system analysis. This activity consists of thefollowingtasks:

1) Identifytheproblemorquestionthatrequiresanalysis.

NOTE This includes technical, functional, and non‐functional objectives of the analysis. Non‐functional objectivesinclude critical quality characteristics, various properties, technology maturity, and technical risks. The problemstatement or question to be answered by the analysis is essential to establish the objectives of the analysis and theexpectationsandutilityoftheresults.

2) Identifythestakeholdersoftheanalysis.

3) Definethescope,objectives,andleveloffidelityoftheanalysis.

NOTE Thenecessaryleveloffidelity(accuracyorprecision)isafactorindeterminingtheappropriatelevelofrigor.




4) Selectthemethodstosupporttheanalysis.

NOTE The methods are chosen based on time, cost, fidelity, technical drivers, and criticality of analysis. Analysismethodshaveawiderangeoflevelsofrigorandincludeexpertjudgment,worksheetcomputations,parametricestimatesandcalculations,historicaldataandtrendanalysis,engineeringmodels,simulation,visualization,andprototyping.Duetocostandscheduleconstraints,mostprojectstypicallyperformsystemanalysisonlyforcriticalcharacteristics.

5) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupporttheanalysis.

NOTE This task includes identificationof requirementsand interfaces for theenablingsystems.Thesystemanalysisenablingsystemsincludethetools,relevantmodels,andpotentialdatarepositoriesneededtosupporttheanalysis.Themethods chosen will be a major factor in determining what tools are appropriate to support the analysis. This alsoincludesdeterminingtheavailabilityofreusableorotherrelevantmodelsanddata,orresources.


NOTE The Infrastructure Management process enables the provision of systems analysis services. The Validationprocessisusedtoobjectivelyconfirmthattheenablingsystemachievesitsintendeduseforitsenablingfunctions.

7) Collectthedataandinputsneededfortheanalysis.

b) Perform system analysis.Thisactivityconsistsofthefollowingtasks:

1) Identifyandvalidatecontextsandassumptions.

2) Applytheselectedanalysismethodstoperformtherequiredanalysis.

3) Reviewtheanalysisresultsforqualityandvalidity.

NOTE Theresultsarecoordinatedwithassociatedanalyzesthathavebeenpreviouslycompleted.

4) Establishconclusionsandrecommendations.

NOTE Theappropriatesubjectmatterexpertsandstakeholdersareidentifiedandengagedinthistask.

5) Recordtheresultsofthesystemanalysis,

c) Manage the system analysis.Thisactivityconsistsofthefollowingtasks:

1) Maintaintraceabilityoftheanalysisresults.

NOTE Through the life cycle, bidirectional traceability ismaintained between the analysis results and any softwaresystem item forwhich the analysis is supporting a decision or providing rationale (e.g., system/software requirementvalues,architecturealternatives).Thisisoftenfacilitatedbyanappropriatedatarepository.


NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.Thisprocess identifiescandidatesforthebaseline,andtheInformationManagementprocesscontrolsthe informationitems.Forthisprocess,theanalysisresultsorreportsaretypicalinformationitemsthataremanaged.

6.4.7 Implementation process

6.4.7.1 Purpose

ThepurposeoftheImplementationprocessistorealizeaspecifiedsystemelement.

This process transforms requirements, architecture, and design, including interfaces, into actions that create asystemelementaccordingtothepracticesoftheselectedimplementationtechnology,usingappropriatetechnicalspecialtiesordisciplines.Thisprocess results ina systemelement that satisfies specified system requirements(includingallocatedandderivedrequirements),architecture,anddesign.

Forsoftwaresystems,thepurposeoftheImplementationprocessistorealizeasoftwaresystemelement.





Software system elements can include hardware, software, and services. For software implementation, thisprocesstransformsspecifieddesigns,behavior,interfacesandimplementationconstraintsintoactionsthatcreatea software system element implemented as a software product or service, also known as a “software item”.Softwareimplementationresultsinasoftwareelementthatsatisfiesspecifiedrequirementsthroughverificationand stakeholder requirements through validation. Software implementation includes various combinations ofconstruction (coding of newly built software elements), acquisition of new software packages (e.g., from opensourceoracommercialororganizationalsource)orre‐useofexistingelements(withorwithoutmodification).

SoftwareimplementationcommonlyinvolvesuseoftheAgreementprocessestoobtainnon‐developmentalitems(NDI), such as hardware and operating systems (the platform) or enabling systems and services. Softwareimplementation is usually performed concurrently with software integration. Implementation is typicallyperformedalongwithalloftheTechnicalManagementprocessesandmanyoftheTechnicalprocesses,especially:

a) TheVerificationprocess,whichprovidesobjectiveevidencethatthesoftwareimplementationfulfillsitsspecified requirements and identifies anomalies (errors, defects, faults) in implementation‐relatedinformation items, (e.g., system/software requirements, architecture, design, or other descriptions),processes,softwareelements,items,units;

b) The Validation process, which confirms that the implementation fulfils requirements for a specificintendeduseofasoftwareworkproduct.

6.4.7.2 Outcomes

AsaresultofthesuccessfulimplementationoftheImplementationprocess:

a) Implementationconstraintsthatinfluencetherequirements,architecture,ordesignareidentified.

b) Asystemelementisrealized.

c) Asystemelementispackagedorstored.

d) Anyenablingsystemsorservicesneededforimplementationareavailable.

e) Traceabilityisestablished.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheImplementationprocess.

a) Prepare for implementation.Thisactivityconsistsofthefollowingtasks:

1) Defineanimplementationstrategy,withconsiderationofthefollowing:

i) development policies and standards, including standards that govern applicable safety, security,privacy and environmental practices; programming or coding standards; unit test policies; andlanguage‐specificstandardsforimplementingsecurityfeatures;

ii) Forreusedoradaptedsoftware,methodstodeterminethelevel,source,andsuitabilityofthereusedsystemelementsandsecurityofthesupplychain;

iii) proceduresandmethodsforsoftwaredevelopment(construction)anddevelopmentofunittests;andtheuseofpeerreviews,unittests,andwalkthroughsduringimplementation;

iv) useofCMcontrolduringsoftwareconstruction;

v) changemanagementconsiderationsformanualprocesses;

vi) implementation priorities to support data and software migration and transition, along withretirementoflegacysystems;




vii) creation of manual or automated test procedures to verify that a software unit meets itsrequirementsbeforecreationofthesoftwareunit(test‐drivendevelopment);and

viii) comprehensive or specialized life cycle development and support environments for realizing andmanaging requirements,models andprototypes,deliverable systemor softwareelements, and testspecificationsandtestcases.

NOTE Theimplementationstrategyiscommonlyrecordedinaproject’sSDPorSEMP,orsometimesinaPMP.

2) Identify constraints from the implementation strategy and implementation technology on thesystem/software requirements, architecture characteristics, design characteristics, or implementationtechniques.

NOTE1 Constraints include current or anticipated limitations of the chosen implementation technology (e.g., forsoftware, the operating system, database management system, web services), acquirer furnishedmaterials or systemelementsforadaptation,andlimitationsresultingfromtheuseofrequiredimplementation‐enablingsystems.

NOTE2 The implementation strategy for software typically identifies and allocates ‘implement‐to’ criteria, e.g.,softwarearchitectureanddesigncharacteristics, system/softwarerequirements includingsoftwareassurance,usabilityconsiderations, configuration management, traceability, or other conditions to be satisfied. These criteria can clarifyappropriateunitaggregationlevels,specifications,andconstraints.

3) Identify andplan for the necessary anddistinct software environments, including enabling systems orservicesneededtosupportdevelopmentandtesting.

NOTE Implementation of software commonly uses distinct environments that are separated under configurationcontrolfromtheoperational(production)environment.CommonImplementationprocess,enablingsystems,andservicesinclude comprehensive or specialized life cycle development and support environments for realizing and managingrequirements, models and prototypes, deliverable elements, and test environments, specifications and test cases;simulatorsforexternalsystems,trainingsystems;andcontentmanagementsystemsforuserdocumentation.

4) Obtainoracquireaccesstothesoftwareenvironmentsandotherenablingsystemsorservices.

NOTE TheValidationprocessisusedtoobjectivelyconfirmthattheintegrationenablingsystemachievesitsintendeduseforitsenablingfunctions.

b) Perform implementation. Thisactivityconsistsofthefollowingtasks:

NOTE Throughout the Implementation process the Verification process is used to objectively confirm the systemelementsconformtorequirements.TheValidationprocessisusedtoobjectivelyconfirmtheelementissuitabletobeusedinitsintendedoperationalenvironmentaccordingtostakeholderrequirements.

1) Realizeoradapt softwareelements, according to thestrategy, constraints,anddefined implementationprocedures.

NOTE1 Software elements are acquired, identified for reuse fromorganizational assets, ordeveloped (constructed).Software elements that are acquired can range from a simple product purchase in accordancewith organizational orprojectpurchasingrulestoacomplexacquisitionofasoftwaresystemthatinvolvestheAcquisitionandSupplyprocesses.Adaptation includesconfigurationof softwareelements thatare reusedormodified.Constructioncan involvesoftwarecoding,adaptivereuseandintegrationofexistingunits,refactoring,databasedevelopment,andconstructionofmanualorautomatedtestproceduresforeachunit.

NOTE2 Forsoftwareelementsthataredeveloped,atthelowestlevelofimplementationexecutablesoftwareunitsareconstructed (often with associated data structures, application programming interfaces, service descriptions, userdocumentation,testcases,orotherelements),controlled,madeavailabletoauthorizedroles,andstoredaccordingtotheCMproceduresfordevelopmentartifacts.

NOTE3 TheSWEBOK, Guide to the Software Engineering Body of Knowledge provides detailed discussion on SoftwareConstruction. This knowledge area addresses fundamentals,management,measurement, practical considerations (e.g.,constructiondesign,languages,testing,reuseandintegration),constructiontechnologies(e.g.,objectoriented,errorandexceptionhandling,executablemodels,distributedsoftware),andtoolsandenvironments.

2) Realizeoradapthardwareelementsofsoftwaresystems.





NOTE Hardware elements are acquired or fabricated using applicable techniques relevant to the physicalimplementation technology andmaterials selected.As appropriate, hardware elements are verified for conformance tospecifiedsystemrequirementsandcriticalqualitycharacteristics.Inthecaseofrepeatedsystemelementimplementation(e.g., mass production, replacement system elements) the implementation procedures and fabrication processes aredefinedandcanbeautomatedtoachieveconsistentandrepeatableproducibility.Somecommonhardwareelements insoftware systems include integrations of acquired COTS systems, special modifications, e.g., for test or operationalenvironments,andhardwarecontrolswithembeddedsoftware.

3) Realizeoradaptserviceelementsofsoftwaresystems.

NOTE Service elements include a set of services to be provided. ISO/IEC 20000 (IEEE Std 20000) applies tomanagementof systemelements realized in services, including strategy,design, and transition.Asappropriate, serviceelementsareverifiedforconformancetothesystemrequirementsandservicecriteria.Forexample,operationalresourceelementsareverifiedforconformancetothesystemrequirementsandoperationalconcept.Serviceelementscanincludenetwork communications, training, software packaging and distribution services, software customization services forcustomer‐specificneeds,operationalandsecuritymonitoring,anduserassistance.

4) Evaluatesoftwareunitandaffiliateddataorotherinformationaccordingtotheimplementationstrategyandcriteria.

NOTE1 Criteriaforevaluationcommonlyincludesatisfactionofunitrequirementsandtestcriteria,unittestcoverage,traceability requirements, consistency with software element requirements or design, internal unit requirementconsistency, and feasibility for further process activity, e.g., integration, verification, validation, operations andmaintenance.

NOTE2 UsetheManage results of implementationactivitytorecordconstructionandaddressanomalies.

5) Packageandstorethesoftwaresystemelement.

NOTE Contain the software system element in order to achieve continuance of its characteristics. Conveyance andstorage, and their durations, can influence the specified containment. For software, amaster copyof the implementedsoftware(electronicoronphysicalmedia)isstoredinacontrolledlocationandmadeavailabletoauthorizedroles(e.g.,for use in the Integration and Transition processes). Configuration and product information is captured by theConfigurationManagementandInformationManagementprocesseswhentheelementisstored.

6) Recordobjectiveevidencethatthesoftwaresystemelementmeetsrequirements.

NOTE Evidence is provided in accordance with supply agreements, legislation and organization policy. Evidenceincludeselementmodificationsmadeduetoprocessingchangesornon‐conformancesfoundduringtheVerificationandValidationprocesses.Theobjectiveevidence ispartof theelement’sas‐implementedconfigurationbaselineestablishedthrough the Configuration Management process and includes the results of unit testing, analysis, inspections, walk‐throughevents,demonstrations,productortechnicalreviews,orotherverificationexercises.

c) Manage results of implementation. Thisactivityconsistsofthefollowingtasks:

1) Recordimplementationresultsandanomaliesencountered.

NOTE Thisincludesanomaliesduetotheimplementationstrategy,theimplementationenablingsystems,orincorrectsoftwaresystemdefinition.TheProjectAssessmentandControlandQualityAssuranceprocessesareusedtoanalyzethedatatoidentifytherootcause,enablecorrectiveorimprovementactions,andtorecordlessonslearned.

2) Maintaintraceabilityoftheimplementedsoftwaresystemelements.

NOTE1 To support traceability throughout the life cycle during operations and maintenance, sources of softwarelicenses and other system assets in the supply chain are recorded. The information management and configurationmanagementprocesses areused tomaintain licenseandmaintenance support terms fora softwareapplicationand itsrequiredinfrastructure(hostsystem).TheISO/IEC19770standardsproviderequirementsforanITassetmanagementsystem.

NOTE2 Bidirectional traceability is maintained between the implemented elements and the software systemarchitecture; design, and related requirements, including interface requirements anddefinitions that arenecessary forimplementation;andvalidationandverificationplans,procedures,andresults.





NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.Thisprocess identifiescandidatesforthebaseline,andtheInformationManagementprocesscontrolsthe informationitems.For this process, the software system elements (e.g., source code), software packages, and unit test results are typicalartifactsthatarebaselined.

6.4.8 Integration process

6.4.8.1 Purpose

ThepurposeoftheIntegrationprocessistosynthesizeasetofsystemelementsintoarealizedsystem(productorservice)thatsatisfiessystem/softwarerequirements,architecture,anddesign.

This process assembles the implemented system elements. Interfaces are identified and activated to enableinteroperationofthesystemelementsasintended.Thisprocessintegratestheenablingsystemswiththesystem‐of‐interesttofacilitateinteroperation.

Softwaresystemintegrationiterativelycombinesimplementedsoftwaresystemelementstoformcompleteorpartialsystemconfigurationsinordertobuildaproductorservice.Softwareintegrationistypicallyperformeddailyorcontinuouslyduringdevelopment and maintenance stages, using automated tools. Continuous integration involves frequent inclusion orreplacementandarchivingofitemsinsoftwarelibrariesunderCMcontrol.

NOTE Interfaces are defined by the Architecture Definition and Design Definition processes. The Integration processcoordinateswiththeseotherprocessestocheckthat the interfacedefinitions,as implementedand integrated,areadequateandthattheytakeintoaccounttheintegrationneeds.

6.4.8.2 Outcomes

AsaresultofthesuccessfulimplementationoftheIntegrationprocess:

a) Integrationconstraintsthatinfluencesystemrequirements,architecture,ordesign, includinginterfaces,areidentified.

b) Approachandcheckpointsforthecorrectoperationoftheassembledinterfacesandsystemfunctionsaredefined.

c) Anyenablingsystemsorservicesneededforintegrationareavailable.

d) Asystemcomposedofimplementedsystemelementsisintegrated.

e) Theinterfacesbetweentheimplementedsystemelementsthatcomposethesystemarechecked.

f) Theinterfacesbetweenthesystemandtheexternalenvironmentarechecked.

g) Integrationresultsandanomaliesareidentified.

h) Traceabilityoftheintegratedsystemelementsisestablished.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheIntegrationprocess.

a) Prepare for integration. Thisactivityconsistsofthefollowingtasks:

1) Definetheintegrationstrategy.

NOTE1 Integration builds sequences of progressively more complete software system element or software itemconfigurations.Itisdependentonapplicablesoftwaresystemelementavailabilityandisconsistentwithafaultisolationand diagnosis strategy. Successive applications of the Integration process and the Verification process, and whenappropriate the Validation process, are repeated for elements in the system structure until the system‐of‐interest hasbeen realized. Simulators or prototypes are typically utilized for system elements that are not yet implemented, e.g.,





receivingdatafrominterfacingsystems.Integratingtheimplementedsoftwaresystemelementsisbasedontheprioritiesoftherelatedrequirementsandarchitecturedefinition,typicallyfocusingontheinterfaces,whileminimizingintegrationtime, cost, and risks. Software system integration commonly maintains version control through the ConfigurationManagementprocessforselectionofconfigurationitemstobeintegrated.

NOTE2 For software integration, the integration strategy typically is consistentwith a regression strategywhich isappliedforre‐verifyingsoftwareelementswhenrelatedsoftwareunits(andpotentiallyassociatedrequirements,designanduserdocumentation)arechanged.

NOTE3 Definingastrategyforsoftwareunitandelementintegrationcommonlyaccompaniesdefiningthestrategyforotherprocessesthatoccurconcurrently,suchas:

i) The Implementation process to help ensure timely coordination of Implementation and Integration processtasksandenablingsystems,e.g.,combinedsoftwaredevelopmentandtestenvironmentstosupportautomatedorcontinuousimplementationandintegrationofsoftwareunitsandelements.

ii) The Verification process to provide objective evidence that the integrated software fulfils its specifiedrequirementsand to identifyanomalies (errors,defects, faults) in integration‐related information items, (e.g.,system/softwarerequirements,architecture,design,test,orotherdescriptions),processes,softwareelements,items,units.

iii) TheValidation process to confirm that awork product fulfils requirements for a specific intended use of anintegratedsoftwarefunction.

iv) TheQualityAssuranceprocesstosupportintegrationprocessandworkproductauditsandinspectionsandtoaddressproblem,non‐conformance,orincidentreportingandhandling.

NOTE4 Theintegrationstrategyiscommonlyrecordedinaplan,e.g.,anintegrationplan,oraproject’sSDPorSEMP.

2) Identifyanddefinecriteriaforintegrationandpointsatwhichthecorrectoperationandintegrityoftheinterfacesandtheselectedsoftwaresystemfunctionswillbeverified.

NOTE1 DetailedverificationoftheinterfacesisperformedusingtheVerificationprocess.Softwareintegrationtypicallyinvolves combining software elements, resulting in a set of integrated software elements, that is consistent with thesoftwaredesign,andthatsatisfies the functionalandnon‐functionalsystem/softwarerequirementsonanequivalentoftheoperationalenvironment.

NOTE2 Forprojects involvingmultiplesuppliersordevelopmentteams,theavailabilityofsoftwaresystemelementsforintegrationistypicallypartoftheprojectschedulewithmilestonesundertheProjectAssessmentandControlprocess.Integration proceeds as the software is verified in its functionality, performance, and suitability for site‐specific orplatform‐specificenvironments.Atmajorintegrationpoints,e.g.,completionofastage,element,orversion,checkpointsforreviewsandvalidationwithstakeholdersaretypicallyheld.Thefrequencyofthesereviewsisrelatedtotheselectedlifecyclemodelanddevelopmentmethod.

3) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportintegration.

NOTE This includes identification of requirements and interfaces for the enabling systems. Enabling systems forintegration commonly include integration facilities, specialized equipment, training systems, discrepancy reportingsystems, simulators, measurement devices, and environmental security. For software, this can involve regression testsuitesandCMsystemsfortheintegratedtestingofsoftwaresystems,incidentandproblemreportingsystems,simulatorsrepresenting external systems or undeveloped elements, and software library management systems for developmentoperations. Changes or specializations needed for the enabling systems to support the integration tasks need to beidentifiedanddefined.Typically,theenablingsystemsorservicesusedforintegrationduringdevelopmentstagescanalsohelpsupportsystemelementintegrationasthesoftwaresystemandenablingenvironmentsevolvetooperationalstatus.This “DevOps” approach supports iterative software system implementation, integration, verification, transition,validation,operationandmaintenanceprocesses.

4) Obtainoracquireaccesstotheenablingsystemsorservicestobeusedtosupportintegration.

NOTE TheValidationprocessisusedtoobjectivelyconfirmthatanintegrationenablingsystemachievesitsintendeduseforitsenablingfunctions.

5) Identifyconstraintsforintegrationtobeincorporatedinthesystem/softwarerequirements,architectureordesign.




NOTE This includes requirements such as accessibility, supply chain security, safety for integrators, requiredinterconnectionsforsetsofimplementedsoftwaresystemelementsandforenablers,andinterfaceconstraints.

b) Perform integration. Successively integrate software system element configurations until the completesystemissynthesized.Thisactivityconsistsofthefollowingtasks:

1) Obtainimplementedsoftwaresystemelementsinaccordancewithagreedschedules.

NOTE The implementedsoftwaresystemelementsareprovidedfromthedevelopersorreceived fromsuppliers, theacquirer,orotherresourcesandtypicallyplacedunderCMcontrol.Theelementsarehandledinaccordancewithrelevanthealth,safety,securityandprivacyconsiderations.

2) Integratetheimplementedelements.

NOTE1 Thistaskisperformedtoachievesoftwaresystemelementconfiguration(completeorpartial)connectingtheimplemented elements as prescribed in the integration strategy, using the defined procedures, interface controldescriptions,andtherelatedintegrationenablingsystems.

NOTE2 Intermsofsoftware,integratingtheimplementedelementscaninvolvelinkingtogetherpiecesofobjectcodeorsimplybringingtogethertheimplementedelementsthatarepartofthesoftwareconfigurationinamethodicalpiecebypiece approach. Software elements are typically compiled into a “build” so that branched units are properly linked ormerged in the assembled element. Firmware elements are fabricated, often as prototypes, and installed in hardwareelements.Ifsoftwarefunctionsarenotyetavailableforintegration,emulatedfunctionality(stubsorscaffolding)canbeused to temporarily support integration of software elements or represent input from external interfaces. Successfulaggregationsresult inanintegratedsoftwareelement, that isstoredandavailableforfurtherprocessing, i.e.,additionalsoftwaresystemelementintegration,verification,orvalidation.

NOTE3 Anti‐counterfeit, anti‐tamper, system and software assurance and interoperability concerns can arise whenperforming integration and identifying and defining checkpoints. Integration and Verification processes often usefictitious data for security or privacy considerations. ISO/IEC/IEEE 15026 and the ISO/IEC 27000 series includeinformationonassurance,integrity,andsecurityconsiderationsaffectingintegration.

3) Checkthattheintegratedsoftwareinterfacesorfunctionsrunfrominitiationtoanexpectedterminationwithinanexpectedrangeofdatavalues.

NOTE Aspartoftheacceptanceoftheimplementedsoftwaresystemelements,selectedelementsarecheckedtohelpensure theymeet acceptance criteria as specified in the integration strategy and applicable agreements. Checking canincludeconformancetotheagreedconfiguration,compatibilityofinterfaces,andthepresenceofmandatoryinformationitems.TheProjectAssessmentandControlprocesscanbeusedinaccordancewiththeintegrationstrategytoplanandconduct technical reviews of the integrated software system elements, e.g., a test readiness review to help ensure theintegratedelementorsystemwithitsaffiliateddataandinformationitemsisreadyforqualificationtesting.

c) Manage results of integration.Thisactivityconsistsofthefollowingtasks:

1) Recordintegrationresultsandanomaliesencountered.

NOTE This includes anomalies due to the integration strategy, the integration enabling systems, execution of theintegrationorincorrectsystemorelementdefinition.Whereinconsistenciesexistattheinterfacebetweenthesystem,itsspecifiedoperationalenvironmentandsystemsthatenabletheutilizationstage,thedeviationsleadtocorrectiveactions.AnomalyresolutiontypicallyinvolvestheTechnicalProcesses,oftenrepetitiveapplicationoftheImplementationprocess.TheQualityAssuranceandProjectAssessmentandControlprocessareusedtoanalyzethedatatoidentifytherootcause,enablecorrectiveorimprovementactions,andtorecordlessonslearned.

2) Maintaintraceabilityoftheintegratedsoftwaresystemelements.

NOTE Bidirectional traceability is maintained between the integrated system elements and the software systemarchitecture,design,andsystemorelement requirements, suchasuse cases,and including interfacerequirementsanddefinitions that are necessary for integration. Integrated software elements and their components are identified byversion.Versionsofintegratedsoftwareelementsarecommonlytraceabletoimplementedunits,testprocedures,andtestcases.


NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.TheIntegration process identifies candidates for the baseline, and the Information Management process controls the





informationitems.Forthisprocess,thetestcases,regressiontests,andautomatedtestscriptsaretypicalartifactsthatarebaselined.Theintegrationstrategyisatypicalinformationitemthatisbaselined.

6.4.9 Verification process

6.4.9.1 Purpose

ThepurposeoftheVerificationprocessistoprovideobjectiveevidencethatasystemorsystemelementfulfilsitsspecifiedrequirementsandcharacteristics.

The Verification process identifies the anomalies (errors, defects, or faults) in any information item (e.g.,system/softwarerequirementsorarchitecturedescription),implementedsystemelements,orlifecycleprocessesusingappropriatemethods, techniques, standardsor rules.Thisprocessprovides thenecessary information todetermineresolutionofidentifiedanomalies.

Verification can be performed across all technical processes. The Verification process is typically used at keypoints in a software system’s life cycle to demonstrate that the requirements (including functional and non‐functionalrequirements)havebeenmet,orthatprocessoutcomeshavebeenachievedorprocessactivitieshavebeen performed. Different domains and engineering or development communities can identify themilestones,verificationstrategiesandcriteriadifferently.

Forsoftwaresystems,theVerificationprocessistypicallyinstantiatedforthefollowingpurposes:

a) Toconfirmthatasoftwareworkproductorserviceproperlyreflects thespecifiedrequirements (oftencalledsoftwareverification);

b) Toconfirm that the integrated softwareproductmeets itsdefined requirements (often called softwarequalificationtesting);and

c) Toconfirmthatthe implementationofeachsystem/softwarerequirement is tested forcomplianceandthatthesoftwaresystemisreadyfordelivery(oftencalledsystemqualificationtesting).

NOTE1 TheVerificationprocessdetermines that the “product isbuilt right”.TheValidationprocessdetermines thatthe“rightproductisbuilt”.

NOTE2 ISO/IEC/IEEE29119Systems and software engineering — Software testing(inmultipleparts)providesdetailedprocessesandtechniquesforverificationperformedthroughtesting. IEEEStd1012‐2012, IEEE Standard for System and Software Verification and Validation, provides additionaldetails about theseprocesses for systems, software, hardware,andinterfacesbeingdeveloped,maintained,orreused.

NOTE3 TheSWEBOK, Guide to the Software Engineering Body of Knowledge, providesdetaileddiscussiononSoftwareTesting. This knowledge area addresses fundamentals, terminology, issues, techniques, application, process planning,measures,tools,practicalconsiderations,andreferences.TheguidealsodiscussesSoftwareVerificationandValidationintermsofSoftwareQualityManagementprocesses,andidentifiesmethodsandtechniquesthatsupportbothVerificationand Validation. The SWEBOK also addresses topics such as software construction for verification and softwareengineeringmodelsandmethodssupport.

6.4.9.2 Outcomes

AsaresultofthesuccessfulimplementationoftheVerificationprocess:

a) Constraintsofverificationthatinfluencetherequirements,architecture,ordesignareidentified.

b) Anyenablingsystemsorservicesneededforverificationareavailable.

c) Thesystemorsystemelementisverified.

d) Dataprovidinginformationforcorrectiveactionsisreported.

e) Objectiveevidencethattherealizedsystemfulfillstherequirements,architectureanddesignisprovided.




f) Verificationresultsandanomaliesareidentified.

g) Traceabilityoftheverifiedsystemelementsisestablished.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheVerificationprocess.

a) Prepare for verification. Thisactivityconsistsofthefollowingtasks:

1) Definetheverificationstrategy,whichincludesthefollowing:

NOTE1 Averificationstrategygenerallyfocusesonminimizingcost,schedule,orrisk,providingabalancedapproachforconfirmingthatthesoftwaresystemorelementhasbeen“builtright”.

NOTE2 Theverificationstrategyandscheduleaccountfordynamicchangeswhenanomalousresults(events,incidents,orproblems)occur.According to theprogressof theproject,plannedverificationactionsare redefinedor rescheduledwhenunexpectedeventsorsystemevolutionsoccur.

NOTE3 Theverificationstrategycanbedocumentedinaplan,e.g.,averificationplan,oraproject’sSDPorSEMP.

i) Identifytheverificationscope,includingthesoftwaresystem,element,orartifact,thepropertiestobeverified,andtheexpectedresults.

NOTE Overall verification scope includes the software system‐of‐interest or system elements, includinginterfaces.Foreachverificationaction,thescopeidentifiesthesoftwaresystem,element,orartifacttobeverified(e.g., theactualsystem,oramodel,amock‐up,aprototype,code,aprocedure,aplanorotherdocument)andtheexpectedresults,suchasconformance,orperformance,faulttolerance,andrecoveryafterserviceinterruption.Thepropertiestobeverifiedcanincluderequirements,architectureanddesigncharacteristics,integration,andaccuracyofdocumentation.Designcharacteristicscanincludesecurityimplicationsofthedesigninthecontextoftheplannedoperationalenvironmentandtheachievementofcriticalqualitycharacteristicsasstatedintherequirements.

ii) Identifytheconstraintsthatpotentiallylimitthefeasibilityofverificationactions.

NOTE Constraints include technical feasibility, cost, time, availability of verification enablers or qualifiedpersonnel,contractualconstraints,andcharacteristicssuchascriticalityofthemission.Suchconstraintsoftenfactorinto verification strategy determination, e.g., whether an organizationally independent verification effort isnecessaryorjustified.

iii) Identifyverificationpriorities.

NOTEIn software systems, verificationof every possible scenario (100% code coverage) is typically infeasible.Theverificationstrategytypicallyincludestradingoffwhatwillbeverified(scope)againsttheconstraintsorlimits,anddeducingwhatverificationactionstoperformandhowmanyiterationsofverificationactionsandreworkareneeded to reduce risk. Amodel‐based testing approach can enable the generation andmanagement of multiplescenarios.Potentialverificationactionsthatarecandidatesfordeletionareevaluatedfortheriskstheirwithdrawalimposes.

2) Identify constraints from the verification strategy to be incorporated in the system/softwarerequirements,architecture,ordesign.

NOTE This includes practical limitations of accuracy, uncertainty, repeatability that are imposed by the verificationenablers, the associated measurement methods, the need for software system integration, and the availability,accessibilityandinterconnectionwithenablers.

3) Definethepurpose,conditionsandconformancecriteriaforeachverificationaction.

4) Selectappropriateverificationmethodsortechniquesandassociatedcriteriaforverificationactions,suchasinspection,analysis,demonstration,ortesting.

NOTE1 Theselectionofverificationmethodsortechniquesismadeaccordingtothetypeofsystem,thepurposeoftheverification,theobjectivesoftheproject,andtheacceptablerisks.Verificationmethodsortechniquesincludeinspection





(including codewalkthroughs andpeer review), analysis (includingmodelling and simulation, and analogy/similarity),demonstration,anddynamicandstatictesting.

NOTE2 Theselectedverificationapproach,methods,andtechniquescanbecoordinatedwithrelevantstakeholderstohelpensuretheverificationapproachisacceptable.

5) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportverification.

NOTE Verification enabling systems include verification facilities, qualified personnel, equipment, simulators, testautomationtools,andincidentandproblemmanagementsystems.Softwaresystemverificationistypicallyperformedindistinctcontrolledenvironmentsthatdonotinterferewithoperationalsoftwareorongoingdevelopment.Iftheenablingsystemsforverificationdifferincapabilityfromtheplannedoperationalenvironment,theMeasurementprocesscanbeusedtocalibratetheperformanceoftheverificationenablingsystemsandsuitabilityfortheverificationaction.

6) Obtainoracquireaccesstotheenablingsystemsorservicestobeusedtosupportverification.

NOTE The acquisition of the enabling systems can be done through various ways such as rental, procurement,development,reuseoforganizationalassets,orsubcontracting.Usuallytheacquisitionofthecompletesetofenablersisamixoftheseways.TheValidationprocessisusedtoobjectivelyconfirmthattheverificationenablingsystemachievesitsintendeduseforitsenablingfunctions.

b) Perform verification. Thisactivityconsistsofthefollowingtasks:

1) Definetheverificationprocedures,eachsupportingoneorasetofverificationactions.

NOTE Verificationprocedures,whichcanbeperformedbyautomatedscripts,includetherequirementstobeverified,thetypeofsoftwaresystemelementorartifacttobeverified(e.g.,theactualsystem,oramodel,amock‐up,aprototype,code,aprocedure,aplan,orotherinformationitem),andtheexpectedresults(successcriteria),suchasconformance,orperformanceofafunctionorcapacityintermsofresponsetimeorthroughput.Theproceduresidentifythepurposeoftheverification with success criteria (expected results), the verification technique to be applied, the necessary enablingsystems (facilities, equipment), and the environmental conditions to perform each verification procedure (resources,qualified personnel, specialized procedural set‐up or work instructions). Verification procedures include how theverificationprocedureresultswillberecorded,analyzed,stored,andreported.

2) Performtheverificationprocedures.

NOTE Verificationoccurs, inaccordancewiththeverificationstrategy,attheappropriatetimeintheschedule, inthedefinedenvironment,withdefinedenablingsystemsandresources.Theperformanceofaverificationactionconsistsofcapturingaresultfromtheexecutionoftheverificationprocedure;comparingtheobtainedandrecordedresultwiththeexpectedresult;anddeducingadegreeofcorrectness(orsuccess/failure)ofthesubmittedelement.

c) Manage results of verification. Thisactivityconsistsofthefollowingtasks:

1) Reviewverificationresultsandanomaliesencounteredandidentifyfollow‐upactions.

NOTE1 This includes anomalies due to the verification strategy, the verification enabling systems, execution of theverification,orincorrectsystemdefinition.TheProjectAssessmentandControlandQualityAssuranceprocessesareusedtoanalyzethedatatoidentifytherootcause,enablecorrectiveorimprovementactions,andtorecordlessonslearned.

NOTE2 The evaluation of verification results and follow‐up corrective action can vary greatly depending on thepurposeoftheverification.Forelementsofsoftware,examplesincludeamodificationorwaiverofrequirements,asimpledefect fix for a failed software element, followed by re‐verification, ormajor project re‐direction based on a failure toattain a key milestone, e.g., failed software system qualification testing. Often simple or recommended solutions toanomalies discovered during verification, are recorded with the verification result to facilitate analysis and potentialcorrectiveaction.

2) Recordincidentsandproblemsduringverificationandtracktheirresolution.

NOTE1 PerformingproblemresolutionishandledthroughtheQualityAssuranceandProjectAssessmentandControlprocesses. During software verification, the conditions under which the problem occurred are documented so that ifpossible,theproblemcanbeduplicatedandtherootcauseofthesoftwaredefectidentified.Changestotherequirements,architecture,design,orsystemelementsaredoneusingotherTechnicalprocesses.

3) Obtainstakeholderagreementthatthesoftwaresystemorelementmeetsthespecifiedrequirements.

4) Maintaintraceabilityoftheverifiedsoftwaresystemelements.




NOTE Bidirectional traceability is maintained between the verified system elements and the record of verificationactivity,systemarchitecture,design,orsystem/softwarerequirements.


NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.Thisprocess identifiescandidatesforthebaseline,andtheInformationManagementprocesscontrolsthe informationitems.Forthisprocess,theverificationstrategyandverificationproceduresaretypicalinformationitems.

6.4.10 Transition process

6.4.10.1 Purpose

Thepurposeof theTransitionprocess is to establisha capability for a system toprovide services specifiedbystakeholderrequirementsintheoperationalenvironment.

Thisprocessmovesthesysteminanorderly,plannedmannerintotheoperationalstatus,suchthatthesystemisfunctional, operable and compatiblewithotheroperational systems. It installs a verified system, togetherwithrelevantenablingsystems,e.g.,planningsystem,supportsystem,operatortrainingsystem,usertrainingsystem,asdefinedinagreements.Thisprocessisusedateachlevelinthesystemstructureandineachstagetocompletethe criteria established for exiting the stage. It includes preparing applicable storage, handling, and shippingenablingsystems.

Forsoftwaresystems, thepurposeof theTransitionprocess is toestablishacapability forasystemtoprovideservicesinadifferentenvironment.

TheTransitionprocessisoftenusedforrecurringdeploymentsofsoftwaretodifferentenvironments,e.g.,fromadevelopmentenvironmenttoatestormaintenanceenvironment,orbetweenvarioustestenvironments,orfromone operational environment to another (e.g., rehosting or use of cloud services). Transitions to backup orcontingentsitesaretypicallyplannedandrehearsedforbusinesscontinuityanddisasterrecovery.Transitionforsoftwaresystemscaninvolvethephysicalrelocationofhardware,theinstallationandactivationordeactivationofphysical or virtual infrastructure or enabling systems in different locations, or no change to the physicalinfrastructure. Transition can involve changes to the data sources, data structure, or updates or upgrades offunctional software. Transition includes recurring scheduled or emergency patches and fixes for security andother concerns. Transition can involve transfer between organizations and also encompasses the addition of alargegroupofnewuserstoanexistingsoftwaresystemorservice.Transitiontoanewsystemoftenisperformedconcurrentlywithretirementanddisposalofanexistingsystem,entailingdatamigrationfromtheoldsystemtoitsreplacement.

NOTE TransitioncaninvolveknowledgetransferusingtheKnowledgeManagementprocess.

6.4.10.2 Outcomes

AsaresultofthesuccessfulimplementationoftheTransitionprocess:

a) Transition constraints that influence system/software requirements, architecture, or design areidentified.

b) Anyenablingsystemsorservicesneededfortransitionareavailable.

c) Thesiteisprepared.

d) Thesystem,asinstalledinitsoperationallocation,iscapableofdeliveringitsspecifiedfunctions.

e) Operators,usersandotherstakeholdersnecessarytothesystemutilizationandsupportaretrained.

f) Transitionresultsandanomaliesareidentified.

g) Theinstalledsystemisactivatedandreadyforoperation.

h) Traceabilityofthetransitionedelementsisestablished.






TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheTransitionprocess.

a) Prepare for the software system transition.Thisactivityconsistsofthefollowingtasks:

1) Define a strategy formanaging software releases and other software system transitions, including thefollowingconsiderations:

i) establishingthetypeoftransitionandtransitionsuccesscriteria;

ii) determining the frequency of recurring transitions, such as updates and upgrades todevelopment,test,andoperationalsoftwaresystems;

iii) minimizingsecurityrisks,disruption,anddowntimeduringtransition;

iv) archiving, destroying, or converting and validating data from previous systems to the newsystem;includingdatareceivedthroughexternalinterfaces;

v) contingency planning for problem resolution, backup and return to the last working systemversion;

vi) schedulingtransitionsconsistentwithongoingbusinessprocessing,withphasedorsynchronizedtransitionofsystems

vii) change management for stakeholders, including interface partners, human operators, systemadministrators,andsoftwaresystemorserviceusers;

NOTE Changemanagementactivitiesareoftenconductedtodesignchangesinbusinessprocessesassociatedwiththenewsystem,planthetransitioninbusinessprocesses,andgainusercommitmenttoproductiveuseofthenewsystem.

viii) associatedstrategiesforvalidationofthetransitioningsystemorelement;

ix) initiatingusersupportandmaintenanceactivitieswiththetransferandupdateofsystemdesigndocumentation,userdocumentation,andtestprocedures;and

x) concurrentexecutionoftheTransition,Operations,andDisposalprocesses,whenanewsystemiscommissionedandanoldsystemisdecommissioned.

NOTE Thestrategyincludesrolesandresponsibilities,approvalauthority,useofreadinessreviewsandtraining.

2) Identify and define facility, site, communications network, or target environment changes needed forsoftwaresysteminstallationortransition.

NOTE Foreachtransition,identifyanddefineanyneededchangesininfrastructureorenablingsystems.Asitesurveycanbeperformedtoidentifyneededchangesinthephysicalenvironmenttoinstallorusethesoftwaresystem,suchaschangestomaintainthephysicalandinformationsecurityofthesystem.

3) Identify information needs and arrange for user documentation and training of operators, users, andotherstakeholdersnecessaryforsystemutilizationandsupport.

NOTE Transition includesmigrationoractivationofuseraccess to thesoftwaresystem.User rolesareestablishedanduseraccountsandaccesscontrolsareimplemented.

4) Preparedetailedtransitioninformation,suchasplans,schedules,andprocedures.

NOTE1 The transition strategy is commonly recorded in a plan, e.g., a transition plan, or a project’s SDP or SEMP.Transitionscheduleshelpvalidatethatsufficientresourcesandinfrastructureareavailabletosupportthetransition,sothatactivitiescanbeexecutedwithinareasonabletimeframetominimizedisruption.Schedulescanincluderehearsals




forcomplextransitions,inwhichprocedures,suchasdatabaseandsystembackupandrestoreandsoftwareinstallation,aretestedtoverifydurationsandcorrectresults.

NOTE2 Duringaspecifiedperiodofchangeoverorconcurrentoperation, thetransferofservices ismanagedsothatcontinuingconformancetopersistentstakeholderneedsoranagreedlevelofserviceisachieved.Ifaperiodofparalleloperationsforboththeoldandnewsystemsisneeded,specialproceduresareidentifiedanddevelopedforreceivingandutilizingdatafrominterfacepartners.

5) Identify system constraints from transition to be incorporated in the software system requirements,architectureordesign.

6) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupporttransition.

NOTE1 Thisincludesidentificationofrequirementsandinterfacesfortheenablingsystems.Transitionofteninvolvestheuseofhighlyautomatedinfrastructuretodeliver,install,andactivateorinactivatesoftware.Forelectronicsoftwaredistribution, temporary or continuing changes in connectivity are often needed for software and data migration andcontinuingsustainment.Enablingsystemscanincludebackuporalternatesystemsforuseduringatransitionalperiod.


NOTE TheValidationprocessisusedtoobjectivelyconfirmthatthetransitionenablingsystemachievesitsintendeduseforitsenablingfunctions.

b) Perform the transition.Thisactivityconsistsofthefollowingtasks:

1) Preparethesiteofoperationorvirtualenvironmentinaccordancewithinstallationrequirements.

NOTE Site preparation is conducted in accordance with applicable health, safety, security and environmentalregulations.Virtualenvironmentsandnewcommunicationresourcesareinitializedandverified.Shippingandreceivingofphysicalsystemelementsandenablingsystemsisarranged.

2) Deliverthesoftwaresystemorelementforinstallationatthecorrectlocationandtime.

NOTE1 Typicallysoftwareisdeliveredelectronically.Forphysicalmedia,hardware,andembeddedsoftwaresystems,itissometimesnecessarytoaccountfortemporarystoragepriortodeliveryorinstallation.

NOTE2 Deliver agreed information items in electronic or physical form, such as training material, logistics supportpackages,oruserdocumentation.

3) Installtheproductinitsphysicalorvirtualoperationallocationandinterfacetoitsenvironment.

NOTE Theproductinstallationincludesconfiguringitwithrequiredoperationaldata,changestotheenvironment,orbusiness process changes. Databases are instantiated and data migration is performed as applicable. Licenses andmaintenanceagreementsforsystemelements,andotherintellectualproperty,aretransferredaccordingtoagreements.

4) Provideuserdocumentationandtrainingfortheoperators,users,andotherstakeholdersnecessaryforproductutilizationandsupport.

5) Performactivationandcheck‐out,includingthefollowingasagreed:

NOTE1 Thistasktakesthestepsneededtoactivatetheproducttoanoperationalstate,includingstart‐up,assessmentofenvironmentalconditions,andotherreadinessevaluations,inaccordancewithoperationalprocedures,organizationalpolicies,andregulations.Wheretheexactlocationorenvironmentofoperationisnotavailableorwhensoftwarewillbeaccessedfrommultipleormobilelocations,arepresentativeexampleisselected.

NOTE2 Acceptance testsare sometimesdefined in theagreement todemonstratesatisfactory installation.This taskinteracts with the Validation process to objectively confirm that the system fulfills stakeholder requirements in theoperationalenvironment.Acceptancetests,asspecifiedinagreements,candefinethecriteriathatdemonstratethatthesoftware system entity possesses the capability to deliver the required functions and services when installed andsustainedinitsoperationalenvironment.Specificattentionisgiventothekeyfunctionsandlogicalinterfaces.

NOTE3 AspartoftheConfigurationManagementprocess,aphysicalconfigurationaudit(PCA)andupdateofas‐builtdocumentationisoftenperformedatthetimeofsystemactivation.Anti‐counterfeitprovisionscanbeconfirmed.





i) Demonstrateproperinstallationofthesoftwaresystem.

NOTEThis task can include integrity checks of data and operations, e.g., that the software code and datarepresentationsproperlyinitialize,execute,andterminateasspecified.

ii) Demonstratetheinstalledortransitionedproductiscapableofdeliveringitsrequiredfunctions.

NOTEThis is an operational readiness task that examines readiness of functional capability for an operationalstate. Specific attention is given to the data interfaces and security concerns: information assurance andinteroperabilityfunctionsareexercised.

iii) Demonstratethefunctionsprovidedbythesystemaresustainablebytheenablingsystems.

NOTEThisisanoperationalreadinesstaskthatexaminesreadinessofenablingsystemsforanoperationalstate.Forexample,activationofmonitoring,problemreporting,accesscontrol,backupandrecovery,anduserassistance(customersupport)aredemonstrated.

iv) Reviewthesoftwaresystemforoperationalreadiness.

NOTEThis includes the results of functional demonstrations, validation activities, and sustainmentdemonstrations.Areadinessreviewcanbeconducted.Deficiencies,risks,andproblemsthatimpactthesuccessofthetransitionareresolved,acceptedforwaiver,orclosed.

v) Commissionthesoftwaresystemforoperations.

NOTEThis includes providing support to the users, administrators, and operators during the operationscommencement(commissioning)ofthesystem.

c) Manage results of transition.Thisactivityconsistsofthefollowingtasks:

1) Recordtransitionresultsandanomaliesencountered.

NOTE This includes anomalies due to the transition strategy, the transition enabling systems, execution of thetransitionorincorrectsoftwaresystemordatabasesystemdefinition.Whereinconsistenciesexistbetweenthesystem,itsoperational environment, and enabling systems, the deviations are resolved through corrective actions, includingrequirementchanges.TheProjectAssessmentandControlandQualityAssuranceprocessesareusedtoanalyzethedatatoidentifytherootcause,enablecorrectiveorimprovementactions,andtorecordlessonslearned.

2) Recordtransitionincidentsandproblemsandtracktheirresolution.

NOTE Performingproblemresolution ishandled throughtheQualityAssuranceandProjectAssessmentandControlprocesses.During transition, the conditionsunderwhich theproblemoccurredaredocumentedso that ifpossible, theproblemcanbeduplicatedandtherootcauseofthedefectidentified.Changestotherequirements,architecture,design,orsoftwaresystemelementsaredoneusingotherTechnicalprocesses.

3) Maintaintraceabilityofthetransitionedsoftwaresystemelements.

NOTE Bidirectional traceability ismaintained between the transitioned and deployed system and elements and theapprovedandcontrolledversionsofthesoftwaresystemandenablingsystems.


NOTE The ConfigurationManagement process is used to establish andmaintain configuration items and baselines,includingtransitionedsoftwaresystemelements.Thisprocessidentifiescandidatesforthebaseline,andtheInformationManagement process controls the information items. For this process, the transition strategy, training material, andinstallation, transition and datamigration procedures, and user documentation are typical information items that arebaselined.




6.4.11 Validation process

6.4.11.1 Purpose

Thepurpose of theValidation process is to provide objective evidence that the system,when in use, fulfils itsbusiness or mission objectives and stakeholder requirements, achieving its intended use in its intendedoperationalenvironment.

Theobjectiveofvalidatingasystemorsystemelementistoacquireconfidenceinitsabilitytoachieveitsintendedmission,oruse,underspecificoperationalconditions.Validationisratifiedbystakeholders.Thisprocessprovidesthe necessary information so that identified anomalies can be resolved by the appropriate technical processwheretheanomalywascreated.

TheValidationprocess istypicallyusedatkeypoints inaproduct’s lifecycletodemonstratethattheproduct’srequirements for stakeholder intended operational use have been met. Validation is also applicable to thesoftware engineering artifacts (viewed as software system elements). Different domains and engineering ordevelopmentcommunitiescanidentifythemilestones,validationstrategiesandcriteriadifferently.

Forsoftwaresystems,highlyiterativelifecyclemodelsoftenfeaturefrequentinvolvementbytheacquirer,userrepresentative,orotherstakeholderstovalidate,e.g.,thepriorityofrequirementsforinclusioninaniteration,theusabilityofthesoftwareinterfacethroughprototypes,andthesuitabilityofthesoftwareforperformingbusinesstasksandfulfillingtheoperationalconcept.

Forsoftwaresystems,thefollowingarepurposesoftheValidationprocess:

a) Toconfirmthat therequirements foraspecific intendeduseof thesoftwareworkproductare fulfilled(oftencalledsoftwarevalidation);and

b) To achieve confidence (especially with an acquirer or customer) that the delivered product meetsstakeholderrequirementsandisfitforuse(oftencalledsoftwareacceptancetesting).

NOTE1 Thevalidationprocessdeterminesthatthe“rightproductisbuilt”.Theverificationprocessdeterminesthatthe“productisbuiltright”.

NOTE2 Acceptancecriteria,asusedforacceptancetesting,includecriteriatodeterminewhetherthedeliveredproductis fit touseornot.Acceptancecriteriaforacceptancecanbespecifiedandagreedbetweentwoparties, i.e.,anacquirerandasupplier,andincludedinthestakeholderrequirements.

NOTE3 IEEE Std 1012‐2012, IEEE Standard for System and Software Verification and Validation, provides detailedrequirements. The SWEBOK, Guide to the Software Engineering Body of Knowledge, discusses software verification andvalidationintermsofsoftwareQualityManagementprocesses,andcontainsmethodsandtechniquesthatsupportbothverificationandvalidation.TheSWEBOKalsoaddressestopicssuchasrequirementsandmodelvalidation.

6.4.11.2 Outcomes

AsaresultofthesuccessfulimplementationoftheValidationprocess

a) Validationcriteriaforstakeholderrequirementsaredefined.

b) Theavailabilityofservicesrequiredbystakeholdersisconfirmed.

c) Constraintsofvalidationthatinfluencetherequirements,architecture,ordesignareidentified.

d) Thesystemorsystemelementisvalidated.

e) Anyenablingsystemsorservicesneededforvalidationareavailable.

f) Validationresultsandanomaliesareidentified.

g) Objectiveevidencethattherealizedsystemorsystemelementsatisfiesstakeholderneedsisprovided.





h) Traceabilityofthevalidatedsystemelementsisestablished.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheValidationprocess.

a) Prepare for validation. Thisactivityconsistsofthefollowingtasks:

1) Definethevalidationstrategy,whichincludesthefollowing:

NOTE1 A validation strategy generally focuses on minimizing cost, schedule, or risk by progressively buildingconfidenceinthequalityandsuitabilityofthesoftwaresystemforthestakeholders.

NOTE2 The validation strategy reflects the life cycle model, and often involves repeated validation for iterative,incremental,orevolutionarylifecycles.

NOTE3 Thevalidationstrategycanbedocumentedinaplan,e.g.,anacceptanceplan,oraproject’sSDPorSEMP.

i) Identify the validation scope, including the characteristics of the software system, element, orartifacttobevalidated,andtheexpectedresultsofvalidation.

NOTESoftware system validation is typically performed both in distinct controlled environments that do notinterferewithoperationalsoftwareorongoingdevelopment,aswellasinoperationalenvironments,typicallybeforefull operational use (e.g., beta testing or acceptance testing for a specified duration with agreed criteria). Scopeincludesstakeholderrequirements,includingrelatedviewsofthesystem(e.g.,scenariosorconceptofoperation)tobeevaluated.Thescopedependsonwhatisappropriateforthesystemslifecyclestage:thesystem‐of‐interestorasystemelementorengineeringartifact,suchasaconceptdescriptionordocument,anoperationalscenario,amodel,amock‐up, or prototype. The scope also includes evaluating that the software product or service is usable in itsintended environment for the principal or critical functions. Additional characteristics to be validated can includeusabilityofthedocumentation;faulttolerance,resilience,andrecoveryfeaturesofthesoftware.

ii) Identifytheconstraintsthatpotentiallylimitthefeasibilityofvalidationactions.

NOTE Constraints includepractical limitations of accuracy, uncertainty, repeatability that are imposedby thevalidationenablers,theassociatedmeasurementmethods,andtheavailability,accessibilityandinterconnectionwithenablers. The validation strategy is constrained by the progress of the project; in particular, planned validationactionsareredefinedorrescheduledwhenunexpectedeventsorsystemevolutionsoccur.Validationcanbeextendedtoincludeongoingmeasurementsofusersatisfactionandcustomercomplaints.

iii) Identifyvalidationpriorities.

NOTE1 To make effective use of stakeholders’ time and expertise, validation typically focuses on stakeholderpriorities,whileverificationisusedfornon‐functionalrequirements.Potentialvalidationactionsthatarecandidatesfordeletionareevaluatedfortheriskstheirwithdrawalimposes

NOTE2 The supplier, the acquirer, or an agent of the acquirer participates in or performs validation. Theresponsibilityisoftendesignatedintheagreement.

2) Identify system constraints from the validation strategy to be incorporated in the stakeholderrequirements.

3) Definethepurpose,conditionsandconformancecriteriaforeachvalidationaction.

4) Selectappropriatevalidationmethodsortechniquesandassociatedcriteriaforeachvalidationaction.

NOTE1 Software system validation methods or techniques include inspection, analysis, analogy/similarity,demonstration, simulation, peer review, and testing. Software validation techniques typically include demonstrations,inspection, reviews and codewalkthroughs, usability tests, and trial use of the software (e.g., beta testing, operationaltesting,usertesting,oranacceptancetestwithagreedcriteria).Theselectionofvalidationmethodsortechniquesismadeaccording to the type of system, the purpose of the validation, the objectives of the project, legal and regulatoryrequirements, and the acceptable risks of a validation action. For software systems with human interaction, usabilitytesting iscommonlyused tovalidate thatrepresentativeuserscanachievespecifiedgoalswitheffectiveness,efficiencyand satisfaction in a specified contextof use. Furtherdetails forusability testing are found in ISO/IECTR25060:2010






Systems and software engineering — Systems and software product Quality Requirements and Evaluation (SQuaRE) —Common Industry Format (CIF) for usability: General framework for usability-related information.

NOTE2 Where appropriate, validation steps or states are defined (e.g., in‐house validation, on‐site validation,operational validation) that progressively build confidence in conformanceof the evolving software system, and assistdiagnosisofanyencountereddiscrepancies.

NOTE3 Criteriaforstakeholderacceptanceofserviceperformanceiscommonlystatedasaservicelevelandrecordedinaservicelevelagreement(SLA).Servicelevelstypicallymeasurecapacity,availability,reliability,andtimelyresponseforservices,andresultinperformancerequirementsforthesupportingsystems.

5) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportvalidation.

NOTE Enabling systems can include simulators, usability laboratory or test facility, qualified personnel, stakeholderand user representatives, according to selected validation methods or techniques. This includes identification ofrequirementsandinterfacesforenablingsystems.

6) Obtainoracquireaccesstotheenablingsystemsorservicestobeusedtosupportvalidation.

NOTE The infrastructure management process or acquisition process can be invoked to obtain access to enablingsystems,suchasthroughrental,procurement,development,reuse,orsubcontracting.Usuallyaccesstothecompletesetofenablersisamixoftheseways.TheValidationprocessisalsousedtoobjectivelyconfirmthatthevalidationenablingsystemachievesitsintendeduseforitsenablingfunctions.

b) Perform validation. Thisactivityconsistsofthefollowingtasks:

1) Definethevalidationprocedures,eachsupportingoneorasetofvalidationactions.

NOTE Validationproceduresidentifystakeholderrequirementstobevalidated,theassociatedsoftwaresystemartifact(e.g.,theactualsystem,oramodel,amock‐up,aprototype,code,asetofinstructionsorotherinformationitem),andtheexpectedresults(successcriteria),suchascompletedandtimelyperformanceofafunction.Theproceduresidentifythepurposeof thevalidationwithsuccesscriteria (expectedresults), thevalidation technique tobeapplied, thenecessaryenabling systems (facilities, equipment), and the environmental conditions to perform each validation procedure(resources, qualified personnel, participating stakeholders, and specialized procedural set‐up or work instructions).Validationstrategyincludeshowthevalidationprocedureresultswillberecorded,analyzed,stored,andreported.

2) Performthevalidationproceduresinthedefinedenvironment.

NOTE Validationoccurs,inaccordancewiththevalidationstrategy,attheappropriatetimeintheschedule,inadefinedenvironment (such as the operational environment, a similar test environment, or other representative environment),with defined enablers and resources. The performance of a validation action typically consists of capturing executionresults, comparing the obtained result with the success criteria, and deducing a degree of compliance or stakeholdersatisfactionwiththesoftwaresystem,element,service,orengineeringartifact.

c) Manage results of validation. Thisactivityconsistsofthefollowingtasks:

1) Reviewvalidationresultsandanomaliesencounteredandidentifyfollow‐upactions.

NOTE1 Confirmthattheservicesofthesystemthatarerequiredbystakeholdersareavailable.Anomaliescanresultfromthevalidationstrategy,thevalidationenablingsystems,executionofthevalidation, incorrectsystemdefinition,orinefficientorineffectivesystemdesign,implementation,andintegration.

NOTE2 Theevaluationofvalidationresultsandfollow‐upactionscanincludeacceptanceoftheanomalyasalowriskoccurrence.Correctiveactioncanvarygreatlydependingontheimpactofthevalidationresult.Forelementsofsoftware,examples include a simple defect fix for a failed software element, additional training for users, corrections andclarifications in documentation, or major project re‐direction based on a failure to attain a key milestone, e.g., failedsoftwaresystemacceptancetesting.

2) Recordincidentsandproblemsduringvalidationandtracktheirresolution.

NOTE The Project Assessment and Control process and Quality Assurance process are used to analyze the data toidentify the root cause of problems, enable corrective or improvement actions, and to record lessons learned. Duringsoftwarevalidation,thegapbetweenstakeholderexpectationsandsystemperformanceisdocumentedsothatifpossible,the root causeof thediscrepancy canbe identified.Problemresolution typically involvesdetermining the severityandimpactoftheproblemandwhetherorwhenasoftwarediscrepancyistobecorrectedoracceptedforatimeasaknownerror.Oftensimpleorrecommendedsolutionstoanomaliesdiscoveredduringvalidationarerecordedwiththevalidation











result to facilitate analysis and potential corrective action. Actual changes to the stakeholder and system/softwarerequirements,architecture,design,orsystemelementsaredonewithinotherTechnicalprocesses.

3) Obtainstakeholderagreementthatthesoftwaresystemorelementmeetsthestakeholderneeds.

4) Maintaintraceabilityofthevalidatedsystemelements.

NOTE Bidirectional traceability is maintained between the validated system elements and the stakeholderrequirementsandrecordofvalidationresults.


NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselines.Thisprocess identifies candidates for thebaseline (suchas thevalidated software systemor element), and the InformationManagementprocesscontrols the information items.Forthisprocess, thevalidationstrategyandvalidationresultsaretypicalinformationitemsthatarebaselined.

6.4.12 Operation process

6.4.12.1 Purpose

ThepurposeoftheOperationprocessistousethesystemtodeliveritsservices.

Thisprocessestablishesrequirementsforandassignspersonneltooperatethesystem,andmonitorstheservicesandoperator‐systemperformance.Inordertosustainservices,itidentifiesandanalyzesoperationalanomaliesinrelationtoagreements,stakeholderrequirementsandorganizationalconstraints.

TheOperationprocesstypicallyaimstocontrolorreducethecostofoperationswhilesustaininganacceptableorimprovedlevelofservice.

Softwaresystemscanhavededicatedinfrastructure,butaretypicallyoperatedindistributedenvironmentswhereother software systems and services (e.g., the internet) are active. The security, availability, and operationalperformanceofthesoftwaresystem‐of‐interestarethusamatterofconcernwithinalargersystemofsystems.Itcan include coordinationwith pre‐existing, concurrent or continuing services delivered by other systems thatprovideidenticalorsimilarservices.

NOTEISO/IEC20000‐1:2011(IEEEStd20000‐1)isaservicemanagementsystemstandardthatspecifiesrequirementsforthe design, transition, delivery and improvement ofmanaged operational services, and supports the Operation process toachieveitspurpose.

6.4.12.2 Outcomes

AsaresultofthesuccessfulimplementationoftheOperationprocess:

a) Operation constraints that influence system/software requirements, architecture, or design areidentified.

b) Anyenablingsystems,services,andmaterialneededforoperationareavailable.

c) Trained,qualifiedoperatorsareavailable.

d) Systemproductservicesthatmeetstakeholderrequirementsaredelivered.

e) Systemproductperformanceduringoperationismonitored.

f) Supporttothecustomerisprovided.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheOperationprocess.




a) Prepare for operation.Thisactivityconsistsofthefollowingtasks:

1) Defineanoperationstrategy,includingthefollowingconsiderations:

i) The expected or agreed capacity, availability, response time, and security of services as they areintroduced,routinelyoperatedandwithdrawnfromservice;

ii) The human resources strategy, depending on the need to define training and qualificationrequirements, train or obtain personnel to control and monitor software system operations,administersystemaccess,andsupportcustomerservicerequestsanduserassistance;

iii) The release criteria and schedules of the software system to permit modifications that sustainexistingorenhancedservices;

iv) The approach to implement the operational modes in the Operational Concept, including normaloperationsandpreparationsfor,andtestingof,envisionedtypesofcontingencyoperations;

v) Measuresforoperationthatwillprovideinsightintoperformancelevels;

vi) Theoperationalandoccupationalsafetystrategyforoperatorsandothersusingorincontactwiththesoftwaresystemduringoperation,accountingforsafetyregulations;and

vii) Theenvironmentalprotectionandsustainabilitystrategyforoperatingthesoftwaresystem.

NOTE ISO/IEC16350 Information technology – Systems and software engineering – Application management, providesguidanceforoperationalaspects.

2) Identify system constraints from operation to be incorporated in changes to the system/softwarerequirements,architecture,design,implementation,ortransition.

3) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportoperation.

NOTE Thisincludesidentificationofoperationalrequirementsandinterfacesfortheenablingsystems.Specialmodesoftheoperationalsoftwaresystem,e.g.,atrainingmode,cansometimesbeactivealongsideorinsteadofafulloperationalmode.Enablingsystemsincludemonitoringforchangesinthreatstothesoftwaresystem.


NOTE TheValidationprocess isusedtoobjectivelyconfirmthattheoperationenablingsystemachieves its intendeduseforitsenablingfunctions.

5) Identify or define training and qualification requirements for personnel needed for software systemoperation.

NOTE Thetrainingandqualificationincludesawarenessofthesoftwaresysteminitsoperationalenvironmentandadefinedprogramoffamiliarization,withappropriatefailuredetectionandisolationinstruction.Operatorknowledge,skillandexperiencerequirementsguidethepersonnelselectioncriteria,andwhererelevant,theirauthorizationtooperateisconfirmed. The scope of qualification depends on the system‐of‐interest and its environment. For example, in someenvironments regulatory requirements include certification of operators, whereas in others there is no certificationrequirement.

6) Depending on the need for human intervention and control of operations, assign trained, qualifiedpersonneltobeoperators.

NOTE Withdueregardforseparationofduties,suchasforadministrativecontrolofsystemaccessandinvestigationofsecurity issues,manymodernsoftwareproductsminimizetheneedforoperatorsasdistinct fromendusers,Operatorscommonly support enabling systems, such as cloud services, database and system software, security monitors, datastorage,andhelpdesk.

b) Perform operation.Thisactivityconsistsofthefollowingtasks:

1) Usethesoftwaresysteminitsintendedoperationalenvironment.





NOTE Where agreed, continuous service capacity and quality is maintained when the software system replaces anexistingsystemorelementthatisbeingretired.

2) Applymaterialsandotherresources,asrequired,tooperatethesoftwaresystemandsustainitsservices.

NOTE Thisincludesenergysourcesforhardware,connectivityforsoftware,andhumanorautomatedoperators.

3) Monitorsoftwaresystemoperation,includingconsiderationofthefollowing:

i) Managingadherencetotheoperationstrategy(e.g.,operationalprocedures);

ii) Recording and reporting significant events, such as possible breaches of software and dataconfidentialityandintegrity;

iii) Operatingthesoftwaresysteminasafemannerandcompliantwithlegislatedguidelinese.g.,thoseconcerningoccupationalsafetyandenvironmentalprotection;and

iv) Recordingwhensoftwaresystemorserviceperformanceisnotwithinacceptableparameters.

NOTE This includes anomalies due to the operation strategy, the operation enabling systems, execution of theoperation, or incorrect software system definition. The system sometimes exhibits unacceptable performance whensystem elements implemented in hardware have degraded or exceeded their useful life or the system’s operationalenvironment affects the software operation, e.g., workload above capacity thresholds, utilization by contendingapplications,securityhacks,orsoftwaredefects.

4) Consistentwiththeoperationalstrategy,developand,wherefeasible,automateoperationalprocedurestominimizetheriskofoperationalanomalies.

NOTE This includes procedures for handling routine (pre‐approved) change requests and service requests, trouble‐shootingandincidentreporting,especiallyforsecurityincidents.

5) Consistentwiththeoperationalstrategy,analyzemeasurementstoconfirmthat:

i) Service performance is within acceptable parameters or agreed service levels for the agreedworkload;

ii) Systemandserviceavailabilityandresponsetimesareacceptable;

iii) Costofoperationisconsistentwithobjectivesandconstraints;and

iv) Potentialimprovementsareidentifiedandprioritized.

NOTE Operator feedback and suggestions are often useful input for improving software system operationalperformance.TheQualityAssuranceandMeasurementprocessescanbeapplied.

6) Performcontingencyoperations,ifnecessary.

NOTE This includesoperating the software system inadegradedmode,performingback‐outand restoreoperation,systemshutdown,implementationofwork‐aroundprocedurestorestoreoperation,orothermodesforspecialconditions.If needed, the operator performs steps necessary to enter into contingency operations and possibly power down thesystem.Contingencyoperationsareperformed inaccordancewithpre‐establishedprocedures for suchanevent.Oftentheseproceduresareaccompaniedbyacontinuityplan.

c) Manage results of operation. Thisactivityconsistsofthefollowingtasks:

1) Recordresultsofoperationandanomaliesencountered.

NOTE The Project Assessment and Control and Quality Assurance processes are used to analyze the incident andproblemdatatoidentifytherootcause,enablecorrectiveorimprovementactions,andtorecordlessonslearned.

2) Recordoperationalincidentsandproblemsandtracktheirresolution.




NOTE1 PerformingincidentandproblemresolutionishandledthroughtheQualityAssuranceandProjectAssessmentandControlprocesses. Changes to the requirements, architecture, design, or software systemelements aredoneusingotherTechnicalprocesses.

NOTE2 Ifanincidentisexperiencedduringoperation,theoperatorrecordstheincident(orisalertedtoanautomatednotification) and performs actions prescribed in validated operating procedures to restore normal operations. Someproceduresallowforprovisionofatemporaryworkaroundsolutionuntilrootcauseanalysiscanbeperformed.

NOTE3 During software operation, the conditions under which the problem occurred are typically documented,consistentwithmaintainingorrestoringoperationalavailability, so that ifpossible, theproblemcanbeduplicated inatestenvironmentandtherootcauseidentified.Problemresolutionusuallyinvolvesdeterminingtheseverityandimpactoftheproblemandwhetherorwhentheproblemistobecorrectedoracceptedforatimeasaknownerror.

3) Maintaintraceabilityoftheoperationalservicesandconfigurationitems.

NOTE Bidirectional traceability ismaintained between the operational services and the business ormission needs,operational concept, concept of operations, and stakeholder requirements. The operational configuration items aretraceabletothereleasedversionsandvalidatedthroughPCAorFCA.


NOTE This process identifies candidates for the baseline, and the Information Management process controls theinformationitems,suchasreportsonoperationalserviceperformance.Keyartifacts(informationitems)forOperationsarelistedinAnnexB.

d) Support the customer. Thisactivityconsistsofthefollowingtasks:

1) Provide assistance and consultation to the customers and users to resolve complaints, incidents,problems,andservicerequests.

NOTE1 Assistance and consultation includes providing or recommending sources for training, documentation,vulnerabilityresolution,anti‐counterfeitactivities,andotherservicessupportingeffectiveuseofthesoftwaresystem.

NOTE2 Customer support can include communicationwith customers of services, users, and other stakeholders toreceiveservicerequestsandchangerequests,resolvecomplaints,andprovideinformationontheresolutionofincidentsandproblems.

2) Recordandmonitorrequestsandsubsequentactionsforsupport.

3) Determine the degree to which the delivered software system or services satisfy the needs of thecustomersandusers.

NOTE Theresultsareanalyzedandtherequiredactionstorestoreoramendsoftwaresystemorservicestoprovidecontinuedcustomersatisfactionandsoftwaresystemusabilityareidentified.Whereverpossiblethebenefitofsuchactionisagreedwithstakeholdersortheirrepresentatives.ThecustomersatisfactiondataalsoservesasaninputtotheQualityManagementprocess.

6.4.13 Maintenance process

6.4.13.1 Purpose

ThepurposeoftheMaintenanceprocessistosustainthecapabilityofthesystemtoprovideaservice.

Thisprocessmonitorsthesystem’scapabilitytodeliverservices,recordsincidentsforanalysis,takescorrective,adaptive,perfectiveandpreventiveactionsandconfirmsrestoredcapability.

For software systems, the Maintenance process makes corrections, changes, and improvements to deployedsoftwaresystemsandelements.Thesoftwaresystemsmaintenanceapproachdiffers forsystemsthatarefreelyavailable,inwidecommercialdistribution,oroperatinginasmallnumberofcontrolledenvironments.

Theneedforsoftwaresystemmaintenancecanarisefrommultiplecausesotherthanlatentsystemdefects,suchaschangestointerfacedsystemsorinfrastructure,evolvingsecuritythreats,andtechnicalobsolescenceofsystemelementsandenablingsystemsoverthesystemlifecycle.Oftentheextensionofcapability,mid‐lifeupgrade,orevolution of legacy systems becomes a new software system development project that will apply the set of





processeswithinanappropriatelifecycle.Ifso,thePortfolioManagementprocessisthestartingpointtoinitiatethework. Inother cases, software systemmaintenance isperformedasa continuing seriesofprioritizedworkitems,possiblyonalevelofeffortbasis.Maintenanceofsoftwaresystemelementscanincludehardware,software,and services, suchas communicationorweb services.Maintenance is closely connectedwith theConfigurationManagementprocess and software assetmanagement and is performed concurrentlywith the otherTechnicalprocesses.

NOTEISO/IEC/IEEE14764:2006Software Engineering — Software Life Cycle Processes — MaintenanceandISO/IEC16350,Information technology — Systems and software engineering — Application management, provide additional detail. TheSWEBOK, Guide to the Software Engineering Body of Knowledge, Software Maintenance knowledge area discusses softwaremaintenancefundamentals,keyissues,measurement,techniques,maintenanceprocessandsupportactivities,andtools.Theguidealsodiscussesmodels,techniquesandmeasuresthatsupportsoftwarereliability.

6.4.13.2 Outcomes

AsaresultofthesuccessfulimplementationoftheMaintenanceprocess:

a) Maintenanceconstraintsthatinfluencesystemrequirements,architecture,ordesignareidentified.

b) Anyenablingsystemsorservicesneededformaintenanceareavailable.

c) Replacement,repaired,orrevisedsystemelementsaremadeavailable.

d) Theneedforchangestoaddresscorrective,perfective,oradaptivemaintenanceisreported.

e) Failureandlifetimedata,includingassociatedcosts,isdetermined.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheMaintenanceprocess.

a) Prepare for maintenance.Thisactivityconsistsofthefollowingtasks:

1) Defineamaintenancestrategy,includingconsiderationofthefollowing:

i) Establishingpriorities,typicalschedules,andproceduresforperforming,verifying,distributing,and installing software maintenance changes in conformance with operational availabilityrequirements;

ii) Establishing techniques andmethods for becoming aware of the need for corrective, adaptive,andperfectivemaintenance;

iii) Periodicassessmentofthedesigncharacteristicsincaseofevolutionofthesoftwaresystemandofitsarchitecture;

iv) Forecasting potential obsolescence of components and technologies using information ontechnicalchangesinrelatedsystems;

v) Establishingprioritiesandresourcestoobtainaccesstothecorrectversionsoftheproductandproductinformationneededforperformingmaintenance(e.g.,scheduledorphasedinstallation,maintenancepatchesorsoftwareupgrades);

vi) Measures formaintenance thatwill provide insight intoperformance levels, effectiveness, andefficiency,includingaccesstohistoricalfaultandfailure;

vii) Agreed rights to data and the impact on data in the system during problem resolution andmaintenanceactivity;

viii) Approachtoassurethatcounterfeitorunauthorizedsystemelementsarenotintroducedintothesystem;




ix) Impactofthemaintenancechangeonothersoftwaresystemselementsversustheriskofleavingareportedsoftwareanomalyinplace;and

x) Theskillandpersonnellevelsrequiredtoeffectsystemorsoftwarerepairsorreplacements,fixes,patches,updates,andupgrades,consideringlegalandregulatoryrequirementsregardinghealthandsafety,security,andtheenvironment.

2) Fornon‐softwareelements,definealogisticsstrategythroughoutthelifecycle,includingacquisitionandoperational considerations: the number and type of replacement elements to be stored, their storagelocationsandconditions,theiranticipatedreplacementrate,andtheirstoragelifeandrenewalfrequency.

NOTE Supportability implications are considered early during concept exploration or development stages. Logisticshelpstoensurethatthenecessarymaterialandresources,intherightquantityandquality,areavailableattherightplaceandtimethroughoutdeploymentandsustainmentstages.

3) Identify constraints from maintenance to be incorporated in the system/software requirements,architecture,ordesign.

NOTE Theseoftenresultfromtheneedto1)re‐useexistingmaintenanceandverificationenablingsystems;2)re‐useexisting holdings of replaceable system element and accommodate re‐supply limitations; 3) conduct maintenance inspecific locations or environments. For example, software architectures and designs that emphasize encapsulation,modularity,andscalabilitycanbesimplertomaintain.Requirementstodocumentthesystemdesignandconstructioncanreducetheeffortneededtoreverseengineersystemsandelementswhenmaintenanceisneeded.Thesystemarchitectureand design reflect the need to roll back, back up, and recover data during problem resolution. Functions tomake thesystemavailableforremotediagnosticsandmaintenancecanbeincorporatedinthearchitectureanddesign.

4) Identifytradessuchthatthesystemandassociatedmaintenanceandlogisticsactionsresultinasolutionthatisaffordable,operable,supportable,andsustainable.

NOTE The System Analysis and Decision Management processes are used to perform the assessments and tradedecisions.

5) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportmaintenance.

NOTE This includes identificationofrequirementsand interfaces for theenablingsystems.Theselectionofenablingsystemsformaintenanceoftenreflectstheneedtore‐useexistingorequivalentdesign,development,andconfigurationmanagementinfrastructureasduringtheinitialsystemimplementation.


NOTE TheValidationprocessisusedtoobjectivelyconfirmthatthemaintenanceenablingsystemachievesitsintendeduseforitsenablingfunctions.

b) Perform maintenance. Thisactivityconsistsofthefollowingtasks:

1) Reviewstakeholderrequirements,complaints,events,incidentandproblemreportstoidentifycorrective,adaptive,perfectiveandpreventivemaintenanceneeds.

NOTE For software systems with iterative life cycles, changing requirements can be considered as the source foradaptiveandperfectivemaintenanceactivities.Forsoftwaremaintenance, thisprocessmakescorrections,changes,andimprovementstodeployedsoftware,aswellaspatchingandupdatestomaintainsystemsecurity.

2) Analyzetheimpactofmaintenancechangesondatastructures,data,andrelatedsoftwarefunctions,userdocumentation,andinterfaces.

NOTE Reviewsandanalyzesoftenincludefactorssuchasthecategoryofmaintenanceaction;sizeofmodification;costinvolved;timetomodify;andimpactsonperformance,safetyorsecurity.

3) Upon encountering unexpected faults that cause a software system failure, restore the system tooperationalstatus.

NOTE Restorationtofullordegradedoperationalstatuscanoftenbeaccomplishedthrougharollback,workaroundorbyidentifyingandcorrectingthecauseofthefault.Iffullrestorationisdelayedornotpossible,thesystemisrestoredtoadegradedmode,consistentwiththecontingencyplanning.Ifpossible,thefaultisreplicatedusingadistinctenvironment





similar to the operational environment and the root causes of the fault are identified. The ConfigurationManagementprocess,especiallyreleasemanagementactivities,isinvokedtocontrolscheduledandemergencychangestothesystem.

4) Implementtheproceduresforcorrectionofflaws(defects)anderrors,orforreplacementorupgradeofsystemelements.

NOTE1CorrectionofflawsanderrorsusesproblemresolutionandcanbehandledthroughtheQualityAssuranceandProjectAssessmentandControlprocesses.

NOTE 2Typically, regression testing is performed to verify that themaintenance change has not introduced otherissues,i.e.,completeandcorrectimplementationofthenewandmodifiedrequirementswithouteffectontheperformanceof theoriginal,unmodified requirements.TheTransitionprocess canbeapplied fordeploymentofmajormaintenancechanges;minorfixesaretypicallyhandledaspartoftheMaintenanceprocess.Actionsarerecordedinordertofacilitatefuturemaintenanceandproblemresolution,andforlogisticsanalyzesofdegradablesystemelements.

NOTE3Systemanddatarecoveryproceduresandmaintenanceinformationareoftenmadeavailableonmediathatisusableatthepointofperformingmaintenance.

5) Perform preventive maintenance by replacing, patching, augmenting, or upgrading software systemelements, to improve the performance of a software system that is projected to reach unacceptableservice levels,e.g., lackofcapacitydueto increases indemandorstoreddata,ortoavoidunacceptableoperatingconditions,e.g.,runningwithoutdatedsecuritysoftware.

6) Identifywhenadaptiveorperfectivemaintenanceisrequired.

NOTE Adaptive and perfective maintenance actions usually involve change to the system/software requirements,architectureanddesign.Anewprojectcanbestartedtomodifytheexistingsoftwaresystem.

c) Perform logistics support. Thisactivityconsistsofthefollowingtasks:

NOTE Thelogisticsactionsenablethesoftwaresystemtosustainoperationalreadiness.Theactionsincludeprovisionsfor staffing, supply support, support equipment, technical data needs (user documentation) and agreed data rights,trainingsupport,communications,equipment/computingresourcesupport,andfacilities.

1) Obtain resources to support the software system through its life cycle or theproject’s life (acquisitionlogistics).

NOTE AcquisitionLogisticsconsiderationsareincludedintheagreementresultingfromtheAgreementprocesses.Thisincludesperforminganalysis to identifycost‐effectivechanges to the initialdesignof thesystemforsupportabilityandeaseofmaintenance,aswellasarrangementsfordistributingsoftwarefixesandupgradesduringutilization/deployment.Thesedecisionsareoftenconstrainedbyavailabilityrequirementsandimpactthesupplychainmanagement.

2) Monitor the quality and availability of replacement elements and enabling systems, their deliverymechanismsandtheircontinuedintegrityduringstorage.

NOTE Operational logistics involves the concurrent adjustment of both the system‐of‐interest and enabling systemsthroughout the operational life to help ensure effective and efficient delivery of software functions. It also includesavailabilityofskilledresources.Forexample,reliableenablingsystemsareavailablewiththecapacity toreadsoftwarestoredonpreviousmediaformats,ortomigratebackupfilestocurrentmediaandcurrentlymaintainedenablingsystems.

3) Implement mechanisms for software system or element distribution, including packaging, handling,storageandcommunicationsortransportationneededforitemsduringthelifecycle.

NOTE1Softwaredistributionandinstallationistypicallyautomated.Softwarepackagescommonlyincludesoftwarelicense terms, includingdata rights,andelements for softwareassetmanagement.Logisticsplanning forothersystemselementsisoftenrequiredtosupporttheobjectivesoftheIntegrationandTransitionprocesses.

NOTE2Considertheneedtostorespareelementsorbackupcopiesofsoftwareonsiteor inadditional locations, tomaintainsoftwaresystemcapabilities,asrequired(perhapsatareducedlevelforcontingencyoperations).

4) Confirmthatlogisticsactionstofulfillsoftwaresystemorelementsupportabilityrequirementsorachieveoperationalreadinessareplannedandimplemented.




NOTE These logistic actions can include staffing, supply support, support equipment, technical data needs (userdocumentation, instructions, lists), training support, communications, equipment/computing resource support, andfacilities.

d) Manage results of maintenance and logistics. Thisactivityconsistsofthefollowingtasks:

1) Record incidents and problems, including their resolutions, and significant maintenance and logisticsresults.

NOTE This includesanomaliesdue to themaintenance strategy, themaintenanceenabling systems, executionof themaintenance and logistics, or incorrect system definition. The Project Assessment and Control and Quality Assuranceprocessesareused toperformmaintenanceproblem identificationand resolution, e.g., analyze thedata to identify theroot cause, enable correctiveor improvement actions, and record lessons learned.This activity can include changes tologisticsorsoftwaredistributionprocedures.Changes to thesoftwaresystemrequirements,architecture,ordesignaredonewithinotherTechnicalprocesses.

2) Identifyandrecordtrendsofincidents,problems,andmaintenanceandlogisticsactions.

NOTE1 Trend data and problem resolution reports are used to inform operations and maintenance personnel,customers,andotherstakeholdersandprojectsthatarecreatingorutilizingsimilarsystementities.

NOTE2 Incidentandproblemreporting, includingresultingactiontaken, istrackedthroughtheincidentandprocessmanagementactivityoftheQualityAssuranceprocess.

3) Maintaintraceabilityofthesystemelementsbeingmaintained.

NOTE Bidirectional traceability is maintained between the recorded maintenance actions and the software systemelements and life cycle artifacts. Changes in software asset management, such as assignment of software licenses toreplacementsystems,arerecorded.


NOTE TheConfigurationManagementprocessisusedtoestablishandmaintainconfigurationitemsandbaselinesandto track licenses and data rights. This process identifies candidates for the baseline, and the InformationManagementprocesscontrolstheinformationitems,suchasmaintenanceprocedures.

5) Monitorandmeasurecustomersatisfactionwithsystemandmaintenancesupport.

NOTE ISO 10004:2012 contains guidelines for monitoring and measuring customer satisfaction. When customersatisfactiondataiscollected,itisthenusedintheQualityManagementprocess.

6.4.14 Disposal process

6.4.14.1 Purpose

ThepurposeoftheDisposalprocessistoendtheexistenceofasystemelementorsystemforaspecifiedintendeduse,appropriatelyhandlereplacedorretiredelements,andtoproperlyattendtoidentifiedcriticaldisposalneeds(e.g.,peranagreement,perorganizationalpolicy,orforenvironmental,legal,safety,securityaspects).

This processdeactivates, disassembles and removes the systemor anyof its elements from the specific use. Itaddressesanywasteproducts,consigningthemtoafinalconditionandreturningtheenvironmenttoitsoriginaloranacceptablecondition.Thewasteproductscanbein‐processresultingduringanylifecyclestage,e.g.,wastematerialsduringfabrication.Thisprocessdestroys,stores,orreclaimssystemelementsandwasteproductsinanenvironmentally sound manner, in accordance with legislation, agreements, organizational constraints andstakeholder requirements. Disposal includes preventing expired, non‐reusable, or inadequate elements fromgettingbackintothesupplychain.Whererequired,itmaintainsrecordsinorderthatthehealthofoperatorsandusers,andthesafetyoftheenvironment,canbemonitored.Whenpartofthesystemwillcontinuetobeinuseinamodifiedform,theDisposalprocesshelpsensuretheproperhandlingoftheportionbeingretired.

Disposalofsoftwaresystemsencompassestheterminationofservicesanddisposalofsoftwareelements,storeddata, media and firmware, information items, and associated hardware elements that will not be reused ortransitioned to another system. The Disposal process is intended to be applicable in any stage of a softwaresystemslifecycle.Forsoftware,theDisposalprocessappliesthroughoutthelifecycletosourcecodeorexecutable





copies of the software, personally identifiable or controlled data used in the software system, and associatedinformation items, retained under centralized configuration control or distributed for use, e.g., disposing ofprototypes in early life cycle stages, and decommissioning elements replaced from modifications duringutilization/deployment and support stages. When the system‐of‐interest is being modified for technology orcapabilityupgrades,onlytheimpactedelementsaredeactivatedandremoved.

NOTE TheBusinessorMissionAnalysisprocessandDecisionManagementprocessaretypicallyappliedtoaddresstheimpactonstakeholdersofsystemdisposalandpotentialnewsystemcapabilities.

6.4.14.2 Outcomes

AsaresultofthesuccessfulimplementationoftheDisposalprocess:

a) Disposalconstraintsareprovidedasinputstorequirements,architecture,design,andimplementation.

b) Anyenablingsystemsorservicesneededfordisposalareavailable.

c) Thesystemelementsorwasteproductsaredestroyed,stored,reclaimedorrecycledinaccordancewithrequirements,e.g.,safetyandsecurityrequirements.

d) Theenvironmentisreturnedtoitsoriginaloranagreedstate.

e) Recordsofdisposalactionsandanalysisareavailable.


TheprojectshallimplementthefollowingactivitiesandtasksinaccordancewithapplicableorganizationpoliciesandprocedureswithrespecttotheDisposalprocess.

a) Prepare for disposal.Thisactivityconsistsofthefollowingtasks:

1) Defineadisposal strategy for the software system, to includeeach systemelementand to identify andaddresscriticaldisposalneeds,includingthefollowingconsiderations:

i) Permanentterminationofthesystem’sfunctionsanddeliveryofservices,e.g.,physicaldestructionofdatastoragedevices,ortransitionofthesoftwaresystemelementsforfuturereuseinmodifiedoradaptedform;

ii) Identificationofownershipand responsibility for retentionordestructionofdataand intellectualpropertyinthesoftwaresystem;

iii) Transformationoftheproductinto,orretentioninasociallyandphysicallyacceptablestate,therebyavoidingsubsequentadverseeffectsonstakeholders,societyandtheenvironment;

iv) Thehealth,safety,securityandprivacyconcernsapplicabletodisposalactionsandtothelong‐termconditionofresultingphysicalmaterialandinformation;

v) Notificationtorelevantstakeholdersofsignificantdisposalactivities,e.g.,retirementorreplacementofasystem,softwareproductsorservices,retirementschedule,orreplacementoptions;and

vi) Identificationofschedules,actions,responsibilities,andresourcesfordisposalactivities.

2) Identify constraints on disposal for the system/software requirements, architecture and designcharacteristics,orimplementationtechniques.

NOTE Thisincludesaccesstoandavailabilityofarchivesorlong‐termstoragelocationsandavailableskilledresourcesforsystemdeactivationandcommunicationwithstakeholdersandinterfacepartners.

3) Identifyandplanforthenecessaryenablingsystemsorservicesneededtosupportdisposal.

NOTE Thisincludesidentificationofrequirementsandinterfacesfortheenablingsystems.





NOTE TheValidationprocessisusedtoobjectivelyconfirmthatthedisposalenablingsystemachievesitsintendeduseforitsenablingfunctions.

5) Specify containment facilities, storage locations, inspection criteriaand storageperiods, if the softwaresystemordataistobestored,consistentwithsecurityandenvironmentalconsiderations.

6) Definepreventivemethodstoprecludedisposedelementsandmaterialsthatshouldnotberepurposed,reclaimedorreusedfromre‐enteringthesupplychain.

b) Perform disposal. Thisactivityconsistsofthefollowingtasks:

1) Deactivatethesoftwaresystemorelementtoprepareitforremoval.

NOTE Interfacestoothersystemsareconsidered,inaccordancewithspecialproceduresorinstructions,andrelevanthealth,safety,securityandprivacyconstraints.

2) Removethesoftwaresystem,itselements,itsdata,andnon‐reusablematerialfromuseorproductionforappropriatedispositionandaction.

NOTE The disposition includes reuse, recycling, reconditioning, overhaul, or destruction. The disposition andsubsequent actions are conducted in accordance with relevant safety, security, privacy and environmental standards,directivesandlaws.Elementsofthesoftwaresystemthathaveusefulliferemaining,eitherintheircurrentconditionorfollowing modification, are transferred to other systems‐of‐interest or organizations. Where appropriate, considerrefurbishingsystemelementstoextendtheirusefullife.

3) Withdraw impacted operating staff from the software system or system element and record relevantoperatingknowledge.

NOTE Reallocate,redeployorretireoperators.Thisisconductedinaccordancewithrelevantsafety,security,privacyandenvironmentalstandards,directivesandlaws.Acttosafeguardandsecureoperator’sknowledgeandskills,usingtheKnowledgeManagementprocess.

4) Reuse,recycle,recondition,overhaul,archive,ordestroydesignatedsoftwaresystemelements.

NOTE Handlesystemelementsandtheirpartsthatarenotintendedforreuseinamannerthatwillassuretheydonotgetbackintothesupplychain.

5) Conductdestructionofthesystemelements,asnecessary,toreducetheamountofwastetreatmentortomakethewasteeasiertohandle.

NOTE Whentheelement isnon‐maintainableornon‐recyclable, it isnecessary toprevent theelements fromgettingbackintothesupplychain,e.g.,completeerasureofallsoftwarefromallsystemstoragemediaandremovaloflicensekeys,data, and interfaces. This activity includes obtaining the destruction services to melt, crush, incinerate, demolish oreradicatethesystemoritselementsasnecessary.

c) Finalize the disposal. Thisactivityconsistsofthefollowingtasks:

1) Confirmthatdetrimentalhealth, safety,security,andenvironmentalconditions followingdisposalhavebeenidentifiedandtreated.

2) Returntheenvironmenttoitsoriginalstateortoastatethatisspecifiedbyagreement.

3) Archive information gathered through the lifetime of the product to permit audits and reviews in theeventoflong‐termhazardstohealth,safety,securityandtheenvironment,andtopermitfuturesoftwaresystemcreatorsanduserstobuildaknowledgebasefromexperience.





Annex A(normative)

Tailoring process

A.1 Introduction

ThisAnnexprovidesrequirementsforthetailoringofthisdocument.

NOTE1 Tailoringisnotarequirementforconformancetothisdocument.Infact,tailoringisnotpermittedifaclaimof“fullconformance”istobemade.Ifaclaimof“tailoredconformance”ismade,thenthisprocessisappliedtoperformthetailoring.

NOTE2 Additionalguidance for tailoringcanbe found in ISO/IEC/IEEE24748(allparts)ontheapplicationof lifecycleprocesses.

A.2 Tailoring process

A.2.1 Purpose

ThepurposeoftheTailoringprocessistoadapttheprocessesofthisdocumenttosatisfyparticularcircumstancesorfactorsthat:

a) surroundanorganizationthatisemployingthisdocumentinanagreement;

b) influenceaprojectthatisrequiredtomeetanagreementinwhichthisdocumentisreferenced;

c) reflecttheneedsofanorganizationinordertosupplyproductsorservices.

A.2.2 Outcomes

AsaresultofthesuccessfulimplementationoftheTailoringprocess:

a) Modifiedornew life cycleprocessesaredefined toachieve thepurposes andoutcomesof a life cyclemodel.

A.2.3 Activities and tasks

If thisdocument is tailored, then theorganizationorprojectshall implement the following tasks inaccordancewithapplicablepoliciesandprocedureswithrespecttotheTailoringprocess,asrequired.

a) Identifyandrecordthecircumstancesthatinfluencetailoring.Theseinfluencesinclude,butarenotlimitedto:

1) stabilityof,andvarietyin,operationalenvironments;

2) risks,commercialorperformance,totheconcernofinterestedparties;

3) novelty,sizeandcomplexity;

4) startingdateanddurationofutilization;

5) integrityissuessuchassafety,security,privacy,usability,availability;

6) emergingtechnologyopportunities;




7) profileofbudgetandorganizationalresourcesavailable;

8) availabilityoftheservicesofenablingsystems;

9) roles,responsibilities,accountabilitiesandauthoritiesintheoveralllifecycleofthesystem;and

10) theneedtoconformtootherstandards.

b) Inthecaseofpropertiescriticaltothesystem,takedueaccountofthelifecyclestructuresrecommendedormandatedbystandardsrelevanttothedimensionofthecriticality.

c) Obtaininputfrompartiesaffectedbythetailoringdecisions.Thisincludes,butmaynotbelimitedto:

1) thesystemstakeholders;

2) theinterestedpartiestoanagreementmadebytheorganization;and

3) thecontributingorganizationalfunctions.

d) Maketailoringdecisions inaccordancewiththeDecisionManagementprocesstoachievethepurposesandoutcomesoftheselectedlifecyclemodel.

NOTE1 OrganizationsestablishstandardlifecyclemodelsasapartoftheLifeCycleModelManagementprocess.Itissometimes appropriate for an organization to tailor processes of this document in order to achieve the purposes andoutcomesofthestagesofalifecyclemodeltobeestablished.

NOTE2 Projectsselectanorganizationally‐establishedlifecyclemodelfortheprojectasapartoftheProjectPlanningprocess.Itissometimesappropriatetotailororganizationallyadoptedprocessestoachievethepurposesandoutcomesofthestagesoftheselectedlifecyclemodel.

NOTE3 Incaseswhereprojectsaredirectlyapplyingthisdocument,itissometimesappropriatetotailorprocessesofthisdocumentinordertoachievethepurposesandoutcomesofthestagesofasuitablelifecyclemodel.

e) Selectthelifecycleprocessesthatrequiretailoringanddeleteselectedoutcomes,activities,ortasks.

NOTE1 Irrespectiveoftailoring,organizationsandprojectsarealwayspermittedtoimplementprocessesthatachieveadditional outcomes or implement additional activities and tasks beyond those required for conformance to thisdocument.

NOTE2 Anorganizationorprojectsometimesencounterasituationwherethereisthedesiretomodifyaprovisionofthis document. Modification is to be avoided because of unanticipated consequences on other processes, outcomes,activities or tasks. If necessary,modification is performed by deleting the provision (making the appropriate claim oftailoredconformance)and,withcarefulconsiderationofconsequences,implementingaprocessthatachievesadditionaloutcomesorperformsadditionalactivitiesandtasksbeyondthoseofthetailoredstandard.





Annex B(informative)

Examples of process information items

TableB.1providesapossiblesetofworkproducts,includingartifacts,records,informationitems,anddatastoresassociatedwitheachprocess.Thislistisnotall‐inclusive:foreachprocess,anorganizationmaydecidetodevelopapolicy,plan,procedures,reports,andrecords,todemonstratetheoutcomesorperformtheactivitiesandtasks.Where less intensive documentation is considered sufficient, information items can be combined. Also theorganizationalpoliciesandprocedurescanbeappliedortailoredforeachprocessandproject.Typicalitemtitlesareshown,includingcommonexamplesofalternatetitlesinparentheses.

NOTE SeeISO/IEC/IEEE15289forguidanceoncontentandmanagementofInformationItems.

Artifacts,records,recordstores,andinformationitemsareusuallyinitiatedinoneprocessandrevised,enhanced,orcompletedinotherprocesses.Forconvenience,theyarelistedonceinthistable,inaprocesswheretheyarecommonly initiated. When the software system artifacts and information are transformed or elaborated byanotherprocess,traceabilityismaintainedandatraceabilitymappingcanbeproduced.Forexample,traceabilitycan bemaintained between organizational andproject processes, and between requirements, architecture anddesignelements,andverificationcases.

Table B.1 — Sample information items by process

Process Group

Process Typical Item Title Item Type

Agreement processes Acquisition process AcquisitionPlan info RequestforSupply(e.g.,RequestforProposal,RequestforTender) info AgreementChangeRequest info Agreement(e.g.,Contract) info AgreementChangeManagementProcedure info DeliveryAcceptanceReport info Supply process SupplyResponse(e.g.,Proposal,Tender) info AgreementChangeRequest info AgreementChangeManagementProcedure info SupplyDeliveryRecords(forsystem,software,productorservice) record

Organizational Project-Enabling processes

Life Cycle Model Management process OrganizationalPolicies info LifeCycleprocesses artifact LifeCycleProcessDescription info LifeCycleModel artifact OrganizationalProcedures(ProcessManagementProcedures) info ProcessAssessmentReport info ProcessImprovementPlan info ProcessImprovementReport info Infrastructure Management process InfrastructureRequirements artifact InfrastructureElement artifact InfrastructureDescription info InfrastructureChangeRequest info Portfolio Management process ProjectPortfolio store ProjectBudget artifact ProjectAuthorization info Human Resource Management process SkillNeedsReport info SkillDevelopmentAssets(TrainingMaterials) artifact SkillDevelopmentRecords(SkillInventory,TrainingRecord) record




Process Group


QualifiedPersonnel artifact StaffAssignmentRecords record Quality Management process QualityManagementPlan(Policies,Objectives) info QualityManagementProcedures info QualityAssuranceAssessmentResults record CorrectiveandPreventiveActionReport(ProblemManagementReport) info Knowledge Management process KnowledgeManagementPlan info KnowledgeManagementProcedures info KnowledgeAssetRecords record KnowledgeAssets artifactTechnical Management processes Project Planning process

ProjectPlan(e.g.,ProjectTechnicalManagementPlan,SystemsorSoftware

EngineeringManagementPlan,SoftwareDevelopmentPlan,TransitionPlan)info

WorkBreakdownStructure artifact ResourceRequest info ProjectSchedule artifact ProjectInfrastructureandServicesRequirements artifact Project Assessment and Control process MeasurementAnalysisResultsandRecommendations info ProjectAssessmentReport info ReviewMinutes info AuthorizationtoProceedtoNextMilestone info Decision Management process DecisionRequest info DecisionRecords record Risk Management process RiskManagementPlan info RiskProfile record RiskActionRequest info Configuration Management process ConfigurationManagementPlan info ConfigurationManagementProcedures info ConfigurationManagementRecords record ConfigurationBaseline artifact CMChange/VarianceRequest info ConfigurationStatusReport info ConfigurationEvaluationReport info System/SoftwareReleaseReport info Information Management process InformationItemArchive store InformationManagementProcedures info InformationManagementReport info Measurement process MeasurementRecords record MeasurementProcedures info MeasurementInformationNeedsReport info MeasurementReport info Quality Assurance process QualityAssuranceProcedures info QualityAssuranceEvaluationReport info QualityAssuranceRecords record IncidentRecords record ProblemRecords recordTechnical processes Business or Mission Analysis process PreliminaryLifeCycleConcept artifact SolutionAlternativeClassesAssessmentReport info Stakeholder Needs and Requirements Definition process OperationalConcept artifact StakeholderNeedsAssessment info StakeholderRequirements artifact StakeholderRequirementsSpecification info StakeholderRequirementsReport info CriticalPerformanceMeasures artifact





Process Group


System/Software Requirements Definition process SystemorElementDescription info System/SoftwareRequirements artifact System/softwarerequirementsSpecification info RequirementsChangeRequest info Architecture Definition process ArchitectureViewpoints artifact ArchitectureViewsandModels(ArchitectureDescription) artifact InterfaceDefinition(initial) artifact Design Definition process DesignArtifact artifact DesignArtifactsReport(Designdescription) info InterfaceSpecification info System Analysis process SystemAnalysisReport info Implementation process SoftwareSystemElement artifact ImplementationProcedures info ImplementationRecords(unittestresults) record Integration process InterfaceControlDescription info IntegrationandTestProcedures info IntegratedSoftwareSystem Elements(softwarelibrary) artifact IntegrationRecords record Verification process VerifiedSystem artifact VerificationProcedures info VerificationRecords record VerificationReport info Transition process PreparedSiteforOperations artifact TransitionedSystem/Software artifact TransitionRecords record Validation process ValidatedSystem artifact ValidationProcedures info ValidationRecords record ValidationReport info Operation process Continuityplan info Operationalprocedures(Userdocumentation) info OperationRecords record ProblemReport info CustomerSupportRequest info CustomerSupportRecords record OperationReport info Maintenance process ReplacementSystemElement artifact MaintenanceProcedures(LogisticsProcedures) info Maintenance(Logistics)Records record MaintenanceRequests record Maintenance(Logistics)Report info Disposal process DisposalRecords record ArchiveReport info




Annex C(informative)

Process Reference Model for assessment purposes

C.1 Introduction

Someusers of this documentmaydesire to assess the implementedprocesses in accordancewith the ISO/IEC33000seriesstandards forprocessassessment.ThisannexprovidesaProcessReferenceModel(PRM)suitableforuseinconjunctionwiththosestandards.

ThePRMiscomposedoftheprocessesinthebodyofthisdocument, includingthename,statementofpurpose,andstatementofoutcomesforeachprocess.SubclauseC.3identifiestheprocessesintheprocessreferencemodelandtheclausesinwhichtheyaredefined.

C.2 Conformance with ISO/IEC 33004

C.2.1 General

ISO/IEC33004subclause5.3places requirementsonprocess referencemodelssuitable forassessmentby thatstandard. The following sections quote the ISO/IEC 33004 requirements for process reference models anddescribehow thesearemetby thisdocument. Ineachof the followingsubclauses the italicized textquotes therequirementfromthetextofISO/IEC33004andthenon‐italicized(upright)textdescribesthemannerinwhichtherequirementissatisfiedinthisdocument.

C.2.2 Requirements for process reference models

A Process Reference Model shall contain: [ISO/IEC 33020, 5.3.1]

a) Adeclarationofthedomainoftheprocessreferencemodel.ThisisprovidedinClause1.

b) Adescriptionof the relationshipbetween theprocess referencemodeland its intendedcontextofuse.ThisisprovidedbyClause5.

c) Descriptions,meetingtherequirementsof[33004]5.4[below],oftheprocesseswithinthescopeoftheprocessreferencemodel;ThisisprovidedinClause6inthedescriptionofeachprocess.

d) Adescriptionoftherelationshipbetweentheprocessesdefinedwithintheprocessreferencemodel.Thisisprovidedin5.6

The process reference model shall document the community of interest of the model and the actions taken to achieve consensus within that community of interest: [ISO/IEC 33020, 5.3.2]

a) the relevant community of interest shall be characterized or specified; TherelevantcommunityofinterestistheusersofISO/IEC/IEEE15288andISO/IEC/IEEE12207.

b) the extent of achievement of consensus shall be documented;BothISO/IEC/IEEE15288andISO/IEC/IEEE12207areinternationalstandardssatisfyingtheconsensusrequirementsofISO/IECandIEEE.(Notapplicable).

c) if no actions are taken to achieve consensus, a statement to this effect shall be documented. (Notapplicable).





Theprocessesdefinedwithinaprocessreferencemodelshallhaveuniqueprocessdescriptionsandidentification.[ISO/IEC33020,5.3.3]Theprocessdescriptionsareunique.Theidentificationisprovidedbyuniquenamesandbytheclausenumberingofthisannex.

C.2.3 Process descriptions

The fundamental elements of a process reference model are the descriptions of the processes within the scope of the model.

The process descriptions in the process reference model incorporate a statement of the purpose of the process, which describes at a high level the overall objectives of performing the process, together with the set of outcomes that demonstrate successful achievement of the process purpose.

A process description shall meet the following requirements:

a) aprocessshallbedescribedintermsofitspurposeandoutcomes;

b) thesetofprocessoutcomesshallbenecessaryandsufficienttoachievethepurposeoftheprocess;and

c) processdescriptionsshallnotcontainor implyaspectsof theprocessqualitycharacteristicbeyondthebasiclevelofanyrelevantprocessmeasurementframeworkconformantwithISO/IEC33003.

A process outcome describes one of the following: [ISO/IEC 30004:2015, 5.4]

a) productionofanartifact;

b) asignificantchangeofstate;and

c) meetingofspecifiedconstraints,e.g.,requirements,goals,etc.

These requirements aremetby theprocessdescriptions inClause6of thisdocument. Someoutcomesmaybeinterpreted as contributing to levels of capability above level 1 (basic) in some relevant processmeasurementframeworks. However, conforming implementation of the relevant processes does not require achievement ofthesehigherlevelsofcapability.

C.3 The process reference model

The Process Reference Model (PRM) is composed of the statement of purpose and outcomes of each of theprocesses included inClause6of thisdocument.ThePRM for the software life cycle is composedof the setofprocessesinFigure4,shownpreviouslyin5.6.1ofthisdocument.




Annex D (informative)

Process integration and process constructs

D.1 Introduction

AharmonizationprojectwithinISO/IECJTC1/SC7—aparallel,coordinatedrevisionofISO/IEC/IEEE15288andISO/IEC/IEEE12207,anddevelopmentofguidanceinISO/IEC/IEEE24748(allparts),whichprovidesguidelinestobothofthesedocuments—isthefirst,largesteptowardsanintegratedsetofstandardsdescribingsystemandsoftware life cycles. Concepts of continual process improvement and capability assessment are now wellestablishedandrecognized,andarebeingstandardizedintheISO/IEC33000seriesofstandards(replacingtheISO/IEC15504series).TheProcessReferenceModelsinAnnexCofISO/IEC/IEEE15288:2015andthisdocumentare intended to be used in conjunction with ISO/IEC 33020:2015 for capability assessment of the life cycleprocesses.Capabilitydeterminationofprocessesrequiresthattheprocessdescriptionsincludeaclearstatementof the purpose of the process and a description of the expected outcomes. Consistent implementation of theprocessesisaidedbyhavingactivities,tasks,andimplementationnotesdefined.Thus,thelifecycleprocessesinbothlifecyclestandardshaveadoptedcommonprocessconstructs,asdefinedinD.2,Processconstructsandtheirusage,andareconsistentwiththeprocessdefinitionguidancecontainedinISO/IEC/IEEETR24774.

D.2 Process constructs and their usage

The process descriptions in this document follow clearly defined rules. First, they were grouped in a logicalfashion.Thosegroupingsaredictatedby:

a) Logicalrelationsamongtheprocesses;and

b) Responsibilityforexecutionoftheprocesses.

ThisdocumentgroupstheactivitiesthatmaybeperformedduringthelifecycleofthesystemintofourProcessGroups.Thetop‐leveldescriptionofthesegroupscanbefoundin5.6.Eachlifecycleprocesswithinthosegroupsis described in terms of its purpose and desired outcomes and lists the activities and tasks that need to beperformedtoachievethoseoutcomes.

c) Agreementprocesses–twoprocesses(6.1);

d) OrganizationalProject‐Enablingprocesses–sixprocesses(6.2);

e) TechnicalManagementprocesses–eightprocesses(6.3);and

f) Technicalprocesses–fourteenprocesses(6.455).

Consistent application of process description rules allows for the normalized clause numbering. Within thisdocumentasubclausenumberedas6.xdenotesaprocessgroupand6.x.ydenotesaprocesswithin thatgroup.Subclauses numbered as 6.x.y.1 describe the purpose of a process, subclauses numbered 6.x.y.2 describe theoutcomesofaprocess,andsubclausesnumberedas6.x.y.3describetheactivitiesandtasksofaprocess.

Figure D.1 is a representation of process constructs used in this document and in ISO/IEC/IEEE 15288:2015.TheseareProcess,Activity,Task,andNote.

A process requires a name, purpose and at least one outcome. Each process has at least one activity. A set ofprocesses,withtheirstatementsofpurposeandoutcomes,constituteaProcessReferenceModel(PRM).

Anactivityisaconstructofrelatedtasksforproducingoutcomes,Activitiesprovideameanstoorganizerelatedtaskswithintheprocess,to improveunderstandingandcommunicationoftheprocess. Ifanactivity iscohesiveenough,itcanbeconvertedtoalowerlevelprocessbydraftingapurposeandasetofoutcomes.





Ataskisadetailedprovisionfor implementationofaprocess. Itmaybepresentedasarequirement(“shall”),arecommendation(“should”)orapermission(“may”).

Notesareusedtoexplaintheintentormechanicsofaprocess,activity,ortask.Notesprovideinsightregardingpotentialimplementationorareasofapplicability,suchaslists,examples,andotherconsiderations.

Figure D.1 — ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015 process constructs

ACTIVITY

TASK

NOTE

Name

PROCESS

NamePurposeOutcome

1

1 …

1

0 …

0 …

11

1 …




Annex E (informative)

Process views

E.1 Introduction

Aprocessviewallowsthoserepresentingaparticularengineeringinteresttoseegatheredinasingleplacethesetofprocessactivitiesthatdirectlyandsuccinctlyaddresstheirconcern.Forsuchinterests,aprocessviewcanbedeveloped toorganizeprocesses,activities,andtasksselectedfromISO/IEC/IEEE15288orISO/IEC/IEEE12207toprovideafocustotheirparticularconcerninamannerthatcutsacrossallorpartsofthelifecycle.Thisannexprovidessampleprocessviewpointsthatmaybeusedtodefineprocessviewsintheseinstances.

E.2 The process view concept

Theremay be cases where a unified focus is needed for activities and tasks that are selected from disparateprocessestoprovidevisibilitytoasignificantconceptorthreadthatcutsacrosstheprocessesemployedacrossthelifecycle.Itisusefultoadviseusersofthisdocumenthowtoidentifyanddefinetheseactivitiesfortheiruse,eventhoughtheycannotlocateasingleprocessthataddressestheirspecificconcern.

Forthispurpose,theconceptofaprocessviewhasbeenformulated.Likeaprocess,thedescriptionofaprocessviewincludesastatementofpurposeandoutcomes.Unlikeaprocess,thedescriptionofaprocessviewdoesnotinclude activities and tasks. Instead, the description includes guidance explaining how the outcomes can beachievedbyemployingtheactivitiesandtasksofthevariousprocessesinISO/IEC/IEEE15288andISO/IEC/IEEE12207.ProcessviewscanbeconstructedusingtheprocessviewpointtemplatefoundinE.3.

E.3 Process viewpoint

A process view conforms to a process viewpoint. The process viewpoint provided here can be used to createprocessviews.

1) TheProcessviewpointisdefinedby:

1) itsstakeholders:usersofthisdocument;and

2) theconcernsitframes:theprocessesneededtoreflectaparticularengineeringinterest.

2) Thecontentsofresultingprocessviewsshouldinclude:

1) processviewname;

2) processviewpurpose;

3) processviewoutcomes;and

4) identificationanddescriptionoftheprocesses,activitiesandtasksthatimplementtheprocessview,andreferencestothesourcesfortheseprocesses,activitiesandtasksinotherstandards.

NOTE The requirements for documenting viewpoints are found in ISO/IEC/IEEE42010:2011, 5.4. This description isconsistentwiththoserequirements.





E.4 Process view for specialty engineering

This section provides an example of applying the process viewpoint to yield a process view for specialtyengineering,intendedtoillustratehowaprojectcanassembleprocesses,activitiesandtasksofthisdocumenttoprovidefocusedattentiontotheachievementofproductcharacteristicsthathavebeenselectedasbeingofspecialinterest.

This example treats the cluster of interests, generally called specialty engineering, which includes but is notlimited to such areas as availability, maintainability, reliability, safety, security, human factors, and usability.Within this document, these “ilities” requirements are referred to as “critical quality characteristics”. Thesecharacteristicsdeterminehowwell theproductmeets its specified requirements in a specific area selected forfocus.SeeE.6foraprocessviewrelatingto(informationsecurityassuranceforsoftwaresystems).

NOTE1 This is a generalized instance of a process view that covers a broad set of functional and non‐functionalcharacteristics related to specialty engineering. It provides a broad view across the processes. If a specific critical qualitycharacteristichasahighpriorityrelativetoothercharacteristics,aspecificprocessviewcanbecreatedforthatcharacteristic,includingmoredetailedinformationandrequirements.

NOTE2 ISO/IEC25030,Software Engineering — Software product quality requirements and evaluation (SQuaRE) — Quality requirements,canbeconsultedinspecifyingsoftwareproductqualityrequirements.

NOTE3 INCOSE Systems Engineering Handbook contains descriptions and elaboration about many of the specialtyengineeringareasandtheassociatedcriticalqualitycharacteristics.

Name: Specialty Engineering Process View

Purpose: ThepurposeoftheSpecialtyEngineeringProcessViewistoprovideobjectiveevidencethatthesystemachievessatisfactorylevelsofcertaincriticalqualitycharacteristicsselectedforspecialattention.

Outcomes:

a) Productcriticalqualitycharacteristicsareselectedforspecialattention.

b) Requirementsfortheachievementofthecriticalqualitycharacteristicsaredefined.

c) Measuresfortherequirementsareselectedandrelatedtothedesiredcriticalqualitycharacteristics.

d) Approachesforachievingthedesiredcriticalqualitycharacteristicsaredefinedandimplemented.

e) Theextentofachievementoftherequirementsiscontinuouslymonitored.

f) Asatisfactorylevelofthecriticalqualitycharacteristicsisspecifiedandachieved.

Theoutcomespermitthepossibilitythatthedesiredcriticalqualitycharacteristicscannotbedirectlymeasured,butinsteadmightbearguedandinferredbasedonotherproductorprocesscharacteristicsthatcanbemeasured.Measurementscanbeused toshowcompliancewithestablishedstandards.Theacquirerandsupplier come toagreementonparticularstandardstobeusedforthiscomplianceverification.

Specialty Engineering processes, activities and tasks

Thisprocessviewcanbeimplementedusingthefollowingprocesses,activities,andtasksfromthisdocument.

a) TheProjectAssessmentandControlprocess(6.3.2)providesformonitoringtheextentofachievementoftherequirementsandcriticalqualitycharacteristicsandcommunicatingtheresultstostakeholdersandmanagers.Relevantactivitiesandtasksincludeb)6),7),9)and10).

b) TheDecisionManagementprocess(6.3.3)providesassessmentofalternativerequirements,architecturecharacteristics and design characteristics against the decision criteria, including the critical qualitycharacteristics.Resultsofthesecomparisonsareranked,viaasuitableselectionmodel,andarethenusedtodecideonanoptimalsolution.Relevantactivitiesandtasksincludeb)(alltasks);andc)1).

c) TheRiskManagementprocess (6.3.4), in its entirety,provides for identifying, evaluating, andhandlingrisksofthesystem,includingthoserelatedtomeetingthecriticalqualitycharacteristics.




d) TheInformationManagementprocess(6.3.6),initsentirety,providesforthespecification,developmentandmaintenanceof information items fordocumentingandcommunicatingtheextentofachievement.Information items used for the purpose of critical quality characteristics are sometimes specialized innature.Sourcesforthedescriptionoftheseinformationitemsincludeindustryassociations,regulators,andspecificstandards.

e) TheMeasurementprocess(6.3.7),initsentirety,providesfordefininganapproachthatrelatesmeasurestotherequiredcriticalqualitycharacteristics.

f) TheQualityAssuranceprocess(6.3.8)addressesidentifiedanomalies(incidentandproblems)thatrelatetotheachievementofcriticalqualitycharacteristics.

g) TheBusinessandMissionAnalysisprocess(6.4.1)providesforthedefinitionoftheproblemspaceandcharacterization of the solution space, including the relevant trade‐space factors and preliminary lifecycleconcepts.Thisincludesdevelopinganunderstandingofthecontextandanykeyparameters,suchasthecriticalqualitycharacteristics,e.g.,securitythreats,safetyhazards,humaninterfaces,operationalcharacteristics,andsystemassurancecontext.Relevantactivitiesandtasksincludeb)1)and2);c)1);andd)1).

h) The Stakeholder Needs and Requirements Definition process (6.4.2) provides for the selection anddefinitionof characteristics, includingcriticalquality characteristics, andassociated information items.The activities and the documentation are useful in identifying, prioritizing, defining, and recordingrequirements for the critical quality characteristics. Relevant activities and tasks include a)1) and 2);b)2),3)and4);c)1)and2);d)alltasks;ande)2).

i) The System/Software Requirements Definition process (6.4.2) provides for the specification ofparameters for the critical quality characteristics and the selection of measures for tracking theachievement of these requirements with respect to the specific system to be developed. Relevantactivitiesandtasksincludea)1);b)alltasks;andc)2).

j) TheArchitectureDefinitionprocess(6.4.4)providesforthe identificationofstakeholderconcerns fromanarchitectureperspective.These concernsoften translate intoexpectationsor constraintsacross thelife cycle stages that relate to the critical quality characteristics, such as utilization e.g., availability,security, effectiveness, usability; support, e.g., reparability, obsolescencemanagement; evolutionof thesystem and of the environment, e.g., adaptability, scalability, survivability; production, e.g.,manufacturability, testability; retirement, e.g., environmental impact, transportability. This processfurtheraddressesthosecriticalqualitycharacteristicrequirementsthatdrivethearchitecturedecisions,includingtheassessmentofthearchitecturewithrespecttotheconcernsandassociatedcharacteristics.Relevantactivitiesandtasksincludea)2)and4);b)1);c)2),3),4),and5);d)1);ande)2).

k) TheDesignDefinitionprocess(6.4.5)providesforthedeterminationofnecessarydesigncharacteristics,which includes the critical quality characteristics, such as security of design criteria for the specialtycharacteristicsandtheevaluationofalternativedesignswithrespecttothosecriteria.Relevantactivitiesandtasksincludea)2);b)1),2),3)4),and6);andc)2).

l) The SystemAnalysis process (6.4.6) provides for the level of analysis needed to understand the tradespacewith respect to the critical quality characteristics through the conductofmathematical analysis,modeling, simulation, experimentation, and other techniques. The analysis results are input to tradesmade through the Decision Management process in support of other Technical processes. Relevantactivitiesandtasksincludea)(alltasks);andb)(alltasks).

m) TheImplementationprocess(6.4.7)providesforrecordingtheevidencethatcriticalqualityrequirementshavebeenmet.Relevantactivitiesandtasksincludeb)3).

n) The Integration process (6.4.8) provides for planning the integration, including the considerations forcritical quality characteristics, and the assurance that the achievement of the characteristics isdeterminedandrecorded.Relevantactivitiesandtasksincludea)1);b)3);andc)1).

o) The Verification process (6.4.9), provides for the planning and execution of a strategy to performverification,includingthecriticalqualitycharacteristics.Theselectedverificationstrategycanintroducedesignconstraintsthataffecttheachievementofthecharacteristics.Relevantactivitiesandtasksincludea)1)and3);b)1),2);andc)1)and2).





p) TheTransitionprocess(6.4.10)providesforinstallingthesysteminitsoperationalenvironment.Becausesome specialty properties involve a trade‐off between design constraints and operational constraints,attentiontoinstallationisoftenimportant.Relevantactivitiesandtasksincludea)4);andb)4),6),and7).

q) The Validation process (6.4.11) provides evidence that the services provided by the systemmeet thestakeholders’ needs, including the critical quality characteristics. Relevant activities and tasks includea)1)and3);b)1)and2);c)1)and2).

r) The Operation process (6.4.12) provides for usage of the system. Assuring that critical qualitycharacteristics are appropriately achieved involves monitoring the operation of the system. Relevantactivitiesandtaskincludeb)3)and4);c)1)and2);andd)1)and2).

s) The Maintenance process (6.4.13) sustains the capabilities of the system, particularly its ongoingavailability to provide its functions, including its critical quality characteristics. This includes failureanalysis, maintenance tasks, and logistics tasks needed to assure continued operation of the system.Relevantactivitiesandtasksincludeb)alltasks;c)alltasks;andd)1)and2).

t) TheDisposalprocess(6.4.14)endstheexistenceofasystem.Theinherentneedtoanticipatedisposalcanplace constraints on development. In fact, these constraints can be critical quality characteristics.Relevantactivitiesandtasksincludea)2);b)1)and2)andc)3).

E.5 Process view for interface management

This section provides an example of applying the process viewpoint to yield a process view for interfacemanagement,intendedtoillustratehowaprojectcanassembleprocesses,activitiesandtasksofthisdocumenttoprovidefocusedattentiontotheachievementofproductcharacteristicsthathavebeenselectedasbeingofspecialinterest.

Thisexampletreatsaspecific instanceofaprocessview,calledinterfacemanagement,whichincludesinterfacedefinition,design,andchangemanagement.Withinthisdocument,thetasksthatcompriseinterfacemanagementarefullycontainedwithintheexistingprocesses.

NOTE Forsoftwaresystems,interfaceswithothersystemsareatypicalwayofreceivinginputdataorexportingoutputdata (reports). Interfaces with external systems and services allow the software system to function in its operatingenvironmentandwithenablingsystems.TheGUIisaspecialinterfaceforhumaninteractionwiththesoftwaresystem.

Name: Interface Management Process View

Purpose: ThepurposeoftheInterfaceManagementProcessViewistofacilitateidentification,definition,designandmanagementofinterfacesofthesoftwaresystem.

Outcomes:

a) Businessormissionneedsrelatedtointerfacesareidentified.

b) Stakeholderneedsrelatedtointerfacesareidentified

c) Requirementsfortheinterfacesaredefined.

d) Interfacesbetweensoftwaresystemelementsareidentifiedanddefined.

e) Interfacesbetweenthesoftwaresystemandexternalsystemsareidentifiedanddefined.

f) Theextentofrealizationoftheinterfacerequirementsiscontinuouslymonitored.

Interface Management processes, activities and tasks


NOTE INCOSE Systems Engineering Handbookcontainsdescriptionsandelaborationaboutinterfacemanagement.




a) The Project Assessment and Control process (6.3.2Error! Bookmark not defined.) provides formonitoringtheextentofachievementoftherequirements, includinginterfaces,andcommunicatingtheresultstostakeholdersanddecisionmakers.Relevantactivitiesandtasksincludeb)6),7),9)and10).

b) The Decision Management process (6.3.3) provides assessing alternative requirements, architecturecharacteristicsanddesigncharacteristicsagainstthedecisioncriteria,includingtheinterfaces.Resultsofthesecomparisonsareranked,viaasuitableselectionmodelandarethenusedtodecideonanoptimalsolution.Relevantactivitiesandtasksincludeb)alltasks);andc)1).

c) TheRiskManagementprocess (6.3.4), in its entirety,provides for identifying, evaluating, andhandlingrisksofthesystem,includingthoserelatedtointerfaces.

d) TheConfigurationManagementprocess(6.3.5)providesfortheidentificationandcontrolofinterfaces.Itincludesmanagementof interfacespecificationsand interfacecontroldocuments. Internalandexternalinterfacerequirementsandchangesaredocumentedinaccordancewiththeproject’sCMstrategy,whichiscommonlyrepresentedinaCMplan.Relevantactivitiesincludeb)1)andd)1).

e) TheInformationManagementprocess(6.3.6),initsentirety,providesforthespecification,developmentandmaintenanceofinformationitemsfordocumentinginterfacesandtheiroperationalperformance.

f) TheMeasurementprocess(6.3.7),initsentirety,providesfordefininganapproachthatrelatesmeasurestotherequiredinterfaceinformationneeds,andthengeneratingandusingthosemeasurestoaddresstheidentifiedinterfaceinformationneeds.

g) The Quality Assurance process (6.3.8), in its entirety, addresses identified anomalies (incidents andproblems)thatrelatetotheachievementofinterfacerequirements.

h) TheBusinessandMissionAnalysisprocess(6.4.1)providesforthedefinitionoftheproblemspaceandcharacterizationofthesolutionspace,includingthedescriptionoftheenvironmentandcontext,aswellaspreliminaryoperationalconcepts,includingsoftwaresysteminterfacesandenablingsysteminterfaces.Itoftenidentifiesexternalsystemsthatinterfacewiththesystem‐of‐interest.Relevantactivitiesandtasksincludeb)1)and2);andc)1).

i) The Stakeholder Needs and Requirements Definition process (6.4.2) provides for the identification ofstakeholders concerned with interfaces, definition of operational concepts and the interactions of thesystemwithusers,existinginterfacestobetransitioned,andtheintendedenvironment(includingothersystems).Itoftenidentifiesexternalsystemsthatinterfacewiththesystem‐of‐interest.Relevantactivitiesandtasksincludea)1),c)1)and2),andd)1)and3).

j) TheSystem/SoftwareRequirementsDefinitionprocess (6.4.3)provides for thedefinitionof thesystemboundaryandtheinterfacerequirements.Relevantactivitiesandtasksincludea)1);b)3)and4);c)(alltasks),andd)1)and3).

k) The Architecture Definition process (6.4.4) provides for the identification of interfaces from anarchitectureperspectiveasthearchitecturemodelsevolve.Thisprocessfurtherdescribesanddefinestheinterfacestotheextentneededforthearchitecturedescription.Relevantactivitiesandtasksincludea)2);c)1)through4);d)2);andf)2)and6).

l) TheDesignDefinitionprocess(6.4.5)providesfortherefinementandfulldefinitionoftheinterfacesandthe creation of the information items to specify the interface characteristics and protocols. Relevantactivitiesandtasksincludeb)2),5)and6);c3),andd)2).

m) The System Analysis process (6.4.6) provides for the level of analysis needed to balance interfacearchitecture, design constraints, interface performance requirements, and operational performancemeasurements, throughtheconductofmodeling,simulation,andothertechniques.TheanalysisresultsareinputtotheDecisionManagementprocessinsupportofotherTechnicalprocesses.Relevantactivitiesandtasksincludea)(alltasks);and(b)(alltasks).

n) The Implementation process (6.4.7) provides for development of the interfaces and recording theevidence that interface requirements for an implemented system element have been met. Relevantactivitiesandtasksincludeb)1)and3).





o) The Integration process (6.4.8) provides for planning the integration, including the considerations forinterfacesbetweensoftwaresystemelementsandwithexternalsystems.Italsoincludestheintegrationof systemsor systemelements and interfaces and confirming the interfaces in the integrated softwaresystem.Relevantactivitiesandtasksincludea)1),2),and5);b)alltasks;andc)1).

p) The Verification process (6.4.9), provides evidence that the services provided by the systemmeet thesystem requirements, including the interface requirements. Theprocessprovides for theplanning andexecution of a strategy to perform verification, including the interface requirements. The selectedverification strategy may introduce interface constraints that affect their implementation. Relevantactivitiesandtasksincludea)1)and3);b)1),2);andc)1).

q) TheTransitionprocess(6.4.10)providesforplanningandmigratingthesoftwaresystemorelementsanddatasetsintoadifferentenvironmentusinginterfaces,andestablishingtheuseofinterfacesinthenewsystem. This includes identifying constraints, and checking the installation, activation and operationalstateoftheinterfaces.Relevantactivitiesandtasksincludea)1)and3);b)3),4),6),and7).

r) TheValidationprocess(6.4.11)providesevidencethattheservicesprovidedbythesoftwaresystemmeetthe stakeholders’ needs, including the interface requirements. The selected validation strategy mayintroduceinterfaceconstraintsthataffecttheirimplementation.Validationinvolvescommunicationwithstakeholderrepresentativesoftheinterfacingsystemsandservices.Relevantactivitiesandtasksincludea)4);b)1)and2);c)1)and2).

s) TheOperationprocess(6.4.12)providesforusageofthesoftwaresystem.Therealsomaybeconstraintsto the interfaces foroperations.Confirming that the interface requirementsareappropriatelyachievedinvolves monitoring the operation of the system, identifying and performing corrective action wheninterfacesdonotfunctionproperly,andsupportingcontactwithinterfacepartners(customers).Relevantactivitiesandtaskincludea)1)and2),b)1),3)and4);c)1)and2),andd(alltasks).

t) TheMaintenanceprocess(6.4.13)sustainsthecapabilitiesofthesoftwaresystem,includingitsinterfaces,andtheirongoingavailabilitytoprovidetheirfunctions.Thisincludesproblemanalysisandmaintenancetasks,andlogisticstasksneededtoassurecontinuedandtimelyoperation.Relevantactivitiesandtasksincludea)2);b)(alltasks);andd)1),2),and3).

u) The Disposal process (6.4.14) ends the existence of a system or an interface. It involves activities todisengageanddiscontinueinterfaces.Relevantactivitiesandtasksincludea)2)and3);andb)1),2),and6).

E.6 Process view for software assurance (Information security)

Thissectionprovidesanexampleofapplyingtheprocessviewpointtoyieldaprocessviewforsoftwareassurance,intended to illustrate how a project can assemble processes, activities and tasks of this document to providefocused attention to the achievement of software assurance characteristics that havebeen selectedas beingofspecialinterest.Thesoftwareassurancecharacteristics,theirextentofachievement,andrelatedinformationmaysupportasoftwareassuranceclaim,asdescribedinISO/IEC/IEEE15026.

This example is focused on protection against intentional subversion or forced failure due to the softwarearchitecture,design,orimplementation,especiallyconstructionofthecode.

Name: Software Assurance Process View

Purpose: ThepurposeoftheSoftwareAssuranceProcessViewistoprovideobjectiveevidencethatthesoftwareachieves satisfactory levels of certainty that sufficient protection is achieved against intentional subversion orforcedfailureduetothesoftwarearchitecture,design,orconstructionofthecode.

NOTE In terms appropriate for conformance to ISO/IEC/IEEE 15026, the assurance claims regarding the softwarecharacteristics selected for special attention are achieved and information is provided showing the achievement of thoseclaims.

Outcomes:

a) Productsoftwareassurancecharacteristicsareselectedforspecialattention.




b) Requirementsfortheachievementofthesoftwareassurancecharacteristicsaredefined.

c) Measuresfortherequirementsareselectedandrelatedtothedesiredsoftwareassurancecharacteristics.

d) Approachesforachievingthedesiredsoftwareassurancecharacteristicsaredefinedandimplemented.

e) Theextentofachievementoftherequirementsiscontinuouslymonitored.

f) Asatisfactorylevelofthecriticalsoftwareassurancecharacteristicsisspecifiedandachieved.

The outcomes permit the possibility that the desired software assurance characteristics or claim cannot bedirectlymeasuredbut insteadmight be inferredbasedonotherproduct orprocess characteristics that canbemeasured.Measurementsmaybeusedtoshowcompliancewithestablishedstandards.Theacquirerandsupplieragreeonparticularstandardstobeusedforthiscomplianceverification.

Software Assurance processes, activities and tasks


a) TheAgreementprocesses(6.1)providefortheestablishmentofexpectationsandresponsibilitiesrelatedtosoftwareassurance,includinglegalagreementsandlicensingrequirements,theprotectionoforganizations’assetsthatareaccessiblebysuppliers,thepossibilityofcompromiseduringdelivery,detectionofanomalies,detectionofcounterfeitsintheapplicationelementatarrival,expectationsfordefectresolution,patchmanagement,servicelevelagreements,andsafeguardsagainstsupplychainthreats.RelevantactivitiesandtasksincludeintheAcquisitionprocess:a)1)and2)andc)1);andintheSupplyProcess,c)1),e)1and2).

b) TheLifeCycleModelManagementprocess(6.2.1)providesfortheestablishmentandmaintenanceofsoftwareassurancepoliciesandproceduresincludingasoftwaresecuritydevelopmentlifecycleandthecontrolleduseofoutsourcedcode.Relevantactivitiesandtasksincludea)2and3),b)1,andc)alltasks.

c) TheInfrastructureManagementprocess(6.2.2),initsentirety,providesforsecuredevelopmentand

operationalenvironments,softwareassurancetools,timelypatchmanagement,andcodelibrariesthatareproperlymaintainedandimprovedbasedonlessonslearnedfromtheprojects,organizationandindustry.

d) TheHumanResourceManagementprocess(6.2.4),initsentirety,providesforrelevantscreeningofemployeesandsupplierswithaccesstothesoftwareorsoftwaredevelopmentenvironmentanddefinesspecifictrainingrelatedtosoftwareassurancebasedonrolesandresponsibilitiesacrossthelifecycle.

e) TheKnowledgeManagementprocess(6.2.6)providesforcollectingandmaintainingknowledgeandinformingtheprojectaboutchangestothethreatlandscape,evolutionsinsoftwareassurancepractices,mitigationsforsoftwarevulnerabilities,lessonslearnedfromincidentsandincidentresponses,andevolutionsinsoftwareassurancetestingtools.Relevantactivitiesandtasksincludeb)(alltasks)andd)3).

f) TheDecisionManagementprocess(6.3.3),initsentirety,assessesalternativerequirements,architecturecharacteristicsanddesigncharacteristicsagainstthedecisioncriteria,includingthesoftwareassurancecharacteristics.Resultsofthesecomparisonsarerankedandrecordedalongwiththeselectionmodel,andarethenusedtodecideonanoptimalsolution.Stakeholderscanmakedecisionsbasedonthejustificationprovided.

g) TheRiskManagementprocess(6.3.4),initsentirety,providesfortheevaluationofthepotentialfornotbeingabletoachievethenecessaryapplicationsecurity,resultinginarisktotheusersincludingtheinterfacepartners,orresultinginthesoftwarenotbeingusedasintended.Softwaresecurityisariskcategoryineachriskanalysis.

h) TheConfigurationManagementprocess(6.3.5)providesfortheestablishmentandmaintenanceoftheintegrityofallidentifiedoutputsofaprojectorprocess,includingthemonitoringofassetsandsecurityofdesignatedstoragesystems,andmakesthemavailabletoauthorizedparties.Thisincludesrecordsofchangesmadetothesoftwareandsoftwarereleases,aswellascontrolandauditofallaccessestothesoftwareitemsthathandlesecurityfunctions.Relevantactivitiesandtasksincludea)1),d)1),andf)2).





i) TheInformationManagementprocess(6.3.6),initsentirety,providestheinformationabouttheachievementofsoftwareassurancetotherelevantstakeholders,includingregulatoryorapprovalauthorities.Thequantifiableinformationaboutthesoftwareiscollectedtosupportasetofargumentsthatjustifyaclaimaboutthesoftwareassuranceofasystem.Duetothesensitivityofthedata,additionalcareisgiventoidentifytheappropriateaudiencesforthevariousassurancemeasures.Informationmanagementincludestheprotectionofsensitiveinformationitemsregardingsoftwareassurance.

j) TheMeasurementprocess(6.3.7),initsentirety,providesacommonplatformforcollectinginformationaboutthesoftwareassuranceclaims,strategies,andevidence,sometimesreferredtoasanassurancecase.

k) TheQualityAssuranceprocess(6.3.8)evaluatesprojectandsupplierprocessesforconformancetosoftwareassurancerequirementsandprocedures.Itaddressesidentifiedanomalies(incidentandproblems)thatrelatetotheachievementofsoftwareassurancecharacteristics.Relevantactivitiesandtasksincludec)ande)(alltasks).

l) TheBusinessandMissionAnalysisprocess(6.4.1)providesforunderstandingtheoperatingenvironmentforthesoftwaresystemunderdevelopmentandlaws,policies,risks,andconstraintsrelatedtosoftwareassurance.Relevantactivitiesandtasksincludeb)1)andc)1).

m) TheStakeholderNeedsandRequirementsDefinitionprocess(6.4.2)providesfortheselectionanddefinitionofrisksandthreatstomissionsorinformation.Itincorporatesthisknowledgeindefiningrequirementsrelatingtosoftwareassurance(informationsecurity),includingconfidentiality,availabilityandintegrityinthecontextofhowthesoftwareisintendedtofunction;andinconsiderationofmisuseandabusescenarios.Stakeholdersneedtoagreeuponwhataspectsofsoftwareassurancearesufficient.Relevantactivitiesandtasksincludea)2);b)1)and2);andc)(alltasks).

n) TheSystem/SoftwareRequirementsDefinitionprocess(6.4.3)providesfortheselectionanddefinitionofsoftwareassurance(informationsecurity)relatedrequirements,includingconfidentiality,availabilityandintegrityinthecontextofhowthesoftwareisintendedtofunction;andrequirementsforsoftwareintegrityintheeventofmisuseandabuse.Relevantactivitiesandtasksincludeb)3)and4);andc)3).

o) TheArchitectureDefinitionprocess(6.4.4)providesfortheidentificationofstakeholderconcernsfromanarchitectureviewpointthroughthreatmodelingandassessingthevulnerabilityoftheproductarchitectureanddesigntopotentialattackstogainanunderstandingofthethreatlandscapeandtherelevantarchitectureelements.Relevantactivitiesandtasksincludea)2)and4);b)1);c)(alltasks),d)5),andf)10,20,and5).

p) TheDesignDefinitionprocess(6.4.5)providesforthedeterminationofnecessarydesigncharacteristics,whichincludeattacksurfacereduction,includingthelocationofcomponents;softwareassurancedesignpatterns;andavoidanceofanti‐patterns.Relevantactivitiesandtasksincludea)2)and3);b)2),3),and6);c)2)andd)1).

q) TheImplementationprocess(6.4.7)providesfortheuseofsecurecodingpracticestoavoidcommoncodingerrorsthatleadtoexploitableproductvulnerabilities,andtheuseofavarietyoftestingtechniquesincludinginspectionforcompetentauthenticity,fuzztesting,staticanalysistesting,anddynamictestingtoidentifyandaddresssoftwareweaknessesandvulnerabilities.Relevantactivitiesandtasksincludea)1);andb)1),2)3)and4).

r) TheIntegrationprocess(6.4.8)providesforplanningtheintegration,includingtheconsiderationsforsoftwareassurancecharacteristics,andtheassurancethattheachievementofthecharacteristicsisdeterminedandrecorded.Implementationofinterfacestandardswhereverpracticalpromotessystemandelementsustainabilityandelementreusability.Relevantactivitiesandtasksincludea)2)and5);b)3);andc)1)and2).

s) TheVerificationprocess(6.4.9)providesfortheplanningandexecutionofastrategytoverifythatsoftwareassurancerequirements,includingthesoftwareassurancecharacteristics,havebeenachieved.Theselectedverificationstrategycanintroducetestingforcodeweaknessesinthedevelopmentprocessorduringsustainment.Threatanalysisprovidesinputintothecreationoftestplansandcases.Theresultsincludetheinformationrequiredtoeffecttheremedialactionsthatcorrectnonconformancesinthesoftwareortheprocessesthatactonitandaccountforuncertaintyinverificationactivities,suchastesttoolreliabilityandleveloftheuncertaintyinresults(i.e.,ratesoffalsepositivesandfalsenegatives).




Additionalconsiderationsincludetheresiliencyofthesoftwaretofunction.Relevantactivitiesandtasksincludea)1),4),5)and6:b)(alltasks);c)1)and2).

t) TheTransitionprocess(6.4.10)providesforinstallingthesoftwaresystemorelementinadifferentenvironment.Becausesomesoftwareassurancepropertiesinvolveatrade‐offbetweendesignconstraintsandoperationalconstraints,attentiontoinstallationanduserdocumentationisoftenimportant.Relevantactivitiesandtasksincludea)2);b)1)and4),5),and6);andc)1)and2).

u) TheValidationprocess(6.4.11)providesevidencethattheservicesprovidedbythesoftwaresystemmeetthestakeholders’needs,includingthesoftwareassurancecharacteristics.Validationmethodsincludevulnerabilityscans,codeassessmentandvalidationusingavarietyoftoolsandtechniquessuchasstaticcodeanalysis,dynamiccodeanalysis,binarycodeanalysis,codecoveragetools,stresstesting,andtheuseoftoolstogatherevidenceofchangesresultingfromremotemaintenanceactivities.Additionalconsiderationsincludetheresiliencyofthesoftwaretofunctionunderuseandabusecases.Relevantactivitiesandtasksinclude,a)1),3,and4),b(alltasks),andc)2)and3).

v) TheOperationprocess(6.4.12)providesforusageofthesoftwaresystem.Assuringthatsoftwareassurancecharacteristicsareappropriatelyachievedinvolvesmonitoringtheoperationofthesystemtodeliveritsservicesinitsintendedenvironmentandprovidessupporttothecustomersofthesoftwareproduct.Plansforthisprocessconsiderachievementofapplicationsecuritythroughoutthelifeofthesystem,operationalrestrictionssuchasaccesscontrol,andconsistencyofassumptionsmadeduringearlierstagesregardingapplicationsecuritywiththeoperationalenvironment.Theprocessincludesestablishingreportingsystemsandproceduresforinvestigationanddispositionofapplicationsecurity‐relatedincidents.Relevantactivitiesandtasksincludea)1),b)(alltasks);c)1),2),and3);andd)1).

w) TheMaintenanceprocess(6.4.13)sustainsthecapabilitiesofthesoftwaresystem,particularlyitsongoingavailabilitytoprovideitssoftwareassurancecharacteristics.Thisincludesfailureanalysis,maintenancetasks,andlogisticstasksneededtoassurecontinuedoperationofthesystem.Themaintenanceprocessprovidesforevaluatingtheeffectonsoftwareassurancefromchangesmadetothesoftwareduringmaintenanceandmaintainingappropriateevidenceforsoftwareassurance.Itincludesadocumentedprocessforpatchingandremediatingsoftware,detectingandremovingorinactivatingunauthorizedandmalicioussoftware,andaprocessforinforminganacquirerorinterfacepartnerofnotificationandremediationmechanisms.Remediationofvulnerabilitiesisprioritizedbasedonavarietyoffactors,includingrisk.Documenteddevelopmentandsustainmentpracticesarefollowedwhenimplementingsoftwareremediation.Relevantactivitiesandtasksincludea)1);b)(alltasks);c)(alltasks);andd)1)and2).

x) TheDisposalprocess(6.4.14)endstheexistenceofasoftwaresystem.Theinherentneedtoanticipatedisposalcanplaceconstraintsondevelopmentandmanagementofdatacontainedinthesoftwaresystem.Infact,theseconstraintscanbesoftwareassurancecharacteristics.Relevantactivitiesandtasksincludea)1),2),and5);b)(alltasks);andc)1)and3).





Annex F (informative)

Software system architecture modelling

F.1 Introduction

Inthisdocument,architectureanddesignactivitiesaredescribedasseparateprocesses.SeveraliterationsoftheArchitecture Definition, Design Definition, and Implementation processes can be involved when evolving asoftware element’s architecture e.g., to determine whether an entity or function will be realized throughintegration of existing software, adaptive reuse, or newly constructed software. In the systems and softwareengineering communities dealing with complex systems, architecture can be followed by different designs fordifferent systems in different product lines. In this case it is important to perform these two processes in aseparatemanner.Furthermore,architectureisoftendoneforotherreasonsthanastheimmediatebasisfordesign,suchastodrivetechnologyinvestments,toachieveconsistencyorreducecomplexityinanorganization’sproductlineorportfolioofprojects,ortoguideacquirer‐supplierdecisions.

The architectureof a software systemcanbeunderstoodas a set of structuredarchitectural entities and theirrelationships, chosen to achieve characteristics such as interoperability, scalability, environmental resilience,encapsulation,availability,affordability,robustness,executionefficiency,ormissioneffectiveness(fitnessforuse).Software systemarchitecturedealswith relationships among a varietyof entities, suchas scenarios, functions,function flows, interfaces, resource flow items, informationordataelements, objects,physical componentsandenvironments,containers,nodes,links,communicationresources,constraints,equationsandparametricmodels.

ThisAnnexdescribessomeofthemodels(modelkinds)thatareusedincreatingandevaluatingthearchitectureofsoftwaresystems.

NOTE ISO/IEC/IEEE15288:2015,AnnexFdescribeshowmodelsandviewsareappliedtothearchitectureofsystemsingeneral,andhasadditionalinformationrelatingtoviewsandmodellingofthearchitectureofphysicalproducts,suchasmassmodelsandlayoutmodels.

F.2 Views, models and model kinds used in software system architecture

TheArchitecturalDefinitionprocessusesavarietyofmodelsforsoftwaresystems,includingtheexamplemodelslisted in the followingsection.Modelkindsspecify the languages,notations,conventions,modelling techniques,analytical methods or other operations to be used on models of that kind. (Traditional system engineeringpracticeclassifiessomeofthesemodelsas“logicalmodels”or“physicalmodels”,butthetaxonomicaldistinctionisunnecessary in the application of this document.) A variety of views are used to represent how the systemarchitecture addresses stakeholder concerns. Views are composed of models. For example, a logical view ofsoftware can represent business processes in its functions; a process view can represent the events andtransformations occurring within different states of the software and can include concurrency and timingconcerns;astructuralviewrepresentsthedifferentsystemcomponents,whichcanbeassociatedwithphysicalorvirtual systemelements, an informationview represents the relationshipsbetweendata elements contained inandtransformedbythesoftware.

RefertoISO/IEC/IEEE42010fordefinitionsofarchitecturetermsandadditionaldetailonarchitectureconceptsandmodels.

F.2.1 Functional model

Afunctionalmodelofthesystemisarepresentationofasetoffunctionsthatdefinesthetransformationsofinputsintooutputsperformedbythesystemtoachieveitsmissionorpurpose.Thesefunctionsaredeterminedbyhowthesystemisexpectedtobehavewhenusedasintended.Consequently,everysystemfunctionisassociatedwithaninteractionbetweenthesystemanditsenvironment.Functional,performance,non‐functional,andconstraintrequirementsareusuallyanalyzedtodeterminefunctionsandinput‐outputflows.Whenfunctionsareassociatedwithsystemelements,thedesigndefinitionprocesswillneedtodetermineifeachsystem/softwareelementhas




been sufficiently specified to build or buy it. If the system element is further resolved in order to achieve thissufficiency, then the functions associated with the system element are also further resolved and properlyassociatedwiththesub‐elements.Typically,therearemultiplewaystodecomposethefunctionsthatcontributetothedefinitionofmultiplecandidatearchitectures.

F.2.2 Static model

A staticmodel describes the structure of a software system. In object‐orientedprogramming, it is representedthroughasetofobjects(classes)andtheirrelationships(inheritance,association,anddependency),depictedasnodesandlinks.

F.2.3 Data model

A data model (semantic or information model) represents the data elements and their relationships andproperties(attributes)thatthesoftwaresystemwillhandle.Logicaldatamodelsuseschematoreflectstructuralrelationshipsbetweendataentitieswhichcanbeimplementedindatabases.Datamodelsreflectdifferenttypesofdata(text,graphics,geographicdata,images,generalobjects)andtheiruseinthesystemfunctions(frequencyofchange,datavolume,useinsearching)aswellasthelogicalrelationshipsamongdataelements.Datamodelsareapplied in thedevelopmentof interfacesandsoftwareservices,dataanalysis, anddata reporting.Physicaldatamodelsreflecttheschemaforstorageandretrievalofdatarecords.

F.2.4 Behavioral model

Abehavioralmodel(dynamicmodel) isanarrangementof functionsand interfaces(internalandexternal) thatdefineshow thesystemor itselementsactunderconditions to sustain theoperational scenarios, including theexecution sequencing, synchronization, and concurrency, the conditions for behavioral change and theperformance.Behavioralmodelsareapplicabletosoftwarecontrolsystems.Abehavioralmodelcanbedescribedwith a set of interrelated scenarios. This includes identifying the behavioral elements (e.g., modes/states,transitions,triggerevents,andoperationalscenarios)throughthelifecycle.

F.2.5 Temporal model

A temporalmodel of the system is a representation that expresses how the time is taken into account in thebehaviorthesystemoritselementsthatpresentslevelsofexecutionfrequencyoffunctions(e.g.,strategiclevel,tactical level, operational monitoring level, regulation level) corresponding to levels of decision that enablehumans and program logic to monitor and control the system operations. This includes identifying temporalelements (e.g., duration, frequency, response time, triggers, timeout, stop conditions), from the operationalconceptandsystemrequirements.

F.2.6 Structural model

Astructuralmodelofthesystemisarepresentationthatshowsthearrangementofelementswithrespecttoeachother and where necessary shows the interfaces between elements and with external entities. Such a modelenables consolidating or identifying physical interfaces between system elements in a level of the systemhierarchyandbetween levels of the systemhierarchy, aswell as thosewith external entities to the concernedsystem(initsenvironment/context).Structuralmodelscanbehierarchicaldecompositionsorobject‐oriented.

F.2.7 Network model

Anetworkmodeldefinesanarrangementofnodesandlinkstohelpunderstandhowresources(e.g.,informationandpeople)traversefromonenodetoanother.Anetworkmodelcanbeusedtodetermineconstraintssuchasthroughput,latency,andcongestionpoints.Anetworkmodelissometimesmodelledalongwithaprotocolstacktounderstandhowlayersinanetworkinteractverticallyupanddownthestack.

F.3 Other model considerations

Stakeholder life cycle concerns, such as maintenance, evolution, disposal, potential changes of environment,obsolescence management, and other non‐functional requirements, are addressed by defining architecturalcharacteristics such as modularity, relative independence, scalability, upgradability, adaptation to several





environments, level of effectiveness, reliability, robustness, and resilience. Other necessarymodels can includesome of these characteristics or other critical quality characteristics. For example, a software assurance case,regarded as a model, can help in deducing potential architectural mitigations to minimize operational risks(missionlossduetoexploitedsecurityvulnerabilities)relatedtocriticalconcernsandfunctions.

Determinationofwhichmodelstouseinsystemdefinitioncanbebasedonexaminationofstakeholderconcerns.Themodels and the resulting viewscanbeused to expresshow the systemarchitectureanddesignaddressestheirconcernsandtogainbetterunderstandingoftheiractualneeds,wantsandexpectations.

Furthermore,modelscanbeusedinotherlifecycleprocessesbesidesarchitectureanddesigndefinition.Model‐BasedSystemsEngineering (MBSE) is the formalizedapplicationofmodelling to support systemrequirements,architecture,design,analysis,andverificationandvalidationactivitiesthroughoutthelifecycle.

NOTE Averificationandvalidationmodeldefinesrepresentationsoftestinformation,whichcansupporttheverificationofthearchitecture.Verificationandvalidationmodelscangeneratetestanalyzes,data,cases,andotherinformation.




Annex G (informative)

Application of software life cycle processes to a system of systems

G.1 Introduction

A system of systems (SoS) is a system‐of‐interest (SOI)whose elements are themselves systems. A SoS bringstogetherasetofsystemsforataskthatnoneofthesystemscanaccomplishonitsown.Eachconstituentsystemkeepsitsownmanagement,goals,andresourceswhilecoordinatingwithintheSoSandadaptingtomeetSoSgoals.Inthecontextofterminologydiscussedin5.2.3(asshowninFigure3),thecompositesetofsystemsincludingtheoriginalSOI,enablingsystemsandinteractingsystemstogetherconstituteanSoS.Wherethereareconcernsthataffectthecompositeset,thesystemofsystemsbecomestheSOI,whichisconsideredtosatisfysomebusinessormission objective that cannot be satisfied by the individual constituent systems, or to understand emergentbehaviorofthecombination.

ThisannexaddressestheapplicationofsystemlifecycleprocessestosuchSoS.Itdescribesgeneralcharacteristics,thecommontypesofSoS,andtheimplicationsthroughoutthelifecycle.

G.2 SoS characteristics and types

SoS are characterized bymanagerial and operational independence of the constituent systems,which inmanycasesweredevelopedandcontinuetosupportoriginally identifiedusersconcurrentlywithusersof theSoS. Inothercontexts,eachconstituentsystemitselfisaSOI;itsexistenceoftenpredatestheSoS,whileitscharacteristicswereoriginallyengineeredtomeettheneedsoftheirinitialusers.AsconstituentsoftheSoS,theirconsiderationis expanded to encompass the larger needs of the SoS. This implies added complexity, particularly when thesystemscontinuetoevolveindependentlyoftheSoS.Theconstituentsystemsalsotypicallyretaintheiroriginalstakeholdersandgovernancemechanisms,whichlimitsalternativestoaddresstheneedsoftheSoS.

SoS have been characterized into four types based on the governance relationships between the constituentsystemsandtheSoS(TableG.1).Thestrongestgovernancerelationsapplytodirectedsystemofsystems,wheretheSoSorganizationhasauthorityovertheconstituentsystemsdespitethefactthattheconstituentsystemswerenot originally engineered to support the SoS. Somewhat less control is afforded for acknowledged SoS,whereallocatedauthoritybetweentheconstituentsystemsandthesystemsofsystemshasanimpactonapplicationofsome of the systems engineering processes. In collaborative SoS, which lack system of systems authorities,application of systems engineering depends on cooperation among the constituent systems. Virtual systems ofsystemsarelargelyself‐organizingandlimitopportunityforsystemsengineeringoftheSoS.

Table G.1 — System of Systems types

Type Characteristic

Virtual Decentralizedmanagementauthority

Noexplicit,centrallyagreed‐uponpurpose

Emergingbehaviorsthatrelyonrelativelyinvisiblemechanismsforcontinuity

Collaborative Constituentsystemsinteractvoluntarilytofulfillagreed‐uponpurposes

Collectivelydecidehowtointeroperate,enforcingandmaintainingstandards

Acknowledged Recognizedobjectives,adesignatedmanagerandresourcesfortheSoS

Constituentsystemsretaintheirindependentownership,management,andresources

Directed IntegratedSoSbuiltandmanagedtofulfillspecificpurposes

Centrallymanagedandevolved

Constituentsystemsmaintainabilitytooperateindependently

Normaloperationalmodeissubordinatedtocentralpurpose





Akey characteristic of SoS isemergence —theunanticipated effects at theSoS level attributed to the complexinteraction dynamics of the constituent systems. However, in SoS, constituent systems are intentionallyconsidered in their combination,soas toobtainandanalyzeoutcomesnotpossible toobtainwith thesystemsalone.Thecomplexityoftheconstituentsystemsandthefacttheyperhapsweredesignedwithoutregardtotheirrole in the SoS, can result in new, unexpected behaviors. Identifying and addressing unanticipated emergentresultsisaparticularchallengeinengineeringSoS.

NOTE Some of the largest software SoS, such as the Internet, are virtual SoS in which the constituent systems areengineered to follow common recommendations and communication protocols. Virtual SoS can exhibit beneficial emergingbehaviorssuchasredundancy,dynamicreconfiguration,collaborationandresilience.

G.3 SE processes applied to systems of systems

G.3.1 General

TheabovecharacteristicsofSoShaveimplicationsontheapplicationofeachofthefourtypesofsystemlifecycleprocesses.

G.3.2 Agreement processes

Agreement processes are crucial for SoS because they establish the modes of developmental and operationalcontrol among the organizations responsible for the SoS and the often independent constituent systems.Constituent systems, which are acquired and managed by different organizations, sometimes hold originalobjectivesthatdonotalignwiththoseoftheSoS.ExceptinthedirectedSoScase,theSoSorganizationcannottaskaconstituentsystemorganizationwithouttheircooperation.InanacknowledgedorcollaborativeSoS,thesetasksare balanced against the tasks of the constituent system as a SOI in its own right. For virtual SoS, agreementprocessesmaybeinformal,orconsideredonlyforanalysispurposes.

Even in agreements among owners of constituent systems, there is still an acquirer and a supplier. A systemownercanbebothanacquirerandasupplierforanotherconstituentsystem.

G.3.3 Organizational project enabling processes

In a typical system‐of‐interest, Organizational Project‐Enabling processes establish the environment in whichprojectsareconducted.Theorganizationestablishestheprocessesandlifecyclemodelstobeusedbyprojects;establishes, redirects,orcancelsprojects;provides resources required, includinghumanand financial; andsetsandmonitorsthequalitymeasuresforsystemsandotherdeliverablesthataredevelopedbyprojectsforinternalandexternalcustomers(6.2).

InanSoS, theownersof theconstituentsystemsusuallyretainresponsibility forengineeringtheirsystemsandthey each have their own Organizational Project‐Enabling processes. Depending on the SoS type, the SoS alsoapplies these Organizational Project‐Enabling processes to the particular considerations of the SoS: planning,analyzing,organizing,andintegratingthecapabilitiesofamixofexistingandnewsystemsintoaSoScapability.

Consequently, in SoS these Organizational Project‐Enabling Processes are implemented at two levels. TheorganizationsresponsiblefortheconstituentsystemsimplementtheseprocessesfortheirSOIindependentoftheSoS. The SoS organization (or in collaborative systems of systems by agreement of the SoS) implement theseprocesses for the SoS for those considerations that apply to the overall SoS. For example, Human ResourceManagement isaddressedbyeachconstituentsystemorganizationfor theengineeringof theirsystem.TheSoSorganization addresses Human Resources Management only for the systems engineering activities that applyacrosstheconstituentsystemstotheSoS.

Aparticularchallenge inSoSengineering is the lackofalignmentamong theconstituent systemOrganizationalProject‐EnablingProcessesandthoseof theSoS.Constituentsystemsprocessesaredesignedtomeettheirownoutcomes and sometimes do not align with those of the SoS. For example, Portfolio Management can be aconstituent system responsibility in caseswhere the constituent system organization has full control over theconstituentsystemandothersystemsandprojectsinitsportfolio,distinctfromtheportfoliomanagementoftheSoSorganization.




G.3.4 Technical management processes

Inatypicalsystem‐of‐interest,TechnicalManagementprocessesareconcernedwithmanagingtheresourcesandassets allocated by organizationmanagement andwith applying them to fulfill the agreements intowhich theorganizationororganizationsenter.Theyrelatetothemanagementofprojects,inparticulartoplanningintermsof cost, timescales and achievements, to the checking of actions for compliance with plans and performancecriteria, and to the identification and selection of corrective actions that recover shortfalls in progress andachievement.Theyareusedtoestablishandperformtechnicalplansfortheproject,manageinformationacrossthe technical team, assess technical progress against the plans for the system products or services, controltechnicaltasksthroughtocompletion,andtoaidinthedecision‐makingprocess(6.3).

TheTechnicalManagement processes are also implemented at the level of the SoS and that of the constituentsystems. Technical Management processes are applied to the particular considerations of SoS engineering—planning, analyzing, organizing, and integrating the capabilities of a mix of existing and new systems into asystem‐of‐systems capability. In parallel, the constituent systems organizations retain responsibility forengineeringtheirsystemsandfortheirownTechnicalManagementprocesses.

The SoS organization addresses the Technical Management processes as they apply across the SoS, while theprocesses are also implemented independently in the constituent system organizations. For configurationmanagement, for instance, constituent systems manage their own configurations while the SoS addressesconfigurationmanagement as it applies to themix of systems in the SoS. Risk ismanaged by the constituentsystemsbasedonassessmentofriskasitappliestotheiroutcomes,whiletheSoSriskmanagementlooksatrisktotheSoS.

Planning and Assessment and Control (6.3) are key to all management practices; a key challenge in SoSengineering is the lack of control by the SoS organization over the processes for the constituent systems(particularlyforacknowledgedandcollaborativeSoS).Drivenbyitsownorganizationalrequirements,eachoftheconstituent systems can be on a development or upgrade schedule that differs from the schedules of otherconstituentsystems.TheSoSorganizationplansanintegratedlifecyclethatrecognizestheindependentchangesintheconstituentsystems,inadditiontotheSoS‐initiatedchangesinalifecyclethattreatstheSoSastheSOI.Thisoften involves the definition of stable intermediate forms that punctuate the SoS evolution with incrementalcapabilitiesaddedamongtheconstituentsystems.

G.3.5 Technical processes

Technicalprocessesareconcernedwithtechnicalactionsthroughoutthelifecycle.Theytransformtheneedsofstakeholders first into a product and then, by applying that product, provide a sustainable service, when andwhereneeded inordertoachievecustomersatisfaction.TheTechnicalprocessesareapplied inordertocreateanduseasystem,whether it is inthe formofamodelor isa finishedproduct,andtheyapplyatany level inahierarchyofsystemstructure(6.4).

As with the other processes when applied to SoS, Technical processes are implemented for both the SoS andconstituent systems; in some cases, the SoS implementation is bymeans of conduct of the constituent systemprocessesratherthanfortheSoSasawhole.

BusinessorMissionAnalysisforanSoSlooksacrossthefullSoSbusinessandmissionenvironment.Tothedegreetheconstituentsystemwasdevelopedtooperateinthatspace,theBusinessorMissionAnalysisforthesystemsofsystemandconstituentsystemswillbelargelyshared.Theobjectiveistodeterminethebestmeanstoprovidethedesiredcapability.

StakeholderNeedsandRequirementsDefinitionfocusesonthetoplevelSoS,butalsoconsidershowthedisparateneedsofthestakeholdersfortheindividualsystemscanleadtoconstraintsontheSoS.

System/Software Requirements Definition for the SoS tends to be defined at the level needed to satisfystakeholderneedsandmissionobjectives,tobetranslatedintorequirementsfortheconstituentsystemswiththeSoSservingas“stakeholder”fornewrequirementsfortheconstituentsystems.

ThearchitecturefortheSoSisaframeworkfororganizingandintegratingthecapabilitiesofamixofexistingandnew systems into a SoS capability, leaving the architectures of the constituent systems to their organizations.BecausetheconstituentsystemsinanSoSusuallypredatetheSoS,SoSArchitectureDefinitionoftenbeginswiththede factoarchitectureof theSoS.Architecturealternativesare thenexamined inorder to framestakeholder





concernsandmeettoplevelSoSrequirements,andtorecognizetheeffectofnewrequirementsfortheconstituentsystemsandaccommodatetheconstituentsystemarchitectureconstraints.

TheDesignDefinitionprocessprovidessufficientdetaileddataandinformationtoenabletheSoSimplementation.ThisinvolvescollaborationwiththeconstituentsystemsorganizationswhowillconducttheirowndesigntradestoidentifytheapproachtoaddressSoSrequirementsastheyapplytotheirsystem.Thesearetheresponsibilityofthe constituent system organizations. Implementation is done by the constituent systems with the SoSorganizationinamonitoringrole.

Integration, Verification, Transition, and Validation are done by the constituent systems for the changes theyimplement to support requirements generated by the SoS. These processes also apply to the SoS when theupgraded constituent systems are integrated into the SoS and performance is verified and validated. Theindependent and asynchronous nature of constituent systems in an SoS poses challenges to effectiveimplementationoftheseprocessesas implementedinatraditionalSOI. Insomecases,theSoS‐levelevaluationscan only be performed in the operational environment, in which case precautionary measures should beconsideredtoavoidadverseSoS‐behavior.

Finally,theOperations,MaintenanceandDisposalprocessestendtobeimplementedbytheconstituentsystems,giventheirmanagementandoperational independence.SoS‐level interactionscanfacilitate interoperabilityandreduceduplicateeffortforthoseprocesses.




Annex H (informative)

Application of Agile

This document is intended to be applied in organizations and software projects using agile approaches andmethods aswell as in those using other formal engineering approaches. Agile development is one of themostwidelyusedapproachesforsoftwaredevelopment(includingsoftwaremaintenance)becauseitisbelievedtobemoreaffordableandtodeliverusableproductsmorequickly.Inlargesoftwaredevelopmenteffortsaswellasinsmallerprojects,manyAgilemethodscanbeusedwithvarious lifecyclemodels,anddifferentmethodscanbeusedatdifferentpointsinthelifecycle.Thisannexpointsoutinterpretationsoftheprocessrequirementsinthisdocumentthatareappropriateforcommonlyusedagiletechniques.

Asdiscussed in5.4.2, the lifecyclemodelsused inagileprojectsareoftenhighly incrementalandevolutionary.However, organizations that use agile methods do apply the life cycle processes identified in this document,includingorganizational,technicalmanagement,andtechnicalprocesses(andmayoperateundertheagreementprocesses).Asstatedin5.4.1,thisdocumentdoesnotprescribeanyparticularsequenceofprocesseswithinthelife cyclemodel.The sequenceof theprocesses isdeterminedbyprojectobjectives andby selectionof the lifecyclemodel.Anagileproject,because ittransformsorcombinesactivitieswhilecreatingor improvingworkingsoftware,mayfinditmoreappropriatetoclaimfullconformancetooutcomes(4.2.1)ratherthanfullconformancetoactivitiesandtasks(4.2.2).

Agiledevelopmentsucceedsinpartbecauseofthenatureofsoftware,whichaccommodatesflexibilityindesignwhile the software is being constructed. In agile practice, software design, implementation (construction), andcontinuousintegrationarefrequentlyperformedconcurrently.Thispracticeiscontrastedwithaformaltop‐downapproach to traceability in which construction cannot begin until design is approved so that the constructedsoftware is traced to a previously approved detailed design. Thus, agile projects take full advantage of theapproach in this document in which processes occur concurrently, as contrasted with sequentially staged(idealizedwaterfall)projects.

Inagileprojects,conceptexploration,development,construction, testing, transition,andretirementofprevioussoftware can be performed concurrently for successive iterations. Agile projects often perform replanningconcurrentlywiththeactivitiesmentionedabove.Insuchapproaches,usingtheendofastageasamanagementcheckpointorcontrolisnotveryuseful.Otheragileapproachesperformreplanningatpointsbetweendesignatediterations(e.g., sprintsorpre‐defined time‐boxedcadences)so thateachof these iterationscanbe treatedasastage.

Agileprojectscanhavecloselytiedcyclesfordevelopmentandsoftwarerelease(e.g.,withdaily,weekly,monthlyscheduled releases) or can separate completion of development iterations from management of scheduledsoftwarereleases,fortheconvenienceofthecustomeroraccordingtoorganizationalstrategy.

Besidesapplyingahighlyiterativeandevolutionarylifecyclemodel,agileorganizationshavespecificpracticesfortheProjectPlanningandProjectAssessmentandControlprocesses.Ratherthanestablishingmajorcontrolpointsatthetransitionbetweenstagesorprocesses,agileprojectsoftenhold less formalcheckpointsorretrospectivereviews at the end of a time‐boxed cycle to agree on improvements for the next cycle. Each iteration includesdesign, development, and test activities (test‐driven development). After a sprint of approximately one to fourweeks or longer, new working software elements are accepted as “done” — completely developed, verified(tested) and validated. Lessons learned andprocess improvements are identified, andworkbegins on anothersprint.Continuinglearning,riskmanagement,andprocessimprovementcanbefacilitatedbyplanningmeetingsthatinitiateeachiterationandretrospectivemeetingsheldattheendofeachiteration.

AgilemethodsemphasizetheStakeholderNeedsandRequirementsDefinitionprocess,facilitatingchangethroughahighdegreeofongoingstakeholderinvolvement.Inagileprojects,keystakeholders,suchastheacquireroruserrepresentatives, are not just approvers of information, measurements, and evaluation reports. Continuousstakeholder involvement is consistentwith this document,which identifies the involvement of stakeholders ineverytechnicalprocessaswellasintheTailoringprocess(AnnexA).Theyarecloselyinvolvedinrequirementsmanagement (6.4.3.3.d) at each iteration, by bringing new requirements and changes in priorities andparticipatingwhenprioritizedrequirementsareselectedfromabacklogofundevelopedstoriesorfunctionsandfurther refined for development. The iterative approach encourages flexibility to add, reprioritize, or defer





requirements which are recognized as being within the general scope of the project. Also, stakeholderinvolvementintheapprovaloftestedsoftwareineachiterationmeansthatvalidationiscontinualthroughouttheproject.

Withtheincrementaldefinitionofevolvingrequirements,theconceptofprojectscopediffersinanagileprojectfrom projects where scope is defined by a predetermined baseline of specified requirements. When an Agileproject requires a defined product, its scope is initially tied to high‐level or fundamental requirements. Moredetailed levels of product definition are expected to emerge as additional knowledge is gained throughoutconstruction. Agile work without pre‐defined products (e.g., level of effort maintenance) may control scopethroughtime‐boxedschedulesorresource‐limitedteams.Thisapproachisparticularlyappropriateforsoftwaremaintenanceefforts,wheretheextentorcontentofcorrectiveoradaptiveworkisnotfullyspecifiedinitially.

Specification of baselines also differs in degree and timing for agile development projects compared to moretraditional development efforts. The baseline of requirements may initially comprise high‐level user stories(“epics”)andkeyperformancemeasurements,includingstandardsforusability.Agileprojectstakefulladvantageofthetaskto“Definebaselinesthroughthelifecycle”(6.3.5.3.b)4).Duringdevelopment,newbaselinesareagreeduponandbuiltatleastdailyunderconfigurationcontrol.Asoftwareelementisgenerallytraceabletoahigh‐levelfunctional requirement and closely traceable to the use case it implements and the test case used to verify itsfunctionalityandperformance.Ratherthanbeingtraceabletoapreviouslyapproved,baselineddesigndocument,anewsoftwareelementmaysimplybetracedtoadesignelementorobjectthatwas,infact,createdduringtheconstructionofthesoftwareandonlythenplacedunderconfigurationcontrol.

Thepreparationofspecifications,designartifacts,andinformationitemsordocumentationduringagileprojectsisoften limited,while softwaredevelopersapply their timeandskills to transformascenarioornarrativeofafunction (“user story”) into a working, testable software element. Rather than preparing elaborate reviewpackages for briefing at infrequent major milestone reviews, the teammeets with stakeholders frequently topresent informal evidence of completing a set of functions and to agree on the content of the next iteration.Documentedinformationitemsfocusonwhatwillbeneededfortransition,operationandmaintenance,suchasoperatorandend‐userdocumentationandbaselinesoftestedandreleasedversionsofsoftwarewithtestplansandtestcases.Projectsreuseorganizationalproceduresforconfigurationandreleasemanagement,verification,and incident and problemmanagement. Where possible, bidirectional traceability is enabled and enforced byintegrated automated systems and procedures for requirements management, architecture and design,configurationmanagement,measurement,andinformationmanagement.

The incremental and iterative nature of Agile development can facilitate efficient technical and managementprocesses and practices to reduce the cost associated with change. In comparison, projects managed at thewaterfallendofthecontinuumseektoreducetotalreworkcostbyminimizingthenumberofchanges,limitingthenumberof controlpoints, andbaseliningdetailed specificationswhichare reviewedand traced throughout theproject.

Agile projects for complex systems attempt tomanage cost by prioritizing themost important capabilities forearlyrealization.Ifanorganizationmanagesthedevelopmentandmaintenanceofitsentireportfolioofsoftwaresystems as a single system, managed by spend rate rather than total spending, then the organization can, inprinciple,manage thatportfolioof systemsas a continuing agiledevelopment, analogous tomanaging a highlyiterative“Kanban”maintenanceeffort.




Annex I (informative)

Process Mapping from ISO/IEC/IEEE 12207:2008

ThisdocumentadoptsaprocessmodelthatisidenticalwithISO/IEC/IEEE15288:2015.Toenabletraceabilityandease transition for users of the previous (2008) edition of ISO/IEC/IEEE 12207, Table I.1 presents a cross‐referenceofprocessesthatshowstheprimaryprocessalignmentsbetweenthetwoversions.TableI.1doesnotimply thatprocessdefinitionsare identicalbetween the2008andthe2017editionsof thisdocument. Insomecases,processesintheearlierversionarenowaddressedthroughactivitiesandtasksordescribedinnotes.Other,moredetailedmappingstoalignprocesspurpose,outcomes,activities,ortasksofthetwoversionsarepossible.OnesuchmappingisdepictedinTableI.2.

Table I.1 — Comparison of processes in ISO/IEC/IEEE 12207:2017 and the previous edition

ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015 process

ISO/IEC 12207:2008 (IEEE Std 12207:2008) process

Subclause Title Subclause Title

6 Softwarelifecycleprocesses6 SystemLifeCycleProcesses

7 SoftwareSpecificProcesses

6.1 Agreementprocesses 6.1 AgreementProcesses

6.1.1 Acquisitionprocess 6.1.1 AcquisitionProcess

6.1.2 Supplyprocess 6.1.2 SupplyProcess

6.2 Organizationalproject‐enablingprocesses 6.2 OrganizationalProject‐EnablingProcesses

6.2.1 Lifecyclemodelmanagementprocess 6.2.1 LifeCycleModelManagementProcess

6.2.2 Infrastructuremanagementprocess 6.2.2 InfrastructureManagementProcess

6.2.3 Portfoliomanagementprocess 6.2.3 ProjectPortfolioManagementProcess

6.2.4 Humanresourcemanagementprocess 6.2.4 HumanResourceManagementProcess

6.2.5 Qualitymanagementprocess 6.2.5 QualityManagementProcess

6.2.6 Knowledgemanagementprocess

6.2.4.2.eHumanResourceManagementProcessKnowledgeManagementactivity

6.2.4.3.4 Knowledgemanagement(activity)

7.3 SoftwareReuseProcesses7.3.1 DomainEngineeringProcess7.3.2 ReuseAssetManagementProcess7.3.3 ReuseProgramManagementProcess

6.3 Technicalmanagementprocesses 6.3 ProjectProcesses

7.2 SoftwareSupportProcesses

6.3.1 Projectplanningprocess 6.3.1 ProjectPlanningProcess

6.3.2 Projectassessmentandcontrolprocess 6.3.2 ProjectAssessmentandControlProcess

7.2.6 SoftwareReviewProcess

6.3.3 Decisionmanagementprocess 6.3.3 DecisionManagementProcess

6.3.4 Riskmanagementprocess 6.3.4 RiskManagementProcess

6.3.5 Configurationmanagementprocess 6.3.5 ConfigurationManagementProcess

7.2.2 SoftwareConfigurationManagementProcess





ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015 process

ISO/IEC 12207:2008 (IEEE Std 12207:2008) process

Subclause Title Subclause Title

6.3.6 Informationmanagementprocess 6.3.6 InformationManagementProcess

7.2.1 SoftwareDocumentationManagementProcess

6.3.7 Measurementprocess 6.3.7 MeasurementProcess

6.3.8 Qualityassuranceprocess 7.2.3 SoftwareQualityAssuranceProcess

7.2.7 SoftwareAuditProcess

7.2.8 SoftwareProblemResolutionProcess

6.4 Technicalprocesses 6.4 TechnicalProcesses

6.4.1 Businessormissionanalysisprocess NA,[butrelatedtosomeoutcomesof6.4.1Stakeholderneedsandrequirementsdefinitionprocess]

6.4.2Stakeholderneedsandrequirementsdefinitionprocess

6.4.1 StakeholderRequirementsDefinitionProcess

6.4.3System/Softwarerequirementsdefinitionprocess

6.4.2 SystemRequirementsAnalysisProcess

7.1.2 SoftwareRequirementsAnalysisProcess

6.4.4 Architecturedefinitionprocess 6.4.3 SystemArchitecturalDesignProcess

7.1.3 SoftwareArchitecturalDesignProcess

6.4.5 Designdefinitionprocess 6.4.3 SystemArchitecturalDesignProcess

7.1.4 SoftwareDetailedDesignProcess

6.4.6 Systemanalysisprocess NA,[butanalysisactivitiesarefoundinmanyprocesses,especiallyDecisionManagement]

6.4.7 Implementationprocess 6.4.4 ImplementationProcess

7.1 SoftwareImplementationProcesses

7.1.1 SoftwareImplementationProcess

7.1.5 SoftwareConstructionProcess

6.4.8 Integrationprocess 6.4.5 SystemIntegrationProcess

7.1.6 SoftwareIntegrationProcess

6.4.9 Verificationprocess 6.4.6 SystemQualificationTestingProcess

7.1.7 SoftwareQualificationTestingProcess

7.2.4 SoftwareVerificationProcess

6.4.10 Transitionprocess 6.2.4 HumanResourceManagementProcess

6.4.7 SoftwareInstallationProcess

6.4.11 Validationprocess 6.4.8 SoftwareAcceptanceSupportProcess

7.2.5 SoftwareValidationProcess

6.4.12 Operationprocess 6.4.9 SoftwareOperationProcess

6.4.13 Maintenanceprocess 6.4.10 SoftwareMaintenanceProcess

6.4.14 Disposalprocess 6.4.11 SoftwareDisposalProcess

AnnexA Tailoringprocess AnnexA TailoringProcess

Table I.2 provides amapping of outcomes of processes in this documentwith outcomes of selected software‐specific implementation, reuse and support processes in ISO/IEC/IEEE 12207:2008. Users of 12207:2008 canidentify outcomes of this document related to previous versions of lower level software‐specific processes,activities or tasks for implementation, support or reuse of software elements in the software system.Table I.2doesnotimplythatprocessoutcomesareidenticalbetweenthe2008andthe2017editionsofthisdocument.Notallprocessoutcomesofthisdocumentareexplicitlyidentifiedinthepreviousedition.




Table I.2 — Comparison of process outcomes in ISO/IEC/IEEE 12207:2017 and software-related outcomes in the previous edition

ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015 process outcome ISO/IEC 12207:2008 (IEEE Std 12207-2008) process outcome

Subclause Outcome Subclause Outcome

6.2.6 Knowledge Management process 7.3.1 Domain Engineering process

6.2.6.2.aAtaxonomyfortheapplicationofknowledgeassetsisidentified.

7.3.1.2.a,

7.3.1.2.b,

7.3.1.2.c,

7.3.1.2.d

Therepresentationformsforthedomainmodelsandthedomainarchitecturesareselected.

Theboundariesofthedomainanditsrelationshipstootherdomainsareestablished.

Adomainmodelthatcapturestheessentialcommonanddifferentfeatures,capabilities,concepts,andfunctionsinthedomainisdeveloped.

Adomainarchitecturedescribingthefamilyofsystemswithinthedomain,includingtheircommonalitiesandvariabilities,isdeveloped.

6.2.6.2.b Theorganizationalknowledge,skills,andknowledgeassetsaredevelopedoracquired.

7.3.1.2.e,

7.3.1.2.f

Assetsbelongingtothedomainarespecified.

Assetsbelongingtothedomainareacquiredordevelopedandmaintainedthroughouttheirlifecycles.

6.2.6.2.cTheorganizationalknowledge,skills,andknowledgeassetsareavailable.

7.3.1.2.gThedomainmodelsandarchitecturesaremaintainedthroughouttheirlifecycles.

7.3.2 Reuse Asset Management process


7.3.2.2.a,

7.3.2.2.b

Anassetmanagementstrategyisdocumented.

Anassetclassificationschemeisestablished.


7.3.2.2.cCriteriaforassetacceptance,certificationandretirementaredefined.


7.3.2.2.d,

7.3.2.2.f,

7.3.2.2.g

Anassetstorageandretrievalmechanismisoperated.

Changestotheassetsarecontrolled.

Usersofassetsarenotifiedofproblemsdetected,modificationsmade,newversionscreatedanddeletionofassetsfromthestorageandretrievalmechanism.

6.2.6.2.d Knowledgemanagementusagedataisgatheredandanalyzed.

7.3.2.2.e Theuseofassetsisrecorded.

7.3.3 Reuse Program Management process


7.3.3.2.a,

7.3.3.2.b

Theorganization’sreusestrategy,includingitspurpose,scope,goalsandobjectives,isdefined.

Thedomainsforpotentialreuseopportunitiesareidentified.





ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015 process outcome

ISO/IEC 12207:2008 (IEEE Std 12207-2008) process outcome



7.3.3.2.c,

7.3.3.2.d,

7.3.3.2.e

Theorganization’ssystematicreusecapabilityisassessed.

Thereusepotentialofeachdomainisassessed.

Reuseproposalsareevaluatedtoensurethereuseproductissuitablefortheproposedapplication.


7.3.3.2.fThereusestrategyisimplementedintheorganization.

6.2.6.2.d Knowledgemanagementusagedataisgatheredandanalyzed.

7.3.3.2.g,

7.3.3.2h

Feedback,communication,andnotificationmechanismsthatoperatebetweenaffectedpartiesareestablished.

Thereuseprogramismonitoredandevaluated.

6.3.1 Project Planning process 7.2.6 Software Review process

6.3.1.2.a Objectivesandplansaredefined. 7.2.6.2.aManagementandtechnicalreviewsareheldbasedontheneedsoftheproject.

6.3.1.2.bRoles,responsibilities,accountabilities,andauthoritiesaredefined.

7.2.6.2.aManagementandtechnicalreviewsareheldbasedontheneedsoftheproject.

6.3.1.2.cResourcesandservicesnecessarytoachievetheobjectivesareformallyrequestedandcommitted.


6.3.1.2.dPlansfortheexecutionoftheprojectareactivated.


6.3.2Project Assessment and Control process

7.2.6 Software Review process

6.3.2.2.aPerformancemeasuresorassessmentresultsareavailable.

7.2.6.2.c,

7.2.6.2.e

Review results are made known to allaffectedparties.

Risksandproblemsareidentifiedandrecorded.

6.3.2.2.bAdequacyofroles,responsibilities,accountabilities,andauthoritiesisassessed.

7.2.6.2a

7.2.6.2.b

Managementandtechnicalreviewsareheldbasedontheneedsoftheproject.

Thestatusandproductsofanactivityofaprocessareevaluatedthroughreviewactivities.

6.3.2.2.c Adequacyofresourcesisassessed.7.2.6.2.a

7.2.6.2.b



6.3.2.2.dTechnicalprogressreviewsareperformed.


6.3.2.2.eDeviationsinprojectperformancefromplansareinvestigatedandanalyzed.

7.2.6.2.bThestatusandproductsofanactivityofaprocessareevaluatedthroughreviewactivities.

6.3.2.2.fAffectedstakeholdersareinformedofprojectstatus.

7.2.6.2.cReviewresultsaremadeknowntoallaffectedparties.

6.3.2.2.gCorrectiveactionisdefinedanddirected,whenprojectachievementisnotmeetingtargets.

7.2.6.2.dActionitemsresultingfromreviewsaretrackedtoclosure.

6.3.4 Risk Management process 7.2.6 Software Review process







6.3.4.2.a Risksareidentified. 7.2.6.2.eRisksandproblemsareidentifiedandrecorded.

6.3.5Configuration Management process

7.2.2 Software Configuration Management process

6.3.5.2.aItemsrequiringconfigurationmanagementareidentifiedandmanaged.

7.2.2.2.a,

7.2.2.2.b

Asoftwareconfigurationmanagementstrategyisdeveloped.

Itemsgeneratedbytheprocessorprojectareidentified,definedandbaselined.

6.3.5.2.b Configurationbaselinesareestablished.

7.2.2.2.b Itemsgeneratedbytheprocessorprojectareidentified,definedandbaselined.

6.3.5.2.cChangestoitemsunderconfigurationmanagementarecontrolled.

7.2.2.2.c,

7.2.2.2.d

Modifications and releases of the items arecontrolled.

Modificationsandreleasesaremadeavailabletoaffectedparties.

6.3.5.2.dConfigurationstatusinformationisavailable.

7.2.2.2.eThestatusoftheitemsandmodificationsarerecordedandreported.

6.3.5.2.eRequiredconfigurationauditsarecompleted.

7.2.2.2.fThecompletenessandconsistencyoftheitemsisensured.

6.3.5.2.fSystemreleasesanddeliveriesarecontrolledandapproved.

7.2.2.2.c,

7.2.2.2.d,

7.2.2.2.g

Modificationsandreleasesoftheitemsarecontrolled.

Modificationsandreleasesaremadeavailabletoaffectedparties.

Thestorage,handlinganddeliveryoftheitemsarecontrolled.

6.3.6 Information Management process 7.2.1 Software Documentation Management process

6.3.6.2.aInformationtobemanagedisidentified.

7.2.1.2.a,

7.2.1.2.c

Astrategyidentifyingthedocumentationtobeproducedduringthelifecycleofthesoftwareproductorserviceisdeveloped.

Documentationtobeproducedbytheprocessorprojectisidentified.

6.3.6.2.bInformationrepresentationsaredefined.

7.2.1.2.b,

7.2.1.2.d

Thestandardstobeappliedforthedevelopmentofthesoftwaredocumentationareidentified.

Thecontentandpurposeofalldocumentationisspecified,reviewedandapproved.

6.3.6.2.cInformationisobtained,developed,transformed,stored,validated,presented,anddisposedof.

7.2.1.2.d,

7.2.1.2.e,

7.2.1.2.f

Thecontentandpurposeofalldocumentationisspecified,reviewedandapproved.

Documentationisdevelopedandmadeavailableinaccordancewithidentifiedstandards.

Documentationismaintainedinaccordancewithdefinedcriteria.

6.3.6.2.dThestatusofinformationisidentified.

7.2.1.2.fDocumentationismaintainedinaccordancewithdefinedcriteria.

6.3.6.2.eInformationisavailabletodesignatedstakeholders.

7.2.1.2.eDocumentationisdevelopedandmadeavailableinaccordancewithidentifiedstandards.

6.3.8 Quality Assurance process 7.2.3 Software Quality Assurance process








6.3.8.2.aProjectqualityassuranceproceduresaredefinedandimplemented.

7.2.3.2.a,

7.2.3.2.d

Astrategyforconductingsoftwarequalityassuranceisdeveloped.

Adherenceofsoftwareproducts,processesandactivitiestotheapplicablestandards,proceduresandrequirementsisverified.

6.3.8.2.bCriteriaandmethodsforqualityassuranceevaluationsaredefined.

7.2.3.2.aAstrategyforconductingsoftwarequalityassuranceisdeveloped.

6.3.8.2.c

Evaluationsoftheproject’sproducts,services,andprocessesareperformed,consistentwithqualitymanagementpolicies,procedures,andrequirements.

7.2.3.2.dAdherenceofsoftwareproducts,processesandactivitiestotheapplicablestandards,proceduresandrequirementsisverified.

6.3.8.2.dResultsofevaluationsareprovidedtorelevantstakeholders.

7.2.3.2.bEvidenceofsoftwarequalityassuranceisproducedandmaintained.

6.3.8.2.f Prioritizedproblemsaretreated. 7.2.3.2.cProblemsand/ornon‐conformancewithrequirementsareidentifiedandrecorded.

7.2.6 Software Review process


7.2.6.2aManagementandtechnicalreviewsareheldbasedontheneedsoftheproject.


7.2.6.2aManagementandtechnicalreviewsareheldbasedontheneedsoftheproject.

6.3.8.2.c


7.2.6.2.a,

7.2.6.2.b




7.2.6.2.cReviewresultsaremadeknowntoallaffectedparties.

6.3.8.2.f Prioritizedproblemsaretreated.7.2.6.2.d,

7.2.6.2.e

Actionitemsresultingfromreviewsaretrackedtoclosure.

Risksandproblemsareidentifiedandrecorded.

7.2.7 Software Audit process


7.2.7.2.aAnauditstrategyisdevelopedandimplemented.


7.2.7.2.aAnauditstrategyisdevelopedandimplemented.

6.3.8.2.c


7.2.7.2.b,

7.2.7.2.c

Complianceofselectedsoftwareworkproductsand/orservicesorprocesseswithrequirements,plansandagreementisdeterminedaccordingtotheauditstrategy.

Auditsareconductedbyanappropriateindependentparty.


7.2.7.2.d

Problemsdetectedduringanauditareidentifiedandcommunicatedtothoseresponsibleforcorrectiveaction,andresolution.

7.2.8 Software Problem Resolution process


7.2.8.2.aAproblemmanagementstrategyisdeveloped.








7.2.8.2.aAproblemmanagementstrategyisdeveloped.


7.2.8.2.fThestatusofallproblemsreportedisknown.

6.3.8.2.e Incidentsareresolved.

6.3.8.2.f Prioritizedproblemsaretreated.

7.2.8.2.b,

7.2.8.2.c,

7.2.8.2.d,

7.2.8.2.e

Problemsarerecorded,identifiedandclassified.

Problemsareanalyzedandassessedtoidentifyacceptablesolution(s).

Problemresolutionisimplemented.

Problemsaretrackedtoclosure.

6.4.3 System/Software Requirements Definition process

7.1.2 Software Requirements Analysis process

6.4.3.2.a

Thesystemorelementdescription,includinginterfaces,functionsandboundaries,forasystemsolutionisdefined.

7.1.2.2.aTherequirementsallocatedtothesoftwareelementsofthesystemandtheirinterfacesaredefined.

6.4.3.2.b

System/softwarerequirements(functional,performance,process,non‐functional,andinterface)anddesignconstraintsaredefined.

7.1.2.2.a,

7.1.2.2.e,

7.1.2.2.f,

7.1.2.2.h

Therequirementsallocatedtothesoftwareelementsofthesystemandtheirinterfacesaredefined.

Prioritizationforimplementingthesoftwarerequirementsisdefined.

Thesoftwarerequirementsareapprovedandupdatedasneeded.

Thesoftwarerequirementsarebaselinedandcommunicatedtoallaffectedparties.

6.4.3.2.cCriticalperformancemeasuresaredefined.

7.1.2.2.cTheimpactofsoftwarerequirementsontheoperatingenvironmentisunderstood.

6.4.3.2.dThesystem/softwarerequirementsareanalyzed.

7.1.2.2.b,

7.1.2.2.c,

7.1.2.2.g

Softwarerequirementsareanalyzedforcorrectnessandtestability.

Theimpactofsoftwarerequirementsontheoperatingenvironmentisunderstood.

Changestothesoftwarerequirementsareevaluatedforcost,scheduleandtechnicalimpact.

6.4.3.2.e

Anyenablingsystemsorservicesneededforsystem/softwarerequirementsdefinitionareavailable.

6.4.3.2.fTraceabilityofsystem/softwarerequirementstostakeholderrequirementsisdeveloped.

7.1.2.2.dConsistencyandtraceabilityareestablishedbetweenthesoftwarerequirementsandsystemrequirements.

6.4.4 Architecture Definition process 7.1.3 Software Architectural Design process

6.4.4.2.aIdentifiedstakeholderconcernsareaddressedbythearchitecture.

7.1.3.2.a,

7.1.3.2.c

Asoftwarearchitecturaldesignisdevelopedandbaselinedthatdescribesthesoftwareitemsthatwillimplementthesoftwarerequirements.

Consistencyandtraceabilityareestablishedbetweensoftwarerequirementsandsoftwaredesign.








6.4.4.2.bArchitectureviewpointsaredeveloped. 7.1.3.2.a


6.4.4.2.cContext,boundaries,andexternalinterfacesofthesystemaredefined.

7.1.3.2.bInternalandexternalinterfacesofeachsoftwareitemaredefined.

6.4.4.2.dArchitectureviewsandmodelsofthesystemaredeveloped.

7.1.3.2.a


6.4.4.2.e

Concepts,properties,characteristics,behaviors,functions,orconstraintsthataresignificanttoarchitecturedecisionsofthesystemareallocatedtoarchitecturalentities.

7.1.3.2.a


6.4.4.2.fSystemelementsandtheirinterfacesareidentified.

7.1.3.2.a,

7.1.3.2.b

Asoftwarearchitecturaldesignisdevelopedand baselined that describes the softwareitems that will implement the softwarerequirements.

Internalandexternalinterfacesofeachsoftwareitemaredefined.

6.4.4.2.gArchitecturecandidatesareassessed.

7.1.3.2.a


6.4.4.2.hAnarchitecturalbasisforprocessesthroughoutthelifecycleisachieved.

7.1.3.2.a


6.4.4.2.iAlignmentofthearchitecturewithrequirementsanddesigncharacteristicsisachieved.

7.1.3.2.a,

7.1.3.2.c


Consistencyandtraceabilityareestablishedbetweensoftwarerequirementsandsoftwaredesign.

6.4.4.2.jAnyenablingsystemsorservicesneededforarchitecturedefinitionareavailable.

6.4.4.2.k

Traceabilityofarchitectureelementstostakeholderandsystem/softwarerequirementsisdeveloped.

7.1.3.2.cConsistencyandtraceabilityareestablishedbetweensoftwarerequirementsandsoftwaredesign.

7.3.1 Domain Engineering process

6.4.4.2.cContext,boundaries,andexternalinterfacesofthesystemaredefined.

7.3.1.2.bTheboundariesofthedomainanditsrelationshipstootherdomainsareestablished.

6.4.4.2.d Architectureviewsandmodelsofthesystemaredeveloped.

7.3.1.2.a,

7.3.1.2.c

Therepresentationformsforthedomainmodelsandthedomainarchitecturesareselected.

Adomainmodelthatcapturestheessentialcommonanddifferentfeatures,capabilities,concepts,andfunctionsinthedomainisdeveloped.







6.4.4.2.hAnarchitecturalbasisforprocessesthroughoutthelifecycleisachieved. 7.3.1.2.d

Adomainarchitecturedescribingthefamilyofsystemswithinthedomain,includingtheircommonalitiesandvariabilities,isdeveloped.

6.4.5 Design Definition process 7.1.4 7.1.4 Software Detailed Design process

6.4.5.2.aDesigncharacteristicsofeachsystemelementaredefined.

7.1.4.2.aAdetaileddesignofeachsoftwarecomponent,describingthesoftwareunitstobebuilt,isdeveloped.

6.4.5.2.bSystem/softwarerequirementsareallocatedtosystemelements.

7.1.4.2.a,

7.1.4.2.c

Adetaileddesignofeachsoftwarecomponent,describingthesoftwareunitstobebuilt,isdeveloped.

Consistencyandtraceabilityareestablishedbetweenthedetaileddesignandtherequirementsandarchitecturaldesign.

6.4.5.2.cDesignenablersnecessaryfordesigndefinitionareselectedordefined.


6.4.5.2.dInterfacesbetweensystemelementscomposingthesystemaredefinedorrefined.

7.1.4.2.bExternalinterfacesofeachsoftwareunitaredefined.

6.4.5.2.eDesignalternativesforsystemelementsareassessed.


6.4.5.2.f Designartifactsaredeveloped. 7.1.4.2.aAdetaileddesignofeachsoftwarecomponent,describingthesoftwareunitstobebuilt,isdeveloped.

6.4.5.2.gAnyenablingsystemsorservicesneededfordesigndefinitionareavailable.

6.4.5.2.h

Traceabilityofthedesigncharacteristicstothearchitecturalentitiesofthesystemarchitectureisestablished.

7.1.4.2.cConsistencyandtraceabilityareestablishedbetweenthedetaileddesignandtherequirementsandarchitecturaldesign.

6.4.7 Implementation process 7.1.1 Software Implementation Process

6.4.7.2.a

Implementationconstraintsthatinfluencetherequirements,architecture,ordesignareidentified.

7.1.1.2.a,

7.1.1.2.b

Animplementationstrategyisdefined.

Implementationtechnologyconstraintsonthedesignareidentified.

6.4.7.2.b Asystemelementisrealized. 7.1.1.2.c Asoftwareitemisrealized.

6.4.7.2.cAsystemelementispackagedorstored.

7.1.1.2.dAsoftwareitemispackagedandstoredinaccordancewithanagreementforitssupply.

6.4.7.2.dAnyenablingsystemsorservicesneededforimplementationareavailable.

7.1.5 Software Construction Process

6.4.7.2.a

Implementationconstraintsthatinfluencetherequirements,architecture,ordesignareidentified.

7.1.5.2.a,

7.1.5.2.d

Verificationcriteriaaredefinedforallsoftwareunitsagainsttheirrequirements.

Verificationofthesoftwareunitsagainsttherequirementsandthedesignisaccomplished.








6.4.7.2.b Asystemelementisrealized.7.1.5.2.b,

7.1.5.2.d

Softwareunitsdefinedbythedesignareproduced.

Verificationofthesoftwareunitsagainsttherequirementsandthedesignisaccomplished.

6.4.7.2.e Traceabilityisestablished. 7.1.5.2.cConsistencyandtraceabilityareestablishedbetweensoftwareunitsandrequirementsanddesign.

6.4.8 Integration process 7.1.6 Software Integration Process

6.4.8.2.a

Integrationconstraintsthatinfluencesystemrequirements,architecture,ordesign,includinginterfaces,areidentified.

7.1.6.2.a

Anintegrationstrategyisdevelopedforsoftwareunitsconsistentwiththesoftwaredesignandtheprioritizedsoftwarerequirements.

6.4.8.2.b

Approachandcheckpointsforthecorrectoperationoftheassembledinterfacesandsystemfunctionsaredefined.

7.1.6.2.a,

7.1.6.2.c

Anintegrationstrategyisdevelopedforsoftwareunitsconsistentwiththesoftwaredesignandtheprioritizedsoftwarerequirements.

Softwareitemsareverifiedusingthedefinedcriteria.

6.4.8.2.cAnyenablingsystemsorservicesneededforintegrationareavailable.

6.4.8.2.d Asystemcomposedofimplementedsystemelementsisintegrated.

7.1.6.2.d Softwareitemsdefinedbytheintegrationstrategyareproduced.

6.4.8.2.eTheinterfacesbetweentheimplementedsystemelementsthatcomposethesystemarechecked.

7.1.6.2.cSoftwareitemsareverifiedusingthedefinedcriteria.

6.4.8.2.fTheinterfacesbetweenthesystemandtheexternalenvironmentarechecked.


6.4.8.2.g Integrationresultsandanomaliesareidentified.

7.1.6.2.c,

7.1.6.2.e

Softwareitemsareverifiedusingthedefinedcriteria.

Resultsofintegrationtestingarerecorded.

6.4.8.2.h Traceabilityoftheintegratedsystemelementsisestablished.

7.1.6.2.fConsistencyandtraceabilityareestablishedbetweensoftwaredesignandsoftwareitems.

6.4.9 Verification process 7.1.5 Software Construction Process

6.4.9.2.a

Constraintsofverificationthatinfluencetherequirements,architecture,ordesignareidentified.

7.1.5.2.aVerificationcriteriaaredefinedforallsoftwareunitsagainsttheirrequirements.

7.1.6 Software Integration Process

6.4.9.2.a


7.1.6.2.b,

7.1.6.2.g

Verificationcriteriaforsoftwareitemsaredevelopedthatensurecompliancewiththesoftwarerequirementsallocatedtotheitems

Aregressionstrategyisdevelopedandappliedforre‐verifyingsoftwareitemswhenachangeinsoftwareunits(includingassociatedrequirements,designandcode)occur.

6.4.9.2.c Thesystemorsystemelementisverified.


7.1.7 Software Qualification Testing process







6.4.9.2.a


7.1.7.2.a,

7.1.7.2.d

Criteriafortheintegratedsoftwarearedevelopedthatdemonstratecompliancewiththesoftwarerequirements.

Aregressionstrategyisdevelopedandappliedforre‐testingtheintegratedsoftwarewhenachangeinsoftwareitemsismade.

6.4.9.2.c Thesystemorsystemelementisverified.

7.1.7.2.b,

7.1.7.2.d

Integratedsoftwareisverifiedusingthedefinedcriteria.

Aregressionstrategyisdevelopedandappliedforre‐testingtheintegratedsoftwarewhenachangeinsoftwareitemsismade.

6.4.9.2.eObjectiveevidencethattherealizedsystemfulfilstherequirements,architectureanddesignisprovided.

7.1.7.2.c Testresultsarerecorded.

6.4.9.2.fVerificationresultsandanomaliesareidentified.

7.1.7.2.c Testresultsarerecorded.

6.4.9.2.gTraceabilityoftheverifiedsystemelementsisestablished.

7.1.7.2.aCriteriafortheintegratedsoftwarearedevelopedthatdemonstratecompliancewiththesoftwarerequirements.

7.2.3 Software Quality Assurance process

6.4.9.2.cThesystemorsystemelementisverified.

7.2.3.2.dAdherenceofsoftwareproducts,processesandactivitiestotheapplicablestandards,proceduresandrequirementsisverified.

7.2.4 Software Verification Process

6.4.9.2.a


7.2.4.2.a,

7.2.4.2.b

Asoftwareverificationstrategyisdevelopedandimplemented.

Criteriaforverificationofallrequiredsoftwareworkproductsareidentified.

6.4.9.2.bAnyenablingsystemsorservicesneededforverificationareavailable.

7.2.4.2.aAsoftwareverificationstrategyisdevelopedandimplemented.

6.4.9.2.cThesystemorsystemelementisverified.

7.2.4.2.cRequiredverificationactivitiesareperformed.

6.4.9.2.dDataprovidinginformationforcorrectiveactionsisreported.

7.2.4.2.d Defectsareidentifiedandrecorded.

6.4.9.2.eObjectiveevidencethattherealizedsystemfulfilstherequirements,architectureanddesignisprovided.

7.2.4.2.eResultsoftheverificationactivitiesaremadeavailabletothecustomerandotherinvolvedparties.

6.4.9.2.fVerificationresultsandanomaliesareidentified.

7.2.4.2.d Defectsareidentifiedandrecorded.

6.4.9.2.gTraceabilityoftheverifiedsystemelementsisestablished.

7.2.4.2.b,

7.2.4.2.c

Criteriaforverificationofallrequiredsoftwareworkproductsareidentified.

Requiredverificationactivitiesareperformed.

6.4.10 Transition process 6.2.4 Human Resource Management Process

6.4.10.2.d

Operators,usersandotherstakeholdersnecessarytothesystemutilizationandsupportaretrained.

6.2.4.2.cSkillsofpersonnelaredeveloped,maintainedorenhanced.








6.4.7 Software Installation Process

6.4.10.2.a

Transitionconstraintsthatinfluencesystem/softwarerequirements,architecture,ordesignareidentified.

6.4.7.2.a,

6.4.7.2.b

Asoftwareinstallationstrategyisdeveloped.

Criteriaforsoftwareinstallationaredevelopedthatdemonstratecompliancewiththesoftwareinstallationrequirements.

6.4.10.2.bAnyenablingsystemsorservicesneededfortransitionareavailable.

6.4.7.2.dReadinessofthesoftwareproductforuseinitsintendedenvironmentisassured.

6.4.10.2.c Thesiteisprepared. 6.4.7.2.dReadinessofthesoftwareproductforuseinitsintendedenvironmentisassured.

6.4.10.2.dThesystem,asinstalledinitsoperationallocation,iscapableofdeliveringitsspecifiedfunctions.


6.4.10.2.e

Operators,usersandotherstakeholdersnecessarytothesystemutilizationandsupportaretrained


6.4.10.2.fTransitionresultsandanomaliesareidentified.


6.4.10.2.gTheinstalledsystemisactivatedandreadyforoperation.

6.4.7.2.c,

6.4.7.2.d

Thesoftwareproductisinstalledinthetargetenvironment.

Readinessofthesoftwareproductforuseinitsintendedenvironmentisassured.

6.4.10.2.hTraceabilityofthetransitionedelementsisestablished.

6.4.7.2.bCriteriaforsoftwareinstallationaredevelopedthatdemonstratecompliancewiththesoftwareinstallationrequirements.

6.4.8 Software Acceptance Support process

6.4.10.2.dThesystem,asinstalledinitsoperationallocation,iscapableofdeliveringitsspecifiedfunctions.

6.4.8.2.a,

6.4.8.2.b

Theproductiscompletedanddeliveredtotheacquirer.

Acquireracceptancetestsandreviewsaresupported.

6.4.10.2.e

Operators,usersandotherstakeholdersnecessarytothesystemutilizationandsupportaretrained

6.4.8.2.c Theproductisputintooperationinthecustomers’environment.

6.4.10.2.fTransitionresultsandanomaliesareidentified.

6.4.8.2.dProblemsdetectedduringacceptanceareidentifiedandcommunicatedtothoseresponsibleforresolution.

6.4.10.2.gTheinstalledsystemisactivatedandreadyforoperation.

6.4.8.2.cTheproductisputintooperationinthecustomers’environment.

6.4.11 Validation process 6.4.8 Software Acceptance Support Process

6.4.11.2.bTheavailabilityofservicesrequiredbystakeholdersisconfirmed.

6.4.8.2.a,6.4.8.2.b,6.4.8.2.c

Theproductiscompletedanddeliveredtotheacquirer.

Acquireracceptancetestsandreviewsaresupported.

Theproductisputintooperationinthecustomers’environment.

6.4.11.2.dThesystemorsystemelementisvalidated.

6.4.8.2.b Acquireracceptancetestsandreviewsaresupported.







6.4.11.2.fValidationresultsandanomaliesareidentified.

6.4.8.2.d Problemsdetectedduringacceptanceareidentifiedandcommunicatedtothoseresponsibleforresolution.

6.4.9 Software Operation Process


6.4.9.2.cThesoftwareistestedanddeterminedtooperateinitsintendedenvironment.

7.2.5 Software Validation Process

6.4.11.2.aValidationcriteriaforstakeholderrequirementsaredefined.

7.2.5.2.a,

7.2.5.2.b

Avalidationstrategyisdevelopedandimplemented.

Criteriaforvalidationofallrequiredworkproductsareidentified.

6.4.11.2.bTheavailabilityofservicesrequiredbystakeholdersisconfirmed.

7.2.5.2.cRequiredvalidationactivitiesareperformed.

6.4.11.2.c

Constraintsofvalidationthatinfluencetherequirements,architecture,ordesignareidentified.

7.2.5.2.a,

7.2.5.2.b

Avalidationstrategyisdevelopedandimplemented.

Criteriaforvalidationofallrequiredworkproductsareidentified.


7.2.5.2.cRequiredvalidationactivitiesareperformed.

6.4.11.2.eAnyenablingsystemsorservicesneededforvalidationareavailable.

7.2.5.2.aAvalidationstrategyisdevelopedandimplemented.

6.4.11.2.fValidationresultsandanomaliesareidentified.

7.2.5.2.d Problemsareidentifiedandrecorded.

6.4.11.2.gObjectiveevidencethattherealizedsystemorsystemelementsatisfiesstakeholderneedsisprovided.

7.2.5.2.e,

7.2.5.2.f

Evidenceisprovidedthatthesoftwareworkproductsasdevelopedaresuitablefortheirintendeduse.

Resultsofthevalidationactivitiesaremadeavailabletothecustomerandotherinvolvedparties.

6.4.11.2.hTraceabilityofthevalidatedsystemelementsisestablished.

7.2.5.2.bCriteriaforvalidationofallrequiredworkproductsareidentified.

6.4.12 Operation process 6.4.8 Software Acceptance Support Process

6.4.12.2.dSystemproductservicesthatmeetstakeholderrequirementsaredelivered.

6.4.8.2.c Theproductisputintooperationinthecustomers’environment.

6.4.9 Software Operation Process

6.4.12.2.a

Operationconstraintsthatinfluencesystem/softwarerequirements,architecture,ordesignareidentified.

6.4.9.2.a Anoperationstrategyisdefined.

6.4.12.2.bAnyenablingsystems,services,andmaterialneededforoperationareavailable.

6.4.9.2.bConditionsforcorrectoperationofthesoftwareinitsintendedenvironmentareidentifiedandevaluated.

6.4.12.2.eSystemproductperformanceduringoperationismonitored.

6.4.9.2.bConditionsforcorrectoperationofthesoftwareinitsintendedenvironmentareidentifiedandevaluated.

6.4.12.2.dSystemproductservicesthatmeetstakeholderrequirementsaredelivered.

6.4.9.2.dThesoftwareisoperatedinitsintendedenvironment.

6.4.12.2.f Supporttothecustomerisprovided. 6.4.9.2.eAssistanceandconsultationisprovidedtothecustomersofthesoftwareproductinaccordancewiththeagreement.








6.4.13 Maintenance process 6.4.10 Software Maintenance process

6.4.13.2.a

Maintenanceconstraintsthatinfluencesystemrequirements,architecture,ordesignareidentified.

6.4.10.2.a,

6.4.10.2.b

Amaintenancestrategyisdevelopedtomanagemodificationandmigrationofproductsaccordingtothereleasestrategy.

Theimpactofchangestotheexistingsystemonorganization,operationsorinterfacesareidentified.

6.4.13.2.bAnyenablingsystemsorservicesneededformaintenanceareavailable.

6.4.10.2.d,6.4.10.2.e

Modifiedproductsaredevelopedwithassociatedteststhatdemonstratethatrequirementsarenotcompromised.

Productupgradesaremigratedtothecustomer’senvironment.

6.4.13.2.cReplacement,repaired,orrevisedsystemelementsaremadeavailable.

6.4.10.c,6.4.10.d,6.4.10.e,6.4.10.f

Affectedsystemandsoftwaredocumentationisupdatedasneeded.

Modifiedproductsaredevelopedwithassociatedteststhatdemonstratethatrequirementsarenotcompromised.

Productupgradesaremigratedtothecustomer’senvironment.

Thesystemsoftwaremodificationiscommunicatedtoallaffectedparties.

6.4.13.2.dTheneedforchangestoaddresscorrective,perfective,oradaptivemaintenanceisreported.

6.4.10.2.bTheimpactofchangestotheexistingsystemonorganization,operationsorinterfacesareidentified.

6.4.13.2.eFailureandlifetimedata,includingassociatedcosts,isdetermined.

6.4.10.2.bTheimpactofchangestotheexistingsystemonorganization,operationsorinterfacesareidentified.

7.3.1 Domain Engineering Process

6.4.13.2.cReplacement,repaired,orrevisedsystemelementsaremadeavailable.

7.3.1.2.fAssetsbelongingtothedomainareacquiredordevelopedandmaintainedthroughouttheirlifecycles.

6.4.14 Disposal Process 6.4.11 Software Disposal Process

6.4.14.2.a

Disposalconstraintsareprovidedasinputstorequirements,architecture,design,andimplementation.

6.4.11.2.a,

6.4.11.2.b

Asoftwaredisposalstrategyisdefined.Disposalconstraintsareprovidedasinputstorequirements.

6.4.14.2.b Anyenablingsystemsorservicesneededfordisposalareavailable.

6.4.11.2.a,6.4.11.2.c

Asoftwaredisposalstrategyisdefined.

Thesystem’ssoftwareelementsaredestroyedorstored.

6.4.14.2.c

Thesystemelementsorwasteproductsaredestroyed,stored,reclaimedorrecycledinaccordancewithrequirements,e.g.,safetyandsecurityrequirements.

6.4.11.2.c Thesystem’ssoftwareelementsaredestroyedorstored.

6.4.14.2.d Theenvironmentisreturnedtoitsoriginaloranagreedstate.

6.4.11.2.dTheenvironmentisleftinanagreed‐uponstate.

6.4.14.2.e Recordsofdisposalactionsandanalysisareavailable.

6.4.11.2.eRecordsallowingknowledgeretentionofdisposalactionsandanyanalysisoflong‐termimpactsareavailable.




Bibliography

[1] ANSI/AIAAG‐043A‐2012e,ANSI/AIAAGuide to the Preparation of Operational Concept Documents

[2] IEC 61508:2010 (all parts), Functional safety of electrical/electronic/programmable electronic safety-related systems

[3] IEEEStd1012™‐2012,IEEE Standard for System and Software Verification and Validation

[4] IEEEStd1062™‐2015,IEEE Recommended Practice for Software Acquisition

[5] IEEEStd730™‐2014,IEEE Standard for Software Quality Assurance Processes

[6] IEEEStd828™‐2012,IEEE Standard for Configuration Management in Systems and Software Engineering

[7] INCOSETP‐2003‐020‐01,Technical Measurement

[8] INCOSE.2015.Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,version4.0.Hoboken,NJ,USA:JohnWileyandSons,Inc.,ISBN:978‐1‐118‐99940‐0

[9] ISO10004:2012,Quality management — Customer satisfaction — Guidelines for monitoring and measuring

[10] ISO10007:2003,Quality management systems — Guidelines for configuration management

[11] ISO14001:2004,Environmental management systems — Requirements with guidance for use

[12] ISO15704:2000, Industrial automation systems — Requirements for enterprise-reference architectures and methodologies

[13] ISO31000:2009,Risk management — Principles and guidelines

[14] ISO9000:2015, Quality management systems — Fundamentals and vocabulary

[15] ISO9001:2015,Quality management systems — Requirements

[16] ISO9004:2009,Quality management systems — Guidelines for performance improvements

[17] ISO 9241‐210:2010, Ergonomics of human-system interaction — Human-centred design for interactive systems

[18] ISOGuide73:2009,Risk management — Vocabulary

[19] ISO/FDIS9241‐220,Ergonomics of human-system interaction — Part 220: Processes for enabling, executing and assessing human-centred design within organizations

[20] ISOTS18152:2010,Ergonomics of human-system interaction — Specification for the process assessment of human-system issues

[21] ISO/IEC 10746‐3:2009, Information technology — Open distributed processing — Reference model: Architecture

[22] ISO/IEC 15026‐3:2011, System and software engineering — Systems and software assurance — Part 3: System integrity levels

[23] ISO/IEC 15026‐4:2012, Systems and software engineering — Systems and software assurance — Part 4: Assurance in the life cycle

[24] ISO/IEC15939:2007,Systems and software engineering — Measurement process





[25] ISO/IEC16085:2006,System and Software Engineering — Life Cycle Management — Risk Management

[26] ISO/IEC 16350:2015, Information technology — Systems and software engineering — Application management

[27] ISO/IEC 19770‐1:2012, Information technology — Software asset management — Part 1: Processes and tiered assessment of conformance

[28] ISO/IEC20000‐1:2011(IEEEStd20000‐1:2013),Information technology — Service management — Part 1: Service management system requirements

[29] ISO/IEC25010:2011,Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models

[30] ISO/IEC 25030:2007, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements

[31] ISO/IEC 25063:2014, Systems and software engineering — Systems and software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability: Context of use description

[32] ISO/IEC26550:2013,Software and systems engineering — Reference model for product line engineering and management

[33] ISO/IEC 27000:2016, Information technology — Security techniques — Information security management systems — Overview and vocabulary

[34] ISO/IEC 27036 (all parts), Information technology — Security techniques — Information security for supplier relationships

[35] ISO/IEC33001:2015,Information technology — Process assessment — Concepts and terminology

[36] ISO/IEC33002:2015, Information technology — Process assessment — Requirement for performing process assessment

[37] ISO/IEC 33004:2015, Information technology — Process assessment — Requirement for process reference, process assessment, and maturity models

[38] ISO/IEC33020:2015,Information technology — Process assessment — Process measurement framework for assessment of process capability

[39] ISO/IEC TR 19759:2015, Guide to the Software Engineering Body of Knowledge (SWEBOK) V3, IEEE Computer Society, 2014

[40] ISO/IECTR24748‐2:2011,Systems and software engineering — Life cycle management — Part 2: Guide to the application of ISO/IEC 15288 (System life cycle processes)

[41] ISO/IECTR24748‐3:2011,Systems and software engineering — Life cycle management — Part 3: Guide to the application of ISO/IEC 12207 (Software life cycle processes)

[42] ISO/IEC TR 24774:20101, Systems and software engineering — Life cycle management — Guidelines for process description

[43] ISO/IEC TR 25060:2010, Systems and software engineering — Systems and software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability: General framework for usability-related information

1The electronic versionof this International Standard canbe freely downloaded from the ISO/IEC InformationTechnologyTaskForce(ITTF)website.




[44] ISO/IECTS24748‐1:2016,Systems and software engineering — Life cycle management — Part 1: Guide for life cycle management

[45] ISO/IEC/IEEE14764:2006,Software Engineering — Software Life Cycle Processes — Maintenance

[46] ISO/IEC/IEEE15288:2015,Systems and software engineering — System life cycle processes

[47] ISO/IEC/IEEE15289:2015,Systems and software engineering — Content of life-cycle information products (documentation)

[48] ISO/IEC/IEEE 16326:2009, Systems and software engineering — Life cycle processes — Project management

[49] ISO/IEC/IEEE 24748‐4:2016, Systems engineering — Life cycle management — Part 4: Application and management of the systems engineering process

[50] ISO/IEC/IEEE 24748‐52, Systems and software engineering — Life cycle management — Part 5: Software development planning

[51] ISO/IEC/IEEE247653,Systems and software engineering — Vocabulary

[52] ISO/IEC/IEEE 26515:2011, Systems and software engineering: Developing user documentation in an agile environment

[53] ISO/IEC/IEEE26531:2015,Systems and software engineering — Content management for product life-cycle, user, and service management documentation

[54] ISO/IEC/IEEE29119(allparts),Systems and software engineering — Software testing

[55] ISO/IEC/IEEE 29148:2011, Systems and software engineering — Life cycle processes — Requirements engineering

[56] ISO/IEC/IEEE42010:2011,Systems and software engineering — Architecture description

[57] NATOAEP‐67,Engineering for System Assurance in NATO Programs

[58] PMIPracticeStandardforWorkBreakdownStructures‐SecondEdition

[59] SAEANSI/EIA649B,Configuration Management Standard

2Tobepublished

3Databaseversionavailableat<computer.org/sevocab>





Important Notices and Disclaimers Concerning IEEE Standards Documents Notice and Disclaimer of Liability Concerning the Use of IEEE Standards Documents IEEEStandardsdocuments(standards,recommendedpractices,andguides),both full‐useandtrial‐use,aredevelopedwithin IEEESocietiesandtheStandardsCoordinating Committees of the IEEE Standards Association (“IEEE‐SA”) Standards Board. IEEE (“the Institute”) develops its standards through a consensusdevelopment process, approved by the AmericanNational Standards Institute (“ANSI”),which brings together volunteers representing varied viewpoints andinterests to achieve the final product. Volunteers are not necessarily members of the Institute and participatewithout compensation from IEEE.While IEEEadministerstheprocessandestablishesrulestopromotefairnessintheconsensusdevelopmentprocess,IEEEdoesnotindependentlyevaluate,test,orverifytheaccuracyofanyoftheinformationorthesoundnessofanyjudgmentscontainedinitsstandards. IEEEdoesnotwarrantorrepresenttheaccuracyorcontentofthematerialcontainedinitsstandards,andexpresslydisclaimsallwarranties(express,impliedandstatutory) not included in this or any other document relating to the standard, including, but not limited to, thewarranties of:merchantability; fitness for aparticularpurpose;non‐infringement;andquality,accuracy,effectiveness,currency,orcompletenessofmaterial.Inaddition,IEEEdisclaimsanyandallconditionsrelatingto:results;andworkmanlikeeffort.IEEEstandardsdocumentsaresupplied“ASIS”and“WITHALLFAULTS.” UseofanIEEEstandardiswhollyvoluntary.TheexistenceofanIEEEstandarddoesnotimplythattherearenootherwaystoproduce,test,measure,purchase,market,orprovideothergoodsandservicesrelatedtothescopeoftheIEEEstandard.Furthermore,theviewpointexpressedatthetimeastandardisapprovedandissuedissubjecttochangebroughtaboutthroughdevelopmentsinthestateoftheartandcommentsreceivedfromusersofthestandard. Inpublishingandmakingitsstandardsavailable,IEEEisnotsuggestingorrenderingprofessionalorotherservicesfor,oronbehalfof,anypersonorentitynorisIEEEundertakingtoperformanydutyowedbyanyotherpersonorentitytoanother.AnypersonutilizinganyIEEEStandardsdocument,shouldrelyuponhisorherownindependent judgmentintheexerciseofreasonablecareinanygivencircumstancesor,asappropriate,seektheadviceofacompetentprofessional indeterminingtheappropriatenessofagivenIEEEstandard. INNOEVENTSHALLIEEEBELIABLEFORANYDIRECT,INDIRECT,INCIDENTAL,SPECIAL,EXEMPLARY,ORCONSEQUENTIALDAMAGES(INCLUDING,BUTNOTLIMITEDTO:PROCUREMENTOFSUBSTITUTEGOODSORSERVICES;LOSSOFUSE,DATA,ORPROFITS;ORBUSINESSINTERRUPTION)HOWEVERCAUSEDANDONANYTHEORYOFLIABILITY,WHETHERINCONTRACT,STRICTLIABILITY,ORTORT(INCLUDINGNEGLIGENCEOROTHERWISE)ARISINGINANYWAYOUTOFTHEPUBLICATION,USEOF,ORRELIANCEUPONANYSTANDARD,EVENIFADVISEDOFTHEPOSSIBILITYOFSUCHDAMAGEANDREGARDLESSOFWHETHERSUCHDAMAGEWASFORESEEABLE. Translations The IEEEconsensusdevelopmentprocess involves the reviewofdocuments inEnglishonly. In theevent that an IEEEstandard is translated,only theEnglishversionpublishedbyIEEEshouldbeconsideredtheapprovedIEEEstandard. Official statements Astatement,writtenororal,thatisnotprocessedinaccordancewiththeIEEE‐SAStandardsBoardOperationsManualshallnotbeconsideredorinferredtobetheofficialpositionofIEEEoranyofitscommitteesandshallnotbeconsideredtobe,orberelieduponas,aformalpositionofIEEE.Atlectures,symposia,seminars,oreducationalcourses,anindividualpresentinginformationonIEEEstandardsshallmakeitclearthathisorherviewsshouldbeconsideredthepersonalviewsofthatindividualratherthantheformalpositionofIEEE. Comments on standards CommentsforrevisionofIEEEStandardsdocumentsarewelcomefromanyinterestedparty,regardlessofmembershipaffiliationwithIEEE.However,IEEEdoesnotprovideconsultinginformationoradvicepertainingtoIEEEStandardsdocuments.Suggestionsforchangesindocumentsshouldbeintheformofaproposedchange of text, togetherwith appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important that anyresponsestocommentsandquestionsalsoreceivetheconcurrenceofabalanceofinterests.Forthisreason,IEEEandthemembersofitssocietiesandStandardsCoordinating Committees are not able to provide an instant response to comments or questions except in those caseswhere thematter has previously beenaddressed.Forthesamereason,IEEEdoesnotrespondtointerpretationrequests.AnypersonwhowouldliketoparticipateinrevisionstoanIEEEstandardiswelcometojointherelevantIEEEworkinggroup. Commentsonstandardsshouldbesubmittedtothefollowingaddress: Secretary,IEEE‐SAStandardsBoard 445HoesLane Piscataway,NJ08854USA Photocopies Subjecttopaymentoftheappropriatefee,IEEEwillgrantusersalimited,non‐exclusivelicensetophotocopyportionsofanyindividualstandardforcompanyororganizationalinternaluseorindividual,non‐commercialuseonly.Toarrangeforpaymentoflicensingfees,pleasecontactCopyrightClearanceCenter,CustomerService,222RosewoodDrive,Danvers,MA01923USA;+19787508400.PermissiontophotocopyportionsofanyindividualstandardforeducationalclassroomusecanalsobeobtainedthroughtheCopyrightClearanceCenter. Patents Attention is called to the possibility that implementation of this standardmay require use of subjectmatter covered by patent rights. By publication of thisstandard, no position is taken by the IEEEwith respect to the existence or validity of any patent rights in connection therewith. If a patent holder or patentapplicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE‐SA Website athttp://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurancemay indicatewhether the Submitter iswilling or unwilling to grant licensesunder patent rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfairdiscriminationtoapplicantsdesiringtoobtainsuchlicenses. EssentialPatentClaimsmayexist forwhichaLetterofAssurancehasnotbeenreceived.TheIEEEisnotresponsible for identifyingEssentialPatentClaimsforwhich a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms orconditionsprovidedinconnectionwithsubmissionofaLetterofAssurance,ifany,orinanylicensingagreementsarereasonableornon‐discriminatory.Usersofthis standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their ownresponsibility.FurtherinformationmaybeobtainedfromtheIEEEStandardsAssociation. Participants: The list of IEEE participants can be accessed at the following URL: http://standards.ieee.org/downloads/12207/12207‐2017/12207‐2017_wg‐participants.pdf.


http://standards.ieee.org/downloads/12207/12207-2017/12207-2017_wg-participants.pdf�

http://standards.ieee.org/downloads/12207/12207-2017/12207-2017_wg-participants.pdf�



Abstract: Thisdocumentestablishesacommonprocessframeworkfordescribingthefulllifecycleof software systems from conception through retirement. It applies to the acquisition ordevelopmentofsoftwareproductsandserviceswhetherperformedinternallyorexternally toanorganization. Those aspects of software system definition needed to provide the context forsoftwareproductsandservicesare included.Thedocumentalso supports thedefinition, control,assessment and improvement of these processes. These processes can be applied concurrently,iteratively, and recursively to a software system and its elements throughout the life cycle of asoftware system.Users of thedocument can apply theprocesses and terminology to construct asuitablelifecyclemodel,composedofstagesthatuseselectedprocesses.TheprocesspurposesandoutcomesinISO/IEC/IEEE15288:2015(systemslifecycleprocesses)andthisdocumentarefullyalignedsothatonemayselectappropriateactivitiesfromeitherdocumentforuseinsystemswithsubstantialsoftwarecontent. Keywords: acquisition, agreement, architecture, design, assessment, audit, configurationmanagement, decision management, development, disposal, enabling system, implementation,informationmanagement, infrastructure, integration, life cycle, life cyclemodel, life cycle stages,maintenance,measurement,operation,planning,process,processimprovement,processreferencemodel, process tailoring, process view, product, portfolio, quality management, requirements,retirement, risk management, service, software, software system, system‐of‐interest, stages,stakeholder requirements, supply, system, system structure, system‐of‐interest, tailoring,transition,validation,verification
