Requirements Management - Accessibility Description of Image An inverted equilateral triangle with its point resting on top of a rectangular box labelled Technical Management Processes. Resting on top of the triangle is the phrase Systems Engineering Process. Below the label of the rectangular box are the processes Decision Analysis, Technical Planning, Technical Assessment, Requirements Management, Risk Management, Configuration Management, Technical Data Management, and Interface Management. There is a rectangular box around Requirements Management. Resting on top of the Technical Management Processes rectangular box on either side of the inverted triangle are two boxes labelled Technical Processes. The box on the left contains, from top to bottom, Stakeholder Requirements Definition, Requirements Analysis, and Architecture Design. There is a rectangular box around Requirements Analysis and a double arrow connects it to the rectangular box around Requirements Management. The word Decomposition is above and to the right of this box inside of a downward-pointing arrow along the side of the inverted triangle. Inside the inverted triangle along the right side of the arrow are, from top to bottom, Operational Need, Requirements, and Design. The other Technical Processes box to the right of the triangle contains, from bottom to top, Implementation, Integration, Verification, Validation, and Transition. The word Realization is above and to the left of this box inside of an upward-pointing arrow along the side of the inverted triangle. Inside the inverted triangle to the left of the arrow are, from bottom to top, Product, Validated Solution, and Delivered Capability. Outside the inverted triangle to the right of the arrow are, from bottom to top, DT&E, OT&E, and IOC/FOC. Inside the inverted triangle are double-headed arrows between pairs of words, from top to bottom, Operational Need and Delivered Capability, Requirements and Validated Solution, and Design and Product. Exercise (40 min) As a group, review the Concept of Operations & Requirements Document for the Joint Airborne Paper Vehicle (JAPV) Using the provided template: 1. Determine which requirements are key system priority requirements 2. Determine feasibility of student testing the JAPV with given requirements 3. Determine which acquisition pathway your team will use Reminder - Attributes of Good Requirements Correct Clear Measurable - how are you going to verify it? Unambiguous - comfortable chair? Achievable (Feasible) - USS Enterprise? Complete - missing piece? Consistent - Regular sine wave? Traceable Expressed as Need not a Solution Facilitates Modular Design Use Adaptive Acquisition Framework Tool - Accessibility Description of Image The image presented represents the Adaptive Acquisition Framework with the pathway selections listed below. 1. Urgent Capability Acquisition 2. Middle Tier of Acquisition 3. Major Capability Acquisition 4. Software Acquisition 5. Defense Business Systems 6. Acquisition of Services Also presented are the Tenets of the Defense Acquisition System 1. Simplify Acquisition Policy 2. Tailor Acquisition Approaches 3. Empower Program Managers 4. Conduct Data Drive Analysis 5. Actively Manage Risk 6. Emphasize Sustainment A link to the Adaptive Acquisition Framework website is also included. Learning Objectives Given a program requirements document, apply the five Requirements Management processes. Given a program requirements document, analyze for key priority systems requirements. Requirements Management Purpose The purpose of the DoD Requirements Management process is to maintain a current and approved set of requirements over the entire system acquisition life cycle.* Benefits Helps ensure delivery of a capability that meets the intended mission performance, as stipulated by the operational user. Robust Requirements Management, implemented in synchronization with the program's Configuration Management process, can help the program to avoid or mitigate unintended or unanticipated consequences of changes. *Systems Engineering Brainbook Requirements Management Defined Requirements Management is the process of Documenting, Analyzing, Tracing, Prioritizing, and Controlling changes to requirements.* It's a continuous process and is conducted throughout a systems life cycle. Requirements Management - Documenting Requirements should be documented throughout a program from beginning through disposal Requirements in the DoD are documented in the: . JUON/UON Letter Initial Capabilities Document (ICD) Capability Development Document (CDD) Specification Capability Needs Statement (CNS) Other Service/Component Unique requirement documents Requirements should be maintained in a relational database, numbering standards, or other methods that show relationships. There are a number of relational databases on the market that systems engineers can use that include: IBM Rational DOORS ViTech CORE Excel? Requirements Management - Analyzing Examines, evaluates, and translates needs into a set of functional and performance requirements that are the basis for the Functional Analysis and Allocation. Requirements Management - Tracing DoD Requirements Management provides traceability back to user- defined capabilities documented in the user's requirements document A good DoD requirements management system should allow for traceability from the lowest level component in the Weapons System Specification all the way back to the original user requirements document. Requirements Management - Prioritizing One characteristic of effective requirements management is that the requirements are prioritized. Requirements prioritization is often expressed as: Key Performance Parameters (KPP) Key System Attributes (KSA) Additional Performance Attributes (APA) Requirements Management - Controlling The Systems Engineer establishes and maintains a Requirements Traceability Matrix (RTM), which captures all the requirements in the system performance specification, their decomposition/derivation and allocation history and rationale for all entries and changes. All affected stakeholders and decision makers should fully understand the effects of proposed changes to requirements at the system or system element level before they accept any changes for incorporation into the design. Questions Does the given CONOPS and Requirements Document provide enough information that you would be comfortable contracting for the prototype's development? Could you test the prototype? Which acquisition pathway would you recommend for the prototype?