WIXLIB

DOT/FAA/AR-08/32Air Traffic OrganizationNextGen & Operations PlanningOffice of Research andTechnology DevelopmentWashington, DC 20591Requirements EngineeringManagement HandbookJune 2009Final ReportThis document is available to the U.S. public throughthe National Technical Information Service (NTIS),Springfield, Virginia 22161.U.S. Department of TransportationFederal Aviation Administration

NOTICEThis document is disseminated under the sponsorship of the U.S.Department of Transportation in the interest of information exchange. TheUnited States Government assumes no liability for the contents or usethereof. The United States Government does not endorse products ormanufacturers. Trade or manufacturer's names appear herein solelybecause they are considered essential to the objective of this report. Thisdocument does not constitute FAA certification policy. Consult your localFAA aircraft certification office as to its use.This report is available at the Federal Aviation Administration William J.Hughes Technical Center’s Full-Text Technical Reports page:actlibrary.tc.faa.gov in Adobe Acrobat portable document format (PDF).

Technical Report Documentation Page1. Report No.2. Government Accession No.3. Recipient's Catalog No.DOT/FAA/AR-08/324. Title and Subtitle5. Report DateREQUIREMENTS ENGINEERING MANAGEMENT HANDBOOKJune 20096. Performing Organization Code7. Author(s)8. Performing Organization Report No.David L. Lempia and Steven P. Miller9. Performing Organization Name and Address10. Work Unit No. (TRAIS)Rockwell Collins, Inc.400 Collins Road NECedar Rapids, Iowa 5224511. Contract or Grant No.12. Sponsoring Agency Name and Address13. Type of Report and Period CoveredU.S. Department of TransportationFederal Aviation AdministrationAir Traffic OrganizationNextGen & Operations PlanningOffice of Research and Technology DevelopmentWashington, DC 20591Final ReportDTFACT-05-C-0000414. Sponsoring Agency CodeAIR-12015. Supplementary NotesThe Federal Aviation Administration Airport and Aircraft Safety R&D Division COTR was Charles Kilgore.16. AbstractThis Handbook presents a set of recommended practices on how to collect, write, validate, and organize requirements. Itattempts to bring together the best ideas from several approaches, organize them into a coherent whole, and illustrate them withconcrete examples that make their benefits clear.The Handbook is targeted to the domain of real-time, embedded systems and specifically to the avionics industry. It describes aset of recommended practices in which basic concepts can be practiced in isolation, but reinforce each other when practiced as awhole. These practices allow developers to progress from an initial, high-level overview of a system to a detailed description ofits behavioral and performance requirements. Due to the growing importance of software in avionics systems, these practicesemphasize techniques to ease the transition from system to software requirements.Concrete examples are used throughout the Handbook to make the concepts clear, but there are many other formats that could beused to obtain the same objectives. It is expected that most organizations wanting to use these practices will want to modifythem, perhaps significantly, to integrate them with their existing processes and tools.17. Key Words18. Distribution StatementRequirements, Engineering, Avionics, Systems, SoftwareThis document is available to the U.S. public through theNational Technical Information Service (NTIS) Springfield,Virginia 22161.19. Security Classif. (of this report)UnclassifiedForm DOT F 1700.7(8-72)20. Security Classif. (of this page)UnclassifiedReproduction of completed page authorized21. No. of Pages14622. Price

TABLE OF CONTENTSPageEXECUTIVE dRECOMMENDED PRACTICES32.14Develop the System evelop System Overview EarlyProvide System SynopsisIdentify System ContextsUse Context DiagramsDescribe External EntitiesCapture Preliminary System GoalsMaintain System Goal InformationIdentify the System Boundary566777892.2.1 Identify the System Boundary Early2.2.2 Choose Environmental Variables2.2.3 Choose Controlled Variables2.2.4 Choose Monitored Variables2.2.5 Ensure Environmental Variables are Sufficiently Abstract2.2.6 Avoid Presentation Details in Environmental Variables2.2.7 Define All Physical Interfaces10111212121213Develop the Operational Concepts142.3.1Document Sunny Day System Behavior162.3.2Include How the System is Used in its Operating Environment172.3.3Employ the Use Case Goal as its Title182.3.4Trace Each Use Case to System Goals182.3.5Identify Primary Actor, Preconditions, and Postconditions182.3.6Ensure Each Use Case Describes a Dialogue18iii

2.42.52.62.3.7Link Use Case Steps to System Functions192.3.8Consolidate Repeated Actions Into a Single Use Case192.3.9Describe Exceptional Situations as Exception Cases192.3.10 Describe Alternate Ways to Satisfy Postconditions as AlternateCourses192.3.11 Use Names of External Entities or Environmental Variables202.3.12 Avoid Operator Interface Details202.3.13 Update the System Boundary202.3.14 Assemble a Preliminary Set of System Functions21Identify the Environmental Assumptions222.4.1 Define the Type, Range, Precision, and Units2.4.2 Provide Rationale for the Assumptions2.4.3 Organize Assumptions Constraining a Single Entity2.4.4 Organize Assumptions Constraining Several Entities2.4.5 Define a Status Attribute for Each Monitored Variable2.4.6 Summary232424252627Develop the Functional Architecture272.5.1 Organize System Functions Into Related Groups2.5.2 Use Data Flow Diagrams to Depict System Functions2.5.3 Minimize Dependencies Between Functions2.5.4 Define Internal Variables2.5.5 Nest Functions and Data Dependencies for Large Specifications2.5.6 Provide High-Level Requirements That are Really High Level2.5.7 Do Not Incorporate Rationale Into the Requirements28293031313233Revise the Architecture to Meet Implementation Constraints332.6.1Modify the Architecture to Meet Implementation Constraints342.6.2Keep Final System Architecture Close to Ideal FunctionalArchitecture352.6.3Revise the System Overview352.6.4Revise the Operational Concepts39iv

2.72.82.92.6.5Develop Exception Cases392.6.6Link Exception Cases to Use Cases402.6.7Revise the System Boundary402.6.8Document Changes to Environmental Assumptions402.6.9Revise Dependency Diagrams402.6.10 Revise High-Level Requirements42Identify the System Modes422.7.1 Identify Major System Modes2.7.2 Define How System Transitions Between Modes2.7.3 Introduce Modes for Externally Visible Discontinuities444445Develop the Detailed Behavior and Performance .8.82.8.92.8.1047474749494949505051Specify the Behavior of Each Controlled VariableSpecify the Requirement as a Condition and an Assigned ValueEnsure That Detailed Requirements are CompleteEnsure That Detailed Requirements are ConsistentEnsure That Detailed Requirements are not DuplicatedOrganize the RequirementsDefine Acceptable Latency for Each Controlled VariableDefine Acceptable Tolerance for Each Controlled VariableDo Not Define Latency and Tolerance for Internal VariablesAlternative Ways to Specify RequirementsDefine the Software .9.82.9.92.9.102.9.115657575758595960606161Specify the Input VariablesSpecify the Accuracy of Each Input VariableSpecify the Latency of Each Input VariableSpecify IN' for Each Monitored VariableSpecify the Status of Each Monitored VariableFlag Design Decisions as Derived RequirementsSpecify the Output VariablesSpecify the Latency of Each Output VariableSpecify the Accuracy of Each Output VariableSpecify OUT' for Each Controlled VariableConfirm Overall Latency and Accuracyv

2.10Allocate System Requirements to Subsystems632.10.1Identify Subsystem Functions652.10.2Duplicate Overlapping System to Subsystem Functions672.10.3Develop a System Overview for Each Subsystem692.10.4Identify the Subsystem Monitored and Controlled Variables692.10.5Create New Monitored and Controlled Variables692.10.6Specify the Subsystem Operational Concepts702.10.7Identify Subsystem Environmental Assumptions Shared WithParent System70Identify Environmental Assumptions of the New Monitored andControlled Variables70Complete the Subsystem Requirements Specification712.10.82.10.92.112.10.10 Ensure Latencies and Tolerances are Consistent71Provide 1.773737474757575Provide Rationale to Explain why a Requirement ExistsAvoid Specifying Requirements in the RationaleProvide Rationale When the Reason a Requirement is not ObviousProvide Rationale for Environmental AssumptionsProvide Rationale for Values and RangesKeep Rationale Short and RelevantCapture Rationale as Soon as lette Thermostat ExampleB—Flight Control System ExampleC—Flight Guidance System ExampleD—Autopilot Examplevi

LIST OF FIGURESFigure12345678910111213141516PageThe System and its EnvironmentExample Use CaseThermostat Dependency DiagramHigh-Level Requirements for the Thermostat FunctionInitial Isolette Fault TreeRevised Isolette Fault TreeRevised Thermostat Dependency DiagramRegulate Temperature Dependency DiagramMonitor Temperature Dependency DiagramRegulate Temperature Function ModesThe Four-Variable ModelExtended Software RequirementsHigh- and Low-Level Software RequirementsFunctional Decomposition of System 1Decomposition of System 1 Into SubsystemsAllocation of FCS Requirements Into Subsystemsvii10173032363738414244545562656668

LIST OF PageDevelop the System OverviewIdentify the System BoundaryThermostat Monitored and Controlled VariablesDevelop the Operational ConceptsRevised Thermostat Monitored and Controlled VariablesPreliminary Set of Isolette Thermostat FunctionsIdentify the Environmental AssumptionsEnvironmental Assumptions for the Current Temperature Monitored VariableDevelop the Functional ArchitectureRevise the Architecture to Meet Implementation ConstraintsIdentify the System ModesDefinition of Regulator StatusDevelop Detailed Behavior and Performance RequirementsAllowed Heat Source Latency BehaviorTabular Specification of RequirementsDefine the Software RequirementsInput Variable Curr Temp InINPUT Variable Curr Temp Status InIN' Relation for Value of Current Temperature'IN' Relation for Status of Current Temperature'OUTPUT Variable Heat Control OUTOUT' Relation for Heat ControlAllocate System Requirements to SubsystemsProvide 960616372

LIST OF ACRONYMS AND titude Heading SystemAeronautical Radio, IncorporatedAerospace Recommended PracticeConsortium Requirements EngineeringControlled Surface ActuatorsFlight Crew InterfaceFlight Control SystemFlight DirectorFlight GuidanceFlight Guidance SystemFunctional Hazard AssessmentHuman Machine InterfacemillisecondNot ApplicablePrimary Flight DisplayPreliminary System Safety AssessmentRequirements Engineering ManagementRequirements State Machine LanguageRequirements State Machine Language without eventsSoftware Cost ReductionSpecification Toolkit and Requirements Methodologyix/x