Presentation on theme: "Requirements Engineering from a Standards Perspective"— Presentation transcript:
1 Requirements Engineering from a Standards Perspective INCOSE Hampton Roads Area ChapterRequirements Management and Analysis SeminarNovember 4-5, 2008John O. ClarkChief Engineer, CSEPNorthrop Grumman Corporation
2 Copyright Acknowledgement All EIA, IEEE, ANSI, and ISO/IEC copyrighted material has been removed from this version in order to comply with the copyright owner’s requirements. Refer to the figures in the standards.
3 Content Introduction Want is Requirements Management? PurposeSE StandardsIn-Seat Warm-up ExerciseKey TermsWhat is Systems Engineering?What is a Requirement?Want is Requirements Management?What is the Requirements Engineering Process?MIL-STD-499B, EIA/ISIEEEANSI/EIAISO/IEC , IEEE StdISO/IEC TR 19760ISO/IEC , IEEE StdAppendix – AcronymsThis is the order of the presentation. Tell them why we go in this order and how long it takes. Tell them a little something about each part.
4 PurposeIntroduce the systems engineering standards which include the requirements engineering processesEmphasize the requirements engineering processes from a “standards” perspective“Stand on the standards," as opposed to relying solely on other sources such as instructions, procedures, guides, textbooks, education, training, and even experience in performing requirements engineering functionsDevelop an appreciation for the different views of the requirements engineering process based on how each of the standards presents this view, thereby getting a more complete viewShow the relationships between systems requirements engineering and software requirements engineering based on these standardsElaborate more on the purpose of the tutorial. The objectives were covered but now you need to appeal to their “feelings” as opposed to their intellect.The goals of this tutorial are to:1) describe the systems engineering and software engineering standards heritage, processes, and products;2) show the relationships between processes, products, and people based on these standards; and3) encourage and challenge the participants to read, understand, select, tailor, and apply these standards, i.e., "stand on the standards," as opposed to relying solely on other sources such as instructions, procedures, guides, textbooks, education, training, and experience. Individuals may have an understanding of portions of systems and software engineering based on these other sources. Standards, developed by subject matter experts and approved by nationally recognized standards organizations, provide a more complete and common understanding.
5 SE Standards IEEE 1220 EIA 632 EIA/IS 632 ISO/IEC 15288 Sheard and LakeScope and Detail of the SE StandardsLevel of DetailBreadth of ScopeIEEE 1220EIA 632EIA/IS 632ISO/IEC 15288Provided with the permission of Sarah Sheard from Sheard, Sarah A., Software Productivity Consortium (SPC), andLake, Jerome G., Systems Management international (SMi), Systems Engineering Standards and Models Compared, July 1998.As is to be expected, SE standards have a different level of detail and scope.The new international SE standard, ISO/IEC 15288, which does not even recognize the term ”SE”, takes the broadest scope approach, adds first the emphasis on Acquirer-Supplier agreement and then adds all the other enterprise processes that must be in place to develop and support the systems for their entire life cycle. However, is the least level of detail (i.e, is the most abstract), is intended for international commerce between countries, but has been adopted as an IEEE standard..The older time-tested US standards, such as EIA/IS-632, EIA-632, and IEEE 1220, have the most detail and least breadth of scope of the SE standards, as they try to provide information on how to do systems engineering, and mostly confine themselves to engineering (plus some project management). EIA/IS-632 and IEEE 1220 were based on MIL-STD-499B which was never issued by the US DoD in favor of “standards reform” and “industry best practice.” EIA-632 changed radically from EIA/IS These three are preferred by the US DoD. Of these, many in the US DoD still favor EIA/IS-632 because it was based on MIL-STD-499B and retains the DoD flavor. Some in DoD (primarily the Navy) use a combination of EIA/IS-632 and EIA The Air Force Space and Missile Command initially published a draft MIL-STD-499C, but it later was issued as a technical report because the DoD did not accept it. IEEE 1220 is the most detailed, has remained mostly unchanged from its beginning, is used by DoD, was adopted as an ISO/IEC standard, and is being aligned with and the international software standard: ISO/IEC11
6 In-Seat Warm-up Exercise JOCInstructions: Answer the following questions on your own without looking at the materials:What is a requirement?Want is requirements analysis?What is requirements management?What is requirements engineering?What is the requirements engineering process?Time: 5 minutesInstructor NotesAsk students to document their answers to the questions above without looking ahead at the materials.Tell them that throughout this module we will be providing them with the answers.Ask them to see how close they were as we go along.
7 Key TermsJOCCapability: A group of related requirements raised to a higher level of abstraction. Synonyms include function, subject, object, or other term useful for presenting the requirements.Requirement: A condition for acceptance of the system.Functional Requirement: What?Performance Requirement: How well?Configuration Item (CI): Any item designated for Configuration Mgmt.Preliminary Design: High-Level Design, one level below (inside) the CI.Detailed Design: Low-Level Design, lowest level of the CI.Validation: Right system?Verification: System right?Verification Methods: Analysis (including modeling and simulation), Demonstration, Test, and Inspection.Use Case: A scenario-driven functional thread through the system.Decompose: Parse or separate.Derive: Deduce (e.g., if a=b+c then c=a-b, or I’ll know it when I see it).Synthesis: Design. Translate requirements (problems) into solutions.Architecture: Design or structure.
8 What is Systems Engineering? Key Terms and RelationshipsJOCCapabilitiesOperational Requirements Document (ORD)Initial Capabilities Document (ICD)Capabilities Development Document (CDD)Mission Needs Statement (MNS)Operational Concept Document (OCD)System Threat Assessment Report (STAR)RequirementsSystem Requirements Document (SRD)System Specification (SS) (MIL-STD-961E)System/Subsystem Specification (SSS)Software Requirements Specification (SRS)System/Subsystem Design Description (SSDD)System Specification (SS) (MIL-STD-961E)Software Design Description (SDD)FunctionsComponents(SSDD/SS/SDD)Capability: “Verb Noun” Example: Transport personnel safely over land.Requirement: “Noun shall verb.”Example: The car shall stop within 100 feet at 50 mph, weigh less than 3000 lbs, and be green.Functional (what) Performance (how well) Physical, Design, or ConstraintFunction: “Verb Noun,” “Verb-ing,” or “Verb.” Examples: Stop Car, Stopping, or Stop.Component: “Noun.” Example: Brake.Capability: “Verb Noun” Example: Transport personnel safely over land.Requirement: “Noun shall verb.”Example: The car shall stop within 100 feet at 50 mph, weigh less than 3000 lbs, and be green.Functional (what) Performance (how well) Physical, Design, or ConstraintFunction: “Verb Noun,” “Verb-ing,” or “Verb.” Examples: Stop Car, Stopping, or Stop.Capability: “Verb Noun” Example: Transport personnel safely over land.Capability: “Verb Noun” Example: Transport personnel safely over land.Requirement: “Noun shall verb.”Example: The car shall stop within 100 feet at 50 mph, weigh less than 3000 lbs, and be green.Functional (what) Performance (how well) Physical, Design, or Constraint
9 What is a Requirement? (cont) INCOSE SE HDBKFunctional Thread Analysis / Use CasesRequirements Specifications and Test Procedures can be written using Use Cases.Provided with the permission of INCOSE from INCOSE SE Handbook, Version 2a. Copyright 2002, 2004 by INCOSE.
10 What is Requirements Management? Technical Baselines, Documents, and ReviewsJOCBaselinesDocumentsReviewsPerformanceORD / TLRA/OSRD / SS / SSSExternal IRSRequirementsRFunctionalSRD / SS / SSSFSSDD, SRS, HRS,Internal IRSAllocatedPDHDD (Drawings)SDD, DBDD, IDDDevelopmentalCDSoftwareHardwareFCA/VPCAPhysical/ProductA/O – Alternative/OperationalCD – Critical DesignDBDD – Data Base Design DescriptionF – FunctionalFCA – Functional Configuration AuditHDD – Hardware Design DescriptionHRS- Hardware Requirements SpecificationIDD – Interface Design DescriptionIRS – Interface Requirements SpecificationORD – Operational Requirements DocumentPCA – Physical Configuration AuditPD – Preliminary DesignTLR – Top Level RequirementsR – RequirementsSDD – Software Design DescriptionSRD – System Requirements DocumentSS – System SpecificationSSS – System/Subsystem SpecificationSRS – Software Requirements SpecificationSSDD – System/Subsystem Design SpecificationV – Verification
12 What is the Requirements Engineering Process? MIL-STD-499B, EIA/IS Systems EngineeringIEEE IEEE Standard for Application and Management of the Systems Engineering ProcessANSI/EIA Processes for Engineering a SystemISO/IEC , IEEE Std Systems and Software Engineering – System Life Cycle ProcessesISO/IEC , IEEE Std Systems and Software Engineering – Software Life Cycle ProcessesISO/IEC TR Systems Engineering – A guide for the Application of ISO/IEC (System Life Cycle Processes)
13 MIL-STD-499B and EIA/IS-632 (cont) John Clark Amplified VersionJOCSystems AnalysisRequirements Trade Studies and AssessmentsEffectiveness Analysis, etc.Functional Trade Studies andPhysical Design Trade StudiesAssessmentsand AssessmentsEffectiveness Analysis, etc.Effectiveness Analysis, etc.Physical Design & AllocationDefine Subsystems and ComponentsAllocate Functions and Sub functions toSubsystems and ComponentsDefine Subsystem & Component RqmtsDefine Subsystem & Component InterfacesEstablish Allocated BaselineDefine Physical ArchitectureDevelop Physical Flow Block DiagramsEstablish Physical/Product BaselineRequirements AnalysisDefine RequirementsDefine InterfacesDecompose and Derive RequirementsDefine Constraints & ConditionsDefine Requirements ArchitectureEstablish Requirements BaselineFunctional Analysis & AllocationDefine FunctionsAllocate Requirements to FunctionsDefine Functional InterfacesDecompose Functions to Sub functionsAllocate Decomposed and DerivedRequirements to Sub functionsDefine Functional ArchitectureDevelop Functional Flow Block DiagramsEstablish Functional BaselineRequirements ArchitectureFunctional ArchitecturePhysical ArchitectureI/FSysI/FF11F12F21F2F1SysI/FF22C1C2C3Sub2Sub1SysI/FR1I/FR2R11I/FR22R21I/FR22Requirements LoopDesign LoopVerification LoopControlRisk ManagementConfiguration & Data ManagementInterface ManagementPerformance-Based Progress Measurement:- SEMS/IMP & SEDS/IMS- TPMs & MetricsSOW, DeliverablesWBS, SBS, PBSWork & Planning Packages- Technical ReviewsEarned Value
14 Summary Introduction Want is Requirements Management? PurposeSE StandardsIn-Seat Warm-up ExerciseKey TermsWhat is Systems Engineering?What is a Requirement?Want is Requirements Management?What is the Requirements Engineering Process?MIL-STD-499B, EIA/ISIEEEANSI/EIAISO/IEC , IEEE StdISO/IEC TR 19760ISO/IEC , IEEE StdAppendix – AcronymsThis is the order of the presentation. Tell them why we go in this order and how long it takes. Tell them a little something about each part.
15 THE END! For More Information Contact: John O. Clark Northrop Grumman Mission SystemsCommand and Control Systems DivisionWarfare Systems Engineering Department468 Viking DriveVirginia Beach, VA USA(757)
16 Acronyms Acronym Description A Alternative Acq Acquisition ACWP Actual Cost of Work PerformedADArchitectural DesignANSIAmerican National Standards InstituteAoAAnalysis of AlternativesAPAssessment ProcessASRAlternative System ReviewAT&LAnalysis, Technology and LogisticsATMAutomatic Teller MachineBCWPBudgeted Cost of Work PerformedBCWSBudgeted Cost of Work ScheduledCComponentCDCritical DesignConcept DecisionCDDCapability Development DocumentCDRCritical Design ReviewCDRLContract Data Requirements ListCIConfiguration ItemCMConfiguration Management PlanCMMICapability Maturity Model IntegratedCPControl ProcessCPDCapability Production DocumentCSCIComputer Software Configuration ItemCVCost VarianceCWBSContract Work Breakdown StructureDABDefense Acquisition BoardDBDDData Base Design DescriptionDIDData Item DescriptionDisDisposalDMDecision MakingDMPData Management PlanDMUDefense Management UniversityDOD-STDDepartment of Defense StandardDOTMLPFDoctrine, Organization, Training, Material,Leadership, Personnel, FacilitiesDSMCDefense Systems Management CollegeEEMEnterprise Environment ManagementEIAElectronic Industries Association
17 Acronyms (cont) HSIP Human Systems Integration Plan HW Hardware HWCI Hardware Configuration ItemIImplementationI&TPIntegration and Test PlanICDInitial Capabilities DocumentIDDInterface Design SpecificationIECInternational Electrotechnical CommissionIEEEInstitute of Electrical and Electronic EngineersILSPIntegrated Logistics Support PlanIMInformation Management,Investment ManagementIMPIntegrated Master PlanIMSIntegrated Master ScheduleINCOSEInternational Council on Systems EngineeringIntIntegrationIOCInitial Operational CapabilityIOT&EInitial Operational Test and EvaluationIPImplementation ProcessIRSInterface Requirements SpecificationEPVPEnd Products Validation ProcessEVMEarned Value ManagementFFunction, FunctionalFinalFABFinal Allocated BaselineFCAFunctional Configuration AuditFFBFinal Functional BaselineFFBDFunctional Flow Block DiagramFFDFunctional Flow DiagramFOCFull On CapabilityFOSFamily of SystemsFPBFinal Product BaselineFRBFinal Requirements BaselineFRPFull Rate ProductionFWFirmwareHDBKHandbookHDDHardware Design DescriptionHDPHardware Development PlanHSHardware Specification
18 Acronyms (cont) P Preliminary P3I Pre-Planned Product Improvement PA Process AreaPABPreliminary Allocated baselinePAPProduct Assurance PlanPBSProduct Breakdown StructurePCAPhysical Configuration AuditPDPreliminary DesignPDRPreliminary Design ReviewPEOProject Executive OfficerPFBPreliminary Functional BaselinePINPersonal Identification NumberPMPProgram Management PlanPPProject PlanningPPBPreliminary Product BaselinePRBPreliminary Requirements BaselinePROCProcessPWBSProgram Work Breakdown StructureQMQuality ManagementISOInternational Organization for StandardizationISRInterim System ReviewJOCJohn O. ClarkJROCJoint Requirements Oversight CouncilLRIPLimited Rate Initial ProductionMIL-STDMilitary StandardMOManual OperationMSMilestoneMTMaintenanceN2N x NNAVAIRNaval Air Systems CommandNAVSEANaval Sea Systems CommandNSSNational Security SystemsOBSOrganizational Breakdown StructureOCDOperational Concepts DocumentOpOperationORDOperational Requirements DocumentOSDOffice of the Secretary of DefenseOSJTFOpen Systems Joint Task Force
19 Acronyms (cont) SOS System of Systems SOW Statement of Work SPCA System Physical Configuration AuditSPDRSystem Preliminary Design ReviewSRStakeholder RequirementsSRDSystem Requirements DocumentSRRSystem Requirements ReviewSRSSoftware Requirements SpecificationSSSystem SpecificationSoftware SpecificationSSCDRSubsystem Critical Design ReviewSSDDSystem/Subsystem Design DescriptionSSFRSubsystem Functional ReviewSSPDRSubsystem Preliminary Design ReviewSSRSoftware Specification ReviewSSRRSubsystem Requirements ReviewSSSSystem/Subsystem SpecificationSTCRSystem Test Completion ReviewSTRRSystem Test Readiness ReviewRRequirementRARequirements AnalysisRDPRequirements Definition ProcessRESMResource ManagementRM&APReliability, Maintainability and Availability PlanRMPRisk Management PlanSSystemSAPSystems Analysis ProcessSBSSystem Breakdown StructureSCDRSystem Critical Design ReviewSDDSoftware Design DescriptionSDPSoftware Development PlanSolution Definition ProcessSESystems EngineeringSEDSSystems Engineering Detailed ScheduleSEMPSystems Engineering Master PlanSEMSSystems Engineering Master ScheduleSFRSystem Functional ReviewSLCMSystem Life Cycle Management Process
20 Acronyms (cont) TLR Top Level Requirements TP Training Plan Transition to Use ProcessTPMTechnical Performance MeasurementTRTest ReadinessTRMTechnical Review ManualTrnTrainingTSCTheater Surface CombatantsUUpdatedUSDUnder Secretary of DefenseValValidationVerVerificationWBSWork Breakdown StructureSupSupplySVSystem VerificationSchedule VarianceSVPSystem Verification ProcessSVRSystem Verification ReviewSWSoftwareSWCDRSoftware Critical Design ReviewSWFCASoftware Functional Configuration AuditSWFRSoftware Functional ReviewSWPCASoftware Physical Configuration AuditSWPDRSoftware Preliminary Design ReviewSWRRSoftware Requirements ReviewSWTCRSoftware Test Completion ReviewSWTRRSoftware Te3st Readiness ReviewT PlnTest PlanT ProcTest ProceduresT RptTest ReportTCTest CompletionTEMPTest and Evaluation Management Plan