 Welcome to the fifth unit of NASA and Sailor Foundation's Space Systems Engineering online course, Unit 5 Requirements. So let's review the objectives for this unit. First, describe the characteristics of a requirement and the meaning of the word requirement, how it's used. Identify the various types of requirements, their definition and how they differ from one another. Describe the source of requirements and the process of requirements development including system decomposition. Describe requirements traceability and the importance of developing a traceable flow-down of requirements to lower levels of responsibility but higher levels of detail. Recognize that requirements can change during the execution of a project and describe the impact of such change. And describe the process of capturing the change in requirements. Subunit 5.1 Requirements Overview. Although the scoping exercise that you see here that we went through in a previous unit does provide a good overview of how the mission should be developed, we need to define a lower level of detail for the system designers to actually go off and to finish a design and build the system that needs to meet all of the things that you've defined in your scoping exercise earlier and that's the process of capturing requirements. A requirement is a characteristic or a statement that captures the understanding of what's to be done, in some cases how well it should be done and in some other cases under what constraints should it be done. As we said, a requirement is a contractually binding statement. It's a documentation of a problem space that provides definition to a problem and it's a means by which people communicate within the engineering community. Now, earlier we laid out the needs, goals and objectives for the Apollo mission in Unit 4 and now we're going to demonstrate how you can take system engineering tools and go from that high level scoping exercise of needs, goals and objectives down to more detailed requirements that are required to design the system. First in this discussion about requirements, let's talk about different types of requirements. They're not all created equal. So if you look here on the next slide it shows that there are three different types, functional requirements, performance requirements and constraints. So each one of them is going to look a little different and be defined a little bit differently. So let's walk through each one. I'll give you an example. The first type of requirement is a functional requirement. So see your very discrete definition. It defines what an item must do. We're going to use the Apollo example of the VHF radio. The VHF radio is just a way for the crew on board the Apollo capsules to be able to talk either to the ground or to astronauts that were outside during a time when some crew members were inside the capsule, some were outside. And so they had to be able to communicate. So they had a radio, a VHF radio. So you might be familiar with a VHF radio. But there had to be very discrete requirements defined for that radio to be able to make sure you bought the right radio and made it configured to the right configuration to be used. So in the world of functional requirements you see here that there was a requirement that said the command module VHF system. That's the module where the crew is sitting. They have their own radio. It should be capable of two-way communication with the Earth during the time that the Earth is in view and they can communicate down to the Earth. And that shows that it's during the mission and even when they come back and they land on the surface and they're floating around in the water at the end of the mission, they need to be able to communicate with other assets on Earth. So that radio is going to come in handy throughout the mission. And then it also says that they also need to be able to communicate with astronauts outside the command module. If while they're in space one of their crew members needed to go out, they actually did some science experiments where one crew member would leave the capsule and have to float outside and collect some science experiments. Or there was a case in a contingency where some crew members might have to transfer. They've launched from the moon, they're docked to the command module to come home and then they can't physically get through the tunnel inside so they have to go outside. So the command module radio needs to be able to communicate with those crew members outside. So that's another requirement, a functional requirement for how that radio has to operate. And lastly, the command module, the cone capsule that you see in Apollo that takes the crew to the moon and puts them in the lunar orbit needs to have a radio that can communicate with the lunar module, the bug-like module that goes down to the surface with two of the crew members. So they need to be able to stay in voice communication during that trip. So again now when you go to buy the radio you know that you've got these functional requirements. I need to be able to communicate from my capsule down to Earth, my capsule to an astronaut outside, or my capsule to the people in the lunar module. That's a functional requirement. It's a function that I have to be able to perform with this unit that I'm going to build. Another type of requirement on the next page is a performance requirement. So in this case it defines how well an item must perform a function. So not only it needs to perform it, but now there's some caveats, some additional information that says how well must it perform that function. So let's again use the VHF radio for Apollo as an example. And now you see a requirement on the next page that the command module s-span, so this is not the VHF, sorry for the confusion, the s-span radio system. There's a separate radio that's going to send data down to the Earth. So this is not the one that you're going to be talking on. This is a way to get data about like the health of the spacecraft. So is the power system working okay? Is the propulsion system tank working okay? That data from your computers on board has to get down to Earth as well. Not only to be able to, you're not just talking, you're sending down data. So this s-span radio that sends down the data has to be able to transmit data back to Earth at 1.6 kilobits per second. So now you've got a performance requirement because it's saying exactly what that data rate needs to be. So if any of you guys have had dial-up internet in your life, 1.6 kilobits per second is pretty darn low, right? But you know, hey, this is folks going to the moon. So even a small amount of data coming back will be enough for them to evaluate the health of the spacecraft and make sure the mission is going safely. So these performance requirements are saying, okay, when I go out to buy the radio, not only does it need to be able to talk back and forth, but it also needs to be able to send data back to the ground and data in a certain quantity. That's the aspect that makes it a performance requirement. So the last one is a constraint. These could be federal regulatory constraints. It could be all kinds of constraints that this requirement states that says there's some constraint on your mission. And we'll stick with the VHF radio example in this case. And so in this case for the command module VHF radio, the one that you're using to talk, it has to be able to communicate between 250 and 300 megahertz on the spectrum. Now, you know, when you tune into your car radio, you tune into a station, every station has been allocated to a certain company to be able to broadcast. Same exact thing for space flight. So groups like the Federal Communication Commission, right, the FCC, they assign different parts of the spectrum of communication, not only for ground communication, but for space communication. And so the radio for Apollo had to operate within a certain regime as defined by regulatory constraints that were levied upon the system. So you can see how you now have a radio system that you've defined what functions it needs to perform, you've defined what level of performance it needs to give you, and then you've also defined some of the constraints that you have to build the system under. So now when you go off to buy the radio, you've got a lot more information to make that purchase because you've defined these three types of requirements around it. So one thing to keep in mind when you're doing requirements development is that there are three different types of requirements and use them appropriately to kind of define how the system is going to need to be built and operate. So next thing about requirements is, okay, you've got these three different kinds of requirements. Well, for any given system that you're going to build, you may have hundreds or thousands of requirements. That's a lot of requirements. So how do you organize them? How do you make sure that you have enough requirements to build your system? I mean, you know, you don't have too much or too little. So the next thing we're going to talk about is how do you organize the requirements process. And so just like we talked about before in the world of scoping and an earlier unit, we went from needs to goals to objectives, where each level was a little bit more refined, a little bit more detailed, but each one supported the one before it, right? So, you know, you start off with a high-level thought and you keep going down to lower and lower levels of detail, and that's what we're going to do here. So you had a set of objectives in the scoping exercise and now you want to develop a set of requirements that will support meeting those objectives. So now this requirements process has got to be tied back to needs, goals, and objectives. And just like everything about system engineering, you think about system engineering, the life cycle itself is broken down into discrete small steps that are easy to define and accomplish along the way step by step, right? Same thing happens in requirements. You're going to define things in smaller and smaller increments so that you get down to a very refined, very specific set of requirements for each specific part of the system. And then you're going to put all that stuff together to build your final system. And so requirements will flow down from top to bottom and that's what we're going to talk about here. So on the next page you see the hierarchy and we're again going to use the Apollo example of how requirements lay out in that hierarchy. So at the top, well, let's kind of move along the left-hand side of the page first. And so you see some labels and so the top level says mission. Under it is system. Below that is segment, element, subsystem, component, and part. So the idea here is that these are the various levels of requirements that will be defined for the system starting all the way up at the top where the mission is the mission you defined in the scoping exercise. And now you're going to take that and you're going to build requirements at lower and lower and lower levels of detail to get this entirely flushed out so that each manufacturer will now know what are the requirements for my radio? What are the requirements for my power battery? What are the requirements for my propulsion thruster? So that's what you're trying to do is you're trying to break this into smaller and smaller pieces where you can clearly define requirements at the lowest level but remembering that these requirements have to trace backwards. So if I said I bought a certain kind of radio for the Apollo command module and that was defined by very low level component requirements or port requirements I should be able to trace it all the way back up and say it's because it has to fit into this system that will be operated on the way to the moon that will accomplish the objectives that you heard earlier President Kennedy had defined for Apollo. So everything that you do ends up having to flow back to that high level set of needs, goals, and objectives. So that's the intent here. So we're going to kind of walk through and I'll kind of quickly show you along the way how for Apollo at least you could take that high level set of requirements and keep going to lower and lower level. So you have one example for each level to kind of show you how the structure works. So we're going to go through this hierarchy of requirements and we'll start with level zero. So level zero requirements you see an example here on the page perform a human lunar landing by the end of 1970s. So that comes right out of the president's speech and the system you're going to build you want it to be able to meet that requirement. So that's a very high level requirement. Let's go down the next level. So at the next level the segment level or at the system level you see a requirement that says return 80 pounds of lunar rock and soil samples to Earth without contaminating these samples. So you start to think about okay that gives me more information about how to design the system because it's really specifying an amount, it's specifying that I can't contaminate them and so you can see I'm getting down into more detail that'll help me define my system. At level two you go down to the next segment, segment level requirements. It says that for the flight segment, the flight segment shall have a mass of no more than 40,823 kilograms at injection into lunar transfer trajectory. That means when they leave the Earth, head it off to the moon, that's the maximum mass of the vehicle. That's the maximum mass that the rocket can push to get to the moon. So now you've again defined something that when I go off to design the system I have to make sure that that's the maximum mass of the system. Go down a little bit lower level, the level three requirements and you see these are the element requirements. And so one of the elements is a lunar module. So again you can see that the problem is getting smaller and smaller. Now we're down to defining requirements for the lunar module specifically. So on the lunar module it says it shall be capable of 45 hours of operation on the lunar nearside surface to side face in the Earth at any time that the nearside is in sunlight. A week, two weeks of time defines a lunar day followed by two weeks that define a lunar night. So if you're ever on the moon, you're going to go through a period. It's not like a day where it's 24 hours and you have light for a certain portion of time. On the moon it's two weeks of light followed by two weeks of darkness. And when you think of the lunar cycle, when you look up in the sky the moon being lit up and the moon being dark at some phases, that's exactly what we're talking about. So all the Apollo missions were accomplished while the nearside, the side face in the Earth was in sunlight. You didn't want to try to send astronauts to the moon when that side of the moon was in darkness. So the lunar module had to be able to survive on the surface for 45 hours while that side of the moon was in the sun. So again that's really helping me understand for this lunar module how do I have to design it? What's it got to look like? It's got to be able to withstand really high temperatures. It's like over 200 degrees Fahrenheit in the sun. So I really got to design a system that can withstand those kind of temperatures. So go down to the next level, level four, the subsystem requirements. And here it says the lunar module docking system. So now I'm not talking about the whole lunar module. I'm defining requirements just for the docking part. The part where the lunar module is going to have to dock to the command module so the crew can transfer back and forth between the two vehicles. So here it says that the lunar module docking element shall be designed to permit a single crew member to affect an unassisted docking with the command module in lunar orbit. So there are two people coming back from the moon. What if one of them is injured? What if one of them has some kind of medical issue that they can't help in the process? Well, the system should be able to be driven, the lunar module should be able to be driven back up into orbit with just one crew member at the controls. And so that's again a requirement on how you have to build that system. Take it to another level, level five, the component level. And here you're down to, again, we're still on the lunar module, you're now down to just the rendezvous radar. So the docking system that's going to dock the two vehicles together has a lot of requirements. But now we're going to talk about specifically requirements on the rendezvous radar, the radar system that's going to aid them as they go to dock the two modules together. So here it says the lunar module rendezvous radar shall be capable of tracking the command module from a minimum distance of five feet and a maximum distance of 400 nautical miles with an accuracy of plus or minus one percent. So it's saying that, hey, I need a radar system that if I'm inside the command module or the lunar module, I should know how far apart the two vehicles are to plus or minus one percent whether the vehicles are close together up to five feet or even if they're 400 nautical miles away from each other, I need to be able to know with this radar system how far apart they are. That's going to help me in doing my docking. So, again, another set of requirements is getting down to very low level of detail on how this docking radar should work. And the last level, the lowest level of requirements that we're going to define are the parts level, the level six requirements. So at this level, we're talking not only about the rendezvous radar, but now we're talking about the motors inside that radar. And what are the requirements on how those motors need to drive the radar as the two vehicles are moving towards each other? Because, right, they could be coming towards each other maybe at an angle. The radar needs to be able to move back and forth, and so there has to be a motor in there to be able to track and allow it to move to track the two vehicles. And so it says here that the rendezvous radar drive motors shall be able to move the antenna, the radar antenna, across its full range of motion at up to seven degrees per second. So there's some assumption being made about how the relative rate that the two vehicles will be moving with respect to each other that this radar needs to be able to move it up to seven degrees per second. So again, when I go off to buy this radar system, I have to make sure that the motors are capable of tracking with that rate of speed. So you can see we just went from very high level requirements, things like you need to be able to go to the moon before the end of the decade. You need to be able to collect what it was, the 80 pounds or whatever it was of mass and bring it back, right? 80 pounds of lunar rocks and bring it back to Earth. Those are very high level all the way down to the drive motor on the radar. So that's what we're doing here in the system engineering processes. We're taking a very high level system concept and we're breaking it down into smaller and smaller pieces and defining requirements. I used one example. There are again hundreds to thousands of requirements that are at each level of this hierarchy for every one of those components, every one of those subsystems so that you see mentioned on the chart. So that's really the key process here is breaking things down into smaller, more easily defined parts. Then you can go off and procure or build all those parts, put them all together and you should have a system that operates to meet that high level set of needs, goals and objectives. That's the way it should work. Now, one of the things you could probably see is as you break it down into smaller and smaller parts, what happens? You look at this chart, you have all these individual pieces now, you're defining individual requirements, but they have to work together. You're going to put them all together into a system, so they have to operate as one unified system at the end when you put it all together. So what are you going to do? Well, you're going to go through and you're going to look at all the interfaces between them and make sure that you've clearly identified what are called interface requirements that show how each piece is going to have to work with every other piece, right? So at every level, you're going to have interface requirements. We're going to talk about one, so you see it circled here. We're going to talk about the Lunar Module and Command Module, two basic elements that have to be able to dock together at multiple points during the mission. So there has to be the capability for these two to be able to interface at a docking port to allow for the crew to transfer back and forth between the two vehicles. So here you see the requirements. So it says the Lunar Module and Command Service Module, that's LEM and CSM, the Lunar and Command Modules. The structure shall be designed to provide window areas located to allow for rendezvous and docking to be initiated by either one of them, right? Using optical means. So what that says is when I define these two vehicles and I go to build their systems, I need to make sure that I can look out the window in the direction where I'm going to be docking with the other vehicle and see the other vehicle so that as one of my aids for docking, I have a window that is perfectly placed to see this docking happening so that with my eye I can visually tell you whether I'm docking properly. So, you know, if I'm designing the Command Module or if I'm designing the Lunar Module, I may not want to worry about that because I'm designing a standalone element. But I do have to worry about it because in the end my element has to be integrated in with all the other elements to provide a system operational capability. So this is where interface requirements come in handy because they're going to force the designers of both elements to meet some interface and to find, in this case, an optical window that has to be put into the vehicles even though for running the Command Module or running the Lunar Module by itself that set of requirements might not be that relevant but the fact that they have to be interfaced is making it critical that this requirement be defined. So there's another interface requirement that says the Command Module shall be responsible for latching the two together, the Command and Lunar Module, and for ensuring structural continuity and pressurization between the two when they're in a docked configuration. So this defines that at the interface one of them is going to be passive, the Lunar Module, one of them is going to be active, the Command Module, and it's going to initiate the sealing between the two when they dock together to make sure there's a pressurized tunnel that the crew can transfer from one vehicle to the other. So this specifically tells the Command Module designers this interface between the two vehicles it's your responsibility to make sure there's a good seal between the two vehicles. If the Command Module team doesn't have to worry about that side of the interface, they can watch and see what the Command Module side's going to do. Okay, so once you've got all these requirements defined and you've got them all at these different levels you've figured out what all your performance requirements are, your functional requirements, your constraints, you've laid it all out. Now one of the other things that's really critical about requirements is the verification of a requirement. So it's true in system engineering. Everyone always says it's not worth writing a requirement. If you can't verify it before launch, what does verify mean? Well, if I said this radio needs to operate at a certain part of the spectrum, I need to be able to on the ground, turn the radio on, tune it to that frequency, and talk to somebody in another room and say, ah, yeah, that works just the way it was supposed to. I can work at the right frequency. If it says that the vehicle should weigh no more than a certain amount of kilograms or pounds, I should be able to put the vehicle on a scale before I launch it and say, I can verify that I did not build this vehicle heavier than what the requirement said it should be. So for every requirement in that whole structure that we just talked about, you should have an identified way of verifying that the requirement has been met before you launch the vehicle. Some are easier than others. Let's say I have a star tracker, something that's going to look out in the sky at a pattern of stars, and it's going to be able to tell me how my spacecraft is oriented by looking at a star field. Well, how do I test it on the ground to make sure it really works? Well, I might have to create a device that I stick on the end of it that creates, maybe with little pinholes, a fake star pattern, and then I can operate it on the ground and say, yeah, it picked up my fake star pattern and it made the right assessment of where I'm pointed in the sky, if that was the pattern it would see. But it could be very complicated. It might be very, you know, you might have to build a lot of special equipment where hundreds or thousands of requirements has been met by the design and the components that you've actually selected, right? So one of the things that happens is when you're going through to verify your requirements, sometimes you have to build these big complex systems. And what you see on the next chart is probably one of the biggest, most complex. So what you see there is a command and service module from Apollo inside a gigantic chamber, and that chamber is one where it's down at Johnson Space Center where you can suck out most of the air, create a pretty good vacuum and you could raise and lower the temperature to the temperatures you would see in space using cryogenic things like cryogenic nitrogen, liquid nitrogen to cool the inside of the chamber. You can heat the chamber up with very bright lights and heaters and so you can replicate a space environment to see, again, I have all these requirements that say my vehicle must work in a space environment. I need to be able to put this thing in a chamber to work as close as I can simulate in a space environment on Earth. So what you see here is that when you do that you might have to actually write some additional requirements that are going to help you do the verification process. And so right here it says the command module Flight Hardware, the Apollo Flight Hardware shall be designed to withstand five acceptance tests and an acceptance test is where you're going to put it in the chamber and run it through and make sure it can operate at temperature, make sure it can operate in vacuum. So you need to be able to do that on five separate occasions using a specific test profile that will be defined like how hot will it be, how low will the pressure be, all those kinds of things. And then you need to be able to do that it's just here between minus 300 Fahrenheit and plus 270 and it gives you a pressure rating as well for the amount of vacuum. So what you're saying is when I build this system not only should it operate in space I need to make sure it's going to operate on the Earth during its verification testing and the chamber is where I may put it in the chamber, run a test, stop, put it back in the chamber at another time, run a test and so I need to make sure I keep that in mind when I'm designing the vehicle not only does it have to operate in space it has to operate during this process of verification. So as we've been hearing throughout this course about the James Webb Space Telescope I just wanted to bring up that this chamber here that you see at Johnson Space Center is actually going to become a key part of verifying that James Webb Space Telescope will be able to operate in orbit by doing tests right at this facility. But again some of these facilities are very unique and so as you're building your requirements you're also thinking about to verify these requirements what kind of facilities am I going to need and in some cases you may have to go off and ask people if they have a facility that's big enough or can take the temperature down low enough or whatever it is to test your specific mission. Now the last part of the process that you're going to do is refining the requirements you've come up with a verification method for each one how are you going to test it and make sure that it's going to be met. The other thing you want to do is look back you've got this big set of requirements do I have the right requirements and so you see this last chart here it says requirements validation to validate now is to say if I look back at a big perspective have I actually done the job I was supposed to do in defining all the requirements needed to build this system requirements validation is really not the process of checking that you can meet each requirement by saying the verification process validation is really looking back and saying have I put enough requirements into the system that when I go to design and build I am going to be able to get a system that's going to operate the way I expected to so requirements validation is kind of the most important kind of last part of the process so when you build these requirements and you go through and you validate that you've got the right ones something to keep in mind if you went back to the life cycle and you see the life cycle chart is that some of the requirements are going to be required to be done in phase A by the system requirements review so you see system requirements review in phase A usually level 1, 2 and 3 requirements have been completed by then you're going to go through and make sure at that level in phase A you've got the right set of high level requirements so then after system requirements review you'll continue to work into phase B to define level 4, 5 and 6 if necessary requirements all the way down to the component and part level so that needs to be wrapped up by about the time you get to the preliminary design review that you see there in phase B and that's the point where you should really have almost all the requirements defined for your system because as we talked about earlier you don't want to go too far in where you're still defining requirements because the later you define requirements the more expensive it could be to change your design to accommodate those changes now click on the icon to read section 4.2 technical requirements definition of the NASA system engineering handbook