systems engineering practice · 2020-03-06 · ryan, principles of satellite communications, argos...

SYSTEMS ENGINEERING PRACTICE

PART I

Professor Mike Ryan

Your Presenter Professor 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 three colleges (electrical, ITEE and systems engineering), 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, Canberra 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 Co‐Chair of the Requirements Working Group INCOSE. He is the author or co‐author of twelve books, three book chapters, and over 250 technical papers and reports. ([email protected])

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 Consultancies 1999 An analysis of the effect of radio‐frequency directed‐energy weapons (RF DEW) 1999 Development of battlespace communications system architecture 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 technical specification for ATHOC: Athens 2004 Olympic Games 2002 Land 125 Soldier Combat System—System Integration Study—Communications 2003 Independent validation and verification (IV&V) of NZ Joint Command and Control System 2003 Land 125 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 Physical/Functional Audit Review ‐ 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 Defence‐wide EW Capability Review & EW Training and Education Review 2010 JP 2089 3B—Tactical Information Exchange—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 2012‐3 JP 2030 Phase 8 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 2017 JP9101 Report ‐ Communications in a Satellite‐denied/degraded Environment 2017 JP9101 Advice on Development of OCD and FPS 2018 Development of SCRAM lessons learned database 2018 JP9101 Report – Shared Load Study 2018 SEA1180 Development of Ship Zero functional specification 2018 SEA1180 Modelling of capability transition 2018 SEA1000 Modelling of through‐life support 2018 JP9101 Expert Advisory Panel for tender CDD suite 2018 Capability Management modelling for Protected Mobility Capability Assurance Program 2018 System Specification development for Protected Mobility Capability Assurance Program 2018 OCD Development for Special Operations 2019 Workshop for Space Situational Awareness Sub‐Program 2019 Preliminary PIOCD for Land Training Environment 2019 Functional description of AEGIS Enterprise 2019 PIOCD for Multi‐domain Training Environment 2019 PIOCD for ADF Training Environment 2019 OCD for Sea, Air, Land, Treatment and Transport (SALTT) System 2019 Naval Guided Weapons Sustainment Planning Tool Development

Acronyms and Abbreviations AAI Accountable Authority Instructions ABL Allocated Baseline ACAT Acquisition Category ACCS Australian Capability Context Scenarios ADF Australian Defence Force ADFA Australian Defence Foce Academy ADO Australian Defence Organisation AFS Average Funded Strength AIC Australian Industry Capability AIOS Acceptance into Operational Service AIPM Australian Institute of Project Management AJOC Australian Joint Operating Concept AMS Australian Military Strategy ANAO Australian National Audit Office ANSI American National Standards Institute APS Australian Public Service ASDEFCON Australian Standard for Defence

Contracting AT&E Acceptance Test and Evaluation BBC Better Business Case BC Business Case BoE Basis of Estimates BNR Business Needs and Requirements C2 Command and Control C4 Command, Control, Communications and

Computers C4ISR Command, Control, Communications,

Computers, Intelligence, Surveillance and Reconnaissance

CabSub Cabinet Submission CAD Computer-aided design CAE Computer-aided engineering CAM Computer-aided manufacturing CASG Capability Acquisition and Sustainment

Group CASE Computer-aided Support Environment CASSS Capability Acquisition and Sustainment

Support Services (Panel) CCB Configuration Control Board CCP Contract Change Proposal CDD Capability Development Documents CDF Chief of the Defence Force CDIC Centre for Defence Industry Capability CDMRT2 Capability Development Management and

Reporting Tool 2 CDR Critical Design Review CDRL Contract Data Requirements List CFO Chief Finance Officer CI Configuration Item CI Critical Issue CIOG Chief Information Officer Group CITE Capability Integration, Test and Evaluation

(Branch) CLC Capability Life Cycle

CM Capability Manager CM Configuration Management CMGR Capability Manager Gate Review CMS Contract Master Schedule CNC Computer numerically controlled COD Concept of Operations Document COE Centre of Expertise COI Critical Operational Issue CONOPS Concept of Operations COTS Commercial-off-the-Shelf CPN Capability Program Narrative CPR Commonwealth Procurement Rules CPSG Capability Program Steering Group CSC Computer Software Component CSCI Computer Software Configuration Item CSU Computer Software Unit CWBS Contract Work Breakdown Structure DA Design Authority DA Design Attribute DAF Defence Architecture Framework DASR Defence Aviation Safety Regulation DC Defence Committee DCAP Defence Capability Assessment Program DDR Detailed Design Review DID Data Item Description DIP Defence Investment Plan DLOD Defence Lines of Development DMO Defence Materiel Organisation (obsolete

post FPR) DoD (U.S.) Department of Defense DOF Department of Finance DOR Description of Requirement DOTMLPF Doctrine, organization, training, materiel,

leadership, personnel, facilities DPG Defence Planning Guidance DPG Defence People Group DPPM Defence Procurement Policy Manual DSwMS Defence Seaworthiness Management

System DT&E Developmental Test and Evaluation DWP Defence White Paper E&IG Estate & Infrastructure Group EBC Enterprise Business Committee ECP Engineering Change Proposal eFFBD Enhanced Functional Flow Block Diagram EIA Electronics Industry Association EMC Electromagnetic Compatibility EMI Electromagnetic Interference EPBC Environment Protection and Biodiversity

Conservation Act 1999 EtP Endorsement to Proceed FACRR Facilities Readiness Review

FBL Functional Baseline FCA Functional Configuration Audit FDD Force Design Division FEA Finite element analysis FELSA Front-End Logistics Support Analysis FFBD Functional Flow Block Diagram FFBNW Fitted-for-but-not-with FIC Fundamental Inputs to Capability FJOC Future Joint Operating Concept FMECA Failure Modes, Effects and Criticality

Analysis FOC Final Operating Capability FOE Future Operating Environment FOREX Foreign Exchange FPC Fixed price contract FPR First Principles Review FPS Function and Performance Specification FQR Formal Qualification Review FRACAS Failure reporting, analysis and corrective

action system FSR Force Structure Review FTE Full Time Equivalent G&S Goods and Services GOTS Government off the Shelf HMI Human Machine Interface HR Human Resources HWCI Hardware Configuration Item I2 Integration and Interoperability I2F Integration and Interoperability Framework IA Independent Assurance IAR Independent Assurance Review IBR Integrated Baseline Review IC Investment Committee ICD Interface Control Document ICT Information and Communications

Technology ICWG Interface Control Working Group IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics

Engineers IIP Integrated Investment Program ILS Integrated Logistics Support ILSM ILS Manager ILSP ILS Plan IMS Integrated Master Schedule INCOSE International Council on Systems

Engineering IOC Initial Operating Capability IOC Integrating Operational Concept IPM Integrated Project Manager IPMP Integrated Project Management Plan IPMT Integrated Project Management Team IPT Integrated Project/Product Team IS Interim Standard ISC Integrated Support Contractor(s)

ISO International Standards Organisation ISREW Intelligence, Surveillance,

Reconnaissance and Electronic Warfare ISREWCS ISREW Cyber Space ITR Invitation to Register Interest IV&V Independent Verification and Validation JCA Joint Capability Authority JCF Joint Concepts Framework JCG Joint Capability Group JCN Joint Capability Narrative JCNS Joint Capability Needs Statement JD Joint Directive JFA Joint Force Authority JICA Joint Integration Concepts and Assurance JP Joint Program JWC Joint Warfare Council LCC Life Cycle Cost LCCA Life Cycle Cost Analysis LCD Life-cycle Concepts Document LORA Level of Repair Analysis LSA Logistic Support Analysis LSAR Logistics Support Analysis Report MCE Major Capital Equipment MIL-HDBK (U.S.) Military Handbook MIL-STD (U.S.) Military Standard MINCE Minor Capital Equipment MinSub Ministerial Submission MOE Measure of Effectiveness MOP Measure of Performance MOS Measure of Suitability MOTS Military off the Shelf MRD Maintenance Requirements Determination MSR Mandated System Review MYEFO Mid-Year Economic Fiscal Outlook NCOSE National Council on Systems Engineering NDI Non-Developmental Item NJF Networked Joint Force NRE Non-Recurring engineering NSC National Security Committee (of Cabinet) OCD Operational Concept Document ODA Offer Definition Activity OT&E Operational Test and Evaluation OTS Off the Shelf PBL Product Baseline PCA Physical Configuration Audit PDR Preliminary Design Review PES Project Execution Strategy PGPA Public Governance Performance &

Accountability Act 2013 PHS&T Packaging, handling, storage and

transportation PIOC Program Integrating Operational Concept PLCD Preliminary Life-cycle Concepts Document

PLICIT Professionalism, Loyalty, Integrity, Courage, Innovation, Teamwork

PM Project Management PM&C Prime Minister and Cabinet (Department) PMBOK Project Management Body of Knowledge PMI Project Management Institute PMP Project Management Plan PMSG Project Management Stakeholder Group PO Project Office PRICIE Personnel, research and development,

infrastructure, concepts and doctrine, information technology, equipment

PRR Project Risk Register PS Program Strategy PWBS Program/Project Work Breakdown

Structure PWD Planned Withdrawal Date QA Quality Assurance RAAF Royal Australian Air Force RAM Reliability, Availability, Maintainability RAN Royal Australian Navy RBS Requirements Breakdown Structure RFI Request for Information RFP Request for Proposal RFT Request for Tender RI Repairable Items RMP Risk Management Plan S&Q Survey and Quote SA Support Analysis SAA System Acceptance Audit SBS System Breakdown Structure SCRAM Schedule Compliance Risk Assessment

Methodology SDD System Design Document SDR System Design (Definition) Review SE Systems Engineering SEBoK Systems Engineering Body of Knowledge SEDS Systems Engineering Detailed Schedule SEI Software Engineering Institute SEMP Systems Engineering Management Plan SEMS Systems Engineering Master Schedule SLOC Source Lines Of Code SME Small-to-Medium Enterprise SME Subject Matter Expert SNR Stakeholder Needs and Requirements SOI System of Interest SOP Standard Operating Procedure(s) SoS System of Systems SoSE SoS Engineering SOW Statement of Work SP&I Strategic Policy & Intelligence (Group) SPPR Spares Provisioning Preparedness Review SRD Stakeholder Requirement Document SRR Systems Requirements Review SS (Mission) System Specification

SSCC Support System Constituent Capabilities SSDDR Support System Detailed Design Review SSSPEC Support System Specification STD Standard StRS Stakeholder Requirements Specification SW Software SWEBOK Software Engineering Body of Knowledge SyRS System Requirements Specification T&E Test and Evaluation TARR Task Analysis Requirements Review TCD Test Concept Document TCO Total Cost of Ownership TDRL Tender Data Requirement List TEMP Test and Evaluation Master Plan TEPPR Training Equipment Provisioning

Preparedness Review TIRA Technical Implementation Risk

Assessment TLS Through Life Support TNGRR Training Readiness Review TPM Technical Performance Measures TRAP Technical Review and Audit Plan TRA Technical Risk Assessment TRR Test Readiness Review TXRR Transition Requirements Review URD User Requirements Document URS User Requirements Specification V&V Verification and Validation VCDF Vice Chief of the Defence Force VCDFG VCDF Group VCRM Verification Cross Reference Matrix VFM Value for Money WBS Work Breakdown Structure WHS Workplace Health and Safety WHS Workplace Health and Safety Act 2013 WSOI Wider SOI

Systems Revision

Systems Engineering Practice / Professor Mike Ryan 1-1

Systems EngineeringPractice

Professor Mike Ryan

Course Outline

• Systems

– Systems revision

– Systems exercises

• Systems Acquisition

– Revision

– Systems acquisition exercises

– Systems acquisition in Defence

• Conceptual Design

– Conceptual Design Activities

– Conceptual Design Exercise

• Preliminary Design

– Preliminary Design Activities

– Preliminary Design Exercise

Systems Revision


Systems Revision

System

• A system is defined by ISO/IEC 15288 as:

a combination of interacting elements organized to achieve one or more stated purposes

• In the broadest sense, a system is something that provides asolution to a complex problem.

• A system combines a number of resources together in anorganized manner so as to perform a collection of specifiedfunctions to specified levels of performance.

• A system meets defined needs, which must be clearly statedby stakeholders, and which represent the start point of thedesign process as well as provide the basis for the ultimatetest of the system’s fitness-for-purpose once fielded.

Systems Revision


Definition of a System

• So, a system comprises: system elements, interconnections(interactions) between elements, and an external systemboundary.

• The purpose of the system is called its mission.

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

System of interest(SOI)

System element

Interconnection/interaction

System boundary

System of interest

Widersystem of interest

Operating environment

Wider environment

A system and its Environment

Systems Revision


Problem Space / Solution Space

• A system can be considered to be the solution to a problem.

• It is common, therefore, to consider system development tobe in the:

– problem space (using mainly functional descriptions)

– solution space (using mainly physical descriptions).

• The definition of problem space (and thence the functionalarchitecture) is generally considered to be the responsibilityof the people who own the business.

• The solution space (and thence the physical architecture) isgenerally considered to be the responsibility of the peopleimplementing the system.

Functional and Physical Design

• A system can be described in two broad ways:

– In functional terms: what the system will do, how well itwill do it, how it will be tested, under what conditions it willperform, and what other systems will be involved with itsoperation.

– In physical terms: a physical description relates to thesystem elements and explains what the elements are,how they look, and how they are to be manufactured,integrated and tested.

• In the development of a system, therefore, there are at leasttwo architectural views of the system: a functionalarchitecture, providing a structured functional description;and a physical architecture, providing a physical description.

Systems Revision



• Both are valid independent descriptions of a system, and it isvery important that a system is described in both ways:

– The functional description contains the ‘whats’ of thesystem, and the physical description contains the ‘hows’.In order to determine whether any particular physicalarchitecture (how we are going to implement the system)is appropriate, we first must understand (from thefunctional architecture) what it is that we want the systemto do (the system’s purpose).

– How we implement current systems shouldn’t colour theway we describe future systems—if we focus on thephysical initially, we would only use old building blocks.

– ...


• Both are valid independent descriptions of a system, and it isvery important that a system is described in both ways:

– ...

– A functional description is ideally suited to the interfacebetween systems design and the business case.

– The functional description changes slowly; the physicaldescription changes much faster, particularly as the paceof technological change quickens.

– Upper-level trade-offs and feasibility analyses must beconducted at the functional level before deciding on thephysical implementation—if not, we will select physicalsolutions that either perform unnecessary functions or donot possess critical functionality.

Systems Revision


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.

System

Operational products Enabling products

Testproduct

Trainingproduct

Disposalproduct

Developmentproduct

Deploymentproduct

Supportproduct

Productionproduct

Endproduct

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

Systems Revision


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

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

Systems Revision


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

….

SOI: System or System-of-Systems

System-of-Interest

System System System


SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

System-of-Systems

System

SystemSystem-of-Systems

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

Systems Revision


System Definition—Revisited

• an arrangement of parts or elements that together exhibit behaviour or meaning that the individual constituents do not. (INCOSE Fellows)

• a combination of interacting elements organized to achieve one or more stated purposes. (ISO/IEEE/IEC 15288)

• For which purpose?

• Which type of elements?

• How arranged (integrated)?

• How do the elements interact?

• For how long?

• How optimised?

System

Subsystem Subsystem

Subsystem Subsystem

Subsystem, System, and SoS

Subsystem

Component Component

Component Component

System

Subsystem Subsystem

Subsystem Subsystem

SoS

System System

System System

Systems Revision



Subsystem

Component Component

Component Component

tightly coupledco-dependent components

optimised at the system level for the permanent

purpose of the system

tightly coupledco-dependent subsystems

optimised at the system level for the permanent

purpose of the system

loosely coupledindependent systems optimised

at the system level for the temporary

purpose of the SoS

System

Subsystem Subsystem

Subsystem Subsystem

SoS

System System

System System


Attribute Subsystem System SoS

Purpose System System SoS

Element Type Component Subsystem System

Integration Tightly Coupled Tightly Coupled Loosely Coupled

Element Interaction Co-dependent Co-dependent Independent

Period Permanent Permanent Temporary

Optimisation Level System System System

Systems Revision


Systems / System-of-Systems

System-of-Interest



SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

OCD


System-of-Interest



SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

OCD

OCD

OCD

OCD

Systems Revision



System-of-Interest



SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

SystemElement

Umbrella OCD

UmbrellaOCD

OCD

OCD

Hierarchy of SoS

SoS

SoS SoSSoS

SoS SoS SoS

SoS SoSSoS

SoS

System SystemSystem

SoS SoS

ADO

ADF

Service

……….. ………..

……….. ………..

……….. ………..

……….. ………..

……….. ………..

Systems Revision


Integrating OCDs & System OCDs

SoS

SoS SoSSoS

SoS SoS SoS

SoS SoSSoS

SoS

System SystemSystem

SoS SoS

Integrating OCD

Integrating OCD

Integrating OCD

Integrating OCD

OCD OCD OCD

……….. ………..

……….. ………..

……….. ………..

……….. ………..

Three Types of Defence Programs

• System of Systems (SoS)—integrated capability.

• Family of Systems (FoS)—common-use systems.

• Portfolio of Systems (PoS)—management grouping.

Source: M.W. Maier, Architecting a portfolio of systems, Systems Engineering. 2019;1-13, wileyonlinelibrary.com/journal/sys

Systems Revision


Defence Programs: Three Grouping Types

Defence Programs

System of Systems (SoS)

Family of Systems (FoS)

Portfolio of Systems (PoS)

• Joint capability • operationally related • e.g. IAMD Program

• common-use systems• common requirements and

design• efficiencies (economies of

scale in production, acquisition, support)

• e.g. radar program

• operationally independent• managerially convenient• largely unrelated attributes • related by budget and mgt• e.g. infrastructure program

(E&IG)

Source: M.W. Maier, Architecting a portfolio of systems, Systems Engineering. 2019;1-13, wileyonlinelibrary.com/journal/sys

Systems Revision

Systems Acquisition


Systems Acquisition

Generic Project and System Life Cycles

AcquisitionPhase

UtilizationPhase

RetirementPhase

Pre-acquisitionPhase

Systems Acquisition


Parties Involved

Acquisition Phase Utilization Phase Retirement PhasePre-acquisition Phase

ProjectManagement

Enterprise/Business

Management

SystemsEngineering

Users /Support

Acquisition and Utilization Phases

AcquisitionPhase

PreliminaryDesign

DetailedDesign and

Development

UtilizationPhase

RetirementPhase

Pre-acquisitionPhase

AcquisitionPhase

UtilizationPhase

ConceptualDesign

Constructionand/or

Production

Operational Useand

System Support

Systems Acquisition


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)

Systems Acquisition


Preliminary Design

• Preliminary Design starts with the Initial FBL and continuesto translate system-level requirements into requirements forthe system elements that will combine to form the system.

• The result of Preliminary Design is the establishment of theconfiguration items (CI) in an Allocated Baseline (ABL), inwhich requirements are ‘allocated’ to specific physicalsystem elements that combine to form the system.

• Preliminary Design ends with the Preliminary Design Review(PDR), which finalizes the ABL.

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Allocated Baseline

Preliminary Design Review (PDR)

Requirements allocation

A way to represent the functional to physical allocation is via an allocation matrix.

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

Systems Acquisition


WBSAircraft 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

Systems Acquisition


Detailed Design and Development

• Detailed Design and Development takes the definitions ofthe overall system (as contained in the FBL) and of the majorCIs (contained in the ABL) and finalizes the design ofspecific components that make up the CIs (and subsystems).

• The realization and documentation of individual componentsused to support production is referred to as the ProductBaseline (PBL) which is established at the Critical DesignReview (CDR).

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Product Baseline

Critical Design Review (SDR)

Construction and/or Production

• Concentrates on construction and/or production of thesystem in accordance with the detailed design frozen atCDR.

• Production refers to manufacturing and procurement effortneed to support construction.

• Construction is the assembly and building of the system.

• Systems can be unique or produced as one of a number.

PreliminaryDesign

DetailedDesign and

Development

AcquisitionPhase

UtilizationPhase

ConceptualDesign

Constructionand/or

Production

Operational Useand

System Support

Systems Acquisition


Systems Engineering Summary

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

Technical Review and Audit Plan (TRAP)

Test and Evaluation Master Plan (TEMP)

Risk Management Plan (RMP)

Configuration Management Plan (CMP)

Systems Engineering Management Plan (SEMP)

Major Responsibilities

NEED

DISPOSAL

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ConceptualDesign

NEED

DISPOSAL

PreliminaryDesign

DetailedDesign and

Development

Operational Useand

System Support

Constructionand/or

Production

ConceptualDesign

Acquirer acceptancefrom contractor

Contract based onSystem Requirement Specification (SyRS)

Stakeholder RequirementSpecification (StRS)

Acquisition Utilisation

User acceptance from acquirer

Customer (User)

Customer (Acquirer)

Contractor

Systems Acquisition


Hard and Soft Systems

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

Soft systems modelling

Hard systems modelling

The Role of Systems Engineering

• Although there are many standards and references thatprovide slightly different definitions of systems engineering,each with a slightly different focus, a number of commonthemes are evident:

– Top-down approach

– Focus on life-cycle

– System optimization and balance

– Integration of disciplines and specialties

– Management

– Focus on requirements engineering

– Traceability

Systems Acquisition


Top-down Design

• Traditional engineering disciplines are based on bottom-upapproach.

– We design and build components, integrate them into thenext higher level assembly 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 notto be suited to bottom-up solutions.

• Systems design and analysis must take a top-downapproach in an attempt to give the designers individual andwell-defined problems to solve.

Top-down Design

• Start by looking at the system as a whole:

– Provides a thorough understanding of the system and itsenvironment and interfaces.

– System-level requirements are developed.

– Emergent properties are identified.

• The likely physical subsystems can then be considered andrequirements assigned to individual subsystems:

– Additional (derived requirements) are also developed.

– Interfaces between subsystems are also identified.

• This process continues until reaching a logical end point.

• Design is top-down but implementation via integration andtesting is still done in a bottom-up manner.

Systems Acquisition


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

ANSI/EIA-632 “Engineering a System”

Bottom-up 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

Systems Acquisition


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

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.

Systems Acquisition


Need

Goals

Objectives

RequirementsLevel 1

RequirementsLevel 2

Requirements Flowdown

Functional Hierarchy of a System

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

Need

Level 1

Level 2

Level 3

Level 4

Level n

….

Systems Acquisition


Hierarchical Elaboration 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

The Impact of Systems Engineering

High

Low

Conceptual &Preliminary

Design

DetailedDesign and

Development

Constructionand/or

Development

Utilization

Impact of systems engineeringAnd requirements engineering

Systems Acquisition


The Importance of Functional Design

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 ServiceSystems Desig

n and Development

The Importance of Functional Design

High

Low

Conceptual &Preliminary

Design

DetailedDesign and

Development

Constructionand/or

Development

Utilization

Ease of making changes

Cost of making changes

Systems Acquisition


Relative Cost to Fix a Defect

Phase

Requirements

Design

Coding

Subsystem integration

System integration

Utilization

1−2

5

10

20

50

200

Davis, A.M., Software Requirements: Objects, Functions and States, Englewood Cliffs, NJ: Prentice Hall, 1993.

Acquisition Models

• It should be noted that our generic system life cycle showsthe phases and activities in sequence and is not intended torepresent any particular development or acquisition modelsuch as the:

– Waterfall (including the vee) model,

– Incremental model,

– Spiral model, or

– Evolutionary acquisition model.

• Each of these models represents a different approach toimplementing the activities of the system life cycle.

Systems Acquisition


Systems Acquisition

Systems Acquisition in Defence



Pre-FPR



Need Requirements Acquisition In-service Disposal

CDG Contractor

Involvement

CD PDDD&D

C&/or

PUtilisation

FPS SS DS PS

Nee

d

Con

tract

Dis

posa

l

Defence Capability Life Cycle

Systems Engineering Life Cycle

DMO User/Support AgencyAc

cept

ance

Before First Principles Review (FPR)

Post-FPR



Post-FPR Defence Capability Lifecycle

Government First PassApproval

Government Second Pass

Approval

Analysis ofrealistic

options

StrategicGuidance

Principal TasksForce Design

Force Posture

In Service DisposalAnalysis ofbroad

options

Requirement

Need AcquisitionAnalysis ofrealistic

options

StrategicGuidance

Principal TasksForce Design

Force Posture

In Service DisposalAnalysis ofbroad

options

Requirement

Need Acquisition

Gate 0 Gate 1 Gate 2

ConceptGate 0 Gate 1 Gate 2

Concept Refinement

Pre-Feasibility FeasibilityAcquisition In Service Transition

Contestability

Strategic Contestability

Project Contestability(Scope, technical, cost and project management)

Contestability

• Is this the right thing to do?• Will we receive the outcome we expect?• Have things been done right?



Capability Integration: Prioritisation (across and down streams in IC)

Cap

abil

ity

Man

agem

ent (

acro

ss d

omai

ns)

ISREW, Space and Cyber

Air & Sea Lift Land Combat & Amphib Warfare

Strike & Air Combat Maritime & Anti-Sub Warfare

Key Enablers

Vice Chief Defence Force

Vice Chief Defence Assoc Secretary

Chief of NavyChief of Army Chief of Air ForceChief of Air Force

Vice Chief Defence Force

Chief of Navy

Chief of Army

Chief of Air Force

DepSec SPI

Capability Streams

Joint Integration

Maritime

Land

Air & Space

Intelligence & Cyber

C4I and Joint Battle Management Systems

Joint ISR and EW

Warfighting Innovation (inc Cyber)

Asymmetric Response

Maritime Tactical C4I

Land ISREW

Land C3

Air and Space Awareness

Strategic Intelligence

Strategic Cyber

Battlefield Aviation

Sea Lift Amphibious Content

Maritime Patrol and Response

Major Surface Combatants Submarines Naval Aviation Maritime Logistics Minor Combatants Maritime Military Geospatial Information

Health Services

Fuel

Explosive Ordnance

Training Support and Simulation

Maritime Infrastructure and Ranges

Combat Service Support Systems

Base Operations

Aircrew Training

Airborne Electronic Attack

Integrated Air and Missile Defence

Air Combat

Combat Vehicles Soldier Systems Non-combat Vehicles Combat Support Special Operations

Air Mobility

Infrastructure & E

state* / Enterprise IC

T* / W

orkforce*

Note – Aligned to the IIP intent @ 20 Oct 15. Program names are changed to reflect integration. Subordinate elements to the Strategy Resource functions are yet to be developed.

Capability Streams

Tailored Journey




Strategic Guidance

Capability Program

Narratives

Joint Capability Narratives

Joint Capability Needs

Statement

ForceDesign

ProjectExecution Strategy

Document JourneyDWPIIPDPG

BusinessCase

Revised ProjectExecution Strategy

Draft Government Submission

Contestability Statement

FinalBusiness

Case

Final ProjectExecution Strategy

Draft Government Submission

Contestability Statement


Capability Manager

VCDF Gp

SP&I StrategicContestabilityAcquisition

Agency

Strategic Contestability

Project Contestability

Strategic Guidance

Capability Program

Narratives

Joint Capability Narratives

Joint Capability Needs

Statement

ForceDesign

Document HierarchyDWPIIPDPG

Capability Manager

Integrated OCD

ProgramIntegrating

OCDProject OCD

ProjectFPS

AcquisitionAgency

Ref

ers

to

Info

rms



Major Artefacts

OperationalConcept

Document(OCD)

Functionand

PerformanceSpecification

(FPS)

SystemSpecification

(SS)

CONTRACT

Sub-systemSpecifications

(SSS)

Test and Evaluation Master Plan(TEMP)

Capability Definition Documents(CDD)

PreliminaryDesign

DetailedDesign and

Development

Constructionand/or

Production

ConceptualDesign

Functional Baseline(System Requirement Specification (SyRS))

System Design Review(SDR)

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)

JointCapability

NeedsStatement

Some Definitions

• Capability: The power to achieve a desired operational effectin a nominated environment within a specified time and tosustain that effect for a designated period. Capability isgenerated by Fundamental Inputs to Capability comprisingorganisation, personnel, collective training, major systems,supplies, facilities and training areas, support, command andmanagement. (DCDH 2011)

• System: An integrated composite of people, products, andprocesses that provides a capability to satisfy a stated needor objective. A system is a combination or assembly ofhardware, software, principles, doctrines, methods, ideas,procedures and personnel, or a combination of them,arranged or ordered towards a common objective. (DCDH2011)



Some Definitions

• Capability System: The combination of the fundamentalinputs to capability, which are the standardised elementsrequired to deliver capability. (DCDH 2011)

• Materiel System: A subset of the Capability System beingthe combination of the Mission System and the SupportSystem. The Materiel System covers those aspects of theFIC that are supplied by the acquisition agency. (DCDH2011)

Some Definitions

• Mission System: That element of capability that directlyperforms the operational function. Includes platforms (ships,vehicles or aircraft), distributed systems (communicationsnetworks), and discrete systems that integrate into othermission systems (radar). (DCDH 2011)

• Support System: The sum of the existing supportinfrastructure and the additional support elements beinggenerated to enable the Mission System to be effectivelyoperated and supported so that the Mission System canmeet its operational requirements. It includes theorganisation of hardware, software, materiel, facilities,workforce, data, processes and services. The SupportSystem embraces the support responsibilities undertaken bythe Department of Defence, in-service support contractorsand in-service support subcontractors. (DCDH 2011)



Capability System

Materiel System

Mission System

SupportSystem

Other Elements of FIC• Command and Management• Organisation• Major System• Personnel• Supplies• Support• Facilities and Training Areas• Collective Training

Capability System(Elements of FIC)

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



Some Definitions

• End User: An equivalent term to ‘Warfighter’ and includes allexternal users of the system. End-users are the personnelwho are involved in tasking the Capability System, receivingits outputs, or requiring its outcomes to achieve theirpurpose. (CDD Guide v2.0)

• Internal User: A person internal to a Capability System (orExisting System), and includes supervisors, operators,engineers, maintainers, suppliers, and trainers. (CDD Guidev2.0)

Definitions

• Solution Class. 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



Capability Definition Documents (CDD)

• The Operational Concept Document (OCD) is the capstonedocument that captures the scope of, and intent for, theproposed Capability.

• The Function and Performance Specification (FPS) specifiesthe formal requirements for the Materiel System andprovides the basis for design and qualification testing of thesystem.

• The T&E Master Plan (TEMP) considers T&E requirementswithin the life-cycle management of the Capability System.The TEMP is elaborated further by the contractor in the V&VPlan.

Transformation of Operational Needs

Transformationdocumented in OCD

Specification documented in FPSSpecifications

Ope

ratio

nal

Nee

ds

Trans

form

atio

n

Warfighter Domain

Well Understood

by Warfighters

ImplementationDomain

Well Understood by Acquirers & Developers

OCDUnderstood by

all partiesT&E expectations documented in TCD

CDD Guide v2.0



OCD, FPS, TEMP 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

….

….

Mission

OCD

FPS

DraftTEMP

Prepared by Stakeholders (CM)


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


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

OCD

FPS

Augmented/prepared by Acquirer (CASG)

(+)

TEMP

DraftTEMP




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


Level 1

Level 2

Level 3

CI

COI

MOE

Level 4 MOP

Level n TPM

….

….

Mission

OCD

FPS

SSS

SS

TEMP

V&VPlan

Prepared by Contractor/Sub-contractors

DraftTEMP

OCD

• Communicates the solution-independent needs of thewarfighter to all stakeholders, including acquirers anddevelopers, in a language that all parties can understand.

• Describes required capability from an operationalperspective.

• Facilitates an understanding of the overall system goals forthe materiel system.

• Details missions and scenarios associated with operationsand support of the Materiel System.

• Provides a reference for determining ‘fitness for purpose’.

• Provides a justifiable basis for the formal requirements forthe Materiel System, as captured in the FPS.

• Details the FIC needed to realise the Capability System inoperational service.

CDD Guide v2.0



OCD Template0. EXECUTIVE SUMMARY0.1 Identification and Justification0.2 Key Boundary Issues0.3 Project Schedule0.4 Capability System Mission and Critical

Operational Issues0.5 Existing Capability Description0.6 Materiel System Solution-class0.7 Fundamental Inputs to Capability1. SCOPE1.1 Capability Identification1.2 Document Purpose & Intended Audience1.3 Justification for Capability1.4 System Boundary and Acquisition

Assumptions1.5 Key Timeframes for Capability2. DEFINITIONS AND REFERENCED

DOCUMENTS2.1 Referenced Documents2.2 Glossary of Terms

3. SOLUTION-INDEPENDENT CAPABILITY NEEDS

3.1 Mission Overview3.2 Operational Policies and Doctrine3.3 Capability System End-user classes3.4 Summary of Operational Scenarios3.4.1 Common Scenario Attributes3.4.2 Scenario 1 - Scenario Title3.4.2.1 Summary of Situation3.4.2.2 Summary of Military Response3.4.2.3 Summary of Operational Needs3.4.3 Scenario 2 - Scenario Title3.4.4 Scenario N - Scenario Title3.5 Summary of Consolidated Operational

Needs3.6 Solution-class-Independent Constraints

DID-ENG-DEF-OCD-V2.0

OCD Template4. EXISTING SYSTEM4.1 Existing System Overview4.2 Existing System Operational Capability

Comparison4.3 Existing System Internal Shortcomings4.4 Existing System Planned or Active

Upgrades4.5 Existing System Internal User classes4.6 Existing System Internal Functionality4.7 Summary of Existing System Internal

Scenarios5. SYSTEM SOLUTION-CLASS

DESCRIPTION5.1 Materiel System Description5.2 Mission System Architecture5.3 Materiel System Interfaces5.4 Materiel System Internal User classes5.5 Materiel System Functionality and

Performance

5.6 Materiel System Support Concepts and Requirements

5.7 Materiel System Constraints5.8 Materiel System Evolution and

Technology Forecast5.9 Summary of Materiel System Internal

Scenarios5.9.1 Internal Scenario 1 - ‘A Typical Day’s

Operation’5.9.1.1 Summary of Situation5.9.1.2 Summary of Process Flows and

Interactions5.9.1.3 Summary of Materiel System

Requirements5.9.2 Internal Scenario 2 - Scenario Title5.9.3 Internal Scenario N - Scenario Title




OCD Template6. CONSOLIDATED FUNDAMENTAL

INPUTS TO CAPABILITY (FIC) REQUIREMENTS

6.1 FIC Related Guidance6.2 Major Systems FIC Element

Requirements6.3 Facilities and Training Areas FIC

Element Requirements6.4 Support FIC Element Requirements6.5 Supplies FIC Element Requirements6.6 Organisation FIC Element

Requirements6.7 Command and Management FIC

Element Requirements6.8 Personnel FIC Element Requirements6.9 Collective Training FIC Element

Requirements6.10 FIC Impacts on Supporting Capabilities6.11 Summary of Overall FIC

Responsibilities6.12 FIC Development Forecast

A. ANNEX A - EXTERNAL SCENARIOSA.1 Capability System Operational ScenariosA.1.1 Common Scenario AttributesA.1.2 Scenario 1 - Scenario TitleA.1.2.1 Scenario 1 - Situation Requiring ADF

ActionA.1.2.2 Scenario 1 - Military ResponseA.1.2.3 Scenario 1 - Operational NeedsA.1.3 Operational Scenario 2 - Scenario TitleA.1.4 Operational Scenario N - Scenario TitleA.2 Consolidated Operational Needs


OCD TemplateB. ANNEX B - EXISTING SYSTEM

INTERNAL SCENARIOSB.1 Internal Scenario 1 - ‘A Typical Day’s

Operation’B.1.1 Internal Scenario 1 - SituationB.1.2 Internal Scenario 1 - Details of Process

Flows and InteractionsB.1.3 Internal Scenario 1 - Identified

ShortcomingsB.2 Internal Scenario 2 - Scenario TitleB.3 Internal Scenario N - Scenario Title

C. ANNEX C - MATERIEL SYSTEM INTERNAL SCENARIOS

C.1 Internal Scenario 1 - ‘A Typical Day’s Operation’

C.1.1 Internal Scenario 1 - SituationC.1.2 Internal Scenario 1 - Details of Process

Flows and InteractionsC.1.3 Internal Scenario 1 - Materiel System

RequirementsC.2 Internal Scenario 2 - Scenario TitleC.3 Internal Scenario N - Scenario TitleC.4 Consolidated Materiel System

Functionality and Performance




OCD Lite (OCDL)

• This document is intended to be used where the solution isrelatively low cost, low risk and of low-to-medium technicalcomplexity while still sufficiently challenging to warrantstructured requirements analysis and definition. Typicallythese systems are the subject of Operational Procurement,in-service modifications, Minor Capital Equipment and ACATIV Major Capital Equipment projects.

• These projects generally apply where:

– the nature of the solution is well understood;

– the solution is not expected to materially alter the wayDefence is organised or operates; and

– the solution may be significantly constrained by platformor other elements including FIC elements.

DMH (ENG) 12-3-004

FPS

• Specifies formal requirements for the Materiel System.

• Provides the basis for design and qualification testing of thesystem.

• Provides the vehicle for the capture of formal, verifiable andunambiguous requirements, ‘distilled’ from the OCD.

• Is intentionally written using formal language, with allrequirements in the FPS traceable to needs in the OCD.

• Addresses the total Materiel System, but will later bedeveloped into a Mission System specification and a SupportSystem specification, usually by a prime contractor or primesystem integrator.

• FPS requirements may also need to be decomposed and/orallocated for the purposes of individual acquisition contracts.

CDD Guide v2.0



FPS TemplateSection 1 – Scope 1.1 – Identification 1.2 – System Overview 1.3 – Document Overview Section 2 – Applicable Documents Section 3 – Requirements 3.1 – Missions 3.2 – System Boundaries and Context 3.3 – Required States and Modes 3.4 – System Capability Requirements 3.5 – Availability 3.6 – Reliability 3.7 – Maintainability 3.8 – Deployability3.9 – Transportability3.10 – Environmental Conditions3.11 – Electromagnetic Radiation 3.12 – Architecture, Growth and Expansion 3.13 – Safety

3.14 – Environmental Impact Requirements 3.15 – Useability and Human Factors 3.16 – Security and Privacy 3.17 – Adaptation Requirements 3.18 – Design and Implementation

Constraints 3.19 – System Interface RequirementsSection 4 – Precedence and Criticality of

Requirements Section 5 – VerificationSection 6 – Requirements TraceabilitySection 7 – Notes

TEMP TemplateSECTION I - SYSTEM DESCRIPTION 1.1 Mission Description 1.1.1 Operational Need 1.1.2 Mission(s) to be Accomplished

1.1.3 Specified Environment 1.2 System Description 1.2.1 Key Functions 1.2.2 System Architecture and Interfaces

1.2.3 Unique System Characteristics 1.3 Critical Operational Issues (COI) 1.4 System Threat Assessment 1.5 Required Operational Characteristics

1.5.1 Key Operational Effectiveness Characteristics 1.5.2 Key Suitability Characteristics 1.5.3 Thresholds

1.6 Key Technical Characteristics

SECTION II - PROGRAM SUMMARY 2.1 Project Phases and V&V Phases 2.2 Stakeholder Responsibilities with respect to V&V 2.3 Integrated Schedule 2.4 Funding Aspects of the V&V process

SECTION III – DT&E OUTLINE 3.1 Critical DT&E Issues 3.2 DT&E to Date 3.3 Future DT&E

3.3.1 DT&E Phases and Objectives 3.3.2 DT&E Activities and Scope of Testing 3.3.3 Critical DT&E Resource Requirements 3.3.4 Constraints and Limitations associated with D&TE

SECTION IV – VALIDATION OUTLINE 4.1 Critical Validation Issues 4.2 Validation to Date 4.3 Future Validation

4.3.1 Validation Phases and Objectives 4.3.2 Validation Activities and Scope of Testing 4.3.3 Critical Validation Resource Requirements 4.3.4 Constraints and Limitations associated with Validation

SECTION V – ACCEPTANCE V&V (AV&V) OUTLINE 5.1 Critical AV&V Issues 5.2 AV&V to Date 5.3 Future AV&V

5.3.1 AV&V Phases and Objectives 5.3.2 AV&V Activities and Scope of Testing 5.3.3 Critical AV&V Resource Requirements 5.3.4 Constraints and Limitations associated with AV&V

SECTION VI - SAFETY 6.1 Assessment of Safety 6.2 Critical Safety Issues 6.3 Safety Management for V&V activities

SECTION VII - SPECIALTY TEST PROGRAMS 7.1 Specialty Test Program Requirements 7.2 Specialty Test Program - Critical Issues

SECTION VIII – SUPPORTABILITY TEST PLAN

SECTION IX – TRANSITION PLAN

SECTION X – SPECIAL RESOURCE SUMMARY 10.1 Schedule of V&V activities with special resource requirements 10.2 Special Resource Requirements for V&V activities

SECTION XI – HUMAN RESOURCE LIMITATIONS

Conceptual & Preliminary Design


Conceptual Design

Needs View Requirements View

Concept of Operations(ConOps)

System

SystemElement

BusinessOperations

BusinessManagement

Enterprise Enterprise Strategies

Mission Analysis

Requirements Analysis

Business or Mission Analysis

Process

Stakeholder Needsand Requirements Definition Process

System Requirements Definition Process

Subsystem Requirements

Definition Process



Mission Analysis




15288 ProcessConcepts View

BusinessManagement

Needs

BusinessManagementRequirements

BusinessOperations

Needs

Preliminary Life-cycle Concepts:Operations (OpsCon), Acquisition,Deployment, Support, Retirement

SystemNeeds

SystemElementNeeds

BusinessAnalysis

Subsystem Life-cycle Concepts:OpsCon, Acquisition, Deployment, Support, Retirement

Life-cycle Concepts:OpsCon, Acquisition, Deployment, Support, Retirement

System Life-cycle Concepts:OpsCon, Acquisition, Deployment, Support, Retirement

BusinessOperations

Requirements

SystemRequirements

SystemElement

Requirements

Domain



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

System Design Review (SDR)



ISO/IEC-15288

• ISO/IEC 15288 proposes a common process frameworkcovering the life cycle of man-made systems in order toaddress a need for a common framework that will improvecommunication and cooperation among the parties thatcreate, utilise, and manage modern systems.

• ISO/IEC 15288 identifies four process groups, each of whichincludes a number of processes:

– Agreement Processes,

– Organisational Project-Enabling Processes,

– Technical Management Processes, and

– Technical Processes.

Stakeholder Needs & Regts Definition

Process

Integration Process

Implementation Process

Transition Process

Architecture Definition Process

Verification Process

Validation Process

System ReqtsDefinitionProcess

MaintenanceProcess

DisposalProcess

OperationProcess

Technical Processes

Human Resource Management Process

Project PortfolioManagement Process

Infrastructure Management Process

Life Cycle Model Management Process

Quality Management Process

Technical Management Processes

Project Assessment & Control Process

Decision Measurement Process

Supply ProcessAcquisition Process

Agreement Processes

Organisational Project‐Enabling Processes

Operation & Support

Project Planning Process

Measurement ProcessConfiguration Mgt

ProcessInformation

Management Process Quality Assurance

Process

Knowledge Management Process

Risk Management Process

Business or Mission Analysis Process

System Analysis Process

DesignDefinition Process



EIA/IS-632 (MIL-STD-499B) SE Process

ProcessInputs

ProcessOutputs

RequirementsAnalysis

FunctionalAnalysis / Allocation

Synthesis

Design Loop

Requirements Loop

Verification

Verification

IEEE 1220 SE Process

Requirements TradeStudies and Assessments

Functional TradeStudies and Assessments

Design TradeStudies and Assessments

Requirement andconstraint conflicts

Requirement trade-offsand impacts

Decomposition and requirement allocation alternatives

Decomposition/allocation tradeoffs and impacts

Design solution requirements and alternatives

Design solutiontradeoffs and impacts

System Analysis

Requirements Baseline

Validated Requirements Baseline

Functional Architecture

Validated Functional Architecture

Physical Architecture

Validated Physical ArchitectureControl


RequirementsVerification

FunctionalAnalysis

FunctionalVerification

Synthesis

DesignVerification

Process Output



IEEE 1220 SE ProcessRequirements Analysis

Define project andenterprise constraints

Define customerexpectations

Define externalconstraints

Define measuresof effectiveness

Define operationalscenarios

Define interfacesDefine system

boundariesDefine life cycle

process conceptsDefine utilisation

environments

Define performancerequirements

Define functionalrequirements

Define technicalperformance measures

Define modes ofoperations

Define humanfactors

Define designcharacteristics

Operationalview

Functionalview

Designview

Establish requirements baseline

FunctionalAnalysis

Conceptual Design Activities



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)

Conceptual Design




Conceptual Design




C1.1 Identify major stakeholders and constraints

C1.2 Define business needs

C1.3 Scope system

C1. Define business needs and requirements (BNR)

C1.4 Define business requirements

C1.5 Finalise business needs and requirements (BNR)

BNR(PLCD and

BRS)



Conceptual Design




Conceptual Design




C2.1 Define stakeholder needs

C2.2 Define stakeholder requirements

C2.3 Finalise stakeholder needs and requirements (SNR)

C2. Define stakeholder needs and requirements (SNR)

SNR(LCD and StRS)

Conceptual Design




Conceptual Design



C2. Define stakeholderneeds and requirements C3. Define system requirements

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



Conceptual Design




Conceptual Design




RefinedSyRS


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



Conceptual Design




Conceptual Design


Initial FBL



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

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



Subsystem requirement analysis

P1.3.2 Define performancerequirements

P1.3.3 Define verificationrequirements

P1.3.1 Derive/decomposefunctional/non-functional

requirementsP1.3.4 Assign rationale

P2. Conduct Requirements Allocation

P1. Conduct subsystem requirements analysis

P1.3 Define subsystem requirements

P1.1 Review SyRS

P1.2 Review TPMs

Configuration items (CI)

• Each of these 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.



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



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



Preliminary Design

SYSTEMS ENGINEERING PRACTICE

DESIGN EXERCISE

BACKGROUND AND NEED ACME Pty Ltd has just acquired Paradise Island in northern Australia and sees an opportunity to create a unique tourist attraction called “Ultimate Paradise”. Your company has been engaged to make this happen. The island is located approximately 80 km west of Weipa in the Gulf of Carpentaria in northern Queensland. The island is roughly circular in shape with a diameter of 25 km. It is generally mountainous with thick rainforest vegetation covering a large portion of the island. Fortunately, there are a few areas of flat terrain suitable for building the resort and the associated recreational facilities. The island was once mined for its gold deposits, but mining ceased 30 years ago when the ore deposits were depleted. Some basic infrastructure remains, such as dirt roads, a rudimentary harbour, an old jetty and a railroad. The railroad is quite exciting as it effectively circumnavigates the island and ACME believes it will make an excellent way of showing tourists the island, transporting the guests to the many attractions, as well as providing transport for other applications such as transporting supplies to the resort. The railway is a key feature of the resort idea. It is hoped that the resort will form the “central” train station on the island. There are some natural attractions around the island near the existing track, and ACME thinks that building “railway stations” near these attractions and allowing guests to ride on a train to and from the attractions will be an excellent idea. ACME wants to build “Ultimate Paradise” on the island including a five-star resort and some recreational attractions to ensure that the guests enjoy their stay. At this stage, the resort will be aimed at all ages, so there will need to be entertainment for adults, teenagers and children alike. The current thinking is that the resort will have a nine-hole golf course, some gym and tennis facilities, and swimming pools. ACME also wants to exploit the natural beauty of the island with attractions such as nature walks. The owner of ACME is also a keen sporting angler and wants to run a commercial fishing adventure enterprise from the resort. In terms of numbers, ACME wants the resort to be capable of handling 150 guests at a time and expects approximately 50 guests to be in transit (arriving or departing) on any one day. The island will only be open to guests staying at the resort. ACME have not developed their requirements further but expect to do so during Conceptual Design.

SYSTEMS ENGINEERING PRACTICE DESIGN EXERCISE

BACKGROUND AND NEED

Bogon Rugby Football Club

Although the Bogon Rugby Football Club (home to the mighty “Moths”) has a fine tradition of fearsome activities both on and off the field, the Club Committee wants to address its current financial situation by moving the club forward into the new millennium with a significant face-lift and a number of measures designed to make the ground a better place to play and watch rugby as well as ensure the future viability of the club. The current club ground at Moth Park is very spacious but has limited facilities as illustrated in the following figure.

200m 130m 60m

200m

Rugbypitch

Footpath

1-m high pipeboundary fence

60m

50m

(Not to scale)

Dirt car park

Refreshment tent& BBQ area

Road

StandsToilets

Cou

ncil

car

park

The Club’s plan calls for the ground to be enclosed so that spectators are required to pay to enter. The current fence therefore requires replacement with a much higher fence that does not allow the game to be viewed from outside the ground. Inside the ground the Club would like the following facilities:

• Change facilities for two sides (home and visitors) and two referees including showers and toilets. Each of the team changing facilities should be able to accommodate up to 35 players.

• Public toilets.

• Bar area where patrons can buy alcohol and see the game.

• Refreshment stand including BBQ area.

• Storage facilities for equipment (sideline posts, goal-post pads, scrum machine etc).

• Viewing stands.

• Club house facilities for after-match activities including drinking and eating (bar snacks only).

• Club offices for manager and administrator.

• Sealed car parking inside the ground for up to 10 cars. (Spectators park with the approval of the local council outside the ground on a large empty lot.)

Current finances are a little strained and the Committee is not sure that it can raise the capital for the whole project (it can probably raise only about $100,000 per year). It would eventually like to include all facilities, but recognises that it may need to phase the project. The requirements listed above are listed in priority order of attainment.

\

To register: https://www.unsw.adfa.edu.au/study/professional-education-courses/programs

Professional Education Courses 2020

School of Engineering and Information Technology Capability Management

Capability Life Cycle (CLC) Management:

5-7 February

23-25 March

28-30 September

CLC Project Artefacts:

28-29 May

28-30 October

CLC Program Artefacts:

26-27 October

Introduction to Systems Engineering (Canberra):

16-18 March; 21-23 September

Systems Engineering Practice (Canberra):

16-20 March; 21-25 September

Introduction to Systems Engineering (Melbourne):

11-13 May

Systems Engineering Practice (Melbourne):

11-15 May

Introduction to Systems Engineering (Adelaide):

2-4 June

Cost Modelling:

30-31 March

12-13 October

Business Case Development:

2-3 April

15-16 October

Project Management

Introduction to Project Management:

11-13 March

14-16 September

Communications

Basic Communications:

18-20 May

Introduction to Electronic Warfare:

25-27 May

Satellite Communications—Overview:

30 November

Satellite Communications—Intermediate:

30 November – 2 December

Satellite Communications—Advanced:

30 November – 4 December

Systems Thinking and Problem Solving

Addressing Complex Problems:

4-6 May

24-26 August

Systems Thinking & Modelling:

4-8 May

24-28 August

Credit into UNSW Canberra Postgraduate Programs for Attendance at

Professional Education Courses

Credit for Professional Practice

UNSW Canberra allows students who have successfully completed approved professional education courses (PEC) to use those courses as credit in eligible postgraduate programs. Students who have successfully completed a minimum of 12 days of approved PEC may use those courses as credit in a course in professional practice—ZEIT8900 Professional Practice—which has two main components:

prior successful completion of 12 days of approved PEC, and

an essay in approved form to explore issues related the professional practice.

What is an approved short course? An approved PEC:

contains at least one day (at least six hours) of course work;

is delivered by a presenter, or presenters, that would be eligible for appointment at an Australian university;

is assessed by at least one hour of examination for every three days of course work; and

is able to be verified by inspection of course and assessment materials.

Are approved short courses offered by any other service provider? A short course offered by a provider other than UNSW Canberra may be considered. An application for approval must contain at least the following:

evidence of the number of hours of course work;

evidence that the presenter(s) would be eligible for appointment at an Australian university (a brief CV of each presenter is required, providing qualifications, background, and experience);

evidence of the assessment for the course (must be at least one hour of examination for three days of course work), including copies of previous tests and marking criteria; and

a copy of the course materials (course notes, and text).

Which UNSW Canberra postgraduate programs are eligible? The following UNSW Canberra postgraduate programs are eligible: Systems Engineering, Project Management, Capability Management, and Engineering Science.

How is credit approved? Students seeking to obtain credit for successful completion of approved PEC are to contact the Director of Postgraduate Studies within the School of Engineering and IT. With approval of the School, students may then manually enrol in ZEIT8900 Professional Practice. Students then engage with Director of Postgraduate Studies to agree a topic for their essay—the essay is submitted by the end of the relevant session and a mark is recorded as satisfactory or unsatisfactory. Credit towards a UNSW Canberra postgraduate program expires after ten years.

Does enrolment in ZEIT8900 require fee payment? Yes, enrolment in ZEIT8900 requires payment of fees for that course.