systems engineering practice · 2020-03-06 · ryan, principles of satellite communications, argos...
Post on 16-Jul-2020
275 Views
Preview:
TRANSCRIPT
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. (m.ryan@adfa.edu.au)
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 Engineering Practice / Professor Mike Ryan 1-2
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
Systems Engineering Practice / Professor Mike Ryan 1-3
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
Systems Engineering Practice / Professor Mike Ryan 1-4
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
Systems Engineering Practice / Professor Mike Ryan 1-5
Functional and Physical Design
• 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.
– ...
Functional and Physical Design
• 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
Systems Engineering Practice / Professor Mike Ryan 1-6
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
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
Systems Revision
Systems Engineering Practice / Professor Mike Ryan 1-7
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
Systems Engineering Practice / Professor Mike Ryan 1-8
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
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
Systems Engineering Practice / Professor Mike Ryan 1-9
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
Systems Engineering Practice / Professor Mike Ryan 1-10
Subsystem, System, and SoS
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
Subsystem, System, and SoS
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 Engineering Practice / Professor Mike Ryan 1-11
Systems / System-of-Systems
System-of-Interest
System System System
System System System
SystemElement
SystemElement
SystemElement
SystemElement
SystemElement
SystemElement
OCD
Systems / System-of-Systems
System-of-Interest
System System System
System System System
SystemElement
SystemElement
SystemElement
SystemElement
SystemElement
SystemElement
OCD
OCD
OCD
OCD
Systems Revision
Systems Engineering Practice / Professor Mike Ryan 1-12
Systems / System-of-Systems
System-of-Interest
System System System
System System System
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
Systems Engineering Practice / Professor Mike Ryan 1-13
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
Systems Engineering Practice / Professor Mike Ryan 1-14
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 Engineering Practice / Professor Mike Ryan 2-1
Systems Acquisition
Generic Project and System Life Cycles
AcquisitionPhase
UtilizationPhase
RetirementPhase
Pre-acquisitionPhase
Systems Acquisition
Systems Engineering Practice / Professor Mike Ryan 2-2
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
Systems Engineering Practice / Professor Mike Ryan 2-3
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
Systems Engineering Practice / Professor Mike Ryan 2-4
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
Systems Engineering Practice / Professor Mike Ryan 2-5
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
Systems Engineering Practice / Professor Mike Ryan 2-6
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 Practice / Professor Mike Ryan 2-7
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
Systems Engineering Practice / Professor Mike Ryan 2-8
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
Systems Engineering Practice / Professor Mike Ryan 2-9
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
Systems Engineering Practice / Professor Mike Ryan 2-10
Top-down Design
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
Subsystem Subsystem
Testproduct
Trainingproduct
Disposalproduct
Developmentproduct
Deploymentproduct
Supportproduct
Productionproduct
Endproduct
System
Operational products Enabling products
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
Systems Engineering Practice / Professor Mike Ryan 2-11
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
Systems Engineering Practice / Professor Mike Ryan 2-12
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
Systems Engineering Practice / Professor Mike Ryan 2-13
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
Systems Engineering Practice / Professor Mike Ryan 2-14
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
Systems Engineering Practice / Professor Mike Ryan 2-15
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 Engineering Practice / Professor Mike Ryan 2-16
Systems Acquisition
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-1
Systems Acquisition in Defence
Pre-FPR
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-2
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
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-3
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?
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-4
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
Gate 0 Gate 1 Gate 2
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-5
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
Gate 0 Gate 1 Gate 2
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
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-6
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)
StakeholderNeeds and
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)
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-7
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)
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-8
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
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-9
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
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-10
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
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-11
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)
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
Augmented/prepared by Acquirer (CASG)
(+)
TEMP
DraftTEMP
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-12
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
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
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-13
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
DID-ENG-DEF-OCD-V2.0
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-14
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
DID-ENG-DEF-OCD-V2.0
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
DID-ENG-DEF-OCD-V2.0
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-15
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
Systems Acquisition in Defence
Systems Engineering Practice / Professor Mike Ryan 3-16
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
Systems Engineering Practice / Professor Mike Ryan 4-1
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
Requirements Analysis
Requirements Analysis
Mission Analysis
Requirements Analysis
Requirements Analysis
Requirements 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 & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-2
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)
Conceptual & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-3
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
Conceptual & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-4
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
Requirements Analysis
RequirementsVerification
FunctionalAnalysis
FunctionalVerification
Synthesis
DesignVerification
Process Output
Conceptual & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-5
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 & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-6
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
C4. Conduct system-level synthesis
C5. Conduct System Design Review (SDR)
C1. Define businessneeds and requirements
Conceptual Design
C3. Define system requirements
To Preliminary Design
C2. Define stakeholderneeds and requirements
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 & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-7
Conceptual Design
C4. Conduct system-level synthesis
C5. Conduct System Design Review (SDR)
C1. Define businessneeds and requirements
Conceptual Design
C3. Define system requirements
To Preliminary Design
C2. Define stakeholderneeds and requirements
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
C4. Conduct system-level synthesis
C5. Conduct System Design Review (SDR)
C1. Define businessneeds and requirements
Conceptual Design
C3. Define system requirements
To Preliminary 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 & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-8
Conceptual Design
C4. Conduct system-level synthesis
C5. Conduct System Design Review (SDR)
C1. Define businessneeds and requirements
Conceptual Design
C3. Define system requirements
To Preliminary Design
C2. Define stakeholderneeds and requirements
RefinedSyRS
C4. Conduct system-level synthesis
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 & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-9
Conceptual Design
C4. Conduct system-level synthesis
C5. Conduct System Design Review (SDR)
C1. Define businessneeds and requirements
Conceptual Design
C3. Define system requirements
Initial FBL
To Preliminary Design
C2. Define stakeholderneeds and requirements
Preliminary Design
Conceptual & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-10
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
Conceptual & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-11
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.
Conceptual & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-12
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
Conceptual & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-13
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
Conceptual & Preliminary Design
Systems Engineering Practice / Professor Mike Ryan 4-14
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.
top related