 Subunit 5.3, requirements and configuration management. During the life cycle of a project or a system from its initiation to operations, requirements can change through a number of different circumstances, including a change of priorities. Maybe the stakeholders have changed some of the priorities, high-level priorities. A new understanding of difficulties of an implementation approach, you have decided to go one route in designing the system and running the problems. Newly added or discovered requirements, maybe your early process of requirements development wasn't sufficient, you missed some things. And measured performance, not meeting required performance. So you went off and bought some equipment and when you tried to test it, it didn't actually do what you thought it would do and have to go back and rethink your requirements. Requirements change due to stakeholders, also due to stakeholders designing on new functions. And performance doesn't measure up to expectation. Requirements in the end will end up driving the cost, the design, the schedules, the required skills to build the system, the human skills, the verification plans, and we'll talk more about verification, and the operational procedures. So it's why it's so critical to make sure that before you go too far in your system design, you've clearly defined all the requirements you might need. So let's talk a little bit about how requirements end up driving cost for your development of a mission. So you see on this graphic here that, you know, when you go through, you see the x-axis is the timeline from beginning, pre-phase A all the way through, and then save the end of this timeline of phase F. And then the cost by percentage of the overall cost of the mission or the system development is the y-axis. And so, you know, you can see that early on when you're going through and if you follow the bottom curve, as you're going through and defining requirements, you're not spending a lot of money. You only have a small team. Typically at this point, they're mainly system engineers on the team. And so the actual cost incurred, the bottom graph, is fairly insignificant, right? You're just not at a point where you're getting to the big part where you're building a lot of equipment and bringing on a lot of people. So the cost incurred is very low at this point. But if you see the other curve, the cost committed curve, the higher curve, that's actually saying that, hey, you might be at a point where you're not spending a lot of money, but what you're deciding on, the requirements that you're defining are actually going to make everything else occur after that. You know, it's kind of like you're set in stone a lot of how this mission is going to look and feel. And so if you're making mistakes and requirements, if you're not putting together the right set of requirements, if you're not getting to the right level of detail for the designers to make decisions in your requirements, any errors in your requirements development process are going to come back later as significant when you go to build the system and then incur that cost. And so this graphic really just says that as you're going through those early stages of a mission and defining the requirements, you're really committing the project at that point to the overall cost profile. Even though while you're doing it, you're really not spending a whole lot of money. So it is a critical phase and you'll see that, you know, at NASA, we try to make sure that we put enough resources into the early requirements development to prevent cost from ballooning later in a project by sometimes based on bad requirements development. So what you see on the next chart here is that the cost to fix an error now is the y-axis. And again, the life cycle kind of spread out on the x-axis is that as you go through the life cycle and make decisions on changing requirements, the cost of those changes, the cost of change that we use at NASA, that phrase, becomes more and more significant. So if you're in pre-phase A or phase A and you decide to make some changes to requirements, those could be fairly straightforward and you only got some paper studies and some documentation to change. That's probably not going to be that expensive to make that change. But think about it, if you've gotten all the way to where you're putting the spacecraft together and then it turns out that the gyroscopes or some component like a gyroscope doesn't work the way you expect it and it turns out it's because you didn't put the right set of requirements in place to define how it should operate or how it should interface to the rest of the spacecraft. The cost of going back and making a change at that point may be significant. You may have to redesign a significant part of the spacecraft that you've already purchased. You may have to throw stuff away and buy new equipment. Designers will have to go back and do new drawings before you can make that change. And so what this really shows here is that making requirements changes later and later in the process becomes a more and more expensive exercise. And so you'd like to know that early on you've defined clearly what all your requirements are. The later the problem is discovered, the more costly it's going to be to fix. The requirements on James Webb are managed through classical system techniques. I mean we have a database of the requirements that show their traceability upward and downward. When we have to make a requirements change, we do that via a requirements working group, a group of engineers, specifically systems engineers, but we call in the stakeholders. And when a requirement is going to be made, we make sure all the stakeholders are there, that the data for the consequence and ramifications of that change are documented and assimilated and vetted, we want the engineers to argue amongst themselves before it goes to the next level. The next level is a more formal level, a configuration control board. And it's at that point where if all us engineers believe that this change needs to be made, we present our data formally to a management and say, hey, here's why we're doing the change. Here's what the ramifications of the change are. Here's why you should do it. And hopefully by that time, if we have cost impact, that's presented as well. And these are, I would call, fairly classical techniques. So along the way, the system engineering responsibility and requirements development is to make sure that a complete set of requirements has been captured and to assess the impacts of any changes to those requirements that are proposed. Those changes will be documented in an engineering change request, an ECR if you like acronyms. And this is a means for making the changes to requirements in an organized and well-reviewed manner to make sure that they're done with forethought. You know, you've gone through and you see this next page is a process called the change control board process. And that change control board is made up of many engineers that will come in and anytime someone proposes changing a requirement, those engineers will assess the potential impact. So many times, and this is why system engineers are critical, a change to a requirement for a propulsion system might seem to the propulsion system designer to be the right thing to do to optimize the propulsion system. That propulsion designer may not really recognize the impact that that change might have on the power system team or on the overall mission and its ability to meet its objectives. And so that's why the system engineering team really needs to get involved and go through this organized change control process to make sure that the impact of any proposed requirements change has been assessed, not only the impact to the specific area where the change is being made, but any collateral impacts that might occur in other parts of the system that have to be taken into account. And so this process of controlling under configuration control where there's only one baseline set of requirements and any changes to those requirements need to go through some formal process is a way to ensure that at any decision point where you're going to make a change, you've done all the analysis and done all the studies to make sure that the impact of that change has been thoroughly thought through before it's agreed to. For how requirements changes are made, the life cycle generally goes like this. Someone comes, suggests to systems engineering that they need to change a requirement for whatever reason. And we send that to the requirements working group. Requirements working group is a set of engineers under systems that gets together. They will see the change and assess the change, say, and they will determine, well, what stakeholders need to be involved. We'll go to our DOORS database and say, here's all the children of that change. Here are all the parents of that change. So let's call in the stakeholders who have dogs in this fight, get them in a room and start getting the technical data together and start arguing amongst ourselves whether or not this is a change worth making. Part of that assessment is to determine whether or not it has a cost impact, a cost or schedule impact. If it does, we let management know, hey, we think this change is probably worth pursuing but we're going to need you to direct the contractors involved that they need to get as cost estimates for this or schedule impacts. And when that data is all assembled together, the requirements working group comes together and I generally get involved at this point. They say, hey, we think we should go along with this. At that point, we send the change to a configuration control board which is generally chaired by management and say, hey, this is the change. Here's its consequences, ramifications and we think you should make this. And then the CCB, the change control board decides. And as for the other part of the question was what does NASA direct in this change process, that depends on the level of the requirement. But if it's a level one, level two or level three, the NASA will share the configuration control board and they'll have the deciding vote on it. Okay, let's go ahead and recap the objectives for this unit. And the first one, establishing good requirements is important in defining the problem to be solved and to establish mission success. Requirements are distributed within the system architecture via flow down, allocation and derivation. Requirements are the basis for verification and validation efforts we talked about. The interfaces created from a decomposed system must be defined and managed. The later a problem is discovered, the more costly it'll be to recover from and the more impact it will have on your ability to meet your cost and schedule goals. Congratulations, you've made it to the end of unit five. There are two final assignments before the unit quiz. First, click on the icon to read section 6.2, requirements management and section 6.5, configuration management of the NASA system engineering handbook. Then answer the discussion question form. Once you've completed the quiz, you can continue your research for the Mars Sample Return mission project.