Transcription
Introduction to the DoDSystem Requirements Analysis GuideSharon VannucciODDR&E/Systems Engineering13th Annual NDIA Systems Engineering ConferenceSan Diego, CA October 28, 201013th Annual NDIA SE ConfOct 2010 Page-1DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08 October 2010 -- SR case number #11-S-0075 applies.
Agenda DoD SE Acquisition Requirements DefinitionChallenges Basis for Establishing a DoD SystemRequirements Analysis (SRA) Guide Application of SRA – An Acquisition Perspective Overview of the SRA Guide Concepts andApproach Summary and Path Forward Questions13th Annual NDIA SE ConfOct 2010 Page-2DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
TranslationCapability to RequirementsMS AMDDDraftCDDICDAoACapabilityRequirement13th Annual NDIA SE ConfOct 2010 Page-3CDD Finalized at MS BTranslation ProcessMDD: Material Development DecisionMS A: Milestone AICD: Initial Capabilities DocumentCDD: Capabilities Definition DocumentAoA: Analysis of AlternativesRFP: Request for ProposalSFR: System Function ReviewTPM: Technical Performance MeasureDT&E: Developmental Test and EvaluationRFPSFRTPMDT&E The ability to achieve a desired effect under specified standards and conditionsthrough combinations of means and ways to perform a set of tasks [CJCSI/M 3010series]. Characteristics that identify the accomplishment levels needed to achieve specificobjectives under a given set of conditions States what the system is supposed to do but not specify how the system is to perform Binding statements in a document or in a contract (CLR 252)DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
DoD SE Acquisition RequirementsDefinition Challenges Good requirements definition practices are core to goodsystems engineering– Current DoD guidance needs to be strengthened: e.g. Better application oflogical architecture approaches– Too often the contractor does the transformation from Capabilities toSystem Requirements incurring latent discovery of issues and risks– Congress is demanding the definition of Technical Parameters and beingverified by DT&E Current Systems Engineering Plan Guidance– No emphasis on CONOPS development or Mission Analysis: A key enablerfor good system requirements analysis– Too much emphasis on requirements management but not enough onrequirements analysis approach NDIA identifies requirements as one of its top issues:– “Requirements are not always well-managed, including the effectivetranslation from capabilities statements into executable requirementsto achieve successful acquisition programs.” (2006 Task Group Report: TopFive Systems Engineering Issues Within DoD and Defense Industry)13th Annual NDIA SE ConfOct 2010 Page-4DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
System Requirements Analysis Guide(New) What is System Requirements Analysis (SRA)?– Structured approach to translating the user’s need into a technicaldefinition of the system Why renewed emphasis in DoD SystemRequirements Analysis?– Establish rigorous approach to translating user capabilities totechnical requirements (System Requirements Document)– Expose as many risks and issues as possible to a preferred systemconcept prior to release the RFPWSARA 2009A Critical Value Streamtranslates topart ofleads toleads talPerformanceTest andMeasuresEvaluationWSARA: Weapon Systems Acquisition Reform Act (PL111-23)13th Annual NDIA SE ConfOct 2010 Page-5DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
System Requirements Analysis GuideObjectives:– Provide guidance to Government SEs in planningand executing the development of systemrequirements throughout the acquisition lifecycle– Clarify the technical data expectations thatsupports technical baseline definition through (MSC) Initial Product Baseline– Describe methods and techniques on how to“transform” requirements: CapabilitiesSystem Requirements System RequirementsSubsystems Requirements– Provide insights and references on “how” todevelop a functional and physical architecture tosupport requirements definition and trade studies13th Annual NDIA SE ConfOct 2010 Page-6DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
System Requirements Analysis(Translation of Capabilities to Requirements)13th Annual NDIA SE ConfOct 2010 Page-7DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
System Requirements AnalysisOverview and Key ThoughtsDecision AnalysisProcessSRA Core ProcessesTechnical mentsAnalysisRequirementsManagementRisk re DesignVerificationValidationTechnical DataManagementInterfaceManagementSRA core processes that provide the greatest influence in requirements definition13th Annual NDIA SE ConfOct 2010 Page-8DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
System Requirements AnalysisAn Integrated ApproachInputs13th Annual NDIA SE ConfOct 2010 Page-9System Requirements Analysis Core ProcessesOutputsDISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
Fundamental SRA Concepts - 1(System Context)It is key to work with the stakeholders to get this right.13th Annual NDIA SE ConfOct 2010 Page-10DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
Fundamental Concepts – 2Specification Language“How well” the system must do it“What” the system must doSystem of InterestFunctional InterfaceSystem Boundaryt0 0 secStimulus data SystemFunctiontimet1 X secPerformanceResponse data Consumesor producesResourceConstraint(s)Imposed design limitationExternal System Actor(Human or Physical System )Analog Interface13th Annual NDIA SE ConfOct 2010 Page-11Physical InterfaceDISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
Fundamental Concepts – 3System Partitioning, Decomposition andAllocation, Behavior and System ThreadsSystem of InterestSubsystem 2PerformanceSystemFunctionSubsystem 1ResourceConstraint(s)Performancet0 0 secStimulusSystemFunctionSubsystem 2ResourcePerformanceConstraint(s)timet1 X secSystemFunctionResponseSystemThreadSubsystem ourceConstraint(s) Internal Environments Other Subsystem Physical Interfaces(e.g. mounts, cables and brackets)Conduct designexcursions tounderstand andmitigate risk.Analog Interface13th Annual NDIA SE ConfOct 2010 Page-12Physical InterfaceDISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
Fundamental Concepts – 4Key SRA Analysis Relationships(From Abstract to Concrete)Analysis of Alternatives (AoA) GuidanceIntegrated Architecture DefinitionInitial Capabilities Document (ICD)Initial Capabilities Definition Document (CDD)Parse and UnderstandMission AnalysisMission TimelinesSystemRequirementstranslationFunctional Architecture DefinitionSystem Performance AnalysisallocationPreferredSystem ConceptPhysical Architecture DefinitionExt.SystemVerification and ValidationSystem Modeling and Simulation Requirements Verification Test Requirements DefinitionTrade straints Analysis Design Constraints Reliability and Maintainability Human Systems Integration ESOH Program Protection Logistics Support Manufacturability Producibility etcTechnical DataForPreferred System ConceptDesignTrade-offsandIteration13th Annual NDIA SE ConfOct 2010 Page-13DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
System Requirements AnalysisGuidance ApproachDRAFTSRA Guide will includetask descriptions, figures,templates, usefulreferences supplementedwith examples.DRAFT13th Annual NDIA SE ConfOct 2010 Page-14DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
Summary and Path Forward Summary– Strengthen Government System Requirements Analysis rigor and discipline– Support for PMs and technical planning for early system definition Path Forward– Draft SRA Guide is expected to be available in Fall 2011Draft DoD SRA Guide Table of Contents13th Annual NDIA SE ConfOct 2010 Page-15DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
Questions13th Annual NDIA SE ConfOct 2010 Page-16DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
For Additional InformationSharon VannucciODDR&E/Systems Engineering(703) 695-6364 sharon.vannucci@osd.milStuart BoothSAIC(703) 695-7773 stuart.booth.ctr@osd.mil13th Annual NDIA SE ConfOct 2010 Page-17DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
Systems Engineering:Critical to Program SuccessInnovation, Speed, and Agilityhttp://www.acq.osd.mil/se13th Annual NDIA SE ConfOct 2010 Page-18DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08October 2010 -- SR case number #11-S-0075 applies.
System. Requirements. Document. Request. for . Proposal. System. Function . Review. System Specification Technical . Performance. Measures. Developmental. Test and . Evaluation. SFR. WSARA 2009. WSARA: Weapon Systems Acquisition Reform Act (PL111- 23) A Critical Value Stream. translates to. part of leads to leads to. identifies. verified. by. AoA. DISTRIBUTION STATEMENT A -- Cleared for
