1. ISA 320 Advanced Software Acquisition Management

2. Lesson 23 Requirements Management

3. Today we will learn to:
Assess the roles and responsibilities of various stakeholders in the software requirements management process Assess the programmatic impact of shifting requirements from hardware solutions to software solutions Assess the impact of software requirements changes or refinements on cost, schedule, and performance Evaluate the impact of a chosen software development methodology on the software requirement management process
Introduction

4. Contents Requirements Management (RM) Policy and Guidance
RM Community of Practice
References
Team Exercise
Introduction

5. Requirements Management Policy and Guidance
What is meant by Requirements Management (software or hardware)
Through the Requirements Management process, the Systems Engineer tracks requirements changes and maintains traceability of end-user needs to the system performance specification and ultimately the delivered capability.  - DAG
It is recognized that requirements management needs flexibility
Capability requirements are not expected to be static during the product life cycle. As knowledge and circumstances change, consideration of adjustments or changes may be requested by acquisition, budgeting, or requirements officials. – DoDI
There are different models for RM for Information Systems (IT Box)
The purpose of an IS-ICD is focused on facilitating more efficient and timely software development efforts, and is not appropriate for hardware development efforts or capturing capability requirements which span a broad scope of combined hardware, software, and/or DOTmLPF-P efforts. – JCIDS Manual
It is recognized that requirements for services are different from tradition programs
Defining requirements is a challenging but essential prerequisite in achieving desired services acquisition outcomes. This enclosure establishes an [Services Requirements Review Board] SRRB process for developing, analyzing, reviewing, and validating requirements for the acquisition of services, pursuant to section 2330 of Reference (h). [at or above $10 M annual obligations] - DoDI
DEFENSE ACQUISITION GUIDEBOOK Chapter 4 -- Systems Engineering
Requirements Management Process
Programs should maintain a current and approved set of requirements over the entire acquisition life cycle. The Requirements Management process helps ensure delivery of capability that meets intended mission performance to the operational end user.
The end-user needs are usually identified in operational terms at the system level during implementation of the Stakeholder Requirements Definition and Requirements Analysis processes; see DAG section Stakeholder Requirements Definition Process and Requirements Analysis, respectively. Through the Requirements Management process, the Systems Engineer tracks requirements changes and maintains traceability of end-user needs to the system performance specification and ultimately the delivered capability. As the system design evolves to lower levels of detail, the Systems Engineer traces the high-level requirements down to the system elements through the lowest level of the design. Requirements Management provides bottom-up traceability from any derived lower-level requirement up to the applicable source (system-level requirement) from which it originates. This bidirectional traceability is the key to effective management of system requirements. It enables the development of an analytical understanding of any system-wide effects of changes to requirements for a given system element, updating requirements documentation with rationale and impacts for approved changes. At the same time, bi-directional traceability ensures that approved changes do not create any “orphaned” lower-level requirements (i.e., that all bottom-up relationships to applicable system-level requirements remain valid after the change). Bidirectional traceability also ensures that higher-level requirements are properly flowed to lower-level requirements and system element designs so that there are no "childless parent" higher-level requirements (i.e., each high-level requirement is ultimately being addressed by lower-level requirements and system element designs).
Robust Requirements Management, implemented in synchronization with the program’s Configuration Management process (see DAG section Configuration Management Process), can help the program to avoid or mitigate unintended or unanticipated consequences of changes through rigorous documentation of the system performance specification. Thoughtful analysis and management of requirements can help the lay foundation for system affordability.
Activities and Products
The Program Manager should keep leadership and all stakeholders informed of cost, schedule, and performance impacts associated with requirement changes and requirements growth.
The Systems Engineer establishes and maintains a Requirements Traceability Matrix (RTM) that captures all requirements in the system performance specification, their decomposition/derivation and allocation history, and rationale for all entries and changes. The requirements should be:
Traceable to and from the stated user needs
Correctly allocated, with potential effects of proposed changes fully investigated, understood, and communicated to the Program Manager
Feasibly allocated, i.e., lower-level system elements cannot have the same or wider tolerance bands as those of the higher-level system elements into which they are incorporated
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. The RTM provides significant benefits during trade-off analysis activities since it captures the system-wide effects of proposed changes to established requirements.
DAG section Tools and Techniques contains information about SE tools generally employed in the Requirements Management process. There are many commercial software packages specifically designed for the traceability aspect of Requirements Management, from top-level operational requirements down to the lowest-level system elements in the Work Breakdown Structure.
MANUAL FOR THE OPERATION OF THE JOINT CAPABILITIES INTEGRATION
AND DEVELOPMENT SYSTEM (JCIDS)
(6) The “IT Box” model. The IT Box model calls for fewer iterations of
validating capability requirement documents through the JCIDS process by
describing the overall IS program, and delegating validation of detailed followon
requirement and solution oversight to a flag-level organization other than
the JROC or JCB. CDDs and CPDs are generally not required as successor
documents to an IS-ICD, and the delegated oversight authority may prescribe
alternative document formats most appropriate to the follow-on efforts.
Introduction

6. Requirements Management Community of Practice
Topics available on this CoP
Policies & Guidance
Points of Contact
Training Center
List of RM Topics
Requirements-Related Policy, Guidance, and Tools
CJCSI Joint Capabilities Integration and Development System (JCIDS) 
JCIDS Manual
JCIDS Road Show and Update Video Briefing - Dr. Scott Maley, Deputy Chief, Joint Requirements Assessment Division, Joint Staff (J-8) 
Legal Size Graphic of the CapabilityMission Lattice (CML)
JCIDS Primer - revised 22 Feb 2016
IT Box Primer - revised 22 Feb 2016
Briefing - JCIDS Changes - revised 22 Feb 2016
GAO Report - Service Chief Concerns, Requirements & Acquisition, Jun 2015
CJCSI Charter for the Joint Requirements Oversight Council (JROC)
DoDI DoD Plain Language Program
DoDD Rapid Fulfillment of Combatant Commander Urgent Operational Needs
DoDI Interoperability of IT, Including National Security Systems (NSS)
CJCSM A - Joint C2 Requirements Management Process and Procedures
Introduction

7. Other Training Available on RM
Certification Courses:  CLR 101, Introduction to the Joint Capabilities Integration & Development System (JCIDS) (on-line) RQM 110, Core Concepts for Requirements Management (on-line) RQM 310, Advanced Concepts and Skills for Requirements Management (resident course) RQM 403, Requirements Management Executive Overview (resident course) RQM 413, Requirements Executive Overview (REO) (resident course)
Core Plus Courses: CLR 030, Environment, Safety and Occupational Health in JCIDS (on-line) CLR 151, Analysis of Alternatives (on-line) CLR 250, Capabilities-Based Assessment (on-line) CLR 252, Developing Performance Attributes (on-line)
DAU's Requirements Management Department produces on-line training, classroom courses, and 24/7 informal learning assets for the Requirements Management community.   Requirements Management Certification Training (RMCT):   By Congressional Mandate - Section 801 of the National Defense Authorization Act of Fiscal Year 2007 requires the Under Secretary of Defense for Acquisition, Technology and Logistics to establish competency requirements and a training program to certify DoD military and civilian personnel with responsibility for generating requirements for Major Defense Acquisition Programs (MDAPs). 
Introduction

8. References
Requirements Management (for software or hardware systems) is a Systems Engineering function. Leading sources for reference are,
The Guide to the Systems Engineering Body of Knowledge (SEBoK) created by the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) project
BKCASE transitioned to a new governance model with shared stewardship between the Systems Engineering Research Center (SERC), the International Council on Systems Engineering (INCOSE), and the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS)
The Systems Engineering Research Center (SERC), a University-Affiliated Research Center of the US Department of Defense, leverages the research and expertise of faculty, staff, and student researchers from more than 20 collaborating universities throughout the United States.
Introduction

9. ExeTeam 1 rcise
Given the article, Adopting an Agile methodology Requirements – gathering and delivery, read the first four pages and respond to the following.
Evaluate the impact of choosing Agile vs Waterfall software development methodology on the software requirement management process.
In your opinion, is there a point in the software development lifecycle where it would be too late to switch from Waterfall to Agile, and where would that be?
Introduction

10. Team 2
Given the article, Will Software-Defined Networking Doom Hardware Vendors?, read it and respond to the following.
Assess the impact of shifting requirements from hardware solutions to software solutions.
How has this trend affected your organization, if it has? 
Reference document: Applying Requirements Management with Use Cases.
Introduction

11. Team 3
Does the choice of software development methodology, Agile or Waterfall, alter the perception of making changes to requirements?
For context, “Agile recognizes that an implementation project will experience bumps in the road. Agile actually expects it. The development team is prepared for iterative change, and the requirements-gathering process should reflect his reality.” – Adopting an Agile methodology p. 3. 
Introduction

12. Team 4
The paper, Requirements Volatility in Software Development Process says
“Software development is considered to be a dynamic process where demands for changes seem to be inevitable. Therefore the problem is not with requirements volatility, the problem is with inadequate approaches for dealing with them in a way that minimizes and communicates the impact to all stakeholders.”
In section V, a list of causes of requirements volatility are presented, how could your organization minimize the effects of these causes? 
Introduction

13. Team 5
The article Stakeholder Needs and Expectations discusses the metrics that stakeholders need in an Agile software development program.
Assess the recommended stakeholder needs presented against your experience with stakeholders in your organization or program.
Introduction

14. Programs managed as an IT Box may have unique requirements processes
Software requirements management is dependent on the software development life cycle methodology
Software requirements should adhere to the same standards as all requirements
Services programs are recognized as unique from traditional defense programs
Programs managed as an IT Box may have unique requirements processes
Introduction