INTRODUCTION TO THE CAPABILITY LIFE CYCLE · engineering and in management and project management....

INTRODUCTION TO THE

CAPABILITY LIFE CYCLE AND

CAPABILITY MANAGEMENT PRACTICES

Part II

Dr Mike Ryan Dr Shari Soutberg

Your Presenters Dr Mike Ryan holds BE, MEngSc and PhD degrees in electrical engineering from the University of New South Wales. He is a Fellow of Engineers Australia (FIEAust), a Chartered Professional Engineer (CPEng) in electrical and ITEE colleges, a Senior Member of IEEE (SMIEEE), a Fellow of the International Council on Systems Engineering (INCOSE), and a Fellow of the Institute of Managers and Leaders (FIML). Since 1981, he has held a number of positions in communications and systems engineering and in management and project management. Since 1998, he has been with the School of Engineering and Information Technology, University of New South Wales, at the Australian Defence Force Academy where he is currently the Director of the Capability Systems Centre. His research and teaching interests are in communications and information systems, requirements engineering, systems engineering, project management, and technology management. He is the Editor‐in‐Chief of an international journal, and is the Chair of the Requirements Working Group INCOSE. He is the author or co‐author of twelve books, three book chapters, and over 200 technical papers and reports.

Dr Shari Soutberg has over 30 years experience in Defence, with a focus on materiel acquisition, sustainment, organisational improvement and reform. Shari is currently an Industry Fellow at the UNSW Capability System Centre. Significant activities include development of a framework for delivery of joint force outcomes and training courses on capability development practices applicable to Defence. Prior to this, Shari was the acting Chief Systems Engineer for CASG and a member of the First Principles Review (FPR) Capability Lifecycle (CLC) team which developed capability management reform initiatives. As Director Systems Engineering and later Director Materiel Engineering in CASG, Shari led the development and implementation of Defence engineering policy and guidance, including fundamental changes arising from the WHS Act 2011. Shari provided stewardship of the Defence Engineering and Technical Job Family through establishing learning and development structures. She also supported Defence corporate engineering and technical workforce planning including industrial relations engagement. Whilst in the Office of the Parliamentary Secretary for Defence Industry, Shari was a significant contributor to the Defence Industry Policy leading to the role of Director Industry Policy. After joining the Department of Defence, Shari worked on maritime platforms and equipment and as a project manager for naval projects. Shari has a Bachelor of Engineering (Electrical), Masters of Management Economics, and a Doctor of Philosophy which addressed requirements development in Defence capability management. Books 1. M. Ryan, Battlefield Command Systems, Brassey’s, 2000. 2. M. Frater and M. Ryan, Electronic Warfare for the Digitized Battlefield, Artech House, 2001. 3. M. Ryan and M. Frater, Tactical Communications for the Digitized Battlefield, Artech House,

2002. 4. M. Ryan and M. Frater, Communications and Information Systems, Argos Press, 2002. 5. R. Faulconbridge and M. Ryan, Managing Complex Technical Projects, Artech House, 2002. 6. M. Ryan, Principles of Satellite Communications, Argos Press, Canberra, 2004. 7. R. Faulconbridge and M. Ryan, Engineering a System: Managing Complex Technical Projects,

Argos Press, 2005. 8. C. Benson, M. Frater and M. Ryan, Tactical Electronic Warfare, Argos Press, Canberra, 2007. 9. M. Ryan and M. Frater, Battlefield Communications Systems, Argos Press, Canberra, 2007. 10. M. Ryan, M. Frater, and M. Pickering, Fundamentals of Communications and Information

Systems, Argos Press, 2011. 11. R. Faulconbridge and M. Ryan, Systems Engineering Practice, Argos Press, Canberra, 2014. 12. M. Ryan, Requirements Practice, Argos Press, Canberra, 2017.

Book Chapters 1. M. Ryan, “Satellite‐based Mobile Communications”, in Handbook on Antennas in Mobile

Communications, L. Godara (ed), CRC Press, Boca Raton, FL, 2002. 2. M. Frater and M. Ryan, “Military Information Systems Security: Challenges and Vulnerabilities”,

in L. Jain (ed), Advances in Intelligent Systems for Defence, World Scientific Publishing Company, 2002.

3. M. Pickering and M. Ryan, “An Architecture for the Compression of Hyperspectral Imagery”, in G. Motta, F. Rizzo, and J. Storer (eds), Hyperspectral Data Compression, Kluwer Academic, 2006.

Major Recent Consultancies 1999 An analysis of the effect of radio‐frequency directed‐energy weapons (RF DEW) 1999 Development of an architecture for a battlespace communications system for the

Australian Army 2000 An analysis of the fitness‐for‐purpose of SSB mode for receive‐only Link‐11

communications 2001 An investigation into the impact of environment on a ship‐based UHF SATCOM receiver 2002 C4I study and development of technical specification for ATHOC: Athens 2004 Olympic

Games 2002 Land 125 (WUNDURRA) Soldier Combat System—System Integration Study—

Communications 2003 Independent validation and verification (IV&V) of NZ Joint Command and Control

System (JCCS) 2003 Land 125 (WUNDURRA) Soldier Combat System—System Integration Study—Security 2004 Development of Strategy Paper for the ADF Tactical Information Exchange Environment 2005 Development of a Security Architecture for the Land Force Information Network 2005 Development of a Space Policy for the Australian Army 2005 Development of a web‐services strategy for Air Services Australia 2005 Review of functions and responsibilities for delivery of the ADF Battlespace Network 2005 Strategic appreciations for the layers of the Defence Information Infrastructure (DII) 2005‐6 Rewrite of Defence Approved Technology Standards List (ATSL) 2006 Independent validation and verification (IV&V) for JP2072 2007 Independent validation and verification (IV&V) for JP2097 2007 Advice on design acceptance for JP141/2087 2007 Systems Engineering Independent Review Team for JP2072 2007 Independent validation and verification (IV&V) for Land 75/125 BMS T&E 2007 Physical/Functional Audit Review for the Hazard Prediction Modelling and Geospatial

Subsystem 2008 Development of system architecture / functional specification for Modular Engineer

Force 2008 Development of CDD suite for Land 125 Phase 4 2009 Business Case for Annual Defence‐wide EW Capability Review 2009 Business Case for Defence‐wide EW Training and Education Review 2010 JP 2089 Phase 3B—Tactical Information Exchange Domain—ARH—Requirements

Workshop facilitation 2010 Rewrite of Defence Approved Technology Standards List (ATSL) 2011 IV&V for ADF EW Training Needs Analysis 2011 Review of AIR 5431 OCD 2012 Requirements Workshop for ADF Enterprise Content Management and Collaboration

System (ECMS) 2012‐3 JP 2030 Phase 8 Evolution 1 and 2 Operational Test and Evaluation (OT&E)

Documentation Update 2013 IV&V for drafting of JP2089 Phase 3A Function and Performance Specification

2015 Revision of Defence Simulation Strategy and Roadmap 2015 AIR 9000 Capability Development Document Redevelopment 2015 AIR 9000 Lifecycle Cost Analysis Modelling 2016 AIR 6500 Facilitation and Modelling 2016 AIR 9000 Life cycle Modelling 2016 Lifecycle Modelling—LAND 2110 and LAND 907 2016 Land Network Integration Centre Test & Evaluation Study 2016 Land Training Areas and Ranges (LTAR) Design Facilitation 2017 SEA129 Modelling 2017 SEA1000 Through life support modelling 2017 SEA 1180 Ship Zero functions development 2017 HJCMI I2 Framework (I2F) Development 2017 HJCMI IAMD IV&V 2017 CASG Report on the Schedule Compliance Risk Assurance methodology (SCRAM) 2017 JP91001 FPS and OCD Development IV&V

The Capability Life Cycle (CLC) and Capability Management Practices

2-1

Dr Mike RyanDr Shari Soutberg

The Capability Life Cycle (CLC)and

Capability Management Practices

Day 2

• System, Capability System, Systems of Systems (SoS)

• Overview of system lifecycle

• Systems Engineering, its relevance and benefits

• Systems Engineering Process

– Conceptual Design

• Project Management

• Program Management


2-2

FPS 2

Defence White Paper

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRsForce Design

CPN

JCN

Portfolio

Program

Product

IIP

DIP

DPPMIssued by JCA to the CM

Raised within Force Design as Program level direction PIOC Program Strategy

PESJCNS

Smartbuyer

OCD

FPS 1

IPMPProjectWBS IMS

Tender and Contracting Documents

Selected ASDEFCON Suite

DPG

JCFConcepts

Strategic Guidance

Combined = Business Case/Proposal/Submission

Systems Engineering


2-3

Use of the word ‘system’

• The word ‘system’ has many contexts:

– Physical systems such as solar systems, river systems,railway systems, satellite systems, communicationsystems, information systems, pulley systems, andnervous systems.

– Philosophical systems, social systems, religious systems,gambling systems, banking systems, and systems ofgovernment.

– More-esoteric examples, such as the consideration ofindividual and social behaviour as a system of purposefulevents.

Use of the word ‘system’

• The common aspect of ‘system’ stems from its early use torefer to:

the whole (or the set) that results:

when a number of things have been grouped,

in a particular manner,

for a particular reason.

• So, what is a ‘system’ in the context of ‘systemsengineering’?


2-4

Definition of a system

• In systems engineering, ISO/IEC 15288 therefore defines asystem as:

a combination of interacting elements organized toachieve one or more stated purposes*

* ISO/IEC 15288-2015, Systems and Software Engineering—System Life Cycle Processes, 2015.


• So, a system comprises:

– system elements,

– interconnections (interactions) between elements, and

– an external system boundary.

System of interest(SOI)

System element

Interconnection/interaction

System boundary


2-5

The mission of the system

• The purpose of the system is called its mission.

– must be clearly stated by business management andstakeholders.

– represents the start point of the design process.

– provides the basis for the ultimate test of the system’sfitness-for-purpose.

• In the broadest sense, the mission of the system is toprovide a solution to a business problem.

Types of systems

• There are four main classifications of system:

– Closed/open systems.

– Natural/human-made/human-modified systems.

– Physical/conceptual systems.

– Precedented/unprecedented.

• A wide variety of combinations of the characteristics canlead to a large number of types of systems, each of whichhas markedly difficult properties.

• Systems engineering is applied to open, physical systemsthat are human-made/modified from largely precedentedelements.


2-6


• Narrowing the definition of a system has two majorimplications:

– The systems elements, interconnections and boundaryare not accidental but result from deliberate design(engineering).

– A system must be managerially and operationallyindependent (and may well have been procuredindependently).

System of interest(SOI)

External element

System element

Interconnection/interaction

External Interface (input/output)

OperatingEnvironment

Boundary

A system and its environment


2-7

System of interest

Widersystem of interest

Operating environment

Wider environment

A system and its environment

System

Operational products Enabling products

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System as a product

• In a physical sense, the term system is sometimesconsidered to be synonymous with product—that is, we saythat the project is delivering a system, or is delivering aproduct.

ANSI/EIA-632-1998, Processes for Engineering a System, Washington, D.C.: Electronic Industries Association (EIA), 1999.


2-8

A system as a capability

• Systems are much more than an aggregation of hardware orsoftware products and also include: organisation, personnel,collective training systems, facilities, data, support, andoperating procedures and organisational policies.

• A system therefore delivers an operational capability, not justproducts.

Capability system

• It is common, therefore, particularly in defenceenvironments, to refer to the system at this level as acapability system.

– US—DOTMLPF

– Australia—FIC

– UK—DLOD

– Canada—PRICIE


2-9

Capability system

• Each of the elements of a capability system will probablyhave a different acquisition cycle, since each represents adifferent type of acquisition.

• Here we focus on the major equipment element so that thedescriptions are less cluttered.

• We must remember, however, that all elements are acquiredin parallel and must be brought back together prior tointroduction into service in order to field an operationalcapability.

Logical and physical descriptions

• A system can be described in two broad ways:

– Logical (or functional)—what the system will do, how wellit will do it, how it will be tested, under what conditions itwill perform, and what other systems will be involved withits operation.

– Physical—what the system elements are, how they look,and how they are to be manufactured, integrated, andtested.

• Both the logical and physical descriptions of a systemcomprise a series of statements called requirements.


2-10


• The two descriptions are valid independent descriptions of asystem:

– We develop the logical description first.

– How we implement current physical systems should notcolour unnecessarily the way in which we might describefuture systems.

– Upper-level trade-offs and feasibility analyses must beconducted at the logical level before deciding on thephysical implementation.

– A logical description is ideally suited to the interfacebetween systems engineering and the business case.

– The logical description changes slowly; the physicaldescription changes much faster.


• In the development of a system, therefore, there are at leasttwo architectural views: a system logical architecture, and asystem physical architecture.

• Of course, these two descriptions are of the same system sothey must be related.

• We will see later how the logical architecture, as outlined inthe requirements breakdown structure (RBS), is mappedonto the physical architecture as represented by theconfiguration items contained in the work breakdownstructure (WBS).


2-11

System

SystemElement

SystemElement

SystemElement

A system

comprises

a set of interacting

system elements

Hierarchical descriptions of a system

• We can consider the system to be a hierarchical compositionof system elements (either logical or physical).

Mission

Function1

Function2

Function1.1

Function1.2

Function1.3

Function2.1

Function2.1

Logical (functional) hierarchy

• In a logical description of a system, the system’s mission isbroken down into a hierarchical structure of its majorfunctions—to form a functional hierarchy, or a functionalarchitecture.


2-12

System

Products

Subsystems

Assemblies

Components

Subcomponents

Parts Subcomponents

Subassemblies

Parts

Physical hierarchy

• We use a simple four-layer representation (system,subsystem, assembly, component) which can be moreelaborate.

IEEE-STD-1220, IEEE Standard for Application and Management of the Systems Engineering Process, New York: IEEE Computer

Physical hierarchy

• It is common to allow the hierarchical terms to be relative.For example, an aircraft system contains, among others, theengine subsystem, which may consist of assemblies such asfuel tanks, pumps and lines, turbines, compressors, gearboxes, and hydraulic pumps.

• The engine manufacturer may consider the engine to be thesystem, comprising fuel, power plant, and hydraulicsubsystems, and so on.

• However, an implicit part of the definition of a system is thatit must be able to stand alone in its own right. An engine istherefore not a system—it is only useful as an element of asystem (that is, as a subsystem).


2-13

System-of-Interest

SystemElement

SystemElement

System System

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

System System

Hierarchy of an SOI

• It is probably better, therefore, to consider an SOI tocomprise a combination of interacting system elements,some of which may be systems in their own right.

ISO/IEC 15288-2015, Systems and Software Engineering—System Life Cycle Processes, 2015.

System

Subsystem Subsystem

Subsystem Subsystem

System-of-Systems

System System

System System

System or system-of-systems (SoS)?


2-14

System or system-of-systems (SoS)?

System

Subsystem Subsystem

Subsystem Subsystem

System-of-Systems

System System

System System

A system is an integration of a number of co‐dependent subsystemsthat are interconnected

permanentlyto achieve a common purpose.

An SoS is an integration of a number of independent systems that are interconnected for a period of time

to achieve a common purpose.

Problem and solution domains

• Remember that a system can be considered to be a solutionto a problem.

• it is common to consider the activities being undertakenthroughout the life of the system to be in either the:

– Problem domain (problem space) where we usepredominantly logical descriptions, or

– Solution domain (solution space) where we usepredominantly physical descriptions.


2-15

System Life Cycle

AcquisitionPhase

UtilizationPhase

RetirementPhase

Pre-acquisitionPhase

Generic system life cycle

• Throughout the life of a system there are a number ofphases and activities, each of which builds on the results ofthe preceding phase or activity.

• The sum all these activities is called a system life cycle.

• A generic system life cycle can be divided into four verybroad phases.


2-16

AcquisitionPhase

UtilizationPhase

RetirementPhase


Pre-acquisition Phase

• The life cycle begins in the Pre-acquisition Phase with anidea for a system being generated as a result of businessplanning.

• Business needs are confirmed and supported by a businesscase.

• Ensures that only feasible, cost-effective projects are takenforward to acquisition.

AcquisitionPhase

UtilizationPhase

RetirementPhase


Acquisition Phase

• The Acquisition Phase is focused on bringing the system intobeing and into service in the organisation.

• The system is defined in terms of:

– business requirements,

– stakeholder requirements, and

– system requirements.

• A contractor is then normally engaged to develop/deliver thesystem.


2-17

AcquisitionPhase

UtilizationPhase

RetirementPhase


Utilization Phase

• The system is operated and supported during the UtilizationPhase

• During utilization, the system may undergo a number ofmodifications and upgrades to:

– rectify performance shortfalls,

– meet changing operational requirements or externalenvironments to enable ongoing support for the system tobe maintained, or

– enhance current performance or reliability.

AcquisitionPhase

UtilizationPhase

RetirementPhase


Retirement Phase

• The system is in service during the Utilization Phase until:

– the business has no further need for the system, or

– it no longer can meet the functions required of it by theorganisation, or

– it is no longer cost-effective to keep it in service.

• If the business need for the capability still exists in theorganisation, the conclusion of one system life cycle marksthe start of another and the process begins again.


2-18

Parties involved

• Throughout the system life cycle, there are a number ofparties involved.

• The customer organization is managed by:

– enterprise management who set the direction for theorganisation and for

– business management who are responsible for theactivities conducted by

– the operations element of the organisation which is run by

– the operators—sometimes called the users.

Parties involved

• The systems used within the organisation are acquired by:

– the acquisition element (also called the acquirer, ortasking activity) of the organisation under the auspices of

– a project, which is typically managed by

– a project manager.

• Project managers are supported by a number of relateddisciplines including:

– systems engineering,

– requirements engineering,

– specialist engineering disciplines,

– quality assurance, and

– integrated logistic support.


2-19

Parties involved

• Operators are supported in their operation of the system bythe support element of the organisation, which supports,sustains, and maintains the system throughout its life.

• In addition to the operational, acquisition, and support staff,there are many others within the customer organization whohave a stake in the successful implementation of the project.

• These stakeholders can include representatives from themanagement, financial, operations, supply, maintenance,and facilities areas of the organisation.

Parties involved

• The system is obtained from a supplier (also called theperforming activity) who may deliver the system off-the-shelfor may develop it, in which case they are often called thedeveloper.

• The supplier (developer) may be an internal part of thecustomer (acquirer) organisation.

• It is increasingly common these days for the supply ordevelopment to be undertaken by an outside organisationcalled a contractor.

• The relationship between the customer and the contractor isdefined by the terms and conditions of the contract.

• Often the contractor is not able to perform all of the workrequired and devolves packages of work to a number ofsubcontractors through a number of subcontracts.


2-20

Acquisition Phase Utilization Phase Retirement PhasePre-acquisition Phase

ProjectManagement

Enterprise/Business

Management

SystemsEngineering

Operations

Responsibilities of the parties involved

• Responsibility for the various phases of the system life cycleis spread across the enterprise (or organisation) within whichthe eventual system will operate.

• Note that all parties are involved at all stages in the lifecycle, with the roles and responsibilities of each partyshifting in emphasis between stages.

AcquisitionPhase

PreliminaryDesign

DetailedDesign and

Development

UtilizationPhase

RetirementPhase


ConceptualDesign

Constructionand/or

Production

Operational Useand

System Support

Activities in Acquisition and Utilization Phases

• Systems engineering is predominantly related to theAcquisition Phase of the system life cycle and, to a lesserextent, the Utilization Phase.

• For these two major phases, we use the life-cycle activitiesbased on those defined by Blanchard and Fabrycky.

Blanchard, B. and W. Fabrycky, Systems Engineering and Analysis, Upper Saddle River, N.J.: Prentice-Hall, 1998.


2-21

Acquisition Phase

• The Acquisition Phase comprises the four main activities ofConceptual Design, Preliminary Design, Detailed Design andDevelopment, and Construction and/or Production.

• Here we look at each of these activities in a little moredetail—we will examine them in much more detail in laterweeks.

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Acquisition Phase

Conceptual Design

• Formal transition from the business world to the projectworld—from the mission statement to complete logicaldescription of the system-of-interest.

• Ensures proper definition of the system requirements.

• Ensures appropriate engagement with business managersand upper-level stakeholders.

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign


2-22

Conceptual Design

• Business Needs and Requirements (BNR) are articulatedand confirmed by business management.

• BNR are elaborated by stakeholders at the businessoperations level into a set of Stakeholder Needs andRequirements (SNR).

• SNR are elaborated by requirements engineers into systemrequirements in the System Requirement Specification(SyRS).

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

System Requirement Specification (SyRS)

StakeholderNeeds and

Requirements(SNR)

BusinessNeeds and

Requirements(BNR)

Conceptual Design

• The BNR, SNR and the SyRS are key elements of what iscalled the Functional Baseline (FBL).

• Conceptual Design ends with the System Design Review(SDR), which finalizes the initial FBL.

• SDR confirms the BNR, SNR and the SyRS, and provides aformal record of design decisions and design acceptance.

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Functional Baseline

System Design Review (SDR)


2-23

Preliminary Design

• Converts the logical architecture in the initial FBL intodescription of the physical subsystems (the upper-levelphysical architecture) that will meet the systemrequirements.

• Results in the Allocated Baseline (ABL), so-called becausethe functionality of the system is now allocated to physicalbuilding blocks called configuration items (CI), which aredescribed in Development Specifications.

• Ends with a Preliminary Design Review (PDR).

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Allocated Baseline(Development Specifications)

Preliminary Design Review(PDR)

Functional Baseline(System Requirement Specification (SyRS))

System Design Review(SDR)


Requirements(SNR)

BusinessNeeds and

Requirements(BNR)

Detailed Design & Development

• Uses engineering disciplines to develop the individualsubsystems, assemblies, and components in the system.

• Results in the Product Baseline (PBL) as the system is nowdefined by the numerous products (subsystems, assemblies,and components) as well as the materials and processes formanufacturing and construction.

• Ends with Critical Design Review (CDR).

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign



Allocated Baseline(Development Specifications)Preliminary Design Review

(PDR)

Product Baseline(Product Specifications)Critical Design Review

(CDR)


Requirements(SNR)

BusinessNeeds and

Requirements(BNR)


2-24

Construction and/or Development

• Components are produced in accordance with the PBLspecifications and the system is ultimately constructed.

• Ends with Formal Qualification Review (FQR), whichprovides the basis upon which the customer accepts thesystem from the contractor.

• FQR is informed by the results of acceptance test andevaluation (AT&E)

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign



Allocated Baseline(Development Specifications)Preliminary Design Review

(PDR)

Product Baseline(Product Specifications)Critical Design Review

(CDR)


Requirements(SNR)

System AcceptanceFormal Qualification Review

(FQR)

BusinessNeeds and

Requirements(BNR)

Utilization and Retirement Phases

• Major activities in Utilization Phase are:

– Operational Use

– System Support

• Modifications may be necessary.

• The system life cycle ends with the Retirement Phase.

AcquisitionPhase

UtilizationPhase

RetirementPhase



2-25

Development Approaches

• We have presented the life-cycle phases and activities insequence.

• This assumes the waterfall approach to development.

• There other approaches such as incremental, spiral, andevolutionary acquisition, each of which has strengths andweaknesses.

• For simplicity, we continue to assume the waterfall approachfor the majority of the course—a solid understanding of theapproach is useful because it helps understand the others,and the others all have the waterfall approach as afundamental building block.

• We return to the other approaches later today.

Introduction toSystems Engineering


2-26

What is systems engineering?

“An interdisciplinary collaborative approach to derive, evolve,and verify a life-cycle balanced system solution which satisfiescustomer expectations and meets public acceptability.”

IEEE P1220, Trial-Use Standard for Application and Management of the Systems Engineering Process, 1994.


“An interdisciplinary approach encompassing the entiretechnical effort to evolve and verify an integrated and life-cyclebalanced set of system, people, product, and process solutionsthat satisfy customer needs. Systems Engineeringencompasses:

• the technical efforts related to the development,manufacturing, verification, deployment, operations, support,disposal of, and user training for, system products andprocesses;

• the definition and management of the system configuration;

• the translation of the system definition into work breakdownstructures; and

• development of information for management decisionmaking.”

EIA/IS 632, Systems Engineering, 1994.


2-27


“Systems engineering is the selective application of scientificand engineering efforts to:

• transform an operational need into a description of thesystem configuration which best satisfies the operationalneed according to the measures of effectiveness;

• integrate related technical parameters and ensurecompatibility of all physical, functional, and technicalprogram interfaces in a manner which optimises the totalsystem definition and design; and

• integrate the efforts of all engineering disciplines andspecialties into the total engineering effort.”

Systems Engineering Capability Maturity Model, Version 1.1, SEI SE-CMM, 1995


• Each definition tends to reflect the particular focus of itssource.

• There are, however, a number of common themes whichindicate the key tenets of systems engineering:

– Top-down approach

– Requirements engineering

– Life-cycle focus

– System optimization and balance

– Integration of specialisations and disciplines

– Management


2-28

Top-down approach

• Traditional engineering disciplines are based on bottom-upapproach:

– We design and build components, integrate them into thenext higher level element and so on until we have thesystem.

– This is very effective so long as we are trying to solve aparticular, well-defined problem.

• Complex problems with many inter-relationships tend not tobe suited to bottom-up solutions.

Top-down approach

• Start by looking at the system as a whole to provide athorough understanding of the system and its environmentand interfaces.

• System-level requirements are developed.

• Likely subsystems can then be considered and requirementsassigned to individual subsystems, the subsystems furtherbroken down into assemblies, and then into components

• This process continues until a complete understanding isachieved of the system from top to bottom which allows:

– Additional (derived requirements) to be developed.

– Interfaces between subsystems to be identified.

• This approach is well documented in process standardssuch as ANSI/EIA-632.


2-29

Top-down design

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

System


Subsystem Subsystem

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

Bottom-up integration

• While design is top-down, integration is bottom-up.

• At each stage of the integration, some form of integrationtesting will be conducted to verify the successful integration.

Subsystem

Component Component

Subsystem

Integration testing

Assembly Assembly

SystemSystem

Development Integration

Design Solution


2-30

Requirements engineering

• Complete and accurate definition of requirements isfundamental to project success.

• Original need translates into statements of requirementwhich form the basis of functional and (eventually) physicaldesign.

• These transitions must be managed by a rigorous processcalled requirements engineering.

• Once requirements have been collected, the systemsengineering process then focuses on the derivation anddecomposition of these requirements from the system levelright down to the lowest constituent component (sometimesreferred to as requirements flowdown).

Requirements engineering

• Requirements traceability is essential:

– Forward traceability allows design decisions to be tracedfrom any requirement down to a lower level.

– Backward traceability means that any lower-levelrequirement is associated with at least one higher-levelrequirement.

• Traceability assures the customer that all requirements canbe accounted for in the design at any stage and that nounnecessary requirements are included.

• Traceability also supports the configuration control (changemanagement) process.

• Requirements traceability is a feature of top-down design,which guarantees that requirements can be satisfied at anystage.


2-31

Life-cycle focus

• Systems engineering maintains a life-cycle focus asdecisions are made.

• Often, the temptation is to focus on acquisition issues inorder to minimise acquisition costs and schedules.

• Given that a system spends a majority of its life in utilisationthe full life-cycle cost (LCC) must be considered.

• As a simple example, it is false economy to buy a cheapercar that has very high running costs, if a slightly moreexpensive car can be acquired which has lower through-lifecosts (and therefore a lower LCC).

System optimisation and balance

• We cover this issue in detail later but basically a collection ofoptimally-designed subsystems do not necessarily lead to anoptimal system.

• Systems engineering is looking for optimal system-levelperformance.

• This sometimes must force subsystem and componentdesigners down sub-optimal paths.

• Also system engineering recognises that the system must bedesigned with balance in mind.

– For example we must balance system performance withother factors such as social, ethical, cultural andpsychological effects (and others).


2-32

Integration of specializations / disciplines

• Systems engineering integrates a diverse range of technicaldisciplines and specializations.

• Our aircraft example illustrates this point because it involvesmore than just engineering disciplines—must also involvefinance, legal, environmental specialists and so on.

• Systems engineering defines the tasks that can becompleted by these disparate disciplines and specialties andthen provides the management to integrate their efforts toproduce a system.

• This function is essential because of the complexity of largeprojects and their contracting mechanisms, and thegeographic dispersion of contractor and subcontractorpersonnel across the country and around the world.

Management

• Systems engineering clearly has a technical role to play butit also has a very important management role.

• There is a very strong link between the necessary functionsof project management and systems engineering.

• Systems engineering products ensure project managementdecisions are informed.

• More on this later.


2-33

Relevance and Benefits ofSystems Engineering

Relevance of systems engineering

• Let’s start the relevance discussion with a quote from aleading systems engineering standard (ANSI/EIA-632) whichstates that it is applicable to:

… the engineering or the re-engineering of:

• commercial or non-commercial systems;

• systems that are large or small, simple or complex,software or hardware focused;

• systems containing products such as hardware,software, firmware, personnel, facilities, data,materials, services, techniques or processes;

• new systems or legacy systems.

• It is tough to imagine a system that doesn’t fit somewhereinto that description.

ANSI/EIA-632-1998, Processes for Engineering a System, Washington, D.C.: Electronic Industries Association (EIA), 1999.


2-34


• Systems engineering can be applied to all systems but wemust do so in a thoughtful manner.

• Thoughtless application of systems engineering canincrease costs, complexity and schedule without anyreduction in risk.

• We must be cognizant of project size, complexity and risk.

• We must tailor systems engineering activities so that theyadd value and reduce risks.


• Systems engineering is relevant to both customers andsuppliers:

– Customers use systems engineering to define systemrequirements, monitor contractor progress and risk.

– Contractors use systems engineering to develop effectiveprocesses for the design, development and test ofsystems.

– Both parties are looking to produce “quality” systemswhilst minimizing exposure to risk.


2-35

Benefits of systems engineering

• There are a number of benefits possible from correctlyapplied systems engineering:

– LCC savings

– Reduction in overall acquisition schedule

– Reduction in technical risk

– Quality system

LCC savings

• Savings over the entire life cycle are possible due to thesystems engineering focus on the entire life cycle.

• Some argue that systems engineering adds too muchcomplexity, cost and time to the acquisition phase.

• This may be true to an extent, but the early additional effortshould be thought of as an investment that will be returnedtime and again throughout the life of the system.


2-36

Reduction in overall acquisition schedule

• A reduction in overall acquisition time is possible throughsolid requirements engineering efforts.

• By getting the requirements right early and then monitor theirinclusion into the subsequent design, we can reduce thepotential for costly and time-consuming changes later.

High

Low

Conceptual &Preliminary

Design

DetailedDesign and

Development

Constructionand/or

Development

Utilization

Ease of making changes

Cost of making changes

Reduction in technical risk

• Systems engineering has a number of tools aimed at riskreduction (we will discuss these later).

• Systems engineering also forces the consideration of allfeasible alternatives with a view to selecting the best solution(allowing risk to be considered during the selection process).

• Design decisions and alternatives are linked back to theoriginal requirements through traceability, which ensuresthat risks are taken with original requirements in mind.

• Technical risk is monitored and assessed continuouslyensuring that risk mitigation occurs in a timely manner.


2-37

Quality system

• Above all of these benefits stands the fact that we areinterested in bringing into service a system of the desired‘quality’.

• Here, quality refers to fitness-for-purpose or an ability toserve the intended purpose.

• By maintaining a focus on requirements and their traceabilityinto design, systems engineering helps to ensure that:

– the specified requirements accurately reflect the businessand stakeholder needs; and

– the resulting system meets the specified requirements.

Conceptual Design


2-38

Conceptual Design

• The systems engineering processes begin in earnest withthe first activity in the Acquisition Phase—ConceptualDesign:

– aims to articulate the needs, to analyse and document thesystem-level requirements flowing from the needs, and tocomplete a logical design of the system

– major product is the Initial Functional Baseline (FBL),which provides a system-level logical architecture that isthe basis for subsequent lower-level (physical) design

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Conceptual Design

• Conceptual Design is critical because:

– The system definition is expanded from relatively briefbusiness needs into a logical set of system-levelrequirements that may be hundreds of pages long.

– All subsequent aspects of the system design will betraced back to the Initial FBL that ends this activity—anyerrors here will flow down to the remainder of theactivities.

– Conceptual Design is concerned with the transition fromthe problem domain into the solution domain. It istherefore essential that the output of Conceptual Designadequately represents the business and stakeholderneeds and requirements.


2-39

Conceptual Design

• Business Needs and Requirements (BNR) are articulatedand confirmed by business management.

• BNR are elaborated by stakeholders at the businessoperations level into a set of Stakeholder Needs andRequirements (SNR).

• SNR are elaborated by requirements engineers into systemrequirements in the System Requirement Specification(SyRS).

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

System Requirement Specification (SyRS)


Requirements(SNR)

BusinessNeeds and

Requirements(BNR)

Conceptual Design

• The BNR, SNR and the SyRS are key elements of what iscalled the Functional Baseline (FBL).

• Conceptual Design ends with the System Design Review(SDR), which finalizes the initial FBL.

• SDR confirms the BNR, SNR and the SyRS, and provides aformal record of design decisions and design acceptance.

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Functional Baseline



2-40

Conceptual Design

C4. Conduct system-level synthesis

C5. Conduct System Design Review (SDR)

C1. Define businessneeds and requirements

Conceptual Design

C3. Define system requirements

BNR (PLCD & BRS)

Draft SyRS

SyRS

Initial FBL

To Preliminary Design

C2. Define stakeholderneeds and requirements

SNR (LCD & StRS)

C1.1.2 Identify business& project constraints

C1.1.3 Identifyexternal constraints

C1.1.1 Identifymajor stakeholders

C1.1 Identify major stakeholders and constraints

C1.2 Define business needs

C1.2.4 Define preliminarylife-cycle concepts

C1.2.2 Define preliminaryoperational scenarios

C1.2.3 Define preliminaryvalidation criteria

C1.2.1 Develop mission,goals and objectives

C1.3.1 Developcontext diagram

C1.3.2 Define system boundary

C1.3 Scope system

C1.1.4 Identifydesign constraints

C2. Define stakeholder needs and requirements

C1. Define business needs and requirements (BNR)

C1.3.3 Defineexternal interfaces

C1.4 Define business requirementsC1.4.4 Select preferred solution class

C1.4.2 Confirm compliance with business needs

C1.4.3 Evaluate available solution classes

C1.4.1 Identify available solution classes

C1.5 Finalise business needs and requirements (BNR)BNR

(PLCD andBRS)

C1.3.4 Endorsedraft business needs

C1.4.5 Definebusinessrequirements (BRS)

C1.5.4 Revisepreliminaryvalidation criteria

C1.5.2 Revise preliminary life-cycle concepts

C1.5.3 Revisesystem scope

C1.5.1 Revisepreliminaryoperational scenarios

C1.5.5 Endorsebusiness needs andrequirements (BNR)


2-41












C1.3 Scope system










(PLCD andBRS)








Identify major stakeholders

• Since their input to the system life cycle is crucial, carefulselection of appropriate stakeholders is fundamental to thesuccess of the project.

• It follows that, if a different set of stakeholders is nominated,the process will most likely end with a different set of systemrequirements.

• Users are invariably stakeholders and other stakeholdersmay include management, maintainers, logisticians, andclients.


2-42


• A stakeholder is commonly defined as someone who has astake in the project—that is, someone who is affected by thesystem in some way, or can affect the system in some way.

• In most systems this is not a useful definition since it is oftendifficult to find someone who is not affected by the system insome way.

• Even in a simple system such as an automatic tellermachine (ATM) network for a bank, there may be millions ofstakeholders by such a definition.

• In committee-based organizations such as public serviceorganizations, the number of potential stakeholders is almostlimitless.


• Conceptual Design cannot progress with such a definition:

– There is not sufficient time to engage with that many.

– It assumes that anyone affected by the system is asource of requirements—even business competitors

– Conceptual Design would therefore be at the mercy of theanyone who wants to contribute requirements, whetherthey are useful or not.

– Stakeholders will not be affected equally and they shouldnot therefore have equal rights in expressingrequirements.

• It is also useful to remember that no complex system can beoptimum to all parties concerned nor can all functions beoptimized.


2-43


• The first step of identifying stakeholders is therefore muchmore complicated than simply listing all those who could beconsidered to have a stake in the new system.

• While we must take into account anyone who is affected bythe new system, just because they are affected does notnecessarily mean that they are stakeholders.

• For example, the armed guards who distribute the cash in anATM system are clearly important—however, they are notstakeholders but are sources of constraints.

• Similarly, there are a number of parties such as the tellerswhose employment may be threatened by the new ATMs(and other competitor banks), who are clearly affected by thesystem, but they are not necessarily stakeholders.


• More usefully, a stakeholder an individual who has a right toinfluence the outcome of the system. Note that a stakeholderis also invariably affected by the system.

• This first act of stakeholder identification is thereforecrucial—business management must decide:

– who are to be considered as stakeholders (those that areto have the right to define the system).

– what leadership approaches are to be taken to addressindividuals or groups that may be disenfranchised by theimplementation of the new system (such as the banktellers in our ATM example)—they will certainly beaffected by the system but will not be nominated asstakeholders.


2-44












C1.3 Scope system










(PLCD andBRS)





C1.5.3 Revisesystemscope



Business and project constraints

• Constraints are requirements that are imposed on thesystem by circumstance, force, or compulsion—theytherefore limit absolutely the options open to a designer byimposing immovable boundaries and limits.

• Before focusing on the detail of the desired system, it isessential to identify the business and project constraints thatare relevant to the system and its acquisition.

• This analysis provides essential information about thedevelopment environment for the system and begins the top-down approach to system development.


2-45


• Business constraints include any organizational policies,procedures, standards or guidelines that guide systemdevelopment and procurement, such as:

– partnering relationships with other companies,

– use of established life-cycle processes,

– contracting policies,

– human resource limitations,

– budget restrictions, and

– specific management guidance to the project.


• Project constraints include budget and schedule constraints,but also the resource allocations to the project as well as anyexternally imposed deliverables and acquisition timeframes.

• Many companies have enterprise-wide standards forprocesses such as quality assurance and systemsengineering and these methodologies guide the manner inwhich projects can operate.

• Additionally, the enterprise may require the project to reportprogress in a particular way or to implement particularmetrics, tools and documentation procedures.


2-46












C1.3 Scope system










(PLCD andBRS)








Identify external constraints

• In addition to enterprise-imposed constraints, there are widerexternal constraints on system development that arise fromthe requirement for conformance to national andinternational laws and regulations, compliance with industry-wide standards, as well as ethical and legal considerations.

• Other external constraints include the requirement forinteroperability and interfacing to other systems.

• Additionally, projects might be constrained to conform toparticular engineering and technical standards; mandatedtoolsets; metrics; documentation sets and plan templates;technology use; and control and reporting mechanisms.

• Again, an important aspect of top-down design is tounderstand these constraints before considering lower-levelsystem requirements.


2-47












C1.3 Scope system










(PLCD andBRS)








Identify design constraints

• Design constraints include those factors that directly affectthe way in which the system design can be conducted. Ofcourse, a number of enterprise, project and externalconstraints (such as budgets, regulations, and standards)will flow down and be inherited as design constraints.

• Typical design constraints include the state-of-the-art ofrelevant technologies, the skill sets of available engineersand tradespersons, as well as extant methodologies andtools to assist in the design, development, construction, andproduction of the system.

• Additionally, bounds such as all-up weight may be a designconstraint for an aircraft system if it is to land on certainclasses of airfield.


2-48

A cautionary note WRT constraints

• Having identified constraints, work should not progress untileach constraint is tested and taken on knowingly into thenext activity.

• That is, we must convince ourselves that each constraint isactually a constraint and is inviolate.

• It also doesn’t necessarily follow that a current constraint willremain so, or should remain so without question.

• We should therefore consider what can be done to removethe constraint if that would facilitate the progress of theproject.

• The cautionary note is therefore that a constraint isn’t so justbecause some stakeholder or regulator said it is, or becauseit always has been so in the past.












C1.3 Scope system










(PLCD andBRS)









2-49

Define mission, goals and objectives

• Every project should begin with a concise statement of themission, elaborated by statements of the system-level goalsand objectives.

• “A problem is half-solved if properly stated.” John Dewey.

System MissionStatement

Requirement 1

Requirement 1.1

Requirement 1.2

Requirement 1.3

Requirement 2

Requirement 2.1

Requirement 2.2

Requirement n


• The mission statement should be quite short and may beexpressed in only a few lines, although it should have a wordor phrase for every important aspect of the system. Whilestakeholders often find it difficult to state the mission in asingle, short sentence, the project is doomed to failure if theowners cannot describe it succinctly at the outset.

• The mission statement is then expanded and qualified byshort declarative statements of the system goals andobjectives. Goals are normally relatively broad statements,each of which spawns a number of more-specific objectives(although these are sometimes treated in the reverse orderand objectives are considered to lead to goals).


2-50


• There are a number of simple principles that should beapplied when developing mission statements:

– A single sentence

– No conjunctions

– Contain no more than 5−7 concepts

– Include an ‘in order to’ clause

– Avoid physical terms

– Rely on iteration

Mission statement for the Aircraft System

• For the ACME Air example, the mission statement for ouraircraft might be:

“… to acquire a medium-sized aircraft that can provideclass-leading comfort to passengers between Class Xairfields on domestic and international routes, in order to …(profit?)”.

• In this example, the goals and objectives would then need toelaborate on such matters as what is meant by ‘class-leading’ and ‘medium-range’, how many passengers are tobe carried, as well as operational issues such as crewingand maintenance.


2-51












C1.3 Scope system










(PLCD andBRS)








Define preliminary operational scenarios

• Operational scenarios, or use cases, provide valuableguidance to the system designers and form the basis ofmajor events in the Acquisition Phase such as acceptancetesting of the system as it is introduced into service.

• Despite any more detailed technical verification andvalidation procedures, the system’s fitness for purpose isfundamentally related to its ability to perform in accordancewith the operational scenarios defined at this stage.

• In many cases it is also useful to define the various modes ofoperation for the system products under development.Designers need to understand if the system is to exist in anumber of different modes even if it is as simple as thedifference between the fully operational mode or the trainingmode.


2-52












C1.3 Scope system










(PLCD andBRS)








Define preliminary validation criteria

• An important top-level activity is the identificationand definition of preliminary validation criteria.

• Broadly, validation criteria encompass anymechanism by which the customer will measuresatisfaction with the products of the AcquisitionPhase.

• Key criteria include performance in each operationalscenario, safety, reliability, supportability,maintainability, ease of use, and time and cost totrain.


2-53

Measures hierarchy

• It is common to develop a hierarchy of measures, such as:

– critical issues (CI) that relate to the measurement ofsystem goals,

– critical operational issues (COI) that relate to themeasurement of objectives,

– measures of effectiveness (MOE) that relate to the nextlevel of the requirements hierarchy,

– measures of performance (MOP) at the next level, and

– down to verification statements at the lowest level.

Measures hierarchy

Critical Operational Issues(COI)

Measures of Effectiveness(MOE)

Measures of Performance(MOP)

Critical Issues(CI)

Technical Performance Measures(TPM)

selected

Verification Statements

selected


2-54

Validation cross reference matrix

• For a measure to be relevant, it must be able to be related toone or more requirements. One common way of doing this isto develop a matrix that relates measures to requirements.

• In fact, the use of relationship matrices is very common insystems engineering—we have traceability matrices thatshow inheritance of requirements, we have verificationmatrices to show how verification means relate to individualrequirements or groups of requirements, and we could havematrices to relate measures to requirements.

• The use of matrices is common to trace between a hierarchyof requirements, and there is a hierarchy of measures.

• Ideally, however, that traceability should be part of thedesign.

Requirements and measures hierarchies

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...

Requirements Hierarchy Measures Hierarchy

Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level m VerificationStatements

…. ….


2-55












C1.3 Scope system










(PLCD andBRS)








Define Preliminary Lifecycle Concepts

• Early in the Acquisition Phase, the stakeholders must givesome guidance on the lifecycle concepts related to thedevelopment, production, testing, distribution, operation,support, training and disposal of the system.

• While the systems engineering procedures that follow willensure a lifecycle focus, it is important that the stakeholdersfocus on the major cost drivers that will impact on thesupportability of the system. There are a number of lifecycle-related trade-offs at a business-case level.


2-56

Define Preliminary Lifecycle Concepts

• For example, consider an inexpensive dashboard-mountedGlobal Positioning System (GPS) for a large truckingcompany.

• Since the item is to be procured in large numbers at a lowcost, it may be deemed as part of the business case that itwould not be cost-effective to implement a repair system fordefective items, which would be discarded when broken.

• The consideration doesn’t stop there, however. If that policywas to be adopted, there would still be a need to inspect‘broken’ items before being discarded to ensure that theywere indeed broken, not just subject to problems such asfinger-faults or sticking buttons that could be rectified simply.If technical resources are to be applied to inspection,perhaps the additional cost of slightly more detailed trainingmay allow some items to be repaired.

Preliminary Acquisition Concept

• Based on the business operational needs for the proposedsystem, business management define the proposedacquisition concept.

• Any business needs for acquisition are articulated, such as:budget and schedule, preferred (and perhaps prohibited)supply sources, types of contract desired, relevant existingcontractual arrangements, any relevant existing acquisitionsupport arrangements, program/project managementconsiderations, reporting issues, and relationship to othersystem acquisitions within the organisation.

• This preliminary acquisition concept is continually refined—first, after the feasibility analysis; then, after participants havebegun to consider their needs and requirements; and then,at every major review as the design continues.


2-57

Preliminary Deployment Concept

• In the Preliminary Deployment Concept, businessmanagement outline the issues surrounding the deploymentof the system (to the extent that they are concerned with theintroduction into service of this system).

• For example, business management may dictate the natureof transition arrangements between an existing andreplacement system, since business continuity is at riskduring this period.

• Additionally, the Preliminary Deployment Concept mayaddress issues such as transition between facilities, trainingof operational personnel (and possibly engaging new staffand retiring others), and transition support arrangements.

Preliminary Support Concept

• The Preliminary Support Concept will capture the needs ofbusiness management for the support of the systemthroughout its life cycle. Issues addressed would includerelevant support policies and procedures; any relevantexisting support arrangements; the support environment;desired maintenance levels and cycles; and the anticipatedimpact of the proposed system on support facilities,equipment, personnel, and training.

• It should be noted that the consideration of support conceptsmust be made in the context of achievement of the capabilityrequired to meet operational scenarios (which is why thepreliminary scenarios are developed first).


2-58

Preliminary Retirement Concept

• When considering the retirement aspects of the systemduring its design, it is useful to undertake three broad tasks:identify the reasons for potential disposal, identify potentialdisposal methods for the system, which then allowsconceptual designers to identify design issues that may arisefrom the consideration of each method.

• We will discuss the retirement phase later.












C1.3 Scope system










(PLCD andBRS)









2-59

Context diagram

• Collectively, these previous few activities are called scopingthe system.

• To assist with the scoping process, a tool called a contextdiagram may be used to illustrate the related systems,relevant regulatory environments, stakeholders, externalsystems, interfaces, and so on.

• Different systems may of course have significantly differentcontext diagrams.

This is NOT a context diagram

SystemUnder

Consideration

How does this system fit in with the rest of the world?

CDD Guide v2.0


2-60

Context diagram

Maintainers ?

Power entrypanel

Powerpoint

Power DistributionSubsystem

HouseSystem

AlarmSystem

PSTN

Resident

Monitoring Agent Monitoringsystem

Power Grid

Police Neighbours

Environment

Context diagram

Maintainers ?

Power entrypanel

Powerpoint


HouseSystem

AlarmSystem

PSTN

Resident


Power Grid

Intruder

Police Neighbours

Environment


2-61

Guidance for context diagrams

• Identify all the possible candidate elements for the contextdiagram (textual list, sticky paper on a board).

• Group similar elements in accordance with their relationshipwith / impact on / interface with the SOI.

• The SOI is shown as a goose-egg in the centre of thediagram—nothing inside the system is shown.

• The groupings are then drawn as goose-eggs:

– two overlapping goose-eggs represent an interface ,

– an arrow between illustrates an influence of one groupover the other (in the direction of the arrow).

• Move around the boundary verifying each relationship as it isdepicted. The diagram is adjusted as necessary and theprocess continues until the diagram is complete.












C1.3 Scope system










(PLCD andBRS)









2-62

Define system boundary

• Definition of the system boundaries is also critical to thesuccess of the fielded system.

• It is essential that these boundaries are defined early in theAcquisition Phase so that it is clear which system elementsare under the design control of the project and which areoutside the control.

• This is also particularly important to the project manager whois vitally concerned with defining what is to be included in thesystem as well as what is to be excluded.

System boundary

• The boundary of a system is normally straightforward todescribe in physical terms (such as a fence line, or externalbuilding walls), but it is often necessary to describe theboundary in conceptual or logical terms as well.

• Additionally, although we traditionally describe the boundaryin terms of what is inside the boundary—that is, what isincluded inside the system—it is often useful to describewhat isn’t inside the boundary.

• This is particularly useful when there are a number ofelements that may commonly be assumed to be part of thesystem but are not in this particular case.


2-63












C1.3 Scope system










(PLCD andBRS)








Define external interfaces

• Interfaces with existing or future external systems must alsobe defined as these will place considerable requirements onthe system under development.

• While these external systems are not directly related to theproject, the success of the fielded system is oftendetermined by its ability to interface to its externalenvironment.

• For example, while it is possible to build a perfectlyfunctional aircraft without consideration of air traffic controlregulations, the aircraft would be useless because it wouldnot be allowed to operate.


2-64

Consider external interfaces

• The definition of an interface requires considerably moredetail than simply identifying and naming the interface.Broadly there are three main steps in interface definition:– Interface description. The interface is given a name, short

title and identifier. The nature of the interface is describedin terms of who, what, when, where, why, how.

– Interface impact analysis. The interface is analyzed interms of its impact on the system. In particular, anyconstraints imposed by the system are identified. A riskanalysis is conducted to determine the impact of theinterface on the operation and design of the system.

– Interface control analysis. Each external interface must beanalyzed to determine the extent to which it can becontrolled so that designers and operators of the systemare not at the mercy of its external interfaces.

External interfaces

Power entrypanel

Powerpoint


HouseSystem

AlarmSystem

PSTN

Resident


Power Grid

Intruder

Police Neighbours

Environment

E01

E02

E03E04

E05/6

E07

E08E09

E10


2-65












C1.3 Scope system










(PLCD andBRS)








System feasibility analysis

• A feasibility analysis should answer questions such as:– Is the system really needed?– What would be the consequences if the system wasn’t

developed?– How will the system contribute to business objectives?– What critical processes must support the system?– What critical processes need not be supported by the

system?– How will the system affect other systems?– What feasible options are there?– What likely technology limitations will apply?– Is there sufficient budget available?


2-66

Feasibility analysis—solution class

• A solution class is a generic solution type, which does notincorporate any specific implementation elements ormanufacturer’s solution. Examples include fighter aircraft,airborne radar, ground-based surveillance, space-basedcommunications, ground transportation, and aircraft carrier.(CDD Guide v2.0)

Long-range Communications

• Cable• Microwave radio relay• HF Communications• Satellite

Surveillance of air-sea gap

• Sky-wave radar• Surface-wave radar• Airborne sensors• Satellite sensors

ACME Aircraft feasibility analysis

• ACME wants to service selected short-to-medium domesticand international routes but doesn’t have the airframes to doit. Based on this simple statement of Business Needs, thefeasible alternative solution classes might be:

– lease or buy an existing aircraft, as commercial-off-the-shelf (COTS);

– lease or buy and modify an existing aircraft (modifiedCOTS);

– contract to have a new aircraft developed;

– outsource the operation to another airline; or

– don’t chase business over these medium routes.


2-67












C1.3 Scope system










(PLCD andBRS)








Define business requirements

• The feasibility analysis and selection of the resultant desiredsolution class may require the draft business needs to berevisited in light of the more-detailed investigations of thefeasibility analysis.

• The hierarchical representation of business needs (mission,goals, objectives) is now further elaborated (decomposedand derived) and formalised into a balanced set of businessrequirements, which are recorded in the BRS.

• The RBS framework is very useful to provide a hierarchicaldescription of the requirement set.


2-68

RBS for the security alarm example

1.1 Deter in neighbourhood1.2 Deter in yard1.3 Deter in Residence1.4 Prevent system disabling

2.1 Detect Un/Authorised Entry2.2 Record Entry Time2.3 Record Entry Location2.4 Detection Failure Rate

3.1 Classify Un/Authorised Entry3.2 Record Classification Details3.3 Record classification3.4 False alarm rate3.5 Adjustable sensitivity

4.1 Report Entry Local4.2 Report Entry Neighbourhood4.3 Report Entry Agent4.4 Modify Agent Details

5.1 Suitable for Residences5.2 Easy to use5.3 Scalar/modular/upgradeable5.4 Relocatable within Residence5.5 Sustainable over Life

Domestic Security Alarm

1.Deter

Unauthorised Entry

2.DetectEntry

3.Classify

Entry

4.Report

Unauthorised Entry

5.Provide

Market-leading Alarm

Conceptual Design




Conceptual Design


BNR (PLCD & BRS)

Draft SyRS

SyRS

Initial FBL



SNR (LCD & StRS)


2-69

C2.1 Define stakeholder needs

C2.2 Define stakeholder requirements

C2.2.4 Define validationcriteria

C2.2.2 Conducttrade studies

C2.2.3 Define stakeholderrequirements (StRS)

C2.2.1 Identifytrade studies required

C2.3.1 Reviseoperational scenarios

C2.3.2 Revise life-cycle concepts

C2.3 Finalise stakeholder needs and requirements (SNR)


C2. Define stakeholder needs and requirements (SNR)


SNR(LCD and StRS)

C2.3.4 Endorsestakeholder needsand requirements (SNR)

C2.1.4 Developlife-cycleconcepts

C2.1.2 Refinemission, goals, objectives

C2.1.3 Develop operational scenarios

C2.1.1 Identify stakeholders

C2.1.5 Endorse stakeholder needs

C1. Define business needs and requirements

Define stakeholder needs and reqts













SNR(LCD and StRS)








Define stakeholder needs


2-70













SNR(LCD and StRS)








Trade studies

Trade studies

• The definition of the scope of the system is greatly assistedby the use of trade-off studies (or trade studies). If we arenot careful, the requirements derivation (hierarchicaldevolution) process will develop an RBS that is far too broadfor us to cope with.

• Design is about choice and we should be careful to ensurethat we make choices whenever we can.

• Having made a choice of a way ahead, therefore, we arelimiting the scope as well as limiting the requirementshierarchy below us.

• Informed choices in design are made through trade studies.


2-71

Trade study process

• A generic trade study process might be:

– Definition of objective and scope for the trade study.

– Identification of alternative solutions.

– Nomination of selection criteria.

– Determination of criteria weighting.

– Scoring function.

– Evaluation of alternatives.

– Sensitivity study.













SNR(LCD and StRS)








Define stakeholder requirements


2-72

Define stakeholder requirements

• A reader of the StRS should be able to understandcompletely:

– the likely applications or missions for which the system isintended;

– the major operational characteristics to be exhibited bythe system;

– the operational constraints that limit the design anddevelopment of the system;

– the external systems and interfaces;

– the operational and support environment; and

– the support concept to be employed.

StRS example for ACME Air

• In our aircraft development example, the StRS will containsuch statements as:

– The Aircraft shall be capable of operating from a Class Xairport.

– The Aircraft shall provide class-leading comfort forpassengers.

– The Aircraft shall be turned around to its next flight within30 minutes.


2-73

StRS example for ACME Air

The Aircraft shall provide class-leading comfort forpassengers.

• Note that the StRS requirement statements are similar inconstruction and language to those that will follow in theSyRS, but they do not have to be as precise and theverification requirements can be less stringent.

• That is, for example, class-leading comfort is not directlyverifiable, but it is sufficiently bounded for the next level ofdesign (conducted by the system designers) to understandwhat quantitative statements must be made that, whenimplemented, will lead to ‘class-leading’ comfort.













SNR(LCD and StRS)








Finalise & Endorse SNR


2-74

Capability system

• Earlier we saw that, because a system is often seen as anoperational capability, it is commonly referred to as acapability system comprising the major equipment solution(hardware and software), organization, personnel, collectivetraining, facilities, data, support system (including supplies),and operating procedures and organizational policies.

• At this point in the design, the business owners andstakeholders must agree on how the elements of thecapability will be acquired.

• There could be a single SyRS developed for the wholecapability system or there could be one SyRS developed foreach element of the capability system, or for anycombination of elements.

AT&E

AT&E

AT&E

AT&E

AT&E

AT&E

Facilities

Training

Support

Supplies

Personnel

SyRS

Requirements Engineering

Capability System Development

Acquisition Phase Utilization Phase

In-service

DeliveredCapabilitySystem

StRSOrganisation

Major System AT&E

OT&E

Validation

Verification

Capability system


2-75

Conceptual Design




Conceptual Design


BNR (PLCD & BRS)

Draft SyRS

SyRS

Initial FBL



SNR (LCD & StRS)

C3.2.2 Define performancerequirements

C3.2.3 Define verificationrequirements

C3.2.1 Define functional /non-functional requirements

C3.2.4 Assign rationale




C3.2 Perform requirements analysis and allocation

C3.1 Establish system requirements framework

C3.3 Draft System Requirements Specification (SyRS)

C3.4 Define Technical Performance Measures (TPM)

C3.5 Conduct System Requirements Review (SRR)

Draft SyRS

Define requirements


2-76

System Requirements Analysis

• Define Functional Requirements– FFBD concept—note: hierarchical nature of the diagram,

numbering system, relationships, inputs and outputs

2.0 3.0

4.0 5.0

Higher-level functions

1.0

Lower-level functions

5.5.1 5.5.2 5.5.3

5.5.4 5.5.5

Lower-level functions

5.1 5.2 5.3

5.4 5.5

3.0

4.0

5.3

5.4

Example functional requirements

Turning around in 30 minutes:

1. Aircraftlands

2. Aircrafttaxis from

runway to terminal

3 Aircraft turns around in 30

minutes

5. Aircrafttakes off


terminal to runway

1. Aircraftlands


runway to terminal

3.1 Unloadpassengers, freight,

luggage (PFL)

3.2 LoadPFL

3.3 Conductrefuelling

3.4 Maintainaircraft



terminal to runway

3.0 – Aircraft turns around in 30 minutes

3.x Otherturn-around

functions


2-77













Draft SyRS

Define performance requirements

Define performance requirements

• Once the functions have been identified and groupedaccording to the agreed RBS, the systems engineers andstakeholders must agree on the performance-relatedparameters that the new system must achieve. Havingdecided what the system must do, the designer must nowdetermine how well the system is to perform each of thosefunctional requirements. A good discipline is to ensure that,every time a functional requirement is articulated, acorresponding performance statement is made.

• Most of the operational functions will have obviousperformance parameters associated with them such asspeed, accuracy, endurance, and acceleration. Support andother functions also require parametric definition to definecompletely the requirement.


2-78



C3.2.1 Define functional /non-functional requirements C3.2.4 Assign rationale









Draft SyRS

Define verification requirements


• The definition of requirements is not complete untilverification requirements are also included. It is goodpractice to ensure that, every time a functional/nonfunctionalrequirement is articulated, a corresponding verificationstatement is made.

• It is often difficult to write verification requirements forsystem-level functions, but the discipline of doing so isimportant since there is little point in stating a requirementfor a function without consideration of how the function is tobe tested.

• An additional benefit of adhering to the discipline at thisstage is that test plans become much easier to writebecause the tests required at any level can be considered asan aggregation of the verification requirements at that level.


2-79


• It is not common to include verification statements in theSyRS. In many instances, the function and performancestatements are included in the SyRS and the verificationrequirements are included in a separate document—such asa test concept document, or through a verification crossreference matrix (VCRM).

• This represents the view of the older style of specification. Amore modern standard, EIA-632 defines a specification as:‘A document that contains specified requirements for aproduct and the means to be used to determine that theproduct satisfies these requirements’.

• Note, therefore, that the two parts are necessary—that is thefunctional and performance requirements as well as themeans to test them (the verification requirements).


• Although verification statements are not common, it isreasonably common to attach a letter after each functionalrequirement to show the methods that is proposed to beutilised to accomplish verification: Analysis [A];Demonstration [D]; Inspection [I]; and Test [T].

• While the attachment of a letter to illustrate the verificationmeans, it is much better practice to write a verificationstatement to make the verification means more specific.

• That is particularly true for the analysis [A] and test [T]verification means because the use of a single letter begs anumber of important questions that really should beanswered at the time the requirement is written.


2-80













Draft SyRS

Assign rationale

Assign rationale

• The rationale explains why each requirement is necessaryand the logic behind performance imperatives assigned tothe requirement.

• It is also useful to record the rationale behind eachrequirement, because:

– The requirement should be able to be justified.

– It helps explain the requirement which may avoidambiguity.

– Communicates intent to lower-level designers.

– Assists in the tracing required for requirementsmanagement.

• Example : Rear Windscreen Design


2-81













Draft SyRS

Analysis and allocation

Analysis and allocation example

• Earlier, in our aircraft development example, we saw that theStRS will contain such statements as:

– The Aircraft shall be capable of operating from a Class Xairport.

– The Aircraft shall provide class-leading comfort forpassengers.

– The Aircraft shall be turned around to its next flight within30 minutes.

• From these selected StRS requirements, a number ofsystem requirements will be elaborated (decomposed andderived).

• Note that there is no intention to be complete—the examplestatements are simply offered as typical of the sort ofrequirements that would be generated.


2-82


1. Operate from Class X Airports

1.1 Operate from specified minimum runway length

1.2 Operate from specified runway surface

1.3 Operate with specified maximum allowable aircraft weight

1.4 Operate with specified essential navigation aids

1.5 Operate with specified essential automatic landingsystems

1.6 Operate with specified essential communications systems

Note that a numbering convention has been added to assistwith traceability during later design activities.


2. Provide class-leading comfort to passengers

2.1 Provide class-leading seating

2.2 Provide class-leading entertainment systems

2.3 Provide class-leading bathroom facilities

2.4 Provide class-leading catering services


2-83


3. Turn the aircraft around in less than 30 minutes

3.1 Load passengers, cargo and catering in < 30 minutes

3.2 Unload passengers, cargo and catering in < 30 minutes

3.3 Conduct refuelling operations in < 30 minutes

3.4 Conduct operational maintainability in < 30 minutes













Draft SyRS

Define TPM


2-84

Technical Performance Measures (TPM)

• TPMs are identified early in the system development effortand are continually monitored and tracked throughout thesystem development as a means of managing the risksassociated with system development.

• The first step in identifying TPMs is to identify thequantitative parameters that require tracking throughout theproject.

• Throughout the design process, a list of TPMs andassociated metrics should be maintained along with thepriority, the ‘benchmark’ objective, and the current level ofachievement and projected/estimated performance.

• Once the parameters have been identified, they should beprioritized in terms of their importance as viewed by thecustomer. A second list of TPMs may be established,prioritized and maintained by the contractor.

Technical Performance Measures (TPM)

• IEEE-STD-1220 states that appropriately selected TPMs canbe used to:

– assess conformance to requirements, assessconformance to levels of technical risk,

– trigger development of recovery plans for identifieddeficiencies, and

– examine marginal cost benefits of performance in excessof requirements.

• Bands of acceptable variation from the expected value willalso be determined and agreed upon so that unnecessaryrisk management actions are not instigated at the first sign ofa very minor variation. The variation bands will be typicallylarge in the early stages of the design but will becomeincreasingly narrower as the design matures.


2-85













Draft SyRS

Conduct System Requirements Reviews (SRR)

System Requirements Reviews (SRR)

• System Requirements Reviews (SRR) may be conductedperiodically throughout Conceptual Design to verify andapprove versions of system-level requirements.

• The aim of the SRRs is to monitor and approveprogressively the system-level requirements that aredeveloped on the way to the Initial FBL.

• Progressive reviews allow the requirements analysis effort tocontinue to lower levels in the logical hierarchy in the RBSby providing validation of the higher levels of abstraction,providing a firm start point for the subsequent analysis.

• SRRs may or may not be considered formal reviews.


2-86

System Requirements Reviews (SRR)

Requirementselicitation & elaboration

Requirementsanalysis & negotiation

Requirementsallocation

Requirementsvalidation

SRRSRRSDR

Informal requirements

Agreedrequirements

Validatedrequirements

document

Draft requirements document

Conceptual Design




Conceptual Design


BNR (PLCD & BRS)

Draft SyRS

SyRS

Initial FBL



SNR (LCD & StRS)


2-87

RefinedSyRS



C5. Conduct System Design Review

C4.1 Identify alternative system solutions

C4.2 Solicit information for each solution

C4.3 Evaluate system solutions

C4.4 Select preferred system solution

C4.5 Update System Requirement Specification (SyRS)

System-level synthesis


• We know that synthesis is another name for evolving design.• System-level synthesis takes the set of system requirements

and determines potential solutions—a broad system-levelarchitecture that is representative of the final system.

• The process of system-level synthesis uses a well-established process of trade-off analysis:– Identify the potential solutions to the problem.– Weigh up the relative pros and cons of each solution

against a set of selection criteria.– Select the preferred system-level solution to the problem.


2-88

System synthesis and evaluation

EvaluationCriteria

EvaluationFramework

SE ManagementRisk Analysis

TPMLife-cycle costing

QATest & Evaluation

MaintenanceILSetc

AlternativeAnalysis & Evaluation

PreferredSystem Architecture

Development ofArchitectural Options

Requirements EngineeringFunctional Analysis and Allocation


• A good example of system-level synthesis is the tenderingprocess adopted by many organisations

• Requirements analysis provides the draft specification thatforms a central part of a request for tender or RFT

• Potential contractors respond to the RFT with their proposedsystem-level solutions– These solutions vary in cost and in compliance with the

draft specification.– Remember the draft specification contains some latitude,

which is expressed using words such as mandatory,important and desirable.

• The customer evaluates the responses and selects thepreferred system-level solution.


2-89


• The preferred solution will be selected based on a number ofissues including compliance with requirements.

• Following selection, the customer and preferred tenderer willneed to meet to massage both the solution and therequirements until a consensus is met.

• This is often called tender negotiation.• The draft SyRS will be refined at this stage and often

changes will need to be made.


• Typical changes to the draft SyRS include:– Removal of terms such as mandatory, important and

desirable.– Removal of bands of acceptable performance and

replacement with agreed minimum level of acceptableperformance.

– Addition, modification, or deletion of requirements• This may involve revisiting the StRS.• This will be a test of our traceability.• We must re-involve the stakeholders here because

systems engineers don’t necessarily own therequirements.


2-90


• At the end of system-level synthesis, we have:– A refined SyRS reflecting exactly:

• what the proposed system will do (function).• how well it will do it (performance).• How it will be verified (verification).• under what conditions it will operate (constraints).• what interfaces into and out of the system will be

present (scope/context).– A broad system-level architecture describing how we

propose to meet the SyRS.– The refined system specification is now in a much

stronger position to represent what we call the initialfunctional baseline or FBL.


• A few words on the refined SyRS:– The refined SyRS is perhaps the most important of all

systems engineering documents.– It is the source of reference for all future work and

documentation.– If solid, it stands the remaining effort in good stead.– Errors, omissions, conflicts and so on will now start

flowing into the following systems engineering stages.– The later these problems are discovered, the more

expensive and less likely the rectification.– …


2-91


• A few words on the refined SyRS:– …– The specification is traceable back to the StRS.– Systems engineers must ensure this traceability and must

ensure that achievement of all of the system specificationrequirements automatically results in satisfaction of theStRS.

– Sounds obvious, but always check that the sum of theSyRS requirements = the StRS requirements.

– This is a challenge always faced by systems engineers asthe broad StRS statements are translated into a series ofmore detailed requirements.

Conceptual Design




Conceptual Design


BNR (PLCD & BRS)

Draft SyRS

SyRS

Initial FBL



SNR (LCD & StRS)


2-92


• At the end of Conceptual Design the System Design Review(SDR) provides the following from a systems engineeringperspective:

– formal confirmation that the logical design meets thebusiness and stakeholder requirements;

– a formal record of design decisions and acceptance;

– a formalized communication of the intended designapproach to the major players in the design effort;

– approval of the V&V plans for the system; and

– approval of the Systems Engineering Management Plan(SEMP) and supporting plans.


• In addition to review of the systems engineering effort, anumber of review activities will most likely be performed atSDR to support project management:

– confirmation that the system to be procured aligns withthe customer’s organizational goals;

– the Project Management Plan (PMP) is refined;

– cost estimates are refined;

– the schedule is refined and is confirmed to be consistentwith the cost and risk goals for the project; and

– confirmation that all required project resources areavailable.


2-93

C5. Conduct System Design Review



C5.1 Prepare and review documentation

C5.2 Prepare agenda

C5.3 Confirm entry criteria met

C5.4 Confirm system-level solution

C5.5 Agree action items

Approved InitialFunctional Baseline

C5.6 Confirm exit criteria met


Introduction toProject Management


2-94

Scope

• To provide an understanding of the processes and practicesassociated with project management.

– Project Management Framework

– Integration Management

– Scope Management

– Time Management

– Cost Management

– Quality Management

– Human Resource Management

– Communications Management

– Risk Management

– Procurement Management

– Stakeholder Management

Project Management Framework


2-95

Introduction

• Project management is still a relatively young, emergingprofession.

• While there is some considerable agreement to the tasksthat should be conducted, many of the terms are still notstandardised.

• We will highlight the major practices and use the mostcommonly accepted terms.

• In particular, we discuss project management within theframework adopted in the Project Management Body ofKnowledge (PMBOK©)*.

* A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute, Upper Darby, PA, 2013.

What is a Project?

• Normally within an organisation there are the people whoconduct the normal operations of an organisation (the tellersin bank, for example) and those that perform projectsundertaken to improve the organisation and its services (theproject managers who roll out the new ATM network, forexample).

• While the distinction between the two is occasionally blurred,operations tend to be ongoing and repetitive, while a projectis:

a temporary endeavour undertaken to create a unique product, service or result.*



2-96

What is a Project?

• Temporary:

– A project has an identifiable start and end date.

– Temporary relates to the activity, not the product.

– Temporary does not indicate any particular duration—some projects are very short (of the matter of days),others can take decades.

• Unique:

– The unique nature of a project arises because there isalways something different about the activities undertakenduring a project.

– For example, building a new house is unique because ofdifferent owners, block of land, design, timeframe, etc.

Project Size

• A project therefore applies to a wide range of activitiesundertaken by an organisation over and above its normaloperational activities.

• Notice that nothing we have said refers to the size of aproject—a project may only involve a few people and asmall number of resources, or thousands of people andbillions of dollars.

• A project can be of any size—from baking a cake to buildingthe Channel Tunnel—whatever the size, the principles wediscuss here are applicable.

• We do need, however, to consider the size of a project (andtherefore the amount of management required) at thebeginning when we are establishing project processes andprocedures.


2-97

What is a Project?

• Typical projects may be:

– Developing a new product or service

– Changing the organisational structure, staffing levels orculture

– Introducing a new operating procedure into anorganisation

– Designing a new city

– Modifying an engine to provide greater power

– Constructing a building or a complex

– Drilling a well in a third-world village

– Running for local office

• In short, a project may be any unique, temporary endeavour.

What is a Project?

• A project is distinctive because it has:

– A distinct start and finish

– A life cycle ( a number of distinct phases between thestart and end)

– A budget and an associated cash flow

– Unique activities

– Use of resources

– A single point of responsibility (the project manager)

– Team roles

* R. Burke, Project Management: Planning and Control Techniques, Burke Publishing, 2003.


2-98

What is Project Management?

• Project management is:

the application of knowledge, skills, tools and techniques to project activities to meet project requirements.*

• Note: “meet”, not “meet or exceed”

• We achieve project management through a number of well-defined processes (ten project management knowledgeareas*) that we discuss in more detail throughout thiscourse.

• They are introduced here to provide an overview of projectmanagement.


What is Project Management?

SCOPE / QUALITY

CUSTOMERSATISFACTION

TIME COST


2-99

Program and Portfolio Management

• A program is defined as a group of related projects managedin a coordinated way to obtain benefits and control notavailable from managing them individually.

• A portfolio is a collection of projects or programs and otherwork that are grouped together to facilitate effectivemanagement of that work to meet strategic businessobjectives.


Who is the Project Manager?

• The project manager is the single point of responsibility for aproject and is the person assigned by the performingorganisation to achieve the project objectives.

• The project manager integrates and coordinates all thecontributions of the project team and guides themsuccessfully to completion.

• Project managers need good:

– General management and administration skills

– Leadership skills

– Planning, problem-solving and decision-making ability

– Communications (written and verbal) skills

– Negotiation skills

– Technical skills


2-100

PMBOK Knowledge Areas

• Integration Management

• Scope Management

• Time Management

• Cost Management

• Quality Management

• Human Resource Management

• Communications Management

• Risk Management

• Procurement Management

• Stakeholder Management

Project Integration Management

• Ensures all project elements are integrated and coordinatedand conflicting alternatives and expectations are managed.

• Key is development of the Project Plan.

• Once the plan is in place, the project must be executed inaccordance with the plan.

• Since the Project Plan will be subject to changes from time totime and some form of change control is required.


2-101


* A Guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute, Upper Darby, PA, 2013.

1.1 Develop Project Charter

.1 Inputs.1 Project SOW.2 Business case.3 Agreements.4 Enterprise environmental

considerations.5 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Facilitation techniques

.3 Outputs.1 Project charter

1.2 Develop Project Management Plan

.1 Inputs.1 Project charter.2 Outputs from other processes.3 Enterprise environmental


.2 Tools and Techniques.1 Expert judgement.2 Facilitation techniques

.3 Outputs.1 Project management plan

1.3 Direct and ManageProject Execution

.1 Inputs.1 Project management plan.2 Approved change requests.3 Enterprise environmental


.2 Tools and Techniques.1 Expert judgement.2 PMIS.3 Meetings

.3 Outputs.1 Deliverables.2 Work performance data.3 Change requests.4 Project management plan

updates.5 Project documentation updates

ProjectIntegration Management


* A Guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute, Upper Darby, PA, 2013.

1.4 Monitor and ControlProject Work

.1 Inputs.1 Project management plan.2 Schedule forecasts.3 Cost forecasts.4 Validated changes.5 Enterprise environmental


.2 Tools and Techniques.1 Expert judgement.2 Analytical techniques.3 PMIS.4 Meetings

.3 Outputs.1 Change requests.2 Work performance reports.3 Project management plan updates.4 Project document updates

1.5 Perform IntegratedChange Control

.1 Inputs.1 Project management plan.2 Work performance reports.3 Change requests.4 Enterprise environmental

factors.5 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Meetings.3 Change control tools

.3 Outputs.1 Approved change requests.2 Change log.3 Project management plan updates.4 Project document updates

1.6 Close Project or Phase

.1 Inputs.1 Project management plan.2 Accepted deliverables.3 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Analytical techniques.3 Meetings

.3 Outputs.1 Final product, service, or result

transition.2 Organisational process assets

updates

ProjectIntegration Management


2-102

Project Scope Management

• Ensures all work necessary to complete the project isincluded in scope.

• Unnecessary work is omitted.• Scope planning and definition are an important part of

scope management.• Makes use of well known SE tools such as RBS/WBS.• As with Integration, once plans have been established, they

need to be verified.• This represents formalised approval of the project and its

scope by all stakeholders.• Changes must be managed following approval.• Remember:

– Change isn’t necessarily bad but uncontrolled change is.


2.2 Collect Requirements

.1 Inputs.1 Scope management plan.2 Requirements management plan.3 Stakeholder management plan.4 Project charter.5 Stakeholder register

.2 Tools and Techniques.1 Interviews.2 Focus groups.3 Facilitated workshops.4 Group creativity techniques.5 Group decision making

techniques.6 Questionnaires and surveys.7 Observations.8 Prototypes.9 Benchmarking.10 Context diagram

.3 Outputs.1 Requirements documentation.2 Requirements traceability matrix

2.3 Define Scope

.1 Inputs.1 Scope management plan.2 Project charter.3 Requirements documentation.4 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Product analysis.3 Alternatives identification.4 Facilitated workshops

.3 Outputs.1 Project scope statement.2 Project documentation updates

ProjectScope Management

A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute, Upper Darby, PA, 2013.

2.1 Plan Scope Management

.1 Inputs.1 Project management plan.2 Project charter.3 Enterprise environmental factors.4 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Meetings

.3 Outputs.1 Scope management plan.2 Requirements management plan


2-103


2.5 Validate Scope

.1 Inputs.1 Project management plan.2 Requirements documentation.3 Requirements traceability matrix.4 Verified deliverables.5 Work performance data

.2 Tools and Techniques.1 Inspection.2 Group decision-making techniques

.3 Outputs.1 Accepted deliverables.2 Change requests.3 Work performance information.4 Project document updates

2.6 Control Scope

.1 Inputs.1 Project management plan.2 Requirements documentation.3 Requirements traceability matrix.4 Work performance data.5 Organisational process assets

.2 Tools and Techniques.1 Variance analysis

.3 Outputs.1 Work performance information.2 Change requests.3 Project management plan updates.4 Project document updates.5 Organisational process assets

updates



2.4 Create WBS

.1 Inputs.1 Scope management plan.2 Project scope statement.3 Requirements documentation.4 Enterprise environmental


.2 Tools and Techniques.1 Decomposition.2 Expert judgement

.3 Outputs.1 Scope baseline.2 Project documentation updates

Project Time Management

• Includes processes required to ensure the timely completionof the project.

• Also called schedule management:

– Starts with activity definition where all project activities areidentified.

– The sequence that these activities will be conducted isthen identified (including parallel).

– The duration of each activity is estimated.

– The schedule results.

• SE is heavily involved with time management.


2-104


• The schedule then needs to be managed and controlledthroughout the project.

• Many computer-aided tools are available to assist (forexample, PERT and CPM software).

• Tools don’t manage the schedule, they merely assist theproject manager.

• Experience and judgement remain the premier timemanagement tools.


3.2 Define Activities

.1 Inputs.1 Schedule management plan.2 Scope baseline.3 Enterprise environmental factors.4 Organisational process assets

.2 Tools and Techniques.1 Decomposition.2 Rolling wave planning.3 Expert judgement

.3 Outputs.1 Activity list.2 Activity attributes.3 Milestone list

3.3 Sequence Activities

.1 Inputs.1 Schedule management plan.2 Activity list.3 Activity attributes.4 Milestone list.5 Project scope statement.6 Enterprise environmental factors.7 Organisational process assets

.2 Tools and Techniques.1 Precedence diagramming method.2 Dependency determination.3 Leads and lags

.3 Outputs.1 Project schedule diagrams.2 Project documentation updates

ProjectTime Management

A Guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute, Upper Darby, PA, 2013.

3.1 Plan Schedule Management


.2 Tools and Techniques.1 Expert judgement.2 Analytical techniques.3 Meetings

.3 Outputs.1 Schedule management plan


2-105


3.5 Estimate Activity Durations

.1 Inputs.1 Schedule management plan.2 Activity lists.3 Activity attributes.4 Activity resource requirements.5 Resource calendars.6 Project scope statement.7 Risk register.8 Resource breakdown structure.9 Enterprise environmental factors.10 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Analogous estimating.3 Parametric estimating.4 Three-point estimating.5 Group decision making techniques.5 Reserve analysis

.3 Outputs.1 Activity duration estimates.2 Project document updates

3.6 Develop Schedule

.1 Inputs.1 Activity lists .2 activity attributes.3 Project schedule network diagrams.4 Activity resource requirements.5 Resource calendars.6 Activity duration estimates++

.2 Tools and Techniques.1 Schedule network analysis.2 Critical path method.3 Critical chain method.4 Resource optimization technique.5 Modelling techniques.6 Adjusting leads and lags.7 Schedule compression.8 Scheduling tool

.3 Outputs.1 Schedule baseline.2 Project schedule.3 Schedule data.4 Project calendars.5/6 Project plan/document updates



3.4 Estimate Activity Resources

.1 Inputs.1 Schedule management plan.2 Activity lists.3 Activity attributes.4 Resource calendars.5 Risk register.6 Activity cost estimates.7 Enterprise environmental factors.8 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Alternative analysis.3 Published estimating data.4 Bottom-up estimating.5 Project management software

.3 Outputs.1 Activity resource requirements.2 Resource breakdown structure.3 Project document updates


3.7 Control Schedule.1 Inputs

.1 Project management plan

.2 Project schedule

.3 Work performance data

.4 Project calendars

.5 Schedule data

.4 Organizational process assets.2 Tools and Techniques

.1 Performance reviews

.2 Project management software

.3 Resource optimization techniques

.4 Modelling techniques

.5 Leads and lags

.6 Schedule compression

.7 Scheduling tool.3 Outputs

.1 Work performance information

.2 Schedule forecasts

.3 Change requests

.4/5 Project plan/document updates

.6 Organizational process assets updates




2-106

Project Cost Management

• Responsible for ensuring that the project is delivered withinthe prescribed budget.

• The next step to estimate the costs associated with each ofthe activities making up the project.

• Can use previous experience, tools, and modelling to assist.

• Cost budgeting involves allocating the budget to individualproject activities.

• Cost control then ensures that changes to the cost baselineis positive.

Total Cost of Ownership

• Costing approaches: bottom-up; top-down; or a combination

• Bottom-up:

– utilises WBS (based on the requirements set)

• Top-down:

– exemplar solution (eg cost estimate based on existingsystem/s)

– Parametric (use a known attribute eg weight of ship,SLOC to develop estimates)

– Analytical techniques using historical data and applicationof factors for projections

– Indexing


2-107

Importance of Good Costing Practice

• Supports consideration of Options for Gate decisions

• Fundamental part of the Business Case and Governmentsubmissions

• Budgeting

• Particular aspects have proven to be difficult eg estimatingdevelopmental and/or integration projects

Costing activities across CLC

• Costing activities and techniques change in type and focusdependent on the phase of the CLC:

– Pre-Gate 0, 1, 2 activities including risk reduction efforts

– Acquisition Costs:

• includes Introduction into Service

– Operating Costs:

• Most difficult to estimate

• Required over LOT of capability

• Techniques include:

– Use of historical data

– Factor against acquisition costs

– Disposal


2-108

Costing considerations across the CLC

• Costing considerations for CLC activities (eg developing submissions)

– Constant versus Out-turned dollars

– FOREX

– Economic Updates (eg Mid Year Economic Financial Outlook (MYEFO); CASG Budget Estimates and Additional Estimates)

– Phasing of expenditure


4.1 Plan cost management.1 Inputs


.2 Project charter

.3 Enterprise environmental factors

.4 Organisational process assets.2 Tools and Techniques

.1 Expert judgement

.2 Analytical techniques

.3 Meetings.3 Outputs

.1 Cost management plan

ProjectCost Management


4.2 Estimate Costs.1 Inputs

.1 Cost management plan

.2 Scope baseline

.3 Human resource mgt plan

.4 Project schedule

.5 Risk register



.1 Expert judgement

.2/3 Analogous/parametric estimating

.4 Bottom-up estimating

.5 Three-point estimating

.6 Reserve analysis

.7 Cost of quality

.8 Project management software

.9 Vendor bid analysis

.10 Group decision making.3 Outputs

.1 Activity cost estimates

.2 Basis of estimates

.3 Project document updates


2-109


4.3 Determine Budget

.1 Inputs.1 Cost management plan.2 Scope baseline.3 Activity cost estimates.4 Basis of estimates.5 Project schedule.6 Resource calendars.7 Risk register.8 Agreements.9 Organisational process assets

.2 Tools and Techniques.1 Cost aggregation.2 Reserve analysis.3 Expert judgement.4 Historical relationships.5 Funding limit reconciliation

.3 Outputs.1 Cost baseline.2 Project funding requirements.3 Project document updates

4.4 Control Costs

.1 Inputs.1 Project management plan.2 Project funding requirements.3 Work performance data.4 Organizational process assets

.2 Tools and Techniques.1 Earned value management.2 Forecasting.3 To-complete performance index.4 Performance reviews.5 Project management software .6 Reserve analysis

.3 Outputs.1 Work performance information.2 Cost forecasts.3 Change requests .4 Organizational process updates.5 Project management plan updates.6 Project document updates

ProjectCost Management


Project Quality Management

• Aims to ensure that the project will satisfy its needs.

• Quality assurance will be dealt with separately later.

• Project Management has an important role to play withrespect to quality management.

• Quality planning requires management to determine whichquality standards will be applied to the project—for example,the ISO 9000 series (more on this later).

• Once the quality standards have been selected, qualityplanning against those standards is required.

• Quality assurance (in accordance with the plan) involvesplanned and systematic activities aimed at enhancingconfidence in project quality.

• Quality control is also used to check specific project results.


2-110

Project Quality Management

5.1 Plan Quality Management

.1 Inputs.1 Project management plan.2 Stakeholder register.3 Risk register.4 Requirements documentation.5 Enterprise environmental factors.6 Organisational process assets

.2 Tools and Techniques.1 Cost-benefit analysis.2 Cost of quality.3 Seven basic quality tools.4 Benchmarking.5 Design of experiments.6 Statistical sampling.7 Additional quality planning tools.8. Meetings

3 Outputs.1 Quality management plan.2 Process improvement plan.3 Quality metrics.4 Quality checklists.5 Project documentation updates

5.2 Perform Quality Assurance

.1 Inputs.1 Quality management plan.2 Process improvement plan.2 Quality metrics.3 Quality control metrics.4 Project Documents

.2 Tools and Techniques.1 Quality management and

control tools.2 Quality audits.3 Process analysis

.3 Outputs.1 Change requests.2 Project management plan updates.3 Project document updates.4 Organisational process asset

updates

5.3 Perform Quality Control

.1 Inputs.1 Project management plan.2 Quality metrics.3 Quality checklists.4 Work performance data.5 Approved change requests.6 Deliverables.7 Project documents.8 Organizational process assets

.2 Tools and Techniques.1 Seven basic quality tools.2 Statistical sampling.3 Inspection.4 Approved change requests review

.3 Outputs.1 Quality control measurements.2 Validated changes.3 Validated deliverables.4 Work performance information.5 Change requests.6 Project management plan updates.7 Project document updates.8 Organizational process updates

ProjectQuality Management


Project Human Resource Management

• Aims to make the most effective use of people involved inthe project.

• Organisational planning is the initial activity involving:

– Identifying requirements.

– Documenting and assigning project roles andresponsibilities.

– Reporting relationships.

• Once the resource requirements have been identified, thestaff must be acquired.

• Finally, the team must be developed to enhance theperformance of the individual and team.


2-111


6.1 Plan HR Management

.1 Inputs.1 Project management plan.2 Activity resource requirements.3 Enterprise environmental factors.4 Organisational process assets

.2 Tools and Techniques.1 Organisation charts and position

descriptions.2 Networking.3 Organizational theory.4 Expert judgment.5 Meetings

.3 Outputs.1 HR management

plan

6.2 Acquire Project Team

.1 Inputs.1 HR management plan.2 Enterprise environmental factors.3 Organisational process assets

.2 Tools and Techniques.1 Pre-assignment.2 Negotiation.3 Acquisition.4 Virtual teams.5 Multi-criteria decision making

.3 Outputs.1 Project staff assignments.2 Resource calendars.3 Project management plan updates

ProjectHR Management



6.3 Develop Project Team

.1 Inputs.1 Project staff assignments.2 Project management plan.3 Resource calendars

.2 Tools and Techniques.1 Interpersonal skills.2 Training.3 Team-building activities.4 Ground rules.5 Co-location.6 Recognition and rewards.7 Personnel assessment tools

.3 Outputs.1 Team performance assessments.2 Enterprise environmental factors

updates

6.4 Manage Project Team

.1 Inputs.1 HR management plan.2 Project staff assignments.3 Team performance assessments.4 Issue log.5 Work performance reports.6 Organizational process assets

.2 Tools and Techniques.1 Observation and conversation.2 Project performance appraisals.3 Conflict management.4 Interpersonal skills

.3 Outputs.1 Change requests.2 Project management plan updates.3 Project documents updates.4 Enterprise environmental factors

updates.5 Organisational process assets

updates

ProjectHR Management



2-112

Communications Management

• Starts with communications planning to determine the overallcommunications requirements—who needs what, when andhow.

• Information is then disseminated in accordance with thefindings of the first step.

• Must be done in a timely manner.

• Reporting the performance and status of the project is animportant part of communications.

• An important communications aspect is reporting the closureof project phases or the project itself.

Project Communications Management

7.1 Plan Communications Management

.1 Inputs.1 project management plan.2 Stakeholder register.3 Enterprise environmental factors.4 Organizational process assets

.2 Tools and Techniques.1 Communications requirements

analysis.2 Communications technology.3 Communication models.4 Communication methods

.3 Outputs.1 Communications management

plan.2 Project documentation updates

7.3 Control Communications

.1 Inputs.1 Project management plan.2 Project communications.3 Issue log.4 Work performance data.5 Organisational process assets

.2 Tools and Techniques.1 Information management

systems.2 Expert judgment.3 Meetings

.3 Outputs.1 Work performance information.2 Change requests.3 Project management plan

updates.4 Project documentation updates.5 Organizational process assets

updates


ProjectCommunications Management

7.2 Manage Communications

.1 Inputs.1 Communications management

plan.2 Work performance reports.3 Enterprise environmental factors.4 Organisational process assets

.2 Tools and Techniques.1 Communications technology.2 Communications models.3 Communications methods.4 Information management

systems.5 Performance reporting

.3 Outputs.1 Project communications.2 Project management plan

updates.3 Project documentation updates.4 Organizational process assets

updates


2-113

Risk Management

• Risk identification:

– Determine possible risks

– Document risk characteristics

– Needs to be performed on a continual basis

• Risk quantification:

– Evaluates risks and determines interactions

– Determines likely impact of the risk on the project

• Risk response development:

– Take advantage of the opportunities

– Manage the risks to project performance

• Risk response control:

– responding to changes to the risks

Project Risk Management

8.1 Plan Risk Management

.1 Inputs.1 Project management plan.2 Project scope.3 Stakeholder register.4 Enterprise environmental factors.5 Organisational process assets

.2 Tools and Techniques.1 Analytical techniques.2 Expert judgment.3 Meetings

.3 Outputs.1 Risk management plan

8.2 Identify Risks

.1 Inputs.1 Risk management plan.2 Cost management plan.3 Schedule management plan.4 Quality management plan.5 Human resource plan.6 Scope baseline.7/.8 Activity cost/duration estimates.9 Stakeholder register.10 Project documents.11 Procurement documents

.2 Tools and Techniques.1 Documentation reviews.2 Information gathering techniques.3 Checklist analysis.4 Assumptions analysis.5 Diagramming techniques.6 SWOT analysis.7 Expert judgment

.3 Outputs.1 Risk register

8.3 Perform QualitativeRisk Analysis

.1 Inputs.1 Risk management plan .2 Scope baseline.3 Risk register.4 Organisational process assets

.2 Tools and Techniques.1 Risk probability and impact

assessment.2 Probability and impact matrix.3 Risk data quality assessment.4 Risk categorisation.5 Risk urgency assessment.6 Expert judgment

.3 Outputs.1 Project documents updates

ProjectRisk Management



2-114

Project Risk Management

8.4 Perform Quantitative Risk Analysis

.1 Inputs.1 Risk management plan.2 Cost management plan.3 Schedule management plan.4 Risk register.5 Enterprise environmental factors.5 Organisational process assets

.2 Tools and Techniques.1 Data gathering and representation

techniques.2 Quantitative risk analysis and

modelling techniques.3 Expert judgment

.3 Outputs.1 Project documents updates

8.5 Plan Risk Responses

.1 Inputs.1 Risk register.2 Risk management plan

.2 Tools and Techniques.1 Strategies for negative risks or

threats.2 Strategies for positive risks or

opportunities.3 Contingent response strategies.4 Expert judgment

.3 Outputs.1 Project management plan updates.2 Project document updates

8.6 Monitor and Control Risks

.1 Inputs.1 Project management plan.2 Risk register.3 Work performance data.4 Work performance reports

.2 Tools and Techniques.1 Risk reassessment.2 Risk audits.3 Variance and trend analysis.4 Technical performance

measurement.5 Reserve analysis.6 Meetings

.3 Outputs.1 Work performance information.2 Change requests .3 Project management plan updates.4 Project document updates.5 Organisational process assets

updates

ProjectRisk Management


Procurement Management

• Responsible for obtaining materials and services for theproject from outside the organisation.

• Planning must be conducted to determine what is requiredand when.

• Solicitation planning—these requirements must bedocumented and potential sources identified.

• Solicitation involves obtaining quotes and offers etc.

• Source selection determines the best offer.

• Contract administration—put in place to manage theprocurement contract with the source.

• Contract close-out—completion and settlement of thecontract.


2-115

Project Procurement Management

9.1 Plan Procurements.1 Inputs


.2 Requirements documentation

.3 Teaming arrangements

.4 Activity resource requirements

.5 Project schedule

.6 Activity cost estimates

.7 Stakeholder register



.1 Make-or-buy analysis

.2 Expert judgment

.3/4 Market research / meetings.3 Outputs

.1 Procurement management plan

.2 Procurement SOW

.3 Procurement documents

.4 Source selection criteria

.5 Make-or-buy decisions

.6 Change requests

.7 Project documentation updates

9.2 Conduct Procurements.1 Inputs


.2 Procurement documents

.3 Source selection criteria

.4 Seller proposals

.5 Project documents

.6 Make-or-buy decisions

.7 Procurement SOW

.8 Organizational process assets.2 Tools and Techniques

.1 Bidder conference

.2 Proposal evaluation techniques

.3 Independent estimates

.4 Expert judgement

.5 Advertising

.6 Analytical techniques

.7 Procurement negotiations.3 Outputs

.1 Selected sellers

.2 Agreements

.3 Resource calendars

.4 Change requests

.5 Project management plan updates

.6 Project documentation updates

ProjectProcurement Management


Project Procurement Management

9.3 Control Procurements

.1 Inputs.1 Project management plan.2 Project documents.3 Agreements.4 Approved change requests .5 Work Performance reports.6 Work performance data

.2 Tools and Techniques.1 Contract change control system.2 Procurement performance reviews.3 Inspections and audits.4 Performance reporting.5 Payment systems.6 Claims administration.7 Records management system

.3 Outputs.1 Work performance information.2 Change requests .3 Project management plan updates .4 Procurement documents updates.5 Organisational process assets

updates

9.4 Close Procurements

.1 Inputs.1 Project management plan.2 Project documents

.2 Tools and Techniques.1 Procurement audits.2 Procurement negotiations.3 Records management system

.3 Outputs.1 Closed procurements.2 Organisational process assets

updates


ProjectProcurement Management


2-116

Stakeholder Management

• The PMBOK says that stakeholder management involves theprocesses required to:

– identify the people, groups, or organizations (thestakeholders) that could impact or be impacted by theproject;

– analyse stakeholder expectations and their impact in theproject; and

– develop appropriate stakeholder management strategies.


Project Stakeholder Management

10.1 Identify Stakeholders

.1 Inputs.1 Project charter.2 Procurement documents.3 Enterprise environmental factors.4 Organizational process assets

.2 Tools and Techniques.1 Stakeholder analysis.2 Expert judgment.3 Meetings

.3 Outputs.1 Stakeholder register

10.2 Plan Stakeholder Management

.1 Inputs.1 Project management plan.2 Stakeholder register.3 Enterprise environmental factors.4 Organizational process assets

.2 Tools and Techniques.1 Expert judgment.2 Meetings.3 Analytical techniques

.3 Outputs.1 Stakeholder management

plan.2 Project documentation updates


ProjectStakeholder Management


2-117

10.4 Manage Stakeholder Expectations

.1 Inputs.1 Stakeholder management plan.2 Communications management plan.3 Change log.4 Organisational process assets

.2 Tools and Techniques.1 Communications methods.2 Interpersonal skills.3 Management skills

.3 Outputs.1 Issue log.2 Change requests.3 Project management plan updates.4 Project document updates.5 Organisational process assets

updates

10.5 Control Stakeholder Engagement

.1 Inputs.1 Project management plan.2 Issue log.3 Work performance data.4 Project documents.5 Organisational process assets

.2 Tools and Techniques.1 Information management systems.2 Expert judgment.3 Meetings

.3 Outputs.1 Work performance information.2 Change requests.3 Project management plan updates.4 Project documentation updates.5 Organisational process assets

updates

ProjectStakeholder Management


Project Stakeholder Management

Project Life Cycle

• Because each project is unique we must be careful tomanage it since there is always at least some part of theproject that we have never done before.

• To assist in managing projects we normally break theactivities up into a number of phases.

• Phases are important because:

– They allow for finer control and management.

– Projects are easier to describe and communicate.

– Decision points at the end of phases allow us theopportunity to review progress and make decisions aboutfuture work.

– Phases of activity can be associated with broaderorganisational financing and scheduling arrangements.


2-118

Project Life Cycle

• Phases normally end with some form of deliverable.

• In some respects, then, we can consider a phase as a mini-project that has resources, a beginning and an end, and soon—we can therefore manage it properly.

• The set of all phases is called the project life cycle.

• There are a number of project life-cycle models adopted bydifferent organisations. While they are largely very similar,they have slightly different phases, end points, reviews, andso on, depending on the unique needs of the industry andthe organisation.

• All project life cycles have a number of common elements.

Project Life Cycle

• Resource usage. At the start, the levels of staffing, financeand other resources are relatively low. As the projectprogresses, the utilisation increases and then diminishesrapidly as the product is completed and delivered.

Initial Phase Final PhaseIntermediate Phases

Start FinishTime

Res

ou

rce

Lev

els

Rate of effort

Accumulative effort


2-119

Project Life Cycle

fast

fast

slow

slowslow

slow

Time

100%

0%

Per

cent

age

Com

plet

e

A

B

0

The Importance of Project Definition

65%

5% 10%

25% 10%

85%

% of Potential Cost or Efficiency Gains Achieved or Lost

% of Total Project Cost for Typical Project

Requirements Identification, Strategy Development, and Initial Risk Assessment

Build and Introduction Into Service


2-120

The Importance of Project Definition

High

Low

Impact of problem definition(ease of making changes)

Resource levels(cost of making changes)

Time

Typical Project Life Cycles

Conceive Develop Implement Terminate

Gather dataIdentify needEstablish:

Goals, objectivesBasic economicsFeasibilityStakeholdersRisk levelStrategyTeam

Estimate resourcesIdentify alternativesPresent proposalGain approval

Appoint teamConduct studiesDevelop scopeEstablish:

Master planBudgetCash flowWBSPolicesProcedures

Assess risksConfirm justificationPresent brief

Set up organisationSet up communicationsMotivate teamDetail technical requirementsEstablish

Work packagesDetailed scheduleInformation control systems

Procure goods and servicesExecute work packagesDirect/monitor/forecast/control:

ScopeQualityTimeCost

Resolve problems

Finalise productsReview and acceptTransfer responsibilityEvaluate productDocument resultsRelease/redirect resourcesReassign project team

Simple Project Life-cycle Phases


2-121


Implementation

Leve

l of E

ffort

Time


NEED

DISPOSAL

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ACQUISITIONPHASE

UTILISATIONPHASE

ConceptualDesign

NEED

DISPOSAL

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ACQUISITIONPHASE

UTILISATIONPHASE

ConceptualDesign

NEED

DISPOSAL

System Design and AnalysisOperational Use

andSystem Support

Constructionand/or

Production

ACQUISITIONPHASE

UTILISATIONPHASE

Systems Engineering—Blanchard, et al


2-122


Australian Department of Defence

Need Requirements Acquisition In Service Disposal

Strategy and Concepts

Risk Mitigation&RequirementsSetting

Acquisition In Service &Disposal

Pre-FPR

Post-FPR


US Department of Defense

Concept and

Technology

Development

System Development

and Demonstration

Production and

DeploymentSupport

Sustainment andMaintenance

Systems Acquisition(Engineering Development,

Demonstration,Production, and Deployment)

Pre-SystemsAcquisition


2-123


Representative Construction Project

FEASIBILTY• Project Formulation

• Feasibility Studies• Strategy Design

and Approval

PLANNINGand DESIGN

• Base Design• Cost and Schedule

• Contract Termsand Conditions

• Detailed Planning

CONSTRUCTION• Manufacturing

• Delivery• Civil Works• Installation

• Testing

TURNOVERand STARTUP• Final Testing• Maintenance

• Civil Works• Installation

• Testing

STAGE I STAGE II STAGE III STAGE IV

100%

Project“GO”

Decision

MajorContracts

Let

InstallationSubstantially

Complete

FullOperations

Life-Cycle Stage

Per

cen

t C

om

ple

te



Software Development—Waterfall Model

REQTSANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

TESTING(Unit, Integration

System, Acceptance)

OPERATION& MAINT


2-124


Representative Life Cycle of a Pharmaceuticals Project


Drug Sourcing

ScreeningLeadIdentified

PreclinicalINDWorkup

FileIND

Patent Process

Discovery ScreeningPreclinicalDevelopment

Ten Plus Years

Registration Workup Post-submission Activity

Phase IClinicalTests

Phase IIClinicalTests

Phase IIIClinicalTests

Formulation Stability

Process Development

FileNDA Post-registration Activity

APPROVAL

Toxicology

Metabolism

Organisational Structure

• In addition to a unique project life cycle, each organisationwill also have unique organisational structure.

• There are again, however, a number of standard structures.

• We describe the three most basic here—more detail onorganisational structures is available in the PMBOK*.



2-125

Functional Organisation

ChiefExecutive

FunctionalManager

FunctionalManager

FunctionalManager

Staff

Staff

Staff

Staff

Staff

Staff

(Black boxes represent staff engaged in project activities.)

ProjectCoordination

Staff

Staff

Staff


Functional Organisation

• Advantages:

– Functional departments provide a home for expertise

– Good support for work packages

– Flexible use of resources within departments

– Simpler to estimate cost and schedule

– Well established lines of communication withindepartments

• Disadvantages:

– No single point of responsibility or coordination

– No formal lines of communication for a project

– Competition and conflict between departments

– Not effective in a multi-project environment


2-126

Projectised Organisation

Systems Engineer Quality Assurance Logistician

Design/Manufacturing Specialist Engineers

User Representative

Project Director

Project Manager 2Project Manager 1 Project Manager 3

Projectised Organisation

• Advantages

– All staff report directly to a project manager

– Lines of communication are stronger and explicit

– Motivation is often higher because project teams tend tobe closer-knit

– Decisions can be made more quickly in a centralisedorganisation

• Disadvantages

– Effort is duplicated when there are a large number ofprojects

– Projects tend to hoard resources leading to less-efficientuse across the organisation

– Project teams work themselves out of a job


2-127

Matrix Organisation

Project Director

Quality Assurance

Logistics

Design/Manufacturing

Specialist Engineers

User Representative

Systems Engineering

Project Manager 2Project Manager 1 Project Manager 3

Matrix Organisation

• Advantages

– Clear single point of responsibility and coordination

– Project can draw on resources from whole organisation

– Shared resources are often more efficient

– Expertise is easier to maintain within functional areas

• Disadvantages

– The structure is complex

– More complex communications links are required

– Some communications problems are increased becauseexpertise is not always dedicated

– Each person effectively has two bosses

– The structure does not encourage strong staffcommitment to the project


2-128

Project Management Processes

• In broad outline, project management process can beorganised into five groups of one or more processes*:

– Initiating processes—authorising and beginning

– Planning processes—defining and refining objectives andselecting the best course of action to attain the definedobjectives

– Executing processes—coordinating people andprocesses to achieve the objectives

– Controlling processes—monitoring and measuring toensure objectives met as anticipated

– Closing processes—finalising project and formalisingacceptance




ClosingProcesses

PlanningProcesses

InitiatingProcesses

ExecutingProcesses

Monitoring & ControllingProcesses


2-129


ExecutingProcesses

Monitoring & ControllingProcesses

PhaseFinish

ClosingProcesses

PlanningProcesses

InitiatingProcesses

PhaseStart

Levelof

ProcessInteraction

Time



Implementation Phase

Design Phase

PriorPhases

SubsequentPhases

Interaction between phases(sequential or overlapped)



2-130



• Project scope management articulates the processesrequired to make sure that the project undertakes all of thework required, and no more than the work required, tocomplete the project.


2-131


2.2 Collect Requirements

.1 Inputs.1 Scope management plan.2 Requirements management plan.3 Stakeholder management plan.4 Project charter.5 Stakeholder register

.2 Tools and Techniques.1 Interviews.2 Focus groups.3 Facilitated workshops.4 Group creativity techniques.5 Group decision making

techniques.6 Questionnaires and surveys.7 Observations.8 Prototypes.9 Benchmarking.10 Context diagram

.3 Outputs.1 Requirements documentation.2 Requirements traceability matrix

2.3 Define Scope

.1 Inputs.1 Scope management plan.2 Project charter.3 Requirements documentation.4 Organisational process assets

.2 Tools and Techniques.1 Expert judgement.2 Product analysis.3 Alternatives identification.4 Facilitated workshops

.3 Outputs.1 Project scope statement.2 Project documentation updates



2.1 Plan Scope Management


.2 Tools and Techniques.1 Expert judgement.2 Meetings

.3 Outputs.1 Scope management plan.2 Requirements management plan


2.5 Validate Scope

.1 Inputs.1 Project management plan.2 Requirements documentation.3 Requirements traceability matrix.4 Verified deliverables.5 Work performance data

.2 Tools and Techniques.1 Inspection.2 Group decision-making techniques

.3 Outputs.1 Accepted deliverables.2 Change requests.3 Work performance information.4 Project document updates

2.6 Control Scope

.1 Inputs.1 Project management plan.2 Requirements documentation.3 Requirements traceability matrix.4 Work performance data.5 Organisational process assets

.2 Tools and Techniques.1 Variance analysis

.3 Outputs.1 Work performance information.2 Change requests.3 Project management plan updates.4 Project document updates.5 Organisational process assets

updates



2.4 Create WBS

.1 Inputs.1 Scope management plan.2 Project scope statement.3 Requirements documentation.4 Enterprise environmental


.2 Tools and Techniques.1 Decomposition.2 Expert judgement

.3 Outputs.1 Scope baseline.2 Project documentation updates


2-132

Work Breakdown Structures (WBS)

• A WBS is a deliverable-oriented grouping of projectcomponents that provides a hierarchical description of thewhole project—if it isn’t in the WBS, it isn’t in the project’sscope.

• The WBS is therefore a graphical overview of the project thathelps verify as well as communicate the project scope.

• The WBS is normally presented in chart form—each item isuniquely identified.

• The lowest level of the WBS contains what are normallycalled work packages.


An example WBS—US DoD MIL-HDBK-881 format

Aircraft system

Systems engineering/project management

Air vehicle

Systems test &evaluation

Training

Data

Operationalactivation

Supportequipment

Spares

Facilities

•Undercarriage CI•Wings/fuselage CI•Fuel system CI•Hydraulic system CI•Flight controls CI•Engine CI•Avionics CI•Interior CI•Design, integration, assembly, test

•Developmental test & evaluation•Acceptance test & evaluation•Operational test & evaluation•T&E support•Test facilities

•Aircraft equipment•Support services•Facilities

•Technical publications•Engineering data•Management data•Support data•Data repository

•Test & measurement equipment•Support & handling equipment

•System-level assembly,installation & checkout

•Technical support•Site construction


2-133


An example WBS—PMBOK

Software ProductRelease 5.0

ProjectManagement

ProjectRequirements

Integrationand Test

Administration

Meetings

Planning

Training ProgramMaterials

UserDocumentation

Software


UserDocumentation

Software

This WBS is illustrative only. It is not intended to represent the full project scope of any specific project,nor to imply that this is the only way to organise a WBS on this type of project

DetailDesign


UserDocumentation

Software

Construct


UserDocumentation

Software



An example WBS—PMBOK

WastewaterTreatment Plan

Design Construction

Structural Drawings

Architectural Drawings

Civil Drawings

Effluent Pumping Station

Aeration Basin

Headworks

This WBS is illustrative only. It is not intended to represent the full project scope of any

specific project,nor to imply that this is the only way to organise a WBS on this type of project

Electrical Drawings

Plumbing Drawings

Mechanical Drawings

Other Drawings

Instrumentation Drawings

Sludge Building

Air-handling Building

LaterPhases

EarlierPhases



2-134


Simple WBS for a house

House

Plumbing ElectricalCivil

Foundations Walls/Roof Piping Sewerage Wiring Appliances

R. Burke, Project Management: Planning and Control Techniques, Burke Publishing, 2003.


Horizontal presentation of house WBS

House

Civil

Plumbing

Electrical

Foundations

Walls/Roof

Piping

Sewerage

Wiring

Appliances



2-135


WBS numbering system

COMPLETE PROJECT

1234 01 01 001

Main assemblies

Sub-assemblies

Parts and components

Work package number



House1.0.0

$32000

Plumbing1.2.0$8000

Electrical1.3.0

$11000

Civil1.1.0

$13000

Foundations1.1.1$5000

Walls/Roof1.1.2$8000

Piping1.2.1$6000

Sewerage1.2.2$2000

Wiring1.3.1$3000

Appliances1.3.2$8000

Example of roll-up of cost using the WBS.



2-136


Example of roll-up of man hours using the WBS.

DrawingOffice Project

1.0.0Mh 6000

Drafting1.2.0

Mh 4400

Doc Control1.3.0

Mh 700

Design1.1.0

Mh 900

Design1.1.1

Mh 400

Specs1.1.2

Mh 500

Drafting1.2.1

Mh 4000

BOM1.2.2

Mh 400

Printing1.3.1

Mh 500

Issue1.3.2

Mh 200


WBS Dictionary

• Detailed description of the components of the WBS:

– Account code identifier

– Description of work

– Responsible organisation

– List of schedule milestones

– Associated schedule activities

– Resources required

– Cost estimates

– Quality requirements

– Acceptance criteria

– Technical references

– Contract information



2-137

Project managementand

systems engineering

PMBOK Knowledge Areas

Inte

grat

ion

Man

agem

ent

Sco

pe

Ma

na

ge

me

nt

Tim

e M

an

ag

em

en

t

Co

st M

an

ag

em

en

tQ

ualit

y M

anag

emen

t

Hu

ma

n R

eso

urc

e M

an

ag

em

en

t

Co

mm

un

ica

tion

s M

an

ag

em

en

t

Ris

k M

an

ag

em

en

t

Pro

cure

me

nt M

an

ag

em

en

t

Requirements Analysis

Requirements Verification

Functional Analysis

Functional Verification

Synthesis

Design Verification

Systems Analysis

Control


Functional Analysis/Allocation

Synthesis

Synthesis Analysis & Control

Acquisition and Supply

Technical Management

System Design

Product Realization

Technical Evaluation

IEEE1220

EIA/IS632

ANSI/EIA632

Agreement Processes

Project-enabling ProcessesISO/IEC15288 Project Processes

Technical Processes

Sta

keh

old

er

Ma

na

ge

me

nt

Introduction toProgram Management


2-138

Program Management

A program is a group of related projects managed in acoordinated manner to obtain benefits not availablefrom managing them individually.

Program management is the application of knowledge,skills, tools and techniques to meet programrequirements.

Source: PMI website

Program Management

• Who needs to know how Programs work:

– those responsible for Programs eg Program Sponsorsand Managers

– those who are part of a Program eg Project and ProductManagers


2-139

CLC Programs

• The common features of Programs:

– Group of related interdependent Projects, Products andactivities that are expected to contribute to an overarchingobjective.

– Constituent Products, Projects, and activities aremanaged mostly separately and will likely be at differentphases of the capability lifecycle.

– The Program authority (Sponsor or Manager) isaccountable for the combined outcomes.

Objectives of Programs

• Program objectives in the Defence context are generally oftwo types:

– operational outcomes eg joint capability

– resource commonality eg common systems or resources(eg fuels) which reap acquisition, sustainment andtraining efficiencies


2-140

Program Management in the CLC

• Application of Program Management as described today isimportant in the CLC for following reasons:

– managing appropriate groupings of Projects, Products,and activities is often the only way feasible way to identifyand achieve shared objectives

– it is how Defence joint capability will be achieved

– can significantly enable efficiencies in a resourceconstrained environment

Role of the Program Sponsor & Manager

• Oversight, monitoring, and decision-making including theauthority to reconcile issues between constituent Projects,Product and activities

• Define shared objectives applicable to constituent Projects,Product and activities

• Provide appropriate governance arrangements includingclear decision-making and escalation structures

• Establish common business and technical requirements andprocesses applicable to all constituents of the Program

• Identify and manage risks relevant to achieving Programobjectives


2-141

Program Management for Joint Capability

• Requires management of fourrelated types of interdependenciesbetween capability systems that areeither in Proposal, Project, orProduct ‘stage’:

• Operational (based on CONOPS)

• Function and Performance

• Technical requirements: systemrequirements, system interfacerequirements (including egstandards and their versions andtailoring)

• Programmatic/Management (all FIC)

What are the operationalinterdependencies among the capability

systems?

What are the function and performance dependencies among the

capability systems that deliver the required operational effects?

What are the technical requirements (system interface requirements, system

requirements and associated standards) that will enable the required function and performance outcomes?

What are the project and product management interdependencies and resulting actions to enable definition, realisation, and ongoing management

of system interdependencies

Key Program Management Actions

• Define intra- and inter-Program interdependencies:

– Operational

– Function and Performance

– Technical requirements

– Programmatic

• Plan: coordinate decisions (incl design and acquisitiondecisions), milestones, schedules

• Set up Governance and Assurance: Setting up appropriatemanagement arrangements (eg Program Steering Group,interface control working groups) to monitor, adjust and report

• Manage Risk: identify, assess and mitigate risks for Programsacross Projects and Products. Also identify opportunities.

• Manage Resources: Manage resources across theconstituent Projects, Products, and activities


2-142

Key Enablers for Program Management

• CPN and JCN: narratives on the expected operationaleffects of the group of capability systems

• PIOC: more detailed description of operational relationshipsbetween capability systems both within the Program andwith other Programs

• Program Strategy: description of the activities, managementarrangements, including integrated schedule across Projectsand Products

• ….


• …

• Program Architectures: detailed representations of Programfeatures using Defence Architecture Framework (DAF)conventions

• I2 Framework including I2 Reference Set: I2-focussedguidance and requirements to achieve joint force outcomes

• Program and Materiel Standards Governance Fora: Intraand inter-Program governance bodies eg PMSG andworking groups


2-143


• Capability Integration practice

• System Integration practice

• S/W integration practice

• Configuration Management practice

System of Systems Engineering

• Program Management can be aided by System-of-Systemsthinking

• System-of-Systems problems have been described (byDeLaurentis and Maier) as problems which exhibit a numberof the following traits :

– Operational Independence of Elements

– Managerial Independence of Elements

– Evolutionary Development

– Emergent Behaviour

– Geographical Distribution of Elements

– Interdisciplinary Study

– Heterogeneity of Systems

– Networks of Systems


2-144

System of Systems Engineering

• The aims of the Systems Approach and SoSE are to:

– optimise the outcomes delivered through the newsystems (Projects) and legacy (Products) which togethersatisfy the Program objectives.

– provide techniques that enable decision-makers to makeinformed decisions on architectural solutions for System-of-Systems problems across eg technical performance,costs

– provide a deliberately managed approach to thedefinition, design and delivery of capability systems in aProgram across Projects and Products

SoS Architecture Practice for Programs

• “An architecture is the structure of components, theirrelationships, and the principles and guidelines governingtheir design evolution over time” (IEEE 610.12-1990).

• The application of architectures for SoS is directly applicableto CLC Programs.

• SoS (and therefore Program) architectures provide:

– details on how constituent systems will be used(CONOPS)

– internal and external operational, functional and technicalrelationships and dependencies among the constituentsystems

– end-to-end functionality and flows of information and data(and other resources)

Source: Based on SEBoK Architecting approaches for SoS


2-145

SoS/Program Architectures

• Provides a common and enduring reference for decisions for Proposals, Projects and Products

• “From the single-system community's perspective, its part of the SoS capability represents additional obligations, constraints and complexities. Rarely is participation in an (sic) SoS seen as a net gain from the viewpoint of single-system stakeholders” (Source: Rebovich 2009)

• SEBoK raises the practical problems and potential solutions for situations in which the SoS architecture may be constrained by a reluctance to make changes or invest in the constituent systems, which could be very mature (e.g. in sustainment) or currently productively supporting other uses.

Source: SEBoK Architecting approaches for SoS

I2 Framework (I2F)

• I2F is based on four actions:

– Use of the I2 Reference Set as an authoritative andcomprehensive source of Defence I2 configuration statusand requirements.

– Tailoring of I2 requirements for each Program, Project,and Product.

– Assurance of tailored I2 requirements by CIT&E (JICA)with focus on Gates 0 to 2.

– Progressive demonstration of I2 achievement over theCLC assured by CIT&E (JICA and JT&E).


2-146

I2 is based on Program, Project and Product Management

I2 Reference Set

• The I2 Reference Set provides:

– an authoritative and up-to-date source of I2 configurationstatus and requirements for all joint force efforts.

– a reliable (configuration managed) basis for analysingand defining joint force relationships, requirements, andrisks throughout the CLC

– a comprehensive ‘toolkit’ of I2 references from whichapplicable elements will be drawn for Program, Project,and Product I2 definition


2-147

I2 is Addressed Across the CLC

FPS 2

Defence White Paper

FOE FJOC

AMS

AJOC

What and Why How

PGPA Act

CPRsForce Design

CPN

JCN

Portfolio

Program

Product

IIP

DIP

DPPMIssued by JCA to the CM

Raised within Force Design as Program level direction PIOC Program Strategy

PESJCNS

Smartbuyer

OCD

FPS 1

IPMPProjectWBS IMS

Tender and Contracting Documents

Selected ASDEFCON Suite

DPG

JCFConcepts

Strategic Guidance

Combined = Business Case/Proposal/Submission

Integration and Interoperability Reference Set:

• Joint Force Outcomes

• Supporting Joint Concepts

• Integrating Objectives

• Directed I2 Requirements

• C4ISR Design

• Materiel Standards

• Program and System Architectures

• Product Baselines


2-148

C4ISR Design

• C4ISR Design 2025 v0.6 was been endorsed by the Jointwarfare Council as at 24 Nov 16.

• Basis for defining C4ISR requirements, informing capabilityexperimentation, integration, and assuring the joint war-fighting environment through eg test and evaluation.

• C4ISR Design Authority is accountable for defining andassuring the joint war-fighting environment, architecture andsetting military I2 requirements.

• …

C4ISR Design

• …

• Defines I2 for Networked Joint Force (NJF) C4 and ISRfunctions

• Provides endorsed joint operational, capability andmission/platforms’ systems (interoperability) design patternsand guidance to:

– enable alignment and integration with existing & futuresystems

– trusted, relevant and timely decision quality information


3-1

Dr Mike RyanDr Shari Soutberg

The Capability Life Cycle (CLC)and

Capability Management Practices

Day 3

• Systems Engineering Process (continued)

– Preliminary Design

– Detailed Design and Development

– Construction and Production’ Utilisation

– Retirement

• Systems Engineering Management and Planning

• Test and Evaluation

• Configuration Management

• Specifications and Standards

• Integration Management

• Requirements and Requirements Engineering


3-2

Preliminary Design

Preliminary Design

• Preliminary Design starts with the Initial FBL fromConceptual Design and continues to translate system-levelrequirements into design requirements for the systemelements that will combine to form the system.

• Trade-off studies are conducted to assist in the choice ofsystem elements.

• The result of the Preliminary Design effort is theestablishment of an Allocated Baseline (ABL), in whichrequirements are ‘allocated’ to specific physical systemelements that combine to form the system.

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign


3-3

Preliminary Design

• The contractor is normally responsible for PreliminaryDesign, who develops the system to meet the requirementsof the FBL (normally prepared by the customer).

• Although the customer normally avoids becoming activelyinvolved in design decisions made during PreliminaryDesign, they remain very interested and their role nowincreasingly becomes one of monitoring, reviewing andsupporting contractor progress.

• In some cases, the customer may opt to add an additionallevel of rigour to the process by engaging independentsystems engineering consultants to provide independentreview of the many artefacts produced by contractors duringsystems development—often called independent verificationand validation (IV&V).

Preliminary Design

P4. Conduct subsystem-level synthesis

P5. Conduct Preliminary Design Review (PDR)

P1. Conduct subsystem requirements analysis

Preliminary Design

P2. Conduct requirements allocation

P3. Conduct interface identification/design

Development Specifications

ApprovedAllocated Baseline

To Detailed Design and Development


3-4

Subsystem requirement analysis

Remember our example FFBD for turning around in 30minutes:

1. Aircraftlands


runway to terminal

3 Aircraft turns around in 30

minutes



terminal to runway

1. Aircraftlands


runway to terminal

3.1 Unloadpassengers, freight,

luggage (PFL)

3.2 LoadPFL

3.3 Conductrefuelling

3.4 Maintainaircraft



terminal to runway

3.0 – Aircraft turns around in 30 minutes

3.x Otherturn-around

functions

Subsystem requirement analysis

We can now do the lower-level analysis of the requiredfunctions:

3.3.1 Confirmcurrent fuel

level

3.3.2 Confirmrequired fuel

level

3.3.3 Providefire safety

precautions

3.3.4 Earthfuel sourceand aircraft

3.3.5 Connectfuel sourceand aircraft

3.3.6 Refuelaircraft

3.3.7 Monitorfuel levels

3.3.9 Removeearthing

3.3.8 Disconnectfuel sourceand aircraft

Subset of 3.3- Conduct refuelling (in 30 minutes)

2 min 2 min 3 min 2 min 2 min 2 min17 min

Subset of 3.0 - Turn around in 30 minutes


3-5

Requirements allocation

P2.1 Identify candidate subsystems

P2. Conduct requirements allocation

P2.2 Group and allocate requirements

P3. Conduct Interface Identification/Design

P2.3 Confirm subsystem selection

Configuration items (CI)

• Each of the major subsystems needs to be consideredindividually during Preliminary Design.

• Depending on how the designers intend to realise thesubsystems, they may be broken down further intoconfiguration items (CIs), which comprise the hardware,software or a combination of both designed to satisfy anallocated group of requirements.

• Sometimes a subsystem will be a single CI, but usually asubsystem will comprise a number of CIs.

• As the name suggests, the configuration of each CI ismanaged as a separate item for design, development,documentation, construction, review, audit, and test.

• The same CIs may also be used during the Utilization Phasefor through-life support although, as we discuss later, the in-service CIs may be different to the development.


3-6

CI selection

• The selection and designation of physical design items asCIs is a configuration management function known asconfiguration identification.

• Configuration management is so critical to systemsengineering that we treat it as a separate topic during thesection on systems engineering management.

• CIs are a matter of design choice and can vary in size andcomplexity—MIL-HDBK-61A(SE), Military Handbook—Configuration Management Guidance says that a CI can beanything from from an aircraft, ship, or electronic system to atest meter, or a round of ammunition.

CI selection• In general, however, items may be identified as CIs because

of:

– Complexity

– Interfaces

– Use/function

– Commonality

– Provided by a single supplier

– Criticality

– Maintenance and documentation needs


3-7

CI selection

• The determination and selection of CIs is a design decisionmade by the design team (contractor) in their attempt tosatisfy the system level requirements in the best possibleway.

• The customer sometimes influences the decision, especiallyif there are mandated solutions or constraints involvingcustomer-furnished equipment that must be used in thedesign.

• Even if the customer does not influence the decision, thecustomer needs to be aware of the CI selection processbecause it impacts on:– acquisition activities such as documentation, design

reviews, configuration audits and test and evaluation; and– operational use and system support activities such as

maintenance and modification programs.


• We have our subsystems and we have our sets ofrequirements.

• We now “join the dots” and allocate requirements tosubsystems (which represents the translation of functionaldesign into physical design).

• Our requirements set will be larger following our subsystemrequirements analysis task but for the sake of the example,we will allocate system-level requirements only.


3-8


CI 1

1.1.11.1.1 ..........1.1.2 ..........1.1.3 ..........1.1.4 ..........1.1.5 ..........1.21.2.1 ..........1.2.2 ..........1.2.3 ..........1.31.3.1 ..........1.3.2 ..........1.3.3 ..........1.3.4 ..........1.41.4.1 ..........1.4.2 ..........1.4.3 ..........1.51.5.1 ..........1.5.2 ..........

CI 2

CI 3

CI 4

CI 5

CI 6

CI 7

CI 8


A better way of representingfunctional to physicalallocation is via an allocationmatrix.

1.1.11.1.1 ..........1.1.2 ..........1.1.3 ..........1.1.4 ..........1.1.5 ..........1.21.2.1 ..........1.2.2 ..........1.2.3 ..........1.31.3.1 ..........1.3.2 ..........1.3.3 ..........1.3.4 ..........1.41.4.1 ..........1.4.2 ..........1.4.3 ..........1.51.5.1 ..........1.5.2 ..........1.5.3 ..........1.61.6.1 ..........1.6.2 ..........1.6.3 ..........1.6.4 ..........1.6.5 ..........

RBS

Fue

l

Hyd

raul

ic

Flig

ht C

ontr

ols

Eng

ine

Avi

onic

s

Inte

rior

Und

erca

rria

ge

Win

gs/F

usel

age


3-9

RBS vs WBS (an aside)

• Early on, we justified the invention of a new term (RBS) bystating that the term was used to different it from a well-known project management term (WBS).

• We are now in a position to investigate the relationshipbetween the RBS and the WBS in order to emphasise thedifferences between the two structures.

• The concept of the WBS is closely related to the physicalstructure shown (horizontally) in the allocation matrix.

• WBS documents the work and products necessary toproduce the system, which necessarily includes all the CIslisted in our allocation matrix.

RBS vs WBS (an aside)

• In addition to the CIs, the WBS adds additional workincluding:

– Design and development work

– Integration effort

– Test and evaluation effort

– And more

• WBS is based more around project managementimperatives and concepts.

• To that end, the relationship between WBS and RBS is verysimilar to the relationship between CI list and RBS.


3-10

RBS vs WBS—Aircraft example

Aircraft system

Systems engineering/project management

Air vehicle

Systems test &evaluation

Training

Data

Operationalactivation

Supportequipment

Spares

Facilities

•Undercarriage CI•Wings/fuselage CI•Fuel system CI•Hydraulic system CI•Flight controls CI•Engine CI•Avionics CI•Interior CI•Design, integration, assembly, test

•Developmental test & evaluation•Acceptance test & evaluation•Operational test & evaluation•T&E support•Test facilities

•Aircraft equipment•Support services•Facilities

•Technical publications•Engineering data•Management data•Support data•Data repository

•Test & measurement equipment•Support & handling equipment

•System-level assembly,installation & checkout

•Technical support•Site construction

.........

.........

.........

.........

............

.........

.........

.........

.........

.........

.........

.........

.........

.........

.........

.........

............

1.1.11.1.1 ..........1.1.2 ..........1.1.3 ..........1.1.4 ..........1.1.5 ..........1.21.2.1 ..........1.2.2 ..........1.2.3 ..........1.31.3.1 ..........1.3.2 ..........1.3.3 ..........1.3.4 .............

Project RBS

CI C

CI D

CI E

CI F

CI n

CI A

CI B

Configuration Items (CI)

Project (Contract) WBS

System Requirements

Project Requirements

EP

3

EP

4

EP

5

EP

6

EP

m

EP

1

EP

2

Enabling Products (EP)

7.7.17.1.1 ..........7.1.2 ..........7.1.3 ..........7.1.4 ..........7.1.5 .............

Sys

tem

Req

uire

men

t Spe

cific

atio

n (S

yRS

)S

tate

men

t of W

ork

(SO

W)

Pro

ject

(C

ontr

act)

Req

uire

men

ts


3-11

Interface identification/design

P3.4 Develop interface requirements

P3.5 Produce ICDs

P3.1 Review requirements allocation

P3. Conduct interface identification/design

P3.2 Identify interface considerations

P3.3 Form ICWG


Interface identification/design

• During the selection of the subsystems/CIs comprising thesystem, the interfaces between the subsystems/CIs areidentified.

• Identification of interfaces is a critical part of PreliminaryDesign because interfaces:

– not only determine successful operation of the systemonce integrated,

– but also place additional limitations and requirements onthe design of the individual subsystems/CIs.


3-12

Interface identification/design example

• Let’s work quickly through an interface example in theaircraft system

• The engine CI must interface with a range of other CIs

• Possibly the most obvious interface is with the fuel CI

• There will be a physical interface to allow fuel to flow into theengines

• The interface requires additional definition through:

– Flow rates and pressures required by the engine tosupport its operation

– The means of physically connecting fuel lines and so onto the engine

Interface definition with the N2 diagram

• An effective interface definition and design tool is known asthe N2 (or N2) diagram.

• Although originally a software engineering tool, the diagramsare extremely useful in all types of interfaces by identifyingthe interfaces, identifying any conflicts, as well ashighlighting any assumptions regarding dependencies.

• In simple terms, the diagram represents a matrix with systemfunctions (or physical elements) running down the diagonaland the remainder of the cells in the matrix represent theinterfaces.


3-13

Generic N2 diagram

Function 1(F1)

Function 2(F2)

Function 3(F3)

Function 4(F4)

Function 5(F5)

F1 F2 F1 F3 F1 F4 F1 F5

F2 F1 F2 F3 F2 F4 F2 F5

F3 F1 F3 F2 F3 F4 F3 F5

F4 F1 F4 F3F4 F2 F4 F5

F5 F1 F5 F3 F5 F4F5 F2

Interface definition with the N2 diagram

Avionics

Engine

Fuel

Hydraulic

Externalsystems

•Throttlecontrols

•Electricalpower

Fuelpumpcontrol

HMI

Mechanicalpower to drive

generators

Mechanicalpower

Inputs tofuel

gauges

Fuelpressure/

supply

Currentquantity

indication

Inputs toHydraulicgauges

Pressureto fuelpumps

Landing &navigation

inputs

Refuelingequipment

Currentquantity

indication

Refillingequipment


3-14

Subsystem-level synthesis

P4.4 Investigate design alternatives

P4.1 Review requirements allocation and interfaces


P4.2 Consider candidate physical architectures

P4.3 Optimize design space


P4.5 Select preferred design










3-15


• There are three broad alternatives open to the designers ofthe subsystems:

– Buy the subsystem from a supplier and integrate thatsubsystem with the other (commercial off-the-shelf orCOTS)

– Buy the COTS subsystem but modify it to suit yourspecific needs (modified COTS)

– Design and build the system from the ground upspecifically for your purpose (developmental approach)

COTS

• Advantages:– Items are likely to be readily available (few or no delays)– COTS items are very likely to be much cheaper than the

developmental approach– Maintenance and support will also probably be already

established for commercial items– Technical risk is reduced - it’s a known quantity whose

performance can be readily tested/verified– May be validated (qualified) in the environment


3-16

COTS

• Disadvantages:– May not be perfectly suitable—common problems include

form, fit or functional problems (size, shape, weight,excessive/insufficient functionality)

– Technology base likely to be quite old– Alternatively, technology could be quite immature– Use and support may be constrained by warranty or IP

issues– Support may have to be back to the supplier– Very little documentation available– May have additional (undesirable) functionality– May not be validated (qualified) in the environment

Modified COTS• Advantages:

– Modified COTS items have the same advantages asCOTS items

• Disadvantages:– Maintenance and support agreements may be voided if

the item is altered– The effort required to modify items is usually grossly

underestimated in terms of both cost and time


3-17

Developmental items• Advantages:

– May precisely meet our requirements in terms of form, fitand function

– All aspects will be understood (and controlled) from asecurity perspective

• Disadvantages:– Advantage may not eventuate– Significant effort associated with developing items– Maintenance and support needs to be developed and

deployed

SyRS


Problem space (in which stakeholders’ business exists)

Stakeholder’sOperationalEnvironment

StakeholderRequirements

CIs

Solution space (including available technologies, and types of products and systems)—stable architectural building blocks

Architectural Family

Logical to Physical Translation

LogicalArchitecture

PhysicalArchitecture

Constrains

Influences

StRS

Constrains

Solution DomainProblem Domain

Use of architectures


3-18









Optimal use of design space

• Even though we are now concentrating on the design ofsubsystems, it is critical that we remain focused on system-level performance.

• Performance of our subsystems must come second behindsystem-level performance.

• Optimal system-level performance often requires sub-optimal subsystem-level performance.

• We refer to the process of ensuring optimal system-levelperformance as making optimal use of the available designspace.


3-19


• Example: Traffic management system

AA

BB

CC

1

1

2

2

3

3


• This example has not shown little design space other thanbeing able to allocate different proportions of red/green timeson the north-south and east-west roads.

• There is generally room to move in the design of oursubsystems.

• Aim is to do the very best we can without failing in someaspects of function or performance.

• This aim requires design teams to “share” some of theirroom to move with other teams.


3-20

Example of optimal use of design space

• Let’s look at the design of the Interior CI for the ACMEaircraft.

• We know that the seat is important to the class-leadingcomfort required and we can trace seat dimensions back tothe StRS.

• Let’s say for this example that the minimum acceptable seatsize is 576 in2.

• Let’s also say, for the purposes of this example, that theminimum acceptable passenger load is 150.

• Designers explain that the number of passengers on boardcritically limits the possible seat dimensions. Naturally, themore passengers, the smaller each seat becomes for agiven overall length allocated to the Interior CI.


• The designers provide us with a simple graph to explain.

Number ofpassengers

Seat dimensions (sq in)

Minimum

576Minimum

Design space

170

750

150


3-21


• Based on this graph, we feel confident that we will meet orexceed both requirements.

• In fact, we can either:

– increase the number of passengers to 170 (exceeding theminimum requirement for 150) and still meet the seatdimension requirement, or

– meet the passenger requirement and provide eachpassenger with a much bigger seat, or we could choosesomewhere in between.

• In short, we have some ‘design space’.


• Provided we keep within the design space available, we willmeet or exceed all requirements.

• We must keep in mind, however, that we don’t want toexceed some requirements at the expense of others.

• Remember, in systems engineering, we are looking to strikea balance.

• To use design space appropriately, however, thestakeholders must be consulted. Designers do notnecessarily own the design space; the stakeholders do.


3-22


• We also need to keep aircraft weight in mind becauseairfields don’t like aircraft denting the runway.

• We know that, to meet the StRS requirement to operate fromall Class X airfields in the world, a maximum aircraft weightconstraint was determined. For this example, we assumethat the aircraft weight is not to exceed 130,000 lbs.

• The designers tells us that the more passengers on board,the heavier the aircraft becomes.

• They have a formula that allows for weight of people,baggage, additional food etc to support the flight.


• The designers provide us with a simple graph to explain.

Number ofpassengers

Aircraftweight (lbs)

130,000Maximum

Design space

Minimum

160

120,000

150


3-23


• We can now see that we can’t carry as many people as theprevious graph showed us (due to weight)—the designspace relating to passenger numbers has now shrunksomewhat.

• We can only carry 160 passengers, which fortunately stillexceeds the minimum requirement of 150.

• And, with 160 people on board, we can still have a seatlarger than 576 square inches, which exceeds that minimumrequirement.

• We are looking good.

• Of course we could opt to save weight rather than to exceedpassengers and seats, in which case the minimum all upweight of the aircraft will be 120,000 lbs.


• This type of exercise often does not come up with such greatresults.

• Unavoidable conflicts between design and requirements areusually uncovered.

• By way of example, let’s assume the designers of the engineCI have identified a COTS engine. The designers areattracted to the COTS engine because it offers all of theclassic advantages of COTS design; reduced schedule, costand technical risk, and well-established logistics support (infact, it may even be mandated by ACME for those reasons).

• Unfortunately, while the engine meets most requirements, itfails to meet a derived requirement for minimum levels ofthrust for a 130,000-lb aircraft.


3-24


• Designers provide the following graph.

Thrust level required tomeet performance

Aircraftweight (lbs)

130,000Maximum

(Requirement 1.3)

COTS Engine

X

115,000


• The COTS engine can support an 115,000 lb aircraft.

• Remember our maximum allowable weight is 130,000 lbs, soweight is not a problem from the perspective of the airfields.

• From the perspective of minimum weight, we have aproblem, however. Remember, if we carry the smallestnumber of passengers, a 120,000 lbs is the lightest aircraftwe can build whilst meeting the requirements for comfort andminimum number of passengers.

• We have a 5,000 lb problem.

• What can be done?


3-25


• We have a conflict between design and our requirements:

– Investigate the other areas (of design) and see if anyonehas spare space to provide to us—that is, can we save5,000 lbs somewhere else?

– Use traceability to understand the relationship betweenthe design and the functional architecture.

– Understand the stakeholder requirements at risk.

– Alert the stakeholders and see whether we have anyroom to move.

– Check for a priority among the conflicting requirements (ina worse case, we may have to meet the highest priorityrequirements at the expense of others).










3-26

Select preferred design

• The reason we have allocated and derived requirements forour subsystems is to ensure the resulting subsystems arecompatible with and add to the achievement of system-levelrequirements.

• We may not achieve a perfect match straight away.• Remember that systems engineering is an iterative

discipline.• We need to select the best solution now and note any

discrepancies or shortfalls.• We may have to continue with the loop of synthesis and

evaluation a number of times before preliminary design issuccessful.

• At the conclusion, we need to arrive at the preferredsubsystem level solution.

Select preferred design

• Once complete, preliminary design results in a description ofthe preliminary architecture of hardware, software, personneland so on organised in such a way as to satisfy the series ofapplicable requirements.

• The main ‘deliverable’ from this design is a description ofeach subsystem including how it interfaces with the othersubsystem—contained in development specifications.

• The specifications need to be detailed enough to allow:

– Hardware people to design and integrate the hardware.

– Software people to write software containing functionality.

– Logistics people to procure off the shelf items anddevelop logistics support for the system.


3-27

Preliminary Design Review (PDR)

P5. Conduct Preliminary Design Review


To Detailed Design and Development

P5.1 Confirm entry criteria satisfied

P5.2 Prepare and review documentation

P5.3 Agree agenda

P5.4 Confirm subsystem-level solution

P5.5 Agree action items

ApprovedAllocated Baseline

P5.6 Confirm exit criteria satisfied


• The major PDR task is to investigate each CI.

• Ensure that all system-level requirements have beenallocated appropriately.

• Ensure that the system-level requirements have beenallocated and derived to sufficient levels of detail to supportdetailed design and development

• Ensure that CI to CI (internal) interfaces have been identifiedand documented.

• Ensure CI to environment (external) interfaces have beenaddressed.


3-28


• PDR should review and approve the documentation set thathas been developed to document the allocated baseline.

• This is the baseline that will be used during detailed designand development.

• Successful PDR establishes the allocated baseline andauthorizes detailed design against that baseline.

• Not all issues will be resolved during PDR: some actionitems are to be expected.

• Actions out of PDR should not be “show stoppers” or theshow should be stopped until they are addressed.


• PDR could be conducted:

– on each subsystem or CI (separate review for each CI), or

– as a system-level review at which all CIs are reviewed

• Approach should be driven by size, complexity and risksassociated with the development effort.

• Documentation reviewed includes:

– Development specifications

– Interface control documents

– Draft product specifications (if applicable and available)


3-29

Detailed Designand

Development

Detailed Design and Development

• The Detailed Design and Development activity continues thedevelopment effort based on the FBL and ABL developedduring Conceptual and Preliminary Design.

• The detailed design effort takes these definitions of theoverall system (FBL) and of the major CIs (ABL) andfinalizes the design of specific components that make up theCIs (and subsystems).

• The realization and documentation of individual componentsused to support production is referred to as the ProductBaseline (PBL).

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign


3-30

Detailed Design & Development

• The major technical activities undertaken during DetailedDesign and Development include:

– Describing the lower-level assemblies and componentsmaking up the CIs (and their interrelationships).

– Defining the characteristics of those items throughspecifications and design data.

– Finalising the design of all interfaces necessary to supportsystem integration.

– Procuring items COTS or designing them.

– Developing prototypes or engineering models of the CIs.

– Conducting a Critical Design Review (CDR) to confirmthat design is ready for construction and production.

Integration

• Design has been focusing on developing the lowest levelcomponents of the system.

• These components need to be:

– Procured (in the case of COTS equipment).

– Procured and modified (for modified COTS).

– Constructed (in the case of developmental items)

• Integration focuses on combining the individual componentsto form the next higher-level assembly.

• At each stage of integration, evaluation will take place toverify success.


3-31

Integration

• Interface information is central to successful integration.

• Interface information is located in:

– SyRS

– Interface Control Documents (ICDs)

– Development Specifications

– Product Specifications

• Integration may bring components together that have beendeveloped in geographically different locations.

• Communications between design teams is critical.

Integration

• While the design process is top-down, the integrationprocess is bottom-up. At each stage of the integration, someform of integration testing will be conducted to verify thesuccessful integration.

Subsystem

Component Component

Subsystem

Integration testing

Assembly Assembly

SystemSystem

Development Integration

Design Solution


3-32

Detailed design reviews

• Equipment/Software Design Reviews

– Can be formal or informal.

– Conducted on each piece of equipment or software item(that is on each CI).

– Concentrates on ensuring that the design is capable ofmeeting allocated requirements.

– Design approach, decisions, and documentation will bethoroughly reviewed.

– Testing results, discrepancies and rectifications will alsobe investigated.

– May involve production readiness reviews (PRRs).

– All reviews need to be completed prior to Critical DesignReview.

Critical Design Review (CDR)

• Major review of Detailed Design and Development.

• Final review prior to commencement of Construction and/orProduction.

• Collection of specifications reviewed and approvedestablishing the PBL.

• Establishment of the PBL is an effective freezing of design-related activity.

• Final TPM results will be investigated as part of CDR.

• Production Plans will also be approved.


3-33

Constructionand/or

Production

Construction and/or Production

• At the end of Detailed Design and Development, the PBLhas been established and the production process is in placeand has been proven (most likely with the trial production ofselected system elements).

• The system can now move into Construction and/orProduction.

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign


3-34


• As with all other system requirements, Construction and/orProduction requirements need to be considered early in thesystem development.

• Issues that need to be addressed include:

– material availability (lead times), ordering, and handling;

– availability of skill sets (including any training);

– availability of production tools and equipment;

– fabrication requirements including productionrequirements, assembly drawings and instructions;

– processing and process control;

– assembly, inspection and test; and

– packaging, storage, and handling.

The Production Plan

• A Production Plan needs to be produced early in theprogram and revised continually to take into account specialrequirements flowing from design.

• The Production Plan will need to be finalised and approvedprior to Construction and/or Production (which means thatCDR is the latest time for approval).

• The content of the plan will vary depending on the specificrequirements of the system.

• Systems engineering process can be used to help developthe plan.


3-35


• Other activities

– Test and Evaluation activities

• These activities are part of the overall T&E effort.

• Will be covered in System Engineering Management.

• Basically revolve around ensuring system (asconstructed) meets requirements.


• Other activities

– Configuration Audits

• Part of the Configuration Management effort.

• Also discussed in Systems Engineering Management.

• Revolve around ensuring items (as built) are inaccordance with the appropriate documentation:

– Physically (Physical Configuration Audit)

– Functionally (Functional Configuration Audit)


3-36

Functional Configuration Audit (FCA)

• FCA is used to verify and certify that the performance of theCI meets the specified requirements.

• That is, it is a check to ensure that the final as-built CIfunctionality as demonstrated by the test and evaluationeffort is the same as the specified functionality for that CI inthe relevant Development Specifications and ProductSpecifications.

• The FCA may not be a complete review of CI functionality; itmay be conducted incrementally throughout thedevelopment of the CI (although a final FCA is necessary forthe CI).

• …

ANSI/EIA-649-B-2011

Functional Configuration Audit (FCA)

• …

• Some CIs depend upon the successful operation of otherCIs and are not testable until after system integration.

• In these cases, the FCA may not be completed until after theintegrated system testing is complete. FCAs for all CIsshould be complete prior to releasing the design to full-scaleproduction.

ANSI/EIA-649-B-2011


3-37

Physical Configuration Audit (PCA)

• The objective of the PCA is to provide confidence that theas-built CIs match the low-level specifications such as theProduct Specifications, assembly specifications, drawingsand technical data.

• PCAs are conducted on the final versions of the CIs (that is,the version of the CIs representative of the as-built items).

• The PCA is performed on the first production version of eachof the CIs.

• In the case of a system where multiple copies are beingproduced, a partial PCA may be conducted on eachsubsequent production item to ensure that the productionprocess remains constant.

• …

ANSI/EIA-649-B-2011

Physical Configuration Audit (PCA)

• …

• Normally, FCA for a given CI will precede PCA. Thisprevents the situation where the CI fails FCA and requiressome changes to be made in which case, if PCA had alreadybeen conducted it may be invalidated by the changes to theCI. Once a CI has passed FCA, PCA can be conducted withmore certainty.

ANSI/EIA-649-B-2011


3-38

Test Readiness Review (TRR)

• Testing is an expensive and time-consuming exerciseinvolving highly trained personnel, expensive facilities, andspecialized test equipment.

• Test Readiness Reviews (TRR) are sometimes contractuallyrequired by the customer to demonstrate that the system CIsare ready to enter formal test and evaluation.

• To that end, CI-level TRRs occur during Construction and/orProduction and are designed to avoid the unnecessaryexpense involved with committing T&E resources to a CI orsystem that is not sufficiently mature to enter testing.

• A system-level TRR may be conducted before commencingmajor verification activities such as AT&E.

Test Readiness Review (TRR)

• To assess the readiness of the CI or system to enter formaltesting, the TRR normally reviews a range of documentationincluding:

– Test and Evaluation Master Plan (TEMP)

– Test plans

– Formal and informal test results

– Supporting documentation

– Support, test equipment, and facilities


3-39

Formal Qualification Review (FQR)

• The Formal Qualification Review (FQR) may be required toverify that the performance of each of the CIs meets all thefunctional requirements when integrated together into thesystem.

• The FQR will demonstrate that the integrated systemcomplies with all the specifications generated as part of theproject including SyRS, Development Specifications, andinterface requirement specifications.

• From this point of view, the FQR could be considered a‘system-level’ configuration audit.

• Normally, the FQR would be conducted following theconfiguration audits and may mark formal system-levelacceptance by the customer.

Configuration management

• During construction and production, it may become clear thatitems of the system are not going to meet the all of theminimum requirements specified in the baselines.

• To cover this possibility, the configuration managementprocess uses a system of requests for variance andengineering changes:– Engineering changes are required where the departure

from the specification is going to result in either a changein design or a change in requirement.

– If, however, the failure to meet the minimum requirementsis temporary in nature, limited to only a small percentageof the supplies or a very minor departure, a request forvariation may be approved by the customer.

• We discuss configuration management in more detailshortly.


3-40

Construction and/or Production Summary

• Follows design freeze after Detailed Design andDevelopment.

• Involves important issues that need consideration early indesign development.

• Systems engineering process used to help develop aProduction Plan.

• Involves Systems Engineering Management functions suchas test and evaluation management and configurationmanagement.

Utilization Phase(Operational Use and System Support


3-41

Operational Use and System Support

• System enters Utilization Phase following successfulConstruction and/or Production

• Systems engineering involvement is now quite minimal

• Major system activities:

– Operational Use

– System Support

– Operational Test and Evaluation

– Modifications

AcquisitionPhase

UtilizationPhase

RetirementPhase



• Operational Use

– Deployment and operation of the system against theoriginal requirements

– Note that requirements and use of the system may wellchange as time goes on

• System Support

– Maintenance and support activities designed duringAcquisition Phase

– Aims to ensure that system is capable of fulfillingoperational requirements

– Support can become challenging as the system ages


3-42


• Modifications

– May be made early in the Utilization Phase to rectifydiscrepancies in System performance discovered duringOperational Test and Evaluation.

– Must be made in accordance with sound configurationmanagement practices (introduced in SystemsEngineering Management).

– Main reasons for modifications include:

• Rectification of system performance problems.

• Failures identified by the FRACAS process (discussedshortly).

• New or revised operational requirements.

• Ensure continued supportability.

Modifications

• Significant modifications can be considered systems in theirown right.

Utilization Phase

Modification A

Modification B

Modification C

Modification D

PreliminaryDesign

DetailedDesign and

Development

ConceptualDesign

Constructionand/or

Production


3-43

Example—ACME Air engine replacement

• Large aircraft systems are often designed to have a usefullife of 30 to 50 years.

• During this time, changes in technology areas such asengines and avionics will continue at a rapid pace. It iscommon for the operators of these aircraft systems toconduct major modifications to their fleets.

• Modifications may include replacing engines with moremodern equivalents and replacing aging avionics with moresophisticated solutions.

• Such modifications have a great impact on the aircraftsystem and may result in performance enhancements in thesystem, may allow additional tasks to be conducted usingthe aircraft and may allow the aircraft to operate in achanged environment.

Example—ACME Air engine replacement

• Adding a new engine to our aircraft system would requiresignificant changes:

– The air vehicle element will be changed significantlybecause the engine is a major component of the aircraft.

– Changing an engine will also require changes to other CIsto which it interfaces. Test and evaluation on the engineitself and any system-level functions affected by theengine will need to be rewritten and performed.

– Training will be impacted as maintainers and operatorswill need to become familiar with the change.

– A new suite of technical and engineering data will berequired to document the changes.

– Support equipment, spares and facilities may also beaffected.


3-44


• When significant modifications are required, systemsengineering becomes relevant in the Utilization Phase.

Sys

tem

s en

gine

erin

g im

pact

High

Low

Modification

Conceptual &PreliminaryDesign

DetailedDesign and Development

Constructionand/orDevelopment

Utilisation &Phase Out

Sys

tem

s en

gine

erin

g im

pact

High

Low

Modification









FRACAS

• A failure reporting, analysis, and corrective action system(FRACAS) is a closed-loop system designed to continuallymaintain visibility into system operation and support.

• The FRACAS is put in place to record, analyze and rectifythe cause of system failures, especially recurring or relatedfailures.

• The important difference between a maintenance systemand a FRACAS is that the maintenance system rectifies thefailure and the FRACAS attempts to rectify the cause.


3-45

FRACAS

• A successful FRACAS may highlight reliability andmaintainability issues as a system proceeds through its lifecycle—as it ages, a system normally become less reliableand more difficult to support and maintain.

• The FRACAS is in place to help counter this natural declinein reliability and maintainability.

• A FRACAS based on MIL-STD-2155(AS) has six steps:

– failure reporting,

– failure analysis,

– failure verification,

– corrective action,

– failure report and close-out, and

– identification and control of failed items.

Example FRACAS process

Testing and operatingthe system

Logfailure

Collectdata

Normaloperation

Failure

Generatefailure report

Failuredatabase

Repeat and analyzefailure

Carry outcorrective action

Configurationmanagement

Monitorresults

Review and recommendcorrective action

MIL-STD-2155(AS)


3-46

Retirement Phase

• Final stage in the life cycle.

• Activities include:

– Transportation

– Handling

– Decomposition

– Processing

• Disposal can be costly and time consuming and theRetirement Concept should be considered early.

• User must ultimately pay for disposal.

AcquisitionPhase

UtilizationPhase

RetirementPhase


Retirement from life cycle

• A system may be retired from a number of life cycles beforefinal disposal at end of life.

Development ProductionConceptUtilization /

SupportRetirement


SupportRetirement

First life cycle

Second life cycle

Final life cycle


SupportRetirement

Disposal

Retirement from first life cycle

Retirement from second life cycle


3-47

Retirement process

• When considering the retirement aspects of the systemduring its design, it is useful to undertake three broad tasks:

– identify the reasons for potential retirement,

– identify potential retirement methods for the system, and

– identify design issues that may arise from theconsideration of each retirement method.

Reasons for retirement

• There can be any number of reasons for system retirement:– The system may have reached the end of its life and no

longer be usable and/or supportable.– The system may still largely be useful, but one or more

critical components may be unusable or unsupportable.– The system may still be perfectly useful, but it (or a

significant subsystem of it) is being retired because:• the business need for the system may have

disappeared; or• the business need is still valid but the business owner

is forced to retire the system.– The system (or one of its critical components) may be

damaged beyond economical repair (by accident, naturaldisaster, act of war, or vandalism).


3-48

Potential retirement methods

• There are a potential retirement methods for the system(although not all may apply to all reasons for retirement):

– Sold as a second-hand item.

– Traded in on a replacement system.

– Re-deployed as a training aid.

– Destroyed and disposed as waste.

– Disassembled—that is, broken up and sold as workingsub-systems, assemblies, or components.

– Scrapped—that is, broken up and sold as sub-systems,assemblies, or components for their value as scrap.

– Placed in storage—that is, mothballed because none ofthe other methods are currently acceptable or tenable.

Design issues that arise

• A number of design issues may arise, such as:

– observance of recycling regulations;

– avoidance of the use of potentially hazardous/toxicmaterials;

– environmental impact;

– cost of disposal/destruction/uninstallation;

– cost of refurbishment for resale or trade-in;

– desirability of salvage or material recovery for resale;

– cost of transportation for disposal;

– …


3-49

Design issues that arise

• A number of design issues may arise, such as:

– …

– need for specialized personnel/equipment required fordisposal;

– observance of any caveats on disposal (such as might beplaced on military equipment by international arms tradeagreements, or might be placed on high technology bynational sanctions);

– time taken to arrange disposal; and

– availability of design data and drawings to supportdisposal.

Disposal problems

• Radioactive Material– But Australia does not use much radioactive material?– Devices such as infra-red detection systems contain

radioactive material.• Cryptographic Material

– Large amount of cryptographic material being used today.– Financial organisations, military, and government.– Reliance on information systems means crypto will

increase.– Disposal of systems that have stored or used

cryptographic material (example hard drives and floppydisks) is not simple.

– Throwing away or selling used machines isunsatisfactory.


3-50

Systems Engineering Management

Systems Engineering Management

SYSTEMS ENGINEERING MANAGEMENT

SYSTEMS ENGINEERING PROCESSES

Preliminarydesigntasks

Detaileddesigntasks

Construction/production

tasks

Utilisationrelatedtasks

Conceptualdesigntasks

RELATED DISCIPLINES

SYSTEMS ENGINEERING

TOOLS


3-51

Systems engineering management

• Topics covered:

– Technical Reviews and Audits

– System Test and Evaluation

– Configuration Management

– Specifications and Standards

– Integration Management

– Systems Engineering Management Planning

Technical reviews and audits

• Technical reviews and audits measure progress and reducetechnical risk by:

– providing a formal evaluation of design maturity

– measuring and reporting on planned and actualperformance

– clarifying and prioritising design requirements

– evaluating and establishing the system baseline atdiscrete points in the design process

– providing an effective means of formal communicationbetween stakeholders

– recording design decisions and rationales for laterreference


3-52


• Work for both customer and contractor.

• Vital part of systems engineering.

• Range from very informal discussions to formal meetings.

• Aim to determine the ability of the design to meet thenecessary requirements.

• Reviews will tend to become more detailed as the designprogresses.

• Normally specified (number, content and timing) incontractual documentation.


• Number of reviews required will depend on:

– Complexity

– Size

– Technical risk

• Reviews must be scheduled at the correct stage in thedevelopment:

– Too early = immature design, unable to determineadequacy

– Too later = miss opportunities to rectify problems

• Normally relate reviews and audits to documentation releasein early stages.

• Seen as a major technical risk monitoring tool.


3-53


• We have already discussed the following reviews and auditsdiscussed in MIL-STD-499B:

– System Requirements Review

– System Design Review

– Preliminary Design Review

– Critical Design Review

– Test Readiness Review

– Functional Configuration Audit

– Physical Configuration Audit

– Formal Qualification Review

Conceptual Design

Preliminary DesignDetailed Design & Developm

Construction and/or Product

ConceptualDesign

DetailedDesign &

Development

PreliminaryDesign

Constructionand/or

Production

Operational Useand

System Support

MISSION

DISPOSAL

•Feasibility Analysis•System RequirementsAnalysis•System Synthesis &Evaluation

•Subsystem FunctionalAnalysis•Requirements Allocation•Sub-system Synthesis &Evaluation

•Detailed DesignRequirements•Designing & IntegratingSystem Elements•System PrototypeDevelopment

System Level Subsystem Level Component Level Modifications Modifications

System Design ReviewPreliminary Design Review

Critical Design Review

Functional Baseline•SyRS

Allocated Baseline•Development Specifications

Product Baseline•Product Specifications•Process Specifications•Material Specifications

Formal Qualification Review

Functional Configuration Audit

Physical Configuration Audit

Test Readiness Review

System Requirements Review

BNR/SNR



3-54

Technical review and audit management

• Review and audit requirements can be extensive.

• Management required to ensure overall aims of the reviewand audit program are met.

• Requirements must be specified in contract.

• However, requirements must be proportional to size andcomplexity of the project:

– Under-reviewing will expose the project to risk.

– Over-reviewing will needlessly increase cost andschedule without additional benefit.

Technical review and audit management

• Both customer and contractor need to be involved.

• Both parties can add value.

• It is not to be used to bring inexperienced personnel ‘up tospeed’.

• Results must be documented.

• Action items must be assigned to an individual (unassignedaction items = unactioned action items).


3-55

Technical Reviews and Audits Plan (TRAP)

• The principal way of managing the technical review andaudit effort is via a Technical Reviews and Audits Plan(TRAP).

• The TRAP documents all formal reviews, detailing the entrycriteria that must be met prior to the commencement of thereview or audit and the exit criteria that must bedemonstrated prior to approval of the review or audit.

• The TRAP is normally drafted and approved duringConceptual Design.

ConceptualDesign

DetailedDesign &

Development

PreliminaryDesign

Constructionand/or

Production

Operational Useand

System Support

MISSION

DISPOSAL















BNR/SNR

Technical Review and Audit Plan (TRAP)

Technical Reviews and Audits Plan (TRAP)


3-56

Test and Evaluation

System T&E

• Ensures consistent and coordinated approach to systemtesting.

• Directs the focus of Test and Evaluation (T&E) effort atdifferent life-cycle stages.

• Aims to progressively test and evaluate the system as itpasses through the life cycle.

• Aims to identify problems early to avoid costly and timeconsuming rectifications later.

• T&E is a major technical risk mitigation measure.


3-57

System T&E

• Testing can be expensive and time-consuming:

– Specialised test equipment.

– Highly trained personnel.

– Expensive operating costs.

– Facilities.

• A formal plan is usually required to manage the entire T&Eeffort: Test and Evaluation Master Plan (TEMP).

Verification and Validation (V&V)

• The entire systems engineering process aims to produce asystem that is:

– verified against the documentation produced, and

– validated against the original needs, goals and objectives.

• V&V ensures that we have both:

– built the system right (verification); and

– built the right system (validation).

• The T&E effort supports V&V.


3-58

T&E categories

• Developmental Test and Evaluation (DT&E):– Largely undertaken in the Acquisition Phase.– Support design and development effort.– Generally undertaken by contractors.

• Acceptance Test and Evaluation (AT&E):– Formal acceptance testing on behalf of customer.– Between the Acquisition and Utilisation Phases.

• Operational Test and Evaluation (OT&E):– Focuses on functional or operational testing of the

system.– Generally undertaken by users following acceptance.– Some OT&E can occur earlier during Acquisition Phase,

particularly for large, phased projects.

T&E categories

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ACQUISITIONPHASE

UTILIZATIONPHASE

ConceptualDesign

AT&E

OT&E

DT&E


3-59

Developmental Test and Evaluation (DT&E)

• Takes place throughout the Acquisition Phase.

• Aims to highlight design deficiencies early—the earlier adeficiency is noted, the cheaper and easier it is to rectify.

• Used to validate designs and to monitor and minimisedesign-related risks.

• Covers a broad range of testing levels:

– Lowest level components - test bench and breadboards

– System prototypes very close to final systemconfiguration

DT&E

• Responsibility normally lies with the contractor.

• Although a contractor responsibility, customer will normallywant visibility into DT&E progress.

– Visibility may come through the Technical Review andAudit process.


3-60

Acceptance Test and Evaluation (AT&E)

• Normally shared by contractor and customer:

– customer approves procedures

– customer and/or contractor conduct testing

– customer will always observe if not conducting

• Focused on confirming that delivered system meets thesystem-level requirements contained in the SystemSpecification and the contract (back to the FunctionalBaseline).

• Discrepancies are documented and rectified.

• On successful conclusion, system is accepted and willformally enter Utilization Phase.

Operational Test and Evaluation (OT&E)

• Used by the customer to assess the ability of the system tomeet the original needs (as articulated and modified duringConceptual design).

• Testing now focused on operational functionality rather thandesign issues.

• Normally, testing agency within the customer’s organisationwill be independent from the procuring agency within thecustomer’s organisation.

• Independence is important to gain an unbiased assessment(sometimes the procuring agency will feel some ownershipand responsibility for system performance).


3-61

OT&E

• Modifications may be suggested as a result of OT&E.

• OT&E may also be used to assist operators to fine-tuneoperational procedures relating to system use.

• Must be conducted in as realistic conditions as possible.

• Responsibility of the customer organisation.

OT&E

AT&E

AT&E

AT&E

AT&E

AT&E

AT&E

Facilities

Training

Support

Supplies

Personnel

SyRS


Capability System Development


In-service

DeliveredCapabilitySystem

StRSOrganisation

Major System AT&E

OT&E

Validation

Verification


3-62

Test management

• To allow a coordinated approach to testing, DT&E, AT&Eand OT&E will normally be managed by the contractor.

• Coordination ensures minimal impact on schedule andmaximum effectiveness.

• Coordination may also save on T&E resources and avoidunnecessary duplication of effort.

Test and Evaluation Master Plan (TEMP)

• Test and Evaluation Master Plan (TEMP) is the major planfor entire T&E effort.

• Required by contract, prepared by contractor and approvedby customer.

• Drafted during Conceptual Design and approved by the endof Preliminary Design.

• Should be reviewed at each formal review to ensure that anydesign changes are reflected in the testing program.


3-63

TEMP content• System Description - brief description of system and major

mission descriptions.• Program Summary - T&E responsibilities and schedule.• T&E Outline:

– DT&E, AT&E and OT&E delineation.– Reference to results of previous testing.– Details of future testing.

• T&E Resource Summary - includes personnel, testequipment, facilities, training and so on.

• Appendices:– Relevant documentation– Includes test procedures and test reports

ConceptualDesign

DetailedDesign &

Development

PreliminaryDesign

Constructionand/or

Production

Operational Useand

System Support

MISSION

DISPOSAL















BNR/SNR





3-64

Configuration Management

Functional-to-physical translation

ABL(CIs)

AcquisitionCM

In-serviceCM

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

Phase

Design

Acquisition UtilizationPhase

Conceptual


3-65

Introduction

• Configuration means:

– “the relative disposition of the parts or elements of athing”.

• In SE terms, a “thing” is normally called a configuration item(CI).

• “The relative disposition of parts or elements” is called abaseline.

Introduction

• Configuration Management:

– “the act of controlling and managing the physical andfunctional make-up of the configuration items thatcomprise the system”.

• Aims:

– Identify the functional and physical characteristics of CIsduring Acquisition.

– Control changes to the characteristics of those CIs

– Record and report status as required.


3-66

Introduction

• An accurate ‘snapshot’ of the CIs and therefore the systemcan be provided through effective configurationmanagement.

• CM also maintains an effective history of the changes.

• History should also include:

– Alternatives considered

– Reasons for selecting preferred alternative

CM functions

• CM planning and management is conducted over the lifecycle to ensure that the appropriate tasks are performed andthe necessary resources are available at the right times.

• Configuration identification identifies the items (the CIs) to beplaced under configuration management.

• Configuration change management ensures that changes toCIs can be conducted in accordance with an effective,systematic, measurable, and documented changemanagement process.

• …


3-67

CM functions

• …

• Configuration status accounting provides accurate and up-to-date status information on the configuration of the itemsplaced under control.

• Configuration verification and audit establishes that theinformation relating to the CI is complete, accurate andcurrent; that the allocated physical, functional and interfacerequirements are met by the CI; and that an adequateprocess is in place to confirm the correct operation of the CMsystem.

Establishing the baselines

• Baselines have been introduced in discussion of theSystems Engineering Process as well as Technical Reviewsand Audits.

– Functional Baseline (FBL)

– Allocated Baseline (ABL)

– Product Baseline (PBL)


3-68

Configuration identification

• A CI can be defined as an aggregation of hardware andsoftware that satisfies an end-use function, whoserequirements are specified and designated for separateconfiguration management.

• Selection of configuration items during the early stages ofthe Acquisition Phase.

• Design decision based on the breakdown and allocation ofrequirements contained in the SyRS.

• Two broad categories:

– Computer Software Configuration Items (CSCIs)

– Hardware Configuration Items (HWCIs)


• CI selection criteria:

– Complexity

– Interfaces

– Use/Function

– Existing item available

– Provided by one supplier

– Criticality

– Maintenance and documentation needs


3-69


• There may be many HWCIs and CSCIs.

• Each is managed separately including design and T&E.

• CM ensures that each CI has the appropriate documentationdefining functional and physical attributes.

• The documentation must be approved, current and availablefor use.

Configuration change management

• Changes to CIs will occur throughout the project.

• Caused by a range of events:

– changes in a requirement,

– changes in available technologies and products.

• Need to be managed by a formal process to ensure impactsare investigated and handled.

• Changes are normally managed by a group called theConfiguration Control Board (CCB).


3-70


• Changes are classified by severity:

– Class 1 changes are major changes and involve form, fitor function.

– Class 2 changes are minor changes.

• Customers must be involved with Class 1 changes but willnormally only be informed of Class 2 changes.

• Example Class 2 changes include documentation update,and material substitution.

• Change managementprocesses will dependlargely on the project.

• A possible process isshown here.

• Note the more involvedprocess associated withClass 1 changes.


Changerequested

Changeapproved

Implementationplan

Monitorstatus

CCBreview

ApprovedUnapproved Undecided

Preparedocumentation

Class I Class II

Determineclass

No furtheraction

Prepareadditional

information

StatusAccountingDatabase

Informcustomer


3-71


• Change Proposals contain:

– Statement outlining the change

– Reasons for the change

– Alternatives available

– Preferred alternative detail

– Impact of the change especially interface impacts

– Draft design documentation reflecting the change

Requests for variance

• Sometimes, it becomes clear during production that itemswithin the supplies are not going to comply with the relevantbaseline specification (for any number of reasons).

• Normally, these non-conformances would be rectified usingthe formal engineering change process, however there aresituations when departures from specifications may beaccepted by the customer without the need to go through theengineering change process.

• Configuration management calls these special casesrequests for variance (previously called deviations orwaivers).

• Note that a variance differs from an engineering change inthat an approved engineering change requirescorresponding revision of the CI’s current approvedconfiguration documentation, whereas a variance does not.


3-72

Deviations and waivers

• In some organisations, the older terms of deviations andwaivers (from MIL-STD-973) may still be in use.

• Deviations and waivers are forms of request for variance—although, strictly speaking a deviation is the closest to arequest for variance.

Deviation

“A specific written authorization, granted prior to themanufacture of an item, to depart from a particularrequirement(s) of an item’s current approved configurationdocumentation for a specific number of units or a specifiedperiod of time. (A deviation differs from an engineeringchange in that an approved engineering change requirescorresponding revision of the item’s current approvedconfiguration documentation, whereas a deviation doesnot.)”


3-73

Waiver

“A written authorization to accept an item, which duringmanufacture, or after having been submitted for Governmentinspection or acceptance, is found to depart from specifiedrequirements, but nevertheless is considered suitable for use“as is” or after repair by an approved method.”

Configuration audits

• Already discussed in Technical Reviews and Audits.

• Include FCAs and PCAs:

– FCA confirms functionality of CI as described by CIdocumentation equates to actual functionality of the CI.

– PCA compares physical configuration of CI with thedocumentation set.

– If multiple copies of the CIs are being produced, theaudits are conducted on the first items.

– In the case of CSCIs, software listings are comparedagainst source code and the executable is, in fact, acompiled version of the documented source code.


3-74

Configuration Management Plan (CMP)

• A major document within the systems engineering domain.

• Defines the approved configuration management process tobe applied to the project.

• Normally two CMPs will be developed over the lifecycle ofthe system:

– Acquisition Phase - CMP developed by contractor

– Utilisation Phase - CMP developed by user/customer

• Content and layout of the CMP will vary from system tosystem.

• Determined by the customer organisation and specified inthe contract.

• An outline structure for a CMP is provided in ISO 10007.

Configuration management documentation

• Change Control Forms

– Normally a set proforma is used during the changemanagement process

– These forms are generically called change control forms

– The change control forms will reflect the approved changemanagement process as documented in the CMP

– In this way, the forms will lead the CCB through thechange management process

– Will cover initialisation, evaluation, approval and releaseof the change


3-75

Configuration management documentation

• Engineering Change Proposals (ECPs)

– relates to engineering aspects

– should contain sufficient information to allow CCB toevaluate and approve the change

– content described earlier

• Contract Change Proposals (CCPs)

– relates to contractual aspects of project

– acceptance of an ECP may well require a CCP

ConceptualDesign

DetailedDesign &

Development

PreliminaryDesign

Constructionand/or

Production

Operational Useand

System Support

MISSION

DISPOSAL















BNR/SNR



Risk Management Plan (RMP)




3-76

Specificationsand

Standards

Documentation

• One of the major outcomes from the SE process is acomplete set of technical documentation accurately definingthe designed system.

• To understand the SE process, we must also understandhow the documentation requirements fit.

• Managing the SE process involves managing thedocumentation throughout all phases since different systemdevelopments will have different documentationrequirements.


3-77

Documentation

• Documentation normally refers to project specific informationgenerated during the project by the customer or contractor -major documents include specifications and plans.

• Standards are more generic documents not related to anyone project, which are authored by many organisationsincluding:

– Government bodies - Military Standards.

– Commercial organisations - IEEE Standards.

Specifications


3-78

Specifications• Produced or procured during acquisition.

• There are five main categories of specifications:

– System Specification (SyRS)

– Development Specification

– Product Specification

– Process Specification

– Material Specification

Process Specifications

• Documents any processes relating to a given product withinthe system.

• Examples:

– Painting

– Welding

– Soldering

– Assembly

• Normally written to support manufacturing processassociated with a given product.

• Normally reviewed and approved at CDR.


3-79

Material Specifications

• Written to support the production process associated with agiven product.

• Apply to:

– Raw materials such as sheet metal

– Mixtures such as paints and chemicals

– Semi-fabricated materials such as fibre optical cable

• Reviewed and approved at CDR.

Specification tree

System RequirementSpecification

InterfaceControl

Document

HardwareDevelopmentSpecification

Hardwarerequirementsspecification

Interfacerequirementsspecification

HardwareProduct

Specification

Interfacedesign

document

ProcessSpecification

MaterialSpecification

COTSProduct

Specification

SoftwareProduct

Specification

SoftwareDevelopmentSpecification

Softwarerequirementsspecification

Interfacerequirementsspecification

Softwaredesign

document

Interfacedesign

document

Databasedesign

document

Hardwaredesign

document


3-80

Standards

Standards

• Standards collate a wealth of experience and knowledge.

• Standards provide technical guidance during systemdevelopment.

• Customers normally specify documentation and standards incontract.

• Required use of standards must be appropriate inspecification, else:

– Additional overhead

– Increased cost

– Longer schedules


3-81

Standards

• Documents that establish engineering and technicalrequirements to be applied to the acquisition process.

• Standards are specified in the contract.

• Even when not specified, the guidance contained instandards is often invaluable.

• Standards are often the product of many years of experienceand expertise.

Standards

• Some popular systems engineering standards will bereviewed later including:

– MIL-STD-499B

– IEEE 1220

– EIA-632

– ISO/IEC 15288

• Here we concentrate on the management issues relating tothe use of standards:

– Over-specification

– Tailoring

– Invocation


3-82

Over-specification of standards

• General tendency to over-specify the use of engineeringstandards.

• Incorrect assumption that including more stringentrequirements will enhance the chances of successful systemdevelopment—in fact, over-specifying introduces significantoverhead without reducing the risks.

• Overheads are passed onto the customer in the form ofincreased cost and longer schedules.

• Customer must be able to justify the inclusion of engineeringstandards.

• Justification is not ‘that standard has always been includedin our contracts’.

Tailoring

• ‘Blanket specification’ is another problem closely related toover-specification of standards.

• This means specifying the entire standard withoutconsideration of the relevance of each of the sections withinthe standard.

• Tailoring is designed to omit irrelevant sections and includeonly those sections that are important to the developmenteffort.


3-83

Tailoring

• Standards are normally designed to be tailored.

• Example:

– Not all technical reviews and audits specified in (say) MIL-STD-499B will be necessary in a relatively simple project.

– Only the most important reviews and audits will berequired.

– Other reviews and audits will be ‘tailored out’.

• Without tailoring, unnecessary and expensive activities anddocumentation will be required.

Tailoring

• Tailoring should be completed prior to tendering.

• Allows tenderers to respond with accurate estimates of cost,schedule and effort.

• In some circumstances, tailoring can be carried out duringConceptual Design with involvement from both Contractorand Customer.

• Whenever it occurs, it must occur to avoid unnecessaryeffort and expense etc.


3-84

Invocation of standards

• Some standards make reference to other standards ratherthan repeating requirements documented elsewhere.

• Example:

– Standard A might refer to Standards B, C, &D.

– Standard B might refer to Standards E, F, & G.

– By specifying the requirements in Standard A, thecustomer may unintentionally invoke Standards B throughto G.

• This may result in an exponential explosion in the number ofrequirements and standards referred to in the contractualdocumentation.

Standards evolution

MIL-STD-499

(1969)

MIL-STD-499A(1974)

MIL-STD-499B(1994)

EIA/IS 632(1994)

IEEE 1220(Trial Use)

(1994)

EIA 632(1999)

IEEE 1220(1998)

MIL-STD-499C(Draft 2005)

ISO/IEC 15288(2008)

IEEE 1220(2005)

ISO/IEC 15288(2003)

ISO/IEC 15288(2015)

EIA 632(2003)


3-85

Integration Management

Interface definition

• Integration of different system elements is managed througha document called the Interface Control Document (ICD).

• The ICD is developed during Preliminary Design (and is at asimilar level as the Development Specifications).

• ICD defines the functional interfaces between differentsystem elements.

• Individual CI interface requirements also defined inDevelopment and Product Specifications.

• ICD defines flow between CIs.


3-86

Interface definition

• Example - ICD between Sub-system A and B:

– Team A will work on A and Team B on B.

– They will write Development and Product Specs for bothsub-systems.

– Team A won’t necessarily review B’s specs and viceversa.

– Need a common document to specify interfaces.

– This will be called the A-B ICD.

Interface Control Document (ICD)

• ICD will completely define the interfaces between two CIs.

• Interface types include:

– Physical

– Electronic

– Electrical

– Hydraulic/Pneumatic

– Software

– Environmental


3-87

Managing the interfaces

• Integration management is all about communications.

• Interface problems are usually blamed on technicaldifficulties but often result from poor communicationsbetween two teams.

• ICD needs to be reviewed regularly if for no other reasonthan to ensure communications.

• Customer should review ICDs at design reviews.

Systems Engineering Management Planning


3-88

Systems engineering management planning

• Engineering Management is one of the four major components ofthis course.

• Systems Engineering is such a broad subject area that an overallmanagement plan or approach needs to be developed.

• This plan is called the Systems Engineering Management Plan(SEMP).

• SEMP details:

– Normally prepared by the contractor.

– Reviewed and approved by the customer.

• There may be more than one SEMP per system development:

– Customer.

– Contractor.

– Major sub-contractors.

SEMP

• Once approved, SEMP is the single governing document forthe engineering effort.

• Changes to the SEMP must be reviewed and approved.

• SEMP is normally reviewed at formal project or designreviews.

• Draft SEMPs received during the tendering phase may beused to determine contractor ability (and assist in comparingcontractors).


3-89

SEMP content

• No fixed content requirements for the SEMP.

• A number of engineering standards are available suggestingSEMP content.

• Standards emphasise importance of the SEMP.

• SEMP is normally the direct result of tailoring the standardsto meet the specific needs of the project.

• SEMP should cover all major functions such as thosecovered in sections on SE process and SE management.

• SEMP will probably refer to subordinate plans such as CMP,RMP, TRAP, TEMP etc.

• Internal contractor processes may also be referenced ifrequired.

ConceptualDesign

DetailedDesign &

Development

PreliminaryDesign

Constructionand/or

Production

Operational Useand

System Support

MISSION

DISPOSAL















BNR/SNR



Risk Management Plan (RMP)


Systems Engineering Management Plan (SEMP)

Systems Engineering Management Plan (SEMP)


3-90

Requirementsand



• We saw earlier, that a system can be described in two broadways:

– Logical (or functional)—what the system will do, how wellit will do it, how it will be tested, under what conditions itwill perform, and what other systems will be involved withits operation.

– Physical—what the system elements are, how they look,and how they are to be manufactured, integrated, andtested.

• Both the logical and physical descriptions of a systemcomprise a series of statements called requirements.


3-91

Needs and Requirements

• While they tend to coexist at each level of consideration,needs and requirements are different:

– Needs are generally capabilities stated in the language ofbusiness management or stakeholders at the businessoperations levels.

– Requirements are formal statements that are structuredand can be validated—there may be more than onerequirement that can be defined for any need.Requirements are generated from needs through aprocess of requirements analysis (also called businessanalysis or mission analysis.

Needs View Requirements View

Concept of Operations(ConOps)

SystemRequirementsSystem

Subsystem

BusinessOperations

BusinessManagement

Enterprise

BusinessNeeds

BusinessRequirements

EnterpriseStrategies

Mission Analysis


StakeholderRequirements

StakeholderNeeds

BusinessRequirementSpecification

(BRS)

StakeholderRequirementSpecification

(StRS)

SystemRequirementSpecification

(SyRS)

SubsystemRequirementSpecification

Preliminary Life-cycle Concepts:Operations (OpsCon), Acquisition,Deployment, Support, Retirement


SystemNeeds


SubsystemNeeds

SubsystemRequirements

Subsystem Life-cycle Concepts:OpsCon, Acquisition, Deployment, Support, Retirement

System Life-cycle Concepts:OpsCon, Acquisition, Deployment, Support, Retirement

Life-cycle Concepts:OpsCon, Acquisition, Deployment, Support, Retirement

Business Needs andRequirements

Definition Process

Stakeholder Needsand Requirements Definition Process

System Requirements Definition Process

Problem Domain

Subsystem Requirements

Definition Process

SolutionDomain


3-92

ConOps and OpsCon

• ANSI/AIAA G-043A-2012 identifies that the terms ‘concept ofoperations’ and ‘operational concept’ are often usedinterchangeably but notes that an important distinction existsbecause each has a separate purpose and is used to meetdifferent ends.

• It is essential that these terms are used so that they areconsistent with ANSI/AIAA G-043A-2012 and ISO/IEC29148, as well as the way in which the terms are used in theUS DoD and many other defence forces.

ConOps

The ConOps, at the organization level, addresses theleadership's intended way of operating the organization. It mayrefer to the use of one or more systems, as black boxes, toforward the organization’s goals and objectives. The ConOpsdocument describes the organization’s assumptions or intent inregard to an overall operation or series of operations of thebusiness with using the system to be developed, existingsystems, and possible future systems. This document isfrequently embodied in long-range strategic plans and annualoperational plans. The ConOps document serves as a basis forthe organization to direct the overall characteristics of the futurebusiness and systems, for the project to understand itsbackground, and for the users of this International Standard toimplement the stakeholder requirements elicitation.

ISO/IEC 29148


3-93

OpsCon

A system OpsCon document describes what the system will do(not how it will do it) and why (rationale). An OpsCon is a user-oriented document that describes system characteristics of theto-be-delivered system from the user's viewpoint. The OpsCondocument is used to communicate overall quantitative andqualitative system characteristics to the acquirer, user, supplierand other organizational elements.

ISO/IEC 29148

Other life-cycle concepts

• The Acquisition Concept describes the way the system willbe acquired including aspects such as stakeholderengagement, requirements definition, solicitation andcontracting issues, design, production, and verification.

• The Deployment Concept describes the way the system willbe validated, delivered, and introduced into operations.

• The Support Concept describes the desired supportinfrastructure and manpower considerations for supportingthe system after it is deployed. A support concept addressesoperating support, engineering support, maintenancesupport, supply support and training support.

• The Retirement Concept describes the way the system willbe removed from operation and retired, including thedisposal of any hazardous materials used in or resulting fromthe process.


3-94

What is a requirement?

• A requirement is:

– something that the system must do,

– a condition the system must meet,

– a quality or attribute that it must possess, or

– a constraint under which it must operate or be developed.

What is a requirement?

• Requirement statements are supported by:

– Performance, verification, and rationale statementssupporting each requirement.

– Definitions of other systems with which the system mustintegrate and to which it must interface.

– Information about the application domain within which thesystem must operate.

• The requirements in the BRS and the StRS are not as formalas those in the SyRS but they have the same structure andfollow the same rules.


3-95

Requirement Characteristics and Attributes

Requirements characteristics

• Each requirement should exhibit all of the followingcharacteristics:

– Necessary

– Singular

– Correct

– Unambiguous

– Feasible

– Appropriate to level

– Complete

– Conforming

– Verifiable


3-96

Requirements attributes

• To support analysis and management, requirements shouldbe allocated a number of attributes:

– Unique identifier

– Short title

– Priority

– Criticality

– Feasibility

– Risk

– Source

– …

Requirements attributes

• To support analysis and management, requirements shouldbe allocated a number of attributes:

– …

– Type

– Rationale

– History

– Relationship to other requirements

– Other information


3-97

What not how?

• In general, a requirement should be a statement of what asystem should do, rather than how it should do it.

• However, this is often too simplistic in practice, because:

– it may be essential that the system should perform afunction in a particular way (for example, forinteroperability, to meet extant standards, etc).

– a specific statement is often less easily confused than anabstract statement of the problem.

– the specifiers of the system are often the domainexperts—they are therefore best placed to state how thesystem should be developed and how it should operate.

What is requirements engineering

SyRS


Business Management

Business Operations

SNR

System Development


In-service

DeliveredSystem

StRS


BRS

BNR

Enterprise


3-98

Why we need requirements

• We need to be able to define a scope for the project. Howelse would we know what the system is to do?

• We need to ensure that everyone involved has had input andthe various points of view have been reconciled.

• We need to be able to justify any expenditure of funds oreffort based on the need to achieve an endorsed set ofrequirements.

• We need to be able to report on progress.

• We need to be able to tell when we are finished (or when thecontractor is finished).

Why we need requirements engineering

• We need to be able to guarantee that we have a completeset of requirements that are unambiguous, complete, non-conflicting, and so on.

• We must be able to trade off functionality for cost—whichimplies that we understand the required functionality,priorities, costs, and so on.

• We need to be able to manage changes in requirements fora wide variety of reasons.


3-99

Requirements Verification and Validation

Verification and Validation (V&V)

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ConceptualDesign

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ConceptualDesign

Acquirer acceptancefrom contractor

Contract based onSystem Requirements Specification (SyRS)

Stakeholder RequirementSpecification (StRS)

Acquisition Utilisation

User acceptance from acquirer

Customer (User)

Customer (Acquirer)

Contractor

Verification

Validation


3-100

V&V


Business Management

Business Operations

SNR

System Development


In-service

DeliveredSystem

StRS


BRS

BNR

Enterprise

RequirementsValidation

SyRS

RequirementsValidation

RequirementsVerification

OT&E

DT&E

AT&E

V&V and Test & Evaluation (T&E)

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ConceptualDesign

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ConceptualDesign

Acquisition Utilisation

DT&E: Developmental T&EAT&E: Acceptance T&EOT&E: Operational T&E


3-101

Requirements Elicitation and Elaboration

Requirements elicitation and elaboration

• Requirement statements are produced through elicitationand elaboration (which involves decomposition andderivation):

– Elicited requirements are attributed to the source and arenormally gathered via interview or a structured workshop.

– Decomposed requirements. Decomposition entailsbreaking a higher-level requirement into those lower-levelrequirements that are explicitly required by it.

– Derived requirements. Derivation entails requirementsengineers drawing some inference. That is, businessmanagement or the stakeholders did not state therequirement directly, but the derived requirement is anecessary part of the system design if one or more of thedirectly stated requirements are to be met.


3-102

Hierarchy of requirements

Requirement 1

Requirement 1.1

Requirement 1.1.1

Requirement 1.1.2

Requirement 1.1.3

Requirement 1.2

Requirement 1.2.1

Requirement 1.2.2

Requirements elicitation & elaboration

• There are therefore seven dimensions to requirementselicitation and elaboration:

– Understanding the business.

– Understanding the application domain.

– Understanding the specific problem.

– Understanding the needs and constraints of systemstakeholders.

– Understanding acquisition and project management.

– Understanding requirements engineering and systemsengineering.

– Understanding the technologies and engineeringinvolved.


3-103

Difficulties inRequirements Elicitation/Generation

Requirements elicitation / generation

• Requirement engineers face a number of problems:

– Application domain information is not always collected inone place and may involve specialist terminology.

– People who understand the problem to be solved areoften too busy to help specify the new system.

– Organisational issues and political factors may influencesystem requirements to satisfy personal agenda.

– Stakeholders often do not help—they often don’t reallyknow what they want, they have no desire to compromisetheir unrealistic demands when faced with cost, and theyhave different requirements that are often expressed indifferent ways.

– …


3-104



– …

– Requirements engineering takes place in an economicand business environment that is continually changing.

– Different people have different perspectives—as keypositions change over, the new incumbent may have asignificantly different view of requirements.

– Not every stakeholder is a supporter of the new system.

– Stakeholders do not understand the requirements-engineering process and often do not participate.

– Stakeholders will often not commit to a written set ofrequirements for fear that it may constrain them.

– ……



– …

– Stakeholders may insist on adding/modifyingrequirements after the set has been endorsed.

– Stakeholders may not be willing (or able) to understandthe technologies and processes involved.


3-105

Requirements Elicitation/GenerationTechniques


• Requirements can be identified by:– structured workshops– brainstorming and problem-solving sessions– interviews– surveys/questionnaires– use cases and operational scenarios– simulations, models and prototypes– observation of work studies (time and motion studies)– participation in work activities– observation of the system’s organisational and political

environment– technical documentation review– market analysis– competitive system assessment– reverse engineering– benchmark processes and systems


3-106

Requirements Management

Requirements management

• Requirements management is the process by whichchanges to requirements are managed throughout thesystem lifecycle.

• Requirements change because:

– they are derived from the stakeholder need and must bemanaged as they are developed,

– stakeholder requirements change over the life of thesystem,

– the business may change,

– the environment will change over the lifecycle, and

– laws and regulations will change over the system’s life.

• It is often the case that more than 50% of a system’srequirements are modified before it is put into service.


3-107

Requirements change management

• Change-management policies are defined to define theprocedures, processes, and standards that are to be used tomanage changes to requirements during the requirementsengineering process.

• Policies should cover:– The process by which a change is proposed.– Definition of the information required to support each

change request.– The process used to analyse the reason for the change

and to assess the impact of the change.– The change-control authority (person or board) that

considers and approves the change.– The process by which the change-control authority

receives, considers, and approves the change.– Tool support for the change-management process.

Requirements traceability

• Requirements cannot be managed effectively withoutrequirements traceability.

• Traceability ensures that we know where the requirementcame from, what requirements are related to it, and whatrequirements were derived from it.

• Good traceability allows us to identify all requirementsaffected by a change, for example.


3-108

Traceability

• Broadly, there are two main sorts of traceability:

– Forward traceability. Forwards traceability gives usconfidence that each requirement has been addressed inthe design.

• Through forward traceability, design decisions can betraced from any given system-level requirement (aparent requirement) down to a detailed design decision(a child requirement).

• For each requirement, we must be able to find at leastone child in the subordinate design documents.

• If there is more than one child, we must be able toidentify all of them.

– ...

Traceability

• Broadly, there are two main sorts of traceability:– ...– Backward traceability. We must be able to trace from

each requirement back to at least one requirement in theparent document.

• This backward traceability ensures that additionalrequirements (not formally endorsed by the customer)have not crept (through requirements creep) into thedesign.

• Any aspect of the design that cannot be traced back toa higher-level requirement is likely to representunnecessary work for which the customer is mostprobably paying a premium.

• An orphan requirement is be out-of-scope.


3-109

Requirements EngineeringTools

Requirements engineering tools

• There are many tools that may assist in requirementsengineering, including the context diagram, functional flowblock diagrams (FFBD), requirements breakdown structure(RBS), and N2 diagrams.

• Other tools include structured analysis, data flow diagrams(DFD), control flow diagrams (CFD), IDEF diagrams,behaviour diagrams, action diagrams, state/mode diagrams,process flow diagrams, function hierarchy diagrams, statetransition diagrams (STD), entity relationship diagrams(ERD), structured analysis and design, object-orientedanalysis (OOA), unified modelling language (UML),structured systems analysis and design methodology(SSADM), and quality function deployment (QFD).

• Here we focus on the RBS and the FFBD, and we discusscontext diagrams later.


3-110

Requirements Breakdown Structure (RBS)

• Here we call the requirements framework the requirementsbreakdown structure (RBS)—which is also called the logicalhierarchy, or the functional hierarchy.

• The words are deliberately chosen to differentiate thisstructure from the well-known project managementdocument called the work breakdown structure (WBS)

Complexity Index, C

• V—the number of independent variables needed to describethe state of the system.

• P—the number of independent parameters needed todistinguish the system from other systems in the same class.

• L—the number of control feedback loops both within thesystem and connecting the system to the surroundings.

• The upper and lower values of C are defined as:

– V + P + L < C < V . P . L


3-111

Complexity Index, C

• Complex problems in organisations: 109 < C < 1013

• Human capacity to deal with complexity: C < 5 (not 105)

• Additionally, we apply very simple, bottom-up problem-solving skills.

• This has important ramifications for the way we go aboutsolving problems and designing systems.

• We must ensure that we are able to use our limited bottom-up problem-solving capability within a top-down construct.

Mission

Goals

Objectives

RequirementsLevel 1

RequirementsLevel 2

Requirements flowdown


3-112

RBS

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...

Mission

Level 1

Level 2

Level 3

Level 4

Level m

….

FFBDs

• The hierarchical representation of requirements in the RBScan be supported by FFBDs to show the flow betweenfunctions.

2.0 3.0

4.0 5.0

System-level functions

1.0

Component-level functions

5.5.1 5.5.2 5.5.3

5.5.4 5.5.5

Subsystem-level functions

5.1 5.2 5.3

5.4 5.5

3.0

4.0

5.3

5.4


3-113

ACME Medical Centre

Conceptual Design Tutorial

ACME Medical Centre Example

• ACME Medical Services has just acquired a block of land ina local shopping centre with the intention of developing amedical centre called “One-stop Medical Centre”.

• Medical services to include:– a doctor’s surgery supporting three GPs,– a dentist’s surgery for two dentists and two dental

assistants,– a physiotherapy centre supporting three physios, and– a pharmacy that provided a basic dispensing service

provided by one pharmacist and an assistant.• Other requirements:

– Secure and comfortable– Shopping Centre car park to be used– No more than two floors


3-114

Shopping Centre

ACMEMedical Centre

Car park

Main Road












C1.3 Scope system










(PLCD andBRS)









3-115

Identify Candidate Stakeholders• ACME Medical Services• Medical practitioners (GPs, dentists, physios, pharmacist)• General staff• Patients/customers• Local community• Body corporate• Other shopping centre tenants• Local council• ACT Health Department• Professional associations (AMA, etc)• Staff Unions• Construction industry• Utilities / services (?)• Other health providers (?)

Identify Candidate Stakeholders

• When you decide to build your own home, which of thefollowing are stakeholders?

– You and your partner

– The bank

– Your children

– In-laws of various types

– Local government

– Neighbours

– The builder and subcontractors

– The architect and draughtspersons


3-116


• If you are looking at a project to install a local area networkwithin the premises of a small business, which of thefollowing are stakeholders?

– The business owner/manager

– The financial manager

– The operations manager

– Employees

– The building manager


• What about stakeholders for a space telescope like theHubble?

– Astronomers

– Manufacturing company

– National space agency

– Launching company

– Operating company

– Politicians


3-117


• What about stakeholders for a new family payment?

– Families

– Politicians

– Taxpayers

– Relevant government departments

– Other government departments

– Other programs

Identify Candidate Stakeholders• ACME Medical Services• Medical practitioners• General staff• Patients/customers• Local community• Body corporate• Other shopping centre tenants• Local council• ACT Health Department• Professional associations (AMA, etc)• Staff unions• Construction industry• Utilities / services (?)• Other health providers (?)

Stakeholders

Stakeholders or constraints?

Constraints

Interfaces


3-118

Stakeholders (Category 1)


• ACME Medical Services• Medical practitioners• General staff• Patients/customers• Local community• Body corporate• Other shopping centre tenants• Local council• ACT Health Department• Professional associations (AMA, etc)• Staff unions• Construction industry

Constraints

Stakeholders (Category 2)

Stakeholders (Category 3)?












C1.3 Scope system










(PLCD andBRS)









3-119

Business and Project Constraints

• Before focusing on the detail of the desired system, it isessential to identify the project and business constraints thatare relevant to the system and its acquisition. This analysisprovides essential information about the developmentenvironment for the system and begins the top-downapproach to system development.

• Business constraints include any organizational policies,procedures, standards or guidelines that guide systemdevelopment and procurement. These constraints caninclude partnering relationships with other companies,contracting policies and so on.

Business and Project Constraints

• Project constraints include the resource allocations to theproject as well as any externally imposed deliverables andacquisition timeframes.

• Many companies have enterprise-wide standards forprocesses such as quality assurance and systemsengineering and these methodologies guide the manner inwhich projects can operate.

• Additionally, the enterprise may require the project to reportprogress in a particular way or to implement particularmetrics, tools and documentation procedures.


3-120

Medical Centre Business Constraints

• Conform to ACME template for livery, procedures, etc

• Project management standards

• Contracting procedures

• Existing partnering arrangements

• Financial—budget and cash flow

• Accounting procedures

• HR policies and procedures

• Existing service contracts

• … etc

Project Constraints

• Project management standards

• ACME SOPs and Centre Guidelines

• Budget (including cash flow)

• Schedule

• Location

• … etc


3-121












C1.3 Scope system










(PLCD andBRS)








Identify External Constraints

• In addition to enterprise-imposed constraints, there are widerexternal constraints on system development that arise fromthe requirement for conformance to national andinternational laws and regulations, compliance with industry-wide standards, as well as ethical and legal considerations.

• Other external constraints include the requirement forinteroperability and the capabilities required for interfacing toother systems.

• Again, an important aspect of top-down design is tounderstand these constraints before considering lower-levelsystem requirements.


3-122


• External constraints could include:– Business environment. The system will no doubt be

affected by changes in the broader business andeconomic environment, particularly those related to cost,pricing, availability, and licensing.

– Conformance to laws and regulations. Conformance tolaws is binding within a national or international legalconstruct; regulations are normally provided by governingbodies within the application domain of the development.

– Compliance with standards. Industry standards providesimilar constraints to laws and regulations, except thatcompliance with any particular standard may be at thediscretion of the developer, unless the standard ismandated by the enterprise or by the contract.

– …


• External constraints could include:

– …

– Ethical considerations and social responsibility. Systemdevelopers have a moral and ethical responsibility to theowners and users of the system, as well as to thecommunity.

– Interoperability and or interfacing requirements. Since it israre that a system would stand alone, interoperability andinterface considerations must be taken into accountduring development.

– Operating environment. The system will have to existwithin an operational environment that will provideconstraints in terms of temperature, humidity, andradiation as well as robustness to shock.


3-123

External Constraints

• AMA and associated regulations

• Government health regulations

• Local council regulations

• Shopping centre and body corporate rules

• Building codes and regulations

• OH&S

• Other suppliers of medical services (x-ray, blood, specialists,hospitals, ambulance, etc)

• Utilities

• Shopping centre car park

• Weather

• …


• …

• Physical access (road, footpath, etc)

• Availability of contractors

• Duty of care

• Ethical considerations

• … etc


3-124












C1.3 Scope system










(PLCD andBRS)








Identify Design Constraints

• Design constraints include those factors that directly affectthe way in which the system design can be conducted. Ofcourse, a number of enterprise, project and externalconstraints (such as budgets, regulations, and standards)will flow down and be inherited as design constraints.

• Typical design constraints include the state-of-the-art ofrelevant technologies, the skill sets of available engineersand tradespersons, as well as extant methodologies andtools to assist in the design, development, construction, andproduction of the system.

• Additionally, bounds such as all-up weight may be a designconstraint for an aircraft system if it is to land on certainclasses of airfield.


3-125

Design Constraints

• Location (on a corner block)

• Location of current utilities and car parks

• Operations and support must be unobtrusive (not visible topatients)

• Patient privacy

• Staff privacy—staff facilities not visible to patients

• Comfort requirements (waiting areas, children?)

• Numbers of staff on duty

• Numbers of patients inside at any point in time

• Security

• No more than two storeys

• …

Design Constraints

• …

• Access to surgery by all GPs

• Access to pharmacy from inside as well as outside

• Wheel-chair access (external and internal)

• Compliance—building codes and regulations, councilregulations, body corporate requirements, health regulations,AMA requirements

• Budget

• Schedule

• Possible contractual arrangements


3-126

A Cautionary Note WRT Constraints

• Having identified constraints, work should not progress untileach constraint is tested and taken on knowingly into thenext activity.

• That is, we must convince ourselves that each constraint isactually a constraint and is inviolate.

• It also doesn’t necessarily follow that a current constraint willremain so, or should remain so without question.

• We should therefore consider what can be done to removethe constraint if that would facilitate the progress of theproject.

A Cautionary Note WRT Constraints

• In many cases the constraint will be intransigent—forexample, if a vehicle is to operate on public roads, it mustconform to the appropriate regulations.

• In many other circumstances, however, the constraint maybe able to be lifted, to the advantage of the project—forexample, budgetary and schedule constraints may be easedwith negotiation, or the restrictions imposed by a standardmandated by the enterprise may be able to be removed if itcan be shown to be unnecessarily prescriptive.

• The cautionary note is therefore that a constraint isn’t so justbecause some stakeholder or regulator said it is, or becauseit always has been so in the past. If a constraint places someundesirable bound on the project, we should not just acceptit without question but should investigate ways of removingthe restriction if that is to our advantage.


3-127












C1.3 Scope system










(PLCD andBRS)








Define Mission, Goals and Objectives

• Because the business has most probably stated their needsin a fairly general way, every project should begin with aconcise statement of the mission, elaborated by statementsof the system-level goals and objectives.

• “A problem is half-solved if properly stated.” John Dewey.


3-128


• Backward traceability leads to a useful observation that thehighest-level requirements also ought to be traceable to asingle parent statement.

• This then is the principal role of the mission statement insystems/requirements engineering—it is the ultimate systemrequirement.

System MissionStatement

Requirement 1

Requirement 1.1

Requirement 1.2

Requirement 1.3

Requirement 2

Requirement 2.1

Requirement 2.2

Requirement n

Mission Statement Hierarchy

• It should be noted here that the system mission statementdoes not exist in isolation and is most likely to be able to betraced to a higher project mission statement and thenperhaps to a business mission statement.

– To increase profit to shareholders … (amount, time)

• To increase existing income streams …

– To develop a Medical Centre at the Canberra Hotellocation …

– To develop a Medical Centre at ...

– To develop a Medical Centre at …

• To add complementary income streams …

• To improve efficiency across the business ...


3-129

ACME Medical Centre Mission Hierarchy

Increase shareholder profit

1.Increase

Existing Income

2.Add

Complementary Income

3.Improve

Business Efficiency

1.1 Develop Medical Centre 11.2 Develop Medical Centre 21.3 Develop Medical Centre 3

2.1 Develop online services2.2 …2.3 …2.4 …2.5 …

3.1 …3.2 …3.3 …3.4 …3.5 …

Enterprise

Business

Project

Mission Hierarchy

Enterprise mission: Increase profit to shareholders …

• Business mission 1: Increase existing income streams …

– Project 1.1 mission: Develop a Medical Centre at theCanberra Hotel location …

• System 1.1 mission: Provide Medical Services at theCanberra Hotel location …

– Project 1.2 mission: Develop a Medical Centre at ...

• System 1.2 mission: Provide Medical Services at …

– Project 1.3 mission: Develop a Medical Centre at …

• System 1.3 mission: Provide Medical Services at …

• ...


3-130


• At the system level, requirements should be have theproperties we saw earlier. The ultimate antecedentstatement—the system mission statement—should thereforehave similar attributes:

– Necessary. It should be obvious from the system missionstatement that the system is necessary—that is, forexample, that it does not already exist in some form.

– Unique. The mission must describe a unique system.

– Singular. The mission statement cannot be a combinationof mission statements for two or more systems—that is,the mission statement must be a single sentence with theleast punctuation possible, and without conjunctions.

– ...


• There are a number of simple rules that should be appliedwhen developing need statements:

– ...

– Unambiguous. The mission cannot contain any more thanfive-to-seven elements to ensure that it remains within theintuition of the stakeholders.

– Feasible. If the mission statement is not feasible, it is notlikely that the requirements derived from it will be feasibleeither.

– Independent of implementation. The mission statementmust be stated in functional terms and must not dictate orimply any particular physical solution.

– …


3-131


• There are a number of simple rules that should be appliedwhen developing mission statements:

– …

– Justifiable (include an ‘in order to’ statement). Later wediscuss the writing of requirements and show that eachmust have an associated rational recorded to describe thereason for its existence. This ‘in order to’ statement in themission is a system-level rationale.

– Verifiable. Even at the high level of abstraction of themission statement, it must be obvious how the system willbe verified. It must be possible at this level, therefore, tobe able to define the tests (probably operational test andevaluation) that will be used to verify that the systemmission is met.


• There are a number of simple principles that should beapplied when developing mission statements:– A single sentence. Writing a single sentence keeps us at

the level of abstraction that defines the system as a‘single thought’. If we feel the need to start a secondsentence we run the risk of adding a second ‘thought’,which may well be describing a second system.

– No conjunctions. The mission statement should notcontain any conjunctions. The mission statement cannotstate, for example, that the mission of the system is to ‘dothis… and … do that…’. As a general rule therefore weshould not have any conjunctions because, if elements ofthe same type are joined by ‘and’, there is a group nounor adjective that can replace them.

– …


3-132


• There are a number of simple principles that should beapplied when developing mission statements:

– …

– Contain no more than 5−7 concepts. The system missionstatement cannot contain any more than five-to-seven keyelements if it is to remain within the intuition of the readerand to remain unambiguous.

– Include an ‘in order to’ clause. The system justification, orrationale, can be made explicit by the inclusion of an “…in order to …” clause at the end of the system missionstatement. This clause then ties the system missionstatement back to the business case for the system.

– ...


• There are a number of simple principles that should beapplied when developing need statements:– …– Avoid physical terms. To ensure that the subsequent

system mission statement is independent of the physicalimplementation means, the elements of the missionshould always be couched in functional, not physical,terms. The system mission statement must not imply anyparticular physical solution.

– Rely on iteration. A perfect mission statement cannot bewritten in a single pass of the above process.Understanding must increase as the design processprogresses—regardless of when it occurs, this increasedunderstanding must be able to flow back into previousartifacts.


3-133


C1.2.1.1.2 Group Need Elements

C1.2.1.1.1 Identify CandidateNeed Elements

C1.2.1.2.2 Group Goal Elements

C1.2.1.2.1 Decompose/DeriveGoal Elements

C1.2.1.3.2 Group Objective Elements

C1.2.1.3.1 Decompose/DeriveObjective Elements

C1.2.1.3.3 Draft Objective Statements

C1.2.1.1 Develop Mission Statement

C1.2.1.2 Develop Goal Statements

C1.2.1.3 Develop Objective Statements

C1.2.1.3.5 Finalise Mission, Goals, Objectives

C1.2.1.2.3 Draft Goal StatementsC1.2.1.3.4 Review Goal

Statements

C1.2.1.2.4 Review Draft Mission and Goal Statements

C1.2.1.1.3 Draft Mission Statement

ToC1.2.2 Define preliminary operational scenarios

Identify Candidate Need Elements

When developing a project mission statement for the ACMEMedical Centre, the candidate need elements might be:

• redevelop the Canberra Hotel location

• build ACME Medical Centre

• provide GP services

• provide dental services

• provide physiotherapy services

• provide pharmacy services

• provide a secure environment

• provide a comfortable environment

• provide privacy

• to the local community


3-134

Group Need Elements

• NE1. redevelop Canberra Hotel location into ACME MedicalCentre– redevelop the Canberra Hotel location– build ACME Medical Centre

• NE2. provide a selected range of medical services– provide GP services– provide dental services– provide physiotherapy services– provide pharmacy services

• NE3. provide a secure and comfortable environment– provide a secure environment– provide a comfortable environment– provide privacy

Draft Project Mission Statement

• … to redevelop the Canberra Hotel location into a medicalcentre (ACME Medical Centre) that provides a selectedrange of medical services in a secure and comfortableenvironment

are we sure of the range of medical services?

Add rationale: in order to … ? (profitable?)


3-135

Draft Project Mission Statement

• … to redevelop the Canberra Hotel location into ACMEMedical Centre that provides a selected1 range of MedicalServices in a secure and comfortable environment, in orderto attain a nominated Profit2

Notes:1. Medical services to include doctor’s surgery supporting three GPs, a dentist’s surgery for two

dentists and two dental assistants, a physiotherapy centre supporting three physios, and a pharmacy that provided a basic dispensing service provided by one pharmacist and an assistant.

2. Profit level of x% is to be attained within y years (confirm with business case).

Decompose/Derive Goal Elements

… to redevelop the Canberra Hotel location into ACME Medical Centrethat provides a selected range of Medical Services in a secure and

comfortable environment, in order to attain a nominated Profit

• The following functions are decomposed from the need:

– GE1. Redevelop the current site into the medical centre

– GE2. Provide medical centre infrastructure

– GE3. Provide selected range of medical services

– GE4. Provide a secure environment

– GE5. Provide a comfortable environment

– GE6. Attain nominated profit level

• The following functions are derived from the need:

– GE7. Manage medical centre and its services

– GE8. Support medical services


3-136

Group Goal Elements

• 1. Provide Medical Centre– GE1. Redevelop the current site into the medical centre– GE2. Provide medical centre infrastructure

• 2. Deliver medical services– GE3. Provide a selected range of medical services

• 3. Manage Medical Centre– GE7. Manage medical centre and its services

• 4. Support Medical Centre– GE8. Support medical services– GE4. Provide a secure environment– GE5. Provide a comfortable environment

• 5. Attain nominated profit– GE6. Attain nominated profit level

Draft Goal Statements

• 1. Provide Medical Centreto provide ACME Medical Centre on the Canberra Hotel location

• 2. Deliver medical servicesto deliver selected medical services

• 3. Manage Medical Centreto manage ACME Medical Centre

• 4. Support Medical Centreto support ACME Medical Centre

• 5. Attain nominated profitto attain x% annual profit within y years


3-137

Review Draft Mission Statement

• We should now re-write the mission so that all goals areexplicit:

… to provide ACME Medical Centre on the Canberra Hotel location to deliver Medical Services1, with appropriate management and support,

in order to attain (a nominated Profit2 level).

Notes:1. Medical services to include doctor’s surgery supporting three GPs, a dentist’s surgery for two dentists

and two dental assistants, a physiotherapy centre supporting three physios, and a pharmacy that provided a basic dispensing service provided by one pharmacist and an assistant.

2. Profit level of x% is to be attained within y years (confirm with business case).

Elaborate Objective Elements (Goal 1)

1. Provide Medical Centre– 1OE1 Engage building designer

– 1OE2 Conduct building design

– 1OE3 Approve building design

– 1OE4 Clean building site

– 1OE5 Acquire appropriate approvals

– 1OE6 Provide site security

– 1OE7 Engage building contractor

– 1OE8 Build Centre building

– 1OE9 Provide utilities interfaces

– 1OE10 Provide medical facilities

– 1OE11 Provide staff facilities

– 1OE12 Provide customer facilities

– 1OE13 Install medical equipment

– ….


3-138

Group Objective Elements (Goal 1)

• 1.1 Design Medical Centre– 1OE1 Engage building designer

– 1OE2 Conduct building design

– 1OE3 Approve building design

• 1.2 Prepare for build– 1OE4 Clean building site

– 1OE5 Acquire appropriateapprovals

– 1OE6 Provide site security

• 1.3 Build Medical Centre– 1OE7 Engage building contractor

– 1OE8 Build Centre building

– 1OE9 Provide utilities interfaces

• 1.4 Fit out building– 1OE10 Provide medical facilities

– 1OE11 Provide staff facilities

– 1OE12 Provide customerfacilities

– 1OE13 Install medical equipment

– 1OE14 Install general equipment

• 1.5 Commission MedicalCentre– …

Goal 1. Provide Medical Centre

• 1.1 Design Medical Centre

– 1.1.1 Engage building designer

– 1.1.2 Conduct building design

– 1.1.3 Approve building design

• 1.2 Prepare for build

• 1.3 Build Medical Centre

• 1.4 Fit out Medical Centre

• 1.5 Commission Medical Centre


3-139

Goal 2. Deliver Medical Services

• 2.1 Deliver GP services

• 2.2 Deliver dental services

• 2.3 Deliver physiotherapy services

• 2.4 Deliver pharmacy services

• 2.5 Deliver medical support

Goal 3. Manage Medical Centre

• 3.1 Manage centre administration

• 3.2 Manage centre finances

• 3.3 Manage centre staff

• 3.4 Manage centre contracts

• 3.5 Manage support services


3-140

Goal 4. Support Medical Services

• 4.1 Provide financial services

• 4.2 Provide logistic support

• 4.3 Provide administrative support

• 4.4 Provide comfortable environment

• 4.5 Provide secure environment

Goal 5. Attain Nominated Profit

• 5.1 Implement business strategy

• 5.2 Understand customer needs

• 5.3 Maintain customer satisfaction

• 5.4 Undertake centre marketing

• 5.5 Engage local community


3-141

Project RBS—Level 1

Develop Medical Centre

1.Provide

Medical Centre

2.Provide

Medical Services

3.Manage

Medical Centre

4.Support

Medical Services

5.Attain

Nominated Profit

Project RBS—Level 2

Develop Medical Centre

1.Provide

Medical Centre

2.Deliver

Medical Services

3.Manage

Medical Centre

4.Support

Medical Services

5.Attain

Nominated Profit

1.1 Design Medical Centre1.2 Prepare for build1.3 Build Medical Centre1.4 Fitout Medical Centre1.5 Commission Medical Centre

2.1 Deliver GP services2.2 Deliver dental services2.3 Deliver physiotherapy services2.4 Deliver pharmacy services2.5 Deliver medical support

3.1 Manage centre administration3.2 Manage centre finances3.3 Manage centre staff3.4 Manage centre contracts3.5 Manage support services

4.1 Provide financial services 4.2 Provide logistic support4.3 Provide administrative support4.4 Provide comfortable environment 4.5 Provide secure environment

5.1 Implement business strategy5.2 Understand customer needs5.3 Maintain customer satisfaction5.4 Undertake centre marketing5.5 Engage local community


3-142

Project RBS—Level 2Develop Medical Centre

1.Provide

Medical Centre

2.Deliver

Medical Services

3.Manage

Medical Centre

4.Support

Medical Services

5.Attain

Nominated Profit

1.1 Design Medical Centre1.2 Prepare for build1.3 Build Medical Centre1.4 Fitout Medical Centre1.5 Commission Medical Centre





Project RBS

System RBS

System RBS

Provide Medical Centre

1.Deliver

Medical Services

2.Manage

Medical Centre

3.Support

Medical Services

4.Attain

Nominated Profit





Provide Medical Centre

Design Medical CentrePrepare for buildBuild Medical CentreFitout Medical CentreCommission Medical Centre


3-143

.........

.........

.........

.........

............

.........

.........

.........

.........

.........

.........

.........

.........

.........

.........

.........

............

1.1.11.1.1 ..........1.1.2 ..........1.1.3 ..........1.1.4 ..........1.1.5 ..........1.21.2.1 ..........1.2.2 ..........1.2.3 ..........1.31.3.1 ..........1.3.2 ..........1.3.3 ..........1.3.4 .............

Project RBS

CI C

CI D

CI E

CI F

CI n

CI A

CI B

Configuration Items (CI)

Project (Contract) WBS

System Requirements

Project Requirements

EP

3

EP

4

EP

5

EP

6

EP

m

EP

1

EP

2

Enabling Products (EP)

7.7.17.1.1 ..........7.1.2 ..........7.1.3 ..........7.1.4 ..........7.1.5 .............

Sys

tem

Req

uire

men

t Spe

cific

atio

n (S

yRS

)S

tate

men

t of W

ork

(SO

W)

Pro

ject

(C

ontr

act)

Req

uire

men

ts












C1.3 Scope system










(PLCD andBRS)









3-144

Operational Scenarios• General scenario—a day in the life of

the centre (opening, closing, waitingroom, staff breaks, etc)

• General scenario as affected byweather (hot, cold, wet)

• Patient visit (one per type of patient)• Multiple consultations per patient• Emergency medical appointments (in

hours and after hours)• Emergency dental appointments (in

hours and after hours)• Reception view of operations• Operational view for each medical

professional• Triage view of operations• Non-patient pharmacy visit• Complaint management• Missed appointment procedure

• Patient transfer• Medical emergency events (for each

type of emergency)• Death of a patient• Community medical emergencies (flu

pandemics, etc)• Non-medical emergency events

(power failure, fire, chemical spill)• Referrals to specialists, pathology,

etc• Centre correspondence• Medical record administration

including transfers, specialist andbloods reports

• New patient scenario• …

Operational Scenarios• …

• Booking and paying

• Finance administration andaccounting

• ICT and network operation (includingadministration, back-up, disasterrecovery, etc)

• Waste disposal (general, medical,recycling)

• Delivery of supplies (general,medical and pharmaceutical)

• Supply management and accounting(particularly pharmaceutical)

• Cleaning

• Security events (for each threat,when centre is occupied and vacant)

• Unscheduled maintenance (hole inwall, dripping tap, etc)—includingafter-hours callout

• Scheduled maintenance (carpetcleaning, painting refresh, etc)

• After-hours access by staff

• Staff training

• Staff performance management

• Staff recruitment and selection

• Management reporting to ACME

• Community health engagement

• OH&S important scenarios


3-145

FFBD—Patient/customer View

Decide

Travel

Travel

Book EnterReception

ArrivalReceptionDeparture

Wait Pharmacy Depart

GP

Dental

Physio


Decide

Travel

Travel

Book EnterReception



GP

Dental

Physio

• What about having to leave before seeing a professional?• What about having to see them again before leaving (having waited fo


3-146


Decide

Travel

Travel

Book EnterReception



GP

Dental

Physio


Decide

Travel

Travel

Book EnterReception



GP

Dental

Physio

• What about coming in to the centre to book?


3-147


Decide Travel

TravelBook

EnterReception



GP

Dental

Physio

• What about coming in off the street to just use the pharmacy?

Book


Decide Travel Travel

Book

EnterReception


Wait

Pharmacy

Depart

GP

Dental

Physio

Book


3-148


• AMA and associated regulations

• Government health regulations

• Local council regulations

• Shopping centre and body corporate rules

• Building codes and regulations

• OH&S

• Other suppliers of medical services (x-ray, blood, specialists,hospitals, ambulance, etc)

• Utilities

• Shopping centre car park

• …


• …

• Physical access (road, footpath, etc)

• Availability of contractors

• Duty of care

• Ethical considerations

• … etc


3-149

Project Constraints

• ACME SOPs and Centre Guidelines

• Budget (including cash flow)

• Schedule

• Weather

• Location

• … etc

Design Constraints

• Location (on a corner block)

• Location of current utilities and car parks

• Operations and support must be unobtrusive (not visible topatients)

• Patient privacy

• Staff privacy—staff facilities not visible to patients

• Comfort requirements (waiting areas, children?)

• Numbers of staff on duty

• Numbers of patients inside at any point in time

• Security

• No more than two storeys

• …


3-150

Design Constraints

• …

• Access to surgery by all GPs

• Access to pharmacy from inside as well as outside

• Wheel-chair access (external and internal)

• Compliance—building codes and regulations, councilregulations, body corporate requirements, health regulations,AMA requirements

• Budget

• Schedule

• Possible contractual arrangements

Needs and Measures Relationship

1 2 n

0

...

1.1 1.2 1.n...

1.1.1 1.1.2 1.1.n...

n.1 n.2 n.n...

n.n.1 n.n.2 n.n.n...

Needs Hierarchy Measures Hierarchy

Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….


3-151

Define MOE—Bottom-up

• Percentage profit

• Numbers of patients

• Rate of return of patients

• Number of unused consultation times

• Waiting time for each consultation

• Length of waiting list / date booked out until

• Proportion of consultations that did not start on time

• Total (daily) working hours for each practitioner

• Number of complaints received from patients (and staff)

• Maintenance rates for facilities and equipment

• Staff retention (length of service) / turnover

• …

Define MOE—Bottom-up

• …

• Centre prestige

• Number of outside scripts filled by pharmacy

• Number of pharmacy items requested that are not available

• Staff security

• Patient/customer security

• Staff comfort

• Patient/customer comfort


3-152

Define MOE—Top-down

• CI 1 Was the ACME Medical Centre provided?

– COI 1.1 Was the Medical Centre designed?

• MOE 1.1.1 Was a building designer engaged

• MOE 1.1.2 Was the building designer briefed?

• MOE 1.1.3 Was the building design conducted?

• MOE 1.1.4 Was the building design approved?

– COI 1.2 Was the site prepared for building?

– COI 1.3 Was the Medical Centre built?

– COI 1.4 Was the Medical Centre fitted out?

– COI 1.5 Was the Medical Centre commissioned?

• CI 2 Are the medical services being delivered?

• …….

Trade Studies

• Safe access by patients (of all classes)

• Options for provision of services, layout of building, numberof floors, etc

• Other services provided (x-ray, day surgery, etc)

• Relationship between profit level and services (consultationtimes, numbers of staff, opening hours, etc)

• Type of patient (in terms of services to be provided)

• Patient access options

• Marketing (attraction of patients)

• Waiting arrangements

• Central reception vs individual receptions

• Lease vs buy equipment

• …


3-153

Trade Studies

• ….

• Staffing arrangements (salary, contract)

• Professional indemnity insurance

• File management (manual vs automated)

• Billing and accounts processes

• ICT/network provision

• Provision of cleaning services

• Provision of ad hoc and planned maintenance

Acquisition Models


3-154

Waterfall Model

Build 2

Build n

TimeRBL1 RBL2 RBLn

Build 1

Build nfielded

Build 2fielded

Build 1fielded

ReqSet

Waterfall—Overlapping builds


3-155

Increment 1 Increment 2 Increment n

Final system scope

Kernel

Increment 1 scope

Increment 1 Increment 2 Increment nKernel Kernel

ReqSet

Incremental Approach

Iteration 1 Iteration 2 Iteration n

Final system scope

Iteration 1 scope

Iteration 1 Iteration 2 Iteration n

Iterative Approach


3-156

Build 1 Build 2 Build n

Final system scope

Build 1 Build 2 Build n

Build 1 scope

InitialReqs

FurtherReqs

FurtherReqs

Evolutionary Approach

Cumulative cost

Evaluate alternativesidentify, resolve risks

Determine objectives,alternatives, constraints

Develop andverify next-level product

Plan next phases

RiskanalysisRisk

analysisRiskanalysis

Riskanalysis

Prototype1

Prototype2

Prototype3

Operationalprototype

Simulations, models, benchmarks

Concept ofoperation Software

requirements Software productdesign

Detaileddesign

Requirementsvalidation

Design validationand verification

Implementation Acceptancetest

Integrationand test

Unittest

Code

Developmentplan

Integrationand test plan

Requirements planLife-cycle plan

Review

Spiral Development

About the Capability Systems Centre

The Centre offers organisations the flexibility to choose unique education and training solutions to fit organisational objectives:

Telephone:

Further Information

Email:

Web:

02 6268 8960 or 02 6268 9566

[email protected]

capabilitysystems.unsw.adfa.edu.au

CLC/Capability Management Short Courses

Custom Programs: Fully customised in-house

development to align with your business education and training strategy.

Tailored on-campus programs.

The Capability Systems Centre offers the following CLC and capability management related professional education short courses.

-

-

The Capability Systems Centre at UNSW Canberrais a centre of research excellence focused on disciplines related to the development, acquisition and sustainment of capability throughout the capability life cycle (CLC).

The Centre is able to provide research, mentoringand assurance support to decision makers, systemsengineers, business analysts, and project, programand portfolio managers in Defence, Government andIndustry.

Capability Systems Centre Short Courses - 2018

Introduction the CLC and Capability Management 4-9 Feb 2018 (Canberra)Systems Engineering Practice19-23 Mar 2018 (Canberra)Introduction to Capability Management25-28 Mar 2018JCNS and OCD Development16-18 Apr 2018 (Canberra)Requirements Writing19-20 Apr 2018 (Canberra)Systems Engineering Practice7-11 May 2018 (Melbourne)Introduction to Project Management23-25 May (Canberra)Introduction to Systems Engineering28-30 May 2018 (Adelaide)Introduction to the CLC and Capability Management 25-29 June 2018 (Canberra)Systems Engineering Practice27-31 Aug 2018 (Canberra)Introduction to Capability Management17-19 Sep 2018 (Canberra)JCNS and OCD Development8-10 Oct Apr 2018 (Canberra)Requirements Writing11-12 Oct 2018 (Canberra)

Further information on these courses or the Capability Systems Centre in general is available by contacting Centre staff at:

The principal focus of the Centre is to address shortfalls in research of methodologies, tools and techniques for developing capability. We do this through cutting-edge research and analysis, publications, education, and events; drawing on world-class academic expertise across ourdisciplinary areas.

Our services include:

Project and program reviews, technical and engineering risk assessments and business and innovation assessments.

Postgraduate courses, professional education short courses and events.

Mentoring, technical ‘deep dives’, investigations and research.

Independent Assurance

Research & Independent

Advice

Education, Training &

Events

Tailored Education and Training

INTRODUCTION TO THE CAPABILITY LIFE CYCLE · engineering and in management and project management....

Documents

Transcript of INTRODUCTION TO THE CAPABILITY LIFE CYCLE · engineering and in management and project management....