1. Requirements Module: Configuration & Change Management Space Systems Engineering, version 1.0
SOURCE INFORMATION:
The material contained in this lecture was developed by Lisa Guerra of NASA’s Exploration Systems Mission Directorate while on assignment in the Department of Aerospace Engineering at the University of Texas at Austin. As part of a course entitled, Space Systems Engineering, the lecture was piloted at UT-Austin in Spring 2008.
The content that follows was also reviewed and edited by Dr. Paul Graf, Adjunct Professor at the University of Colorado at Boulder.

2. Module Purpose: Configuration and Change Management
Define system baselines and when they are updated.
Describe why system baselines are useful.
Define requirements and configuration management and why they are necessary.
Discuss the fact that changes are inevitable.
Describe a typical management process for considering and assessing the impact of requirements and configuration changes.

3. Baselines Periodically Capture the Complete System Representation
A system baseline is a complete system description including the latest requirements, designs, constraints, assumptions, interfaces, resource allocations and team responsibilities at the time the baseline is created.

4. Baselines Help Ensure Everyone is on the Same Page
With large teams working on many different parts of a project simultaneously, it is important to make sure there is a common understanding of what is to be done and that no necessary task is ignored.
Baselines are established at milestone reviews (SDR, PDR, CDR, ORR) and are the common departure point for subsequent design and product maturation.
Baselines also ensure that the entire project matures at an approximately uniform rate.
If one subsystem design is advanced much beyond its peers and it is later discovered that the allocations or interfaces are inappropriate, more rework will have to be done than if the subsystems had advanced at the same rate.
Definitions as discussed in project life cycle module
SDR- System Design Review
PDR-Preliminary Design Review
CDR-Critical Design Review
ORR-Operational Readiness Review

5. System Maturity Advances Over the Project Life Cycle
Feasible
Concepts
Allocated
Baseline
As-Built
Baseline
Functional
Baseline
Product
Baseline
Operational
Baseline

6. Technical Baseline Definitions
Functional Baseline (Phase A)
The functional baseline is the approved documentation describing a system’s functional, performance, and interface requirements and the verifications required to demonstrate achievement of those specified characteristics.
Established at the System Definition Review (SDR).
Allocated Baseline aka the ‘Design-to’ Baseline (Phase B)
The allocated baseline extends the top-level performance requirements of the functional baseline to sufficient detail for initiating manufacturing or coding.
Established at the Preliminary Design Review (PDR).
Product Baseline aka the ‘Build-to’ Baseline (Phase C)
The product baseline describes detailed form, fit, and function characteristics; the selected functional characteristics designated for production acceptance testing; the production acceptance test requirements.
Established at the Critical Design Review (CDR).
‘As-Built’ Baseline (Phase D)
The as-built baseline describes the detailed form, fit, and function of the system as it was built.
Established at the Flight Readiness Review (FRR).
Operational Baseline aka ‘As-Deployed’ Baseline (Phase E)
The as-deployed baseline occurs at the Operational Readiness Review (ORR) . At this point, the design is considered to be functional and ready for flight. All changes will have been incorporated into the final documentation.

7. Evolution of the Technical Baseline
Source: 2007 NASA Systems Engineering Handbook, page 153
Or the NASA Systems Engineering Process for Programs and Projects; JSC 49040; page 4-7; 10/94
A-Specs, B-Specs etc are from Mil-Std 490A; Specification Practices; 10/30/68

8. Baselines Are More Than Just Requirements and Designs
Technical baseline deals with requirements and design.
New focus: Integrated program management synchronizes these baselines:
Requirements
Design
Affordability ($$$)
Schedule
Risk
All 5 baselines need to be linked and tracked over the project life cycle.
Use of tools and processes to ensure that the linkages and their impacts are captured and updated in all major project documents.
This practice enables informed decision making for the future.
Source: Constellation Program Office Management Requirements Document (# CxP 70071)
Integrated Program Management

9. Managing Requirements and the System Configuration is a Necessity
Capturing all the requirements and their traceability can be a mess!
Parent requirements beget child requirements
Problem-space requirements beget solution-space requirements
Functional and performance requirements have lots and lots of peers
Traceability, linkages and rationale must be documented and maintained
So baselined requirements are required for each control gate
Management of it all.
Configuration management keeps track of all of the requirements, and once hardware is built or software coded, keeps track of what has been built and coded.
This is a huge, complex and extremely important bookkeeping job – made easier today by database tools (e.g.,CRADLE or DOORS).

10. Change - The One Constant
9903
Change - The One Constant
Concept & Technology
Development
Preliminary Design & Tech Completion
System Assembly , Int & Test, Launch
Concept
Studies
Final Design & Fabrication
Operations & Sustainment
Organizations
&
People
Changes
Problems
Concepts
Expecta-
tions
User
CONOPS
System
Reqmts.
Validation
Plan
Concept
Verificat’n
Plan
Design-to
Specs
Form, Fit,
& Function
Build-to
Specs
Verificat’n
Procedures
As-built
As-verified
Anomalies
As-
deployed
operated
Artifacts 10

11. Where Do Changes Come From?
Requirements change when:
They are reallocated as the system design matures, since initial allocations are typically suboptimal.
New requirements are added to the system, since initial requirements may not have been complete.
A stakeholder decides that new functions or performance is needed.
Measured performance does not meet requirements. Reallocation or redesign are possible responses to non-compliance in test.
Configurations change when:
What is built is not identical to what is designed. Configuration descriptions strive to be the most accurate possible description of the current system.
Something breaks in test. Reallocation or redesign are possible responses to test failures.

12. Pause and Learn Opportunity
The Cosmic Background Explorer (COBE) satellite was slated to launch on the Space Shuttle in 1989, but the loss of the Challenger on January 28, 1986 changed everything. The COBE team was forced back to the drawing board: it had to find a new way to get COBE into orbit.
Using the COBE case study (COBE_case study.pdf) discuss the impact to a system design based on a single baseline change — a new launch vehicle.

13. Requirements Change Control
Capturing the complete set of requirements and assessing the impacts of considered changes are systems engineering responsibilities.
Top level requirements are captured first, then lower levels as the system design matures.
Top level requirements are typically placed under change control just after the System Requirements Review (SRR).
Lower level requirements are placed under change control after the corresponding subsystem Preliminary Design Review (PDR).
Engineering Change Requests (ECRs) are the means for making changes to requirements, with assessment and review.
Change Control Boards (CCBs) are established to review and assess the impacts of ECRs.

14. Typical Requirement and Configuration Control Flowchart
9903
Typical Requirement and Configuration Control Flowchart
Changes
Enhance-
ments
Problems
Evaluate Engineering Change Proposal
Project Design Review Board
Analyze and Assess Impact
Approve?
Incorporate Change
Yes No
Archive Change
Engineering Change Proposal Preparation
Project Configuration Control Board
Notes:
The point is not that a project needs this exact process; the point is that there needs to be a process for approval based on solid impact assessment.
Many projects have an initial administrative person or group that preprocesses changes to ensure that they are ready for the process.
A best practice is to run all potential changes through the process, including problems, suggested enhancements, and identified changes.
Part of the approval process involves determining effectivity – when the change will be implemented.
Verify Change
Supply Feedback to Originator
Applicable to all baselined artifacts
Disseminate Change
End 14

15. The Later a Change is Proposed the More Costly it is to Implement
For every hour spent in writing requirements- hundreds of hours will be spent in reading requirements- plus
Endless meetings
Countless debates
Continual rewrites
Continual rework
=> $$$$$$
System
Verification
Plans & Procedures
Requirement
Segment
Segment
Requirement
Requirement
Test
Plans
Requirement
Element
Requirement
Test
Proce-
dures
Ops
Proce-
dures
Test
Results

16. Mission Analysis, Like We Usually Have to Do It
Is use approval needed from United Feature Syndicate, Inc?

17. Module Summary: Configuration and Change Management
System baselines capture the complete, current system description.
System baselines are updated periodically at five major milestone reviews - SDR, PDR, CDR, FRR and ORR.
Requirements and configuration changes are inevitable, so a formal process of considering the implications of these changes is used.
It is important to have managed baselines, requirements and configurations so that the entire team is working with the same assumptions of what the current system is and what it must do.
Systems engineering is responsible for creating and updating the system baseline, assessing the implications of considered changes and disseminating the news of any accepted changes.

18. Backup Slides for Requirements — Configuration &CM Module

19. Pause and Learn Opportunity
Discuss James Webb Space Telescope (JWST) Requirements Examples using the following document:
JWST Mission Requirements Document (.pdf)
Section 4.1 Descriptions of types of verification
Section 4.2 Verification Matrix
See Notes to this slide for more detail.
Notes for reviewing the JWST Mission Requirements Document
There is a traceability matrix in appendix B with the parent-child relationships identified.
There is a verification table with the primary methods of verification - test, demonstration, analysis and inspection and the integrated product team (IPT) responsible for verification is identified.
There are a small number of TBDs and TBRs with assignments and resolution plans.
BUT, there are no rationale statements.
There are no performance allocation trees or error budgets for the performance requirements.
There are some implementation specific requirements.

20. Change Control Boards Ensure Coordination of Changes
Level -1 CCB controls the following:
Interface
Level-1, 2, or 3 requirements
Master Schedule
Cost
Safety
Mission Risk
Interchangeability
Level -2 CCB controls the following:
Changes not shown above
Outside controlled baseline
In-scope cost
Prior to formal release (freeze)
Level -3 CCB controls the following:
Changes not affecting another design team
Prototype drawings
Level -1 CCB players:
Project manager
Project scientist
Project System Engineer
Mission Assurance Mgr
Config. Mgmnt. Engineer
Level -2 CCB players:
Design teams and their associated
Project SE
Level -3 CCB players:
Cognizant engineers

21. Blue text indicates changes from last update

22. 9903
Prioritization
List items that are mandatory.
Group them as “musts.”
All other items are “wants” that can be prioritized.
Important “wants” are given a high weighted value.
When candidate concepts are evaluated, if they do not satisfy all the “musts,” they are eliminated.
Be careful about overstating the “musts.” Otherwise, promising candidates may be prematurely eliminated.
Be careful to communicate clearly here A defines requirements as absolute musts. Using this definition “wants” are not requirements, they are “wants”. 22

23. Get the users involved to establish and baseline the priorities.
9903
Prioritizing Wants
Several methods:
High, Medium, Low
Select highs and lows and all else falls into medium
One, Two, Three
Same as high, medium, and low
Relative to a base of ten
Relative importance assigned a number against a scale (0-10), with ten being the highest.
Pair-wise comparison
Each “want” is compared to each other and a decision is made as to which one is more important. When all comparisons have been made a priority stacking results.
Categorize “satisfaction” and “dissatisfaction”
“How pleased will you be when this capability is provided?”
“How upset will you be if we cannot provide this capability?”
Get the users involved to establish and baseline the priorities. 23