 Subunit 5.2, requirements basics. In the previous subunit we talked a lot about requirements. Our requirements are defined different categories of requirements and a lot about how you take requirements and you break them down into smaller and smaller units so that you can define for the lowest level the components that you're going to build for the spacecraft what the specific requirements for those are. So now we're going to talk a little bit about some specific definitions that you're going to need along the way. Maybe I kind of brush through it a little quickly the last subunit. So here we're going to kind of go through some of the definitions and make sure you kind of understand some of the terminology. So first thing is when you do that decomposition, when you go from one level to the next level there's a relationship here called parents and children, right? So the higher level being the parent and then when you take that requirement and you specifically decompose it or send it down to the next level. Like we talked about the lunar module, right? You have requirements on the whole lunar module element and then when you break that down into just the requirements for the docking system or then just the requirements for the docking radar all of those requirements need to be tied to the ones above them and there's this parent-child relationship. So this idea that the lunar module itself and the requirements that define the entire thing at that level all kind of flow down to all their children underneath, right? So we'll talk a little bit more. We'll use some examples. I'll give you some idea of how that flow down happens but just for now just kind of keep in mind that these are called parent-child relationships and the key here and you see over on the side is that if at one level you do a bad job of defining your requirements your parents are not defined well your children are probably not going to come out that well. So if you have incomplete or incorrect or ambiguous or conflicting or unverifiable requirements at one level the requirements you then try to build at the next lower level are also probably going to be not that good. So bad parents equals bad children. So something to keep in mind in the world of requirements development. So another thing is that all the requirements need to be traceable. So these parents and children all need to be connected. No orphan requirements allowed, right? So every requirement at every level has to be able to show that in some way it helps you meet a higher level requirement. So this docking system helps me meet a higher level requirement that the lunar module needs to perform. The docking radar helps me meet a higher level requirement that the docking system needs to be able to perform. So all these has to be hierarchically connected in a traceable way. And so we're going to talk a little bit about how that traceability works so how you define that interaction between levels. So when you go from level to level and you want to tie these requirements together and get down to more detail there are three different ways. We're going to talk about the concept of system decomposition and specifically requirements decomposition and we'll talk about the three ways that you can break down requirements into lower levels. One is a flow, one is an allocation, and one is derivation. So let's talk about an example and what each one means. So the first one is a flow down. So I've got this parent requirement and I'm just going to take the same requirement and I'm going to say, you know, the lunar module needs to meet this requirement and so does the docking part of the lunar module. So I'm going to flow it directly down. I'm going to write the same exact requirement at the next level and you say, well, what's the value of doing that? Well, you see, you know, I'm going to give you an example here. If it says that the spacecraft shall be able to operate at a temperature between minus 300 Fahrenheit and plus 300 Fahrenheit well so should the docking part of the spacecraft and so should the docking radar which is mounted on the outside of the spacecraft and so you can see here that you don't really change this requirement you just flow it from one level to the other because if the whole lunar module needs to survive a certain space environment so does every component that you build the lunar module out of and so when I go off to buy the docking radar and when I go off to buy all the other parts of a lunar module I want to know that they all can survive the temperature extremes of space but that's all derived from a higher level parent requirement that said the lunar module itself needs to survive in that specific temperature environment so whether it's an antenna or whether it's any other part the flow down is the same requirement at every level, okay? Another way to break the requirements down from parent to child is called allocation so in some cases a requirement that flows down from one level to the other may change in some aspect and so let's say I had a requirement that said the spacecraft overall should weigh no more than a thousand kilograms let's say my lunar module should be no heavier than a thousand kilograms well I can't flow that down directly to every part of the lunar module because every part can't be a thousand kilograms and so I've got to make some decisions so I might say well gee the docking system can only have a mass of 300 kilograms and the propulsion system can only have a mass of 400 kilograms or whatever it is but then when I break that down all the way to the antenna the part of the docking radar I might be down to that the docking radar could be no more massive than 3 kilograms and that I know that if I took all those components the way I've allocated out that mass and I add all that mass up that the final lunar module is not going to be more than a thousand kilograms and so in this case I've taken a high level parent of a thousand kilograms for the mass of an element in this case the lunar module and I've distributed down all the way to where all the parts have a specific part of that an allocation of that requirement so that their specific requirement is written in a way that when you add it all up the final requirement could be met with an allocation of requirements versus just straight flow down another one is derivation so derivation is a third way to take a parent requirement and break it down into lower level children so when it comes to derivation you might have a requirement let's say that the lunar module needs to be able to accelerate in space so many meters per second so you need to be able to step on the gas and you need to be able to have that lunar module accelerate by so many meters per second well if I wanted to find if rockets are required to make the spacecraft move like that and how much propellant I need to carry on board to do it well I need to take that requirement and turn it into something else based on some mathematical equations I may take the amount of change in velocity this acceleration that I need to perform and I can derive a requirement that says in the end I need to have so many kilograms of propellant in the fuel tank so many equations again that that amount of propellant when run through my propulsion system will give me that acceleration so here the requirement that I levied at the top level for an acceleration through some mathematical equations and analysis I've actually now derived a lower level requirement that says now I have a requirement for how much propellant needs to be on board the spacecraft so you can see three very different ways of taking a parent requirement that you can either flow it directly down in some cases you can allocate part of the requirement to different children and break it up in some way like in the case of mass allocation and then in other cases you might have to go through some complex derivation or analysis to take a high level parent requirement and then from there derive your child requirements but in all cases you should be able to look at those children and say I know whose parents they are because I can look at how they're written and I know that they're helping meet that higher level that direct relationship has to be there requirements are all traceable back up from child, back up in appearance now let's hear about the decomposition of requirements from the perspective of Dr. John Mather and his work on the James Webb Space Telescope when we do what's called flowing down the requirements it means okay we need to have this kind of sensitivity for certain astronomy purposes and what does that mean for engineering we have to have such a size of telescope the perfection has to be so much the pointing has to be so good the stability has to be this after that's figured out then it becomes more hierarchical because you can divide the responsibilities for meeting the requirements into the various teams that have to do it so that's a pretty important job of parsing the requirements and flowing them down to lower levels of responsibility but higher levels of detail so each step of dividing the requirements into pieces makes the system hierarchical but also manageable if you couldn't do that you could never go anywhere because you can't all vote on everything when you've got a team of a thousand people so that's why systems engineering is so completely important to a large project now click on the icon to read a case study on the launching of the VASA, a Swedish gunship from the 1600s the related discussion forum question helps you to answer the questions that the case study poses on page 3 make sure to post your answers to the forum and collaborate with your peers