Dissertation Cost Optimization In

Total Page:16

File Type:pdf, Size:1020Kb

Dissertation Cost Optimization In DISSERTATION COST OPTIMIZATION IN REQUIREMENTS MANAGEMENT FOR SPACE SYSTEMS Submitted by Tami E. Katz Department of Systems Engineering In partial fulfillment of the requirements For the Degree of Doctor of Philosophy Colorado State University Fort Collins, Colorado Spring 2021 Doctoral Committee: Advisor: Steve Simske Ron Sega Erika Miller John Macdonald Copyright by Tami E. Katz 2021 All Rights Reserved ABSTRACT COST OPTIMIZATION IN REQUIREMENTS MANAGEMENT FOR SPACE SYSTEMS When producing complex space systems, the transformation of customer needs into a realized system includes the development of product requirements. The ability to generate and manage the requirements can either enable the overall system development or drive significant cost and schedule impacts. Assessing practices in the industry and publications, it is observed that there is a substantial amount of documented approaches to address requirement development and product verification, but only a limited amount of documented approaches for requirements management. A complex system can have tens of thousands of requirements across multiple levels of development which, if not well managed, can lead to hidden costs associated with missed requirements and product rework. With current space system projects being developed at a rapid pace using more cost constrained approaches such as fixed budgets, an investigation into more efficient processes, such as requirements management, can yield methods to enable successful, cost effective system development. To address the optimal approach of managing requirements for complex space systems, this dissertation assesses current practices for requirements management, evaluates various contributing factors towards optimization of project costs associated with this activity, and proposes an optimized requirements management process to utilize during the development of space systems. Four key areas of process control are identified for requirements management optimization on a project, including utilization of a data focused requirements management approach, development (and review) of requirements using a collaborative software application, ensuring the requirement set is a consolidated with an appropriate amount of requirements for the project, and evaluating when to officially levy requirements on the product developers based on requirement maturation stability. Multiple case studies are presented to evaluate if the proposed requirements management process yields improvement over traditional approaches, including a simulation of the current state and proposed ii requirements management approaches. Ultimately, usage of the proposed optimized set of processes is demonstrated to be a cost effective approach when compared against traditional processes that may adversely impact the development of new space systems. iii ACKNOWLEDGEMENTS Research and generation of new material is not a solo activity, and significant appreciation goes to those that helped me produce this dissertation. The support from those that gave of their time and shared their experiences working on projects has been invaluable, and greatly added to the depth of this research. Thank you to Lou Wheatcraft, Katie Trase, Ken Eastman, Raymond Wolfgang, Joel Knapp, Kevin Orr, David Hill, Angie Wise and John Curry. Those that passionately seek to improve the field of requirements in a voluntary capacity have also contributed to this project; thank you to the INCOSE Requirements Working Group co-chairs, Lou, Kevin, Mike Ryan and Rick Zinni for helping me explore better ways to address requirements on a project. Additional appreciation goes to Saulius Pavalkis at Dassault Systèmes for his support during the development of the requirements management model and simulation, his advice and troubleshooting recommendations helped to keep the modeling progress on course. I would like to acknowledge the companies that I have worked for during this effort, Sierra Nevada Corporation and Ball Aerospace, both of which supported my research and enabled me to continue my education while I was employed full time. The support and advice of my colleague, Erik Wilkinson, has significantly enabled my ability to question established methods to seek more optimal ways. I will always be grateful for his support and inspiration to try new things. Significant support was provided by Dr. Steve Simske, my advisor and guide for pursuing this research, thank you for challenging me to push my ideas further. And finally, my love and appreciation to my husband, Mike Katz, and children Janelle and Jason Katz, for supporting my long nights and weekends researching requirements engineering and writing this paper, thank you for your incredible encouragement! iv TABLE OF CONTENTS ABSTRACT .................................................................................................................................................. ii ACKNOWLEDGEMENTS ......................................................................................................................... iv LIST OF TABLES ........................................................................................................................................ x LIST OF FIGURES .................................................................................................................................... xii Chapter 1: INTRODUCTION ................................................................................................................ 1 1.1 The Challenge with Requirements ................................................................................................ 1 1.2 Dissertation Organization ............................................................................................................. 3 Chapter 2: CONCEPT OF REQUIREMENTS ENGINEERING .......................................................... 5 2.1 The Systems Engineering Process and the Project Life Cycle...................................................... 5 2.2 Overview of Requirements Engineering ....................................................................................... 8 2.2.1 Terminology and Authoritative Publications ........................................................................ 8 2.2.2 The Requirements Development Processes ........................................................................ 12 2.2.3 Requirements Development Among Different Organizations ............................................ 20 2.2.4 Concept of Requirements Traceability................................................................................ 22 2.2.5 Results of Poor Requirements Engineering ........................................................................ 26 2.3 Requirements Engineering Conclusions ..................................................................................... 29 Chapter 3: INVESTIGATION INTO REQUIREMENTS MANAGEMENT ...................................... 30 3.1 Current Approaches to Requirements Management ................................................................... 30 3.1.1 Definition of Requirements Management ........................................................................... 30 3.1.2 Requirements Management Process Models ...................................................................... 31 3.1.3 Why Requirements Change on a Project ............................................................................ 46 3.1.4 Requirement Stability Using TBX Management ................................................................ 50 3.1.5 Requirements Management for Product Lines .................................................................... 53 3.1.6 Ensuring Requirements Quality through Requirements Management ................................ 54 3.1.7 Data Attributes for Requirements Management ................................................................. 56 3.1.8 Conclusion on Current Approaches to Requirements Management ................................... 56 3.2 Newer Requirements Management Trends ................................................................................. 57 3.2.1 Trends Based on the INCOSE Requirements Working Group Efforts ............................... 57 3.2.2 Trends Based on Author Published Research Efforts ......................................................... 60 3.2.3 Trends in Various Industries ............................................................................................... 61 v 3.2.4 Requirements Management (RM) Tools ............................................................................. 64 3.2.5 Observations from Requirements Engineering Practitioners .............................................. 80 3.2.6 Requirement Trends Conclusions ....................................................................................... 94 Chapter 4: CHALLENGES ASSOCIATED WITH SPACE SYSTEMS ............................................. 96 4.1 Overview of the Space Industry .................................................................................................. 96 4.1.1 Complexity in Space Systems ............................................................................................. 96 4.1.2 Definition of a Successful Space System Project ............................................................. 103 4.1.3 Space System Cost Calculations as a Function of System Requirements ......................... 105 4.2 Space Project Example 1: MAVEN ........................................................................................
Recommended publications
  • Why Johnny Can't Write Requirements Any Contractor Who Has Tried to Respond to a Set of Requirements Knows the Difficulty of the Task
    Why Johnny Can’t Write Requirements by Ivy Hooks Abstract Program cost overruns and schedule delays are attributed, in large part, to problems associated with requirements. These problems range from incomplete, inconsistent, and incomprehensible requirements to the complexities of the change management process. These problems stem from an inability to write good requirements and a lack of understanding about the importance of requirements. They are compounded by the scope, complexity, and long life cycle of major programs. Education of the people involved and automation and integration of the requirements management process are needed to combat the problem. The Problem with Requirements Requirements problems have been identified as major contributors to program cost overruns and schedule slips. This "problem with requirements" can be attributed to two major factors: 1. The initial requirements were incomplete, inaccurate, and/or misunderstood by the designers/developers. 2. Circumstances changed which resulted in changes to the requirements. There are several reasons why problems exist with requirements: 1. The program total life cycle, including operations, was not well defined at the time that many of the requirements were written. 2. "Johnny can't write requirements" 3. Few people understand the requirements process. 4. Management has not focused sufficient attention on the problem. 5. Changes are required to correct poor assumptions or poorly written requirements or to correct for inconsistencies or mission requirements. 6. Changes are required in response to external factors over which the program has no control. All of the reasons for requirements problems stated above contribute to operations costs and schedules. From an operations perspective, the problem is manifested by the fact that the requirements focus is often on what is to be built without consideration for how it will be operated.
    [Show full text]
  • Biographical Data Sheet
    IVY F. HOOKS BIOGRAPHICAL DATA SHEET NAME: Ivy F. Hooks ORAL HISTORY: 5 MARCH AND 24 MARCH 2009 EDUCATIONAL BACKGROUND: • Bachelor of Science degree in Mathematics, University of Houston, Houston, TX, 1963 • Master of Science degree in Mathematics, University of Houston, Houston, TX, 1965 NASA EXPERIENCE: NASA Manned Spacecraft Center/Lyndon B. Johnson Space Center, Houston, TX (1963–1984) • Aerospace Engineer, Space Vehicle Design Branch, Spacecraft Technology Division, Engineering and Development Directorate (1963) • Aerospace Engineer, Flight Worthiness Branch, Spacecraft Technology Division, Engineering and Development Directorate (1963–1964) • Aerospace Engineer, Mission Effectiveness Section, Mission Feasibility Branch, Advanced Spacecraft Technology Division, Engineering and Development Directorate (1964–1966) • Aerospace Engineer, Analytical Aerodynamics Section, Flight Performance & Dynamics Branch, Advanced Spacecraft Technology Division, Engineering and Development Directorate (1966) • Cost Analysis Group, Planning and Cost Support Office, Advanced Spacecraft Technology Division, Engineering and Development Directorate (1966) • Aerospace Engineer, Analytical Aerodynamics Section, Flight Performance & Dynamics Branch, Advanced Spacecraft Technology Division, Engineering and Development Directorate (1966–1969) • Aerospace Engineer, Applied Flight Dynamics Section, Flight Technology Branch, Engineering Analysis Office, Engineering and Development Directorate (1969–1971) • Assistant Director for Advanced Planning and Design, Engineering
    [Show full text]
  • + 1970 News Releases (7.6 Mb PDF File)
    NEWS R_A_ _0_ 70-1 Sigurd Sjoberg named Director of Flight Operations 1/2/70 70-2 AC Electronics Division contract 1/6/70 . 70-3 Boeing Company contract 1/6/70 70-4 Raytheon Company contract 1/6/70 ?0-5 Astronauts Bean_ Cunn_n_ham_ and Kerw_ groundinss 1/6/70 70-6 Hamilton Standard contract 1/7/70 _f0-',/ Release of Apollo 12 samples to Principal Investigator_ 1/7/70 70-8 Dale D. Myers named Associate Administrator for Manned!Space flight 1/8/70 70-9 Reseheduling of Apollo 13 to April lh 1/8/70 .... _ 'Release of Surveyor III parts for study 1/16/70 70-11 Announcing Itek contract ,. 1/26/70 70-12 'ALSEP 1 Systems Status report _ 1/23/70 (0-13 Panel discussion_ '_Onl{nnntdthe RoleE::_!tr?+ienof Clinicalof qp_Pathology i_ 1/26 Hts. Dr. yon Braun transferred to Headquarters 1/27 Release of water bag to be used on Apollo 13 //_y 70-15 Organizational changes in S_AD 1/28 70-!5!_ U.N. Committee on Peaceful Uses of Outer Space 1/28 ZO-1T Borman's leaving active duty at NASA 1/29 70-18 Accident report on Rainey 1/29 70-17a STC contract release 1/29 '_ ALSEP 1 status report 2/2 NEWS .r_'_A-_v c_ LOG., ,,I 70-20 Extension of %ia contract at White Sands - Extension of fuel cell operatinE life (by 70-21 Allis-Chalmers) i 70-22 ! Award of S_rvlce Teeb_olo_r eor_or_+.qn_ _ _7_h_ 2/6 70-23 iRelease of study to prepare space environments 2/10 ALSEP Systems status report _ 2fl0 70-24 Apollo 12 lunar sample distribution _ _//_ 70-25 ;Announcement of establishment of Space Shuttle Program 0fc.
    [Show full text]
  • Scope – Magic by Ivy Hooks and Lou Wheatcraft
    Compliance Automation, Inc. http://www.complianceautomation.com/ Scope – Magic By Ivy Hooks and Lou Wheatcraft This paper was written as a result of a presentation to the Alamo Chapter of the Project Management Institute (PMI) by Ivy Hooks of Compliance Automation, Inc. Portions of this paper are excerpts from “Guide for Managing and Writing Requirements”, Ivy Hooks, 1994 and from “Customer-Centered Products: Creating Successful Products Through Smart Requirements Management”, Ivy Hooks and Kristin Farry, 2000. Abstract: A key challenge for project managers is to deliver a quality product to the customer on time, on budget, and meeting or exceeding the customer’s expectations. Only too often, project managers are not able to achieve all of these things for their projects. Why is success so hard to achieve? A major contributor to project failure is the failure to spend the time at the beginning of the project to clearly define the project scope and define the product requirements before beginning product development. Meeting or exceeding stakeholder needs and expectations involves balancing competing demands: scope, time, cost, quality, and stakeholders with differing needs and expectations. This paper covers common scope issues, the benefits of clearly defining scope, and introduces five key tools and techniques you can use to define your project’s scope. Project Scope Management The Project Management Institute (PMI) Project Management Book of Knowledge, defines product scope as “the features and functions that are to be included in
    [Show full text]
  • Table of Contents
    CONTENTS Page PART i SESSION 1: INTEGRATED AVIONICS Cochairmen: H. E. Smith, Johnson Space Center W. C. Bradford, Marshall Space Flight Center J. A. Anderson, Kennedy Space Center EVOLUTION OF SHUTTLE AVIONICS REDUNDANCY MANAGEMENT/FAULT TOLERANCE ...... Jack C. Boykin_' Joseph'R_ Thibodeau, and'Henry'E. Schneider SHUTTLE AVIONICS SOFTWARE -- TRIALS, TRIBULATIONS AND SUCCESSES . 19 O. L. Henderson SHUTTLE AVIONICS SOFTWARE DEVELOPMENT -- TRIALS, TRIBULATIONS, AND SUCCESSES: THE BACKUP FLIGHT SYSTEM ............. 30 Edward S. Chevers FLIGHT SOFTWARE FAULT TOLERANCE VIA THE BACKUP FLIGHT SYSTEM 35 Terry D. Humphrey and Charles R. Price SSME DIGITAL CONTROL DESIGN CHARACTERISTICS ............. 38 Walter T. Mitchell and Richard F. Searle _tAN-MACHINE INTERFACE AND CONTROL OF THE SHUTTLE DIGITAL FLIGHT SYSTEM .......................-.. - 47 Richard D. Burghduff and James L. Lewis, Jr. SPACE SHUTTLE MAIN ENGINE HARDWARE SIMULATION ............ 54 H. G. Vick and P. W. Hampton DEVELOPMENT AND IMPLEMENTATION OF THE VERIFICATION PROCESS FOR THE SHUTTLE AVIONICS SYSTEM ................. 64 H. E. Smith, W. B. Fouts, and J. Mesmer GROUND/MAN-MACHINE INTERFACES FOR ORBITER CHECKOUT ......... 76 F. Herb Blackmon INTEGRATION OF GROUND AND ON-BOARD SYSTEM FOR TERMINAL COUNT .... 81 Charles A. Abner and Don H. Townsend INTEGRATED DESIGN CHECKOUT OF SHUTTLE PAYLOAD AVIONICS INTERFACES .................. 87 John F. Muratore'and Kathy K. Whitcomb vii Precedingpageblank Page AUTOMATIONOFCHECKOUTFORTHESHUTTLEOPERATIONSERA 97 Judith A. Anderson and Kenneth O.
    [Show full text]
  • Guy Thibodaux, Max Faget, Paul Purser INTERVIEWERS: Robbie Davis-Floyd and Ken Cox INTERVIEW DATE: Sept
    53 INTERVIEW #2 INTERVIEWEES: Guy Thibodaux, Max Faget, Paul Purser INTERVIEWERS: Robbie Davis-Floyd and Ken Cox INTERVIEW DATE: Sept. 10, 1996 at the home of Guy Thibodaux in Clear Lake, Texas RECAP: Interview #1 was with Guy Thibodaux, the engineer and rocket propulsion scientist responsible for the propulsion work on Mercury and many other space projects, at his home near Johnson Space Center in Houston/Clear Lake, on Sept. 9, 1996. The following day we met again at his home, this time to conduct a joint interview with Thibodaux and his colleagues Maxime Faget, who was instrumental in the design of the Mercury, Apollo, and Gemini spacecrafts and the early shuttle, and is widely considered the father of spacecraft design, and Paul Purser, engineer and manager at Langley Research Center in the Pilotless Aircraft Research Division, which formed the early nucleus of the space program. Brief biographies of these three space pioneers can be found at the beginning of Interview #1. The following taped interview has been edited for clarity, organization, and flow. Both interviewers and all three interviewees have read and edited the interview transcript; their written commentaries are included below in italics or as parenthetical interjections. [Editorial comments from Davis-Floyd and Cox appear in brackets.] For background and context, interspersed throughout the interview text, in italics, are excerpts (sometimes adapted and amplified) from “Annals of Space: Max Faget and Caldwell Johnson,” by Henry S.F. Cooper, The New Yorker, Sept. 2, 1991, pp. 41-69. MAX FAGET: At the very top levels, these days, they don’t know or care what happened.
    [Show full text]
  • Full Bibliography
    Bibliography for T-Minus: The Race to the Moon 1 of 8 The story told in T-Minus is true, and the characters you met in the book are real. But roughly 400,000 men and women worked on the Mercury, Gemini, and Apollo programs, and to show them all would have meant putting more than 3,000 people on each page! So C.C. and Max are based on real NASA engineers Caldwell C. Johnson and Max Faget, but in our story they played not only their own parts but also stood in for many engineers and technical people as well. Similarly, Harrison Storms of North American Aviation took on some of the roles and said some of the things that rightfully belonged to other private contractors. Just like in the United States, many thousands of people worked on the Soviet space program, of course. Sergei Korolev was so pivotal to their program, though, that he almost always spoke for himself in the book. So, here’s what we read and consulted to create T-Minus — Zander, Kevin, and I hope you liked the book enough to read others about the space race. Excellent Overview Andrew Chaikin, A Man on the Moon: The Voyages of the Apollo Astronauts (NY: Penguin, 1994). This book is not presented in alphabetical order like the rest of them because it’s special: It is the basis for the HBO Series “From the Earth to the Moon,” it’s long (but won’t feel long), and is as complete a book as you could ever hope for.
    [Show full text]
  • Nasa Johnson Space Center Oral History Project Edited Oral History Transcript
    NASA JOHNSON SPACE CENTER ORAL HISTORY PROJECT EDITED ORAL HISTORY TRANSCRIPT IVY HOOKS INTERVIEWED BY REBECCA WRIGHT BOERNE, TEXAS – 24 MARCH 2009 WRIGHT: Today is March 24, 2009. This oral history with Ivy Hooks is being conducted for the Johnson Space Center Oral History Project in Boerne, Texas. Rebecca Wright is the interviewer, and she’s assisted by Sandra Johnson. We appreciate you letting us come into your home this afternoon and take your time. This is a continuation of your oral history that we started earlier this month, and I’d just like to see where you want to start today and what topic you would like to begin with. HOOKS: I thought I might want to talk a little bit about involvement with the different programs and how that felt as a person working in that at NASA. I’ll probably repeat some things from last time. But when I came to work, the first job I was given was to try to come up with the lunar lighting, and I talked about that last time, about what the lighting would be like on the Moon. I’m a student; I went and looked things up in the library. There were math models. So that’s how that began. I left that job and went to work in the area where they were doing cost models, and the leaving was because it was not a very pleasant place to work; it was not going well there. It was in the same division, another section. I worked on cost models for a couple years, and I learned a whole lot, and I talked quite a bit about that.
    [Show full text]