Session 2: Requirements Definition

• Download English-US transcript (PDF)

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or to view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.

PROFESSOR: You have to make some design decisions. And then once you've made those design decisions, then you can actually write your level 2, level 3 requirements and so forth, it's an iterative process. But when you look at the classic v model, you don't really see those iterations. But they actually exist.

So what we typically do at the system requirements review is we review and then agree on the high level requirements, level 0, level 1, maybe level 2 requirement, but not the lower level ones, because you can't, because you typically haven't done the design yet.

The other thing I want to say is a lot of the-- this is really a critical issue. And a lot of the problems we talked about last time in the schedule, cost overruns, really, a lot of these things are traceable back to the requirements. Either the requirements were over ambitious. You can set requirements that were essentially unachievable. Or you missed requirements that actually became clear later on. But they weren't written. So nobody paid attention to them.

A couple of examples. So I have sort of one example of core requirements, and then a good example. So this is a mission that you may have heard about.

A 1998 MCO. So who was born in-- I'm looking at you guys. Justin, right? Justice, when were you born? '94? OK, so you're older than MCO by four years.

So MCO was a very well-known just about not quite 20 years ago, a very well known mission failure that happened. A Mars climate orbiter, it was launched on December 1998. And it had multiple functions study the Martian climate, weather and surface changes. And it was to act as a relay satellite for the Mars polar Lander, which came after it and also failed. Both failed.

And unfortunately MCO burned up. We think contact was lost with a spacecraft after it basically entered the Martian atmosphere. And you know nothing-- there was no more communication. So we don't know for sure. But their best guess is that the spacecraft burned up in the approach to Mars, that the actual altitude at which had entered the Martian atmosphere was about 57 kilometers. And it was supposed to be about 220. So even though the Martian atmosphere is very thin, when you enter at very high velocities, that's not a good thing.

This is the very famous-- you've heard about this-- confusion of units problem, like this mission that one part of the team used SI units, specifically Newton's seconds, this is momentum, right? Force times time, that gives you momentum. So when you burn your engines for x number of seconds the sum of the product of those two is your momentum. And then another part of the team used English units, pounds of force times second. OK, and so that was fundamentally the problem that caused the burn up.

Now if you read the accident report. And I have a link here to the accident report, you will notice that the requirements were actually OK. The requirements were written correctly. So specifically, there was a document called the software interface specification, SIS, that specified everything should be in SI units on the ground segment and on the space segment. But the problem is that this was not checked and implemented.

And so here's a quote from the accident report. Items that the mission assurance manager, which didn't exist for this mission. So the mission Assurance Manager role is to make sure the requirements are actually followed. There was no mission Assurance Manager on the MCO mission. Included ensuring that the AMD file, which is one of the files put out by the propulsion system, met the requirements of the softwares in the interface specification And that did not happen. And so that was sort of the root cause there.

Here's a good example for requirements. This is a little bit older. This is the DC-3. This is an old plane. First flight in December 1935. This was this was really an airplane that kickstarted civil aviation as a commercial service. And so first of all, the DC-3 was based on an earlier evolution of the DC-2. And I first saw this when I worked in St. Louis. There was a little museum at the headquarters. And they had like a, like a nice plaque on the wall with actually a replica of the contract. You know, the original letter that left the DC-3 contract.

And the story is that this-- these requirements-- these are-- this is level 0 requirements, what's written here, was hammered out in a single quote, end quote marathon phone call between Smith and Douglas. So Smith was, at that time, the head of what was today essentially United Airlines. And Douglas, who by the way, is a graduate of this department here at MIT, Donald Douglas, was the head of the Douglas Aircraft Company. And here are the requirements: range about 1,000 miles. So this means that you don't have a trans-continental range, right? If you want transcontinental range in the US, you need about how many miles? Like Boston to San Diego, Seattle to Miami. 3,000? Yeah, reserves. Yeah, 3,000 miles.

So this means that, if you go transcontinental with the DC-3, you've got to refuel twice, basically. But you know, that was OK. Today, we wouldn't-- we probably wouldn't accept it. But that's OK back then. Cruise speed about 150 miles. 20 to 30 passengers, depending on the configuration. Twin engines. And then something that we would say today. That's a fuzzy-- that's a not a well written requirement, because it's fuzzy. But it said, it should be a rugged and economical.

And based on this sort of high level requirements that were pretty clearly defined, the airplane was then designed, built, and very, very successful. And over 10,000 copies of this airplane were built.

So what happened since then is the requirements explosion. This is a chart from a document called the technical multi-disciplinary design optimization white paper. And it's a little dated, but the basic message here is pretty stunning if you think about it. So first, heavier than air flight, 1903, the Wright brothers, right? 1G flight. What is the requirement for 1G flight? Get off the ground. Get off the ground. And stay off the ground for at least a few seconds, right? Not just ballistic. That's the requirement. Get off the ground. Heavier than air flight. Yeah, big success. Big milestone.

Well, pretty clear after not too long, it was well-- we also want to turn. We don't want to just fly straight on the beach and land again, so maneuvering, gust acceleration. There are winds buffeting. You've got to handle those gusts. So that that's important.

And then what were the first airplanes made of? Let's see an EPFL, guys. What's the first airplanes? What materials did they use?

[STATIC]

[INAUDIBLE]

AUDIENCE: Wood.

PROFESSOR: Wood, yeah. What else?

AUDIENCE: Canvas.

PROFESSOR: Canvas.

AUDIENCE: [INAUDIBLE]

PROFESSOR: Exactly. so then very soon after that, maybe in the 20s and 30s, we started using metals, right? Metallic structures. And the big issue there, especially if you're flying close to the ocean and salt water, is corrosion control. Your airplanes can't rust. And so a corrosion control became important. And pressurization, what is that all about?

Higher, faster. So at some point, you need to pressurize the cabin, right? That's a new requirement. The Wright brothers never thought about that. Well, they didn't-- maybe they thought about it. But they certainly didn't have to pressurize their Wright flyer.

So you see you see what's happening is we get greedy. You know, we were excited. We can fly now. But now we want to go higher. We want to stay longer. So we get greedy. And we go to more extreme environments and so forth. And as we do that, it get harvested do and more and more requirements start piling up. And you see a big step here, World War II, right? Handling quality, radar transparency. Radar was invented. So now you want to have airplanes that are not visible on the radar. Fatigue, rough field landing. And then we have another big step here in the 60s and 70s. This was during the Cold War, smart weapons, nuclear, fly by wire, right? Replacing cables with electronic flight controls. And then a lot of the "ilitys" in the last 20 years, reducibility, affordability, portability, et cetera.

So if you actually look at the requirements set for the new generation of airplanes, whether commercial or military, it's overwhelming. I mean, it's thousands and thousands of requirements, because we've gotten greedy. And we've gotten good at it. So we keep adding more requirements. And that's a big issue right now. And we'll talk later in the semester about complexity management. But the key message here is requirements have been growing over time. More and more requirements added as systems grow and in performance and complexity.

So here's some standards. I won't go through those in detail. But people recognize, in the system engineering community, how important it is, these requirements. So in the system engineering handbook, there's two sections, 4.2, which is about technical requirements definition, and then section 6.2, which is about requirements management. So definition means that's the initial definition of the initial requirement. And then management is the process of updating them, adding requirements, modifying them, making sure they're up to date. And there are a couple of appendices.

INCOSE, the International Council of System Engineering has, in the handbook, a whole section. There's even a requirement working group, people who really specialize in this, and then as well in the ISO standard, you have a lot written about requirements. So this is really a big deal.

So the last thing I want to do here in this section is to sort of, at a very high level, communicate to you what requirement really are about. What they are about is, like I said, don't set off in your ship without-- you don't know what port you're sailing to, right? So requirements set goals and constrain the design in the objective space.

So whatever you're designing, you're always going to have two spaces that you're dealing with. The design space, on the one hand, that's the things you can choose as a designer. These are the knobs you can turn, the decisions you can make. And then the objective space, which is the things that, essentially, your customer cares about. I'll give you a quick example here.

So when we use the word shall, which I'll get to in a minute. The English word, shall, means this is essentially a constraint. You must accomplish this. And when you use the word, should, it's more like a goal. It would be nice to do this. But it's not absolutely mandatory. So shall is a hard constraint. Should it is desirable as a goal.

So let me give you this quick example here. So let's say you're designing a house. You're about setting off to design a house. And what would be some requirements for a house. So I wrote four of them here. And I'll map them to the design space and the objective space.

First requirement, the house shall sleep between four and six people. Well, is that in the design space or in the objective space? That's in the objective space, right? Yeah, that's right. So here, we have an axis called occupance, right? So four is the minimum and six is sort of the maximum. So that's the upper bound.

The next one, the total build cost should be less than $550,000. Should be. What is that? Maybe an EPFL.

AUDIENCE: It's a goal.

PROFESSOR: It's a goal. Yup, that's right. And is it in the design space or the objective space?

AUDIENCE: The objective space.

PROFESSOR: That's correct. So I put this as a dashed line, OK, because it's a should. So what I've done here, just by writing these two sentences, these two requirements, is I've essentially carved out a space, right? And I can shape that box. Basically, what these two requirements do is they put a box around in the objective space saying that, whatever house you're going to design, it has to fit within this box.

Then the third one is the house shall have at least at least three bedrooms. What is that? In the design space or objective space? Design space, right? Because defining a bedroom is a design decision, right? And the house should have a fireplace. So you can show the lower bound here, at least three bedrooms. And then the fireplace is a-- it would be nice to have. But you don't absolutely have to have it. So you can sort of draw this-- it's more like a line here, right? Yes, fireplace. But it's a dashed line. And then at least three bedrooms.

So just these four sentences, we've now put a-- we've defined the space that we're going to be designing in. So we have constraints in the design space. And we have constraints in the objective space. And that's fundamentally the role of requirement is to constrain, to give us direction as to what we're going to design.

OK, so let's do our first concept question for today. And that's the following question, do you think there's a fundamental difference in the meaning between the words, requirements, which we've talked about so far, and then the word, specifications, which I haven't mentioned yet. So no, you think they're essentially the same. Yes, there is a difference. Requirements are like the input, and specifications are the output of the design process.

Yes, you think a difference. Specifications include the requirements as a subset. Or you're not sure. So think about this. And then submit your answers. And as far as these URLs are concerned, for the concept questions, I went to all lowercase. Hopefully, that's a little bit easier. So secc3. tiny.cc/secc3. What do you think? Requirements and specifications. The same thing or not?

Who needs more time? Anybody? OK.

OK, so we have nobody thinks they're the same. 62 thirds of you think that requirements are the input, specifications are the output. 9 of you think that requirements are a subset. And then 6% are not sure. So that's good. I agree with that.

So a lot of people use requirements and specifications as the same thing. They're really not. OK, so think of requirements and you haven't actually started to design that. This is your putting constraints in the design space, defining the direction. But we don't actually know what the design will look like. You may have some requirements may say you must use this box, or you must use this sensor, right? And you might actually find some of those in the CanSat. But basically the requirements are the input.

So any-- What are your experiences? When have you heard those terms, requirements or specifications used interchangeably or not interchangeably? Has this come up as an issue for you before? [? Marissa, ?] you're worked at-- you're worked on human spaceflight, right? Space tourism vehicles. So what-- how did you guys do it at Virgin Galactic?

AUDIENCE: Well, I think something that you generally saw was like people will look at sensors. And they would-- there's a specification for a sensor. And they would not necessarily compare the requirements to the specification. So or they would not understand how the two intersected. So I think there was a bit of a misunderstanding of the difference between what the actual requirements were, versus what the specifications were designed to be.

PROFESSOR: The sensors you're talking about would be sensors, I'm assuming, that you would purchase, right? As commercial--

AUDIENCE: Yeah, absolutely. So I think we were buying of the shelf. And so I mean, sometimes the specifications were broader than what we wanted and sometimes they were narrower. But you know, you can do additional testing on it. So there was sometimes a breakdown between understanding really whether the sensor met what we are looking for or it didn't.

PROFESSOR: OK. Good. What about an EPFL. Any experiences? [? Walker, ?] you worked on slip rings, right? Slip rings was one of the big specialties of your company. I'm assuming that you guys had to make that distinction, right? Between requirements and specifications. What are your thoughts at EPFL on this?

GUEST SPEAKER: Well, yes, from outside, we clearly had a separation also on an ether level. But I was wondering here in the class, has anybody seen the difference between specification requirements? Any comments? Maybe some of the PhD students that have been around the block?

AUDIENCE: [INAUDIBLE]

PROFESSOR: Yeah, OK, great. So I found here, I, you know, I wanted to sort of find a real example that everybody can relate to very, very easily. So the answer is there is a distinction. They are quite different. But they're-- got to be careful, because you can mix them up.

So requirements specify what the product or system should-- shall or should do, right? Functions it shall perform, how well it should perform these. Also maybe the degree of autonomy, how automated is the system? So what the operators must do, when the system is operating. And also compatibility with other devices.

And then specifications are about how the system is built and how it actually works. So the form, right? What the materials that are used, the dimensions, schematics, blueprints, the details of the user interface. Those are things-- those are all specifications. So I try to look up a very simple consumer product that we all are familiar with, a microwave oven.

Kenmore Elite Countertop 2.2 cubic foot. You go to Sears website. And what's interesting is they actually do a pretty good job. It's actually pretty consistent with what I'm saying here, except they don't talk about requirements. They call it description. So what's listed on their description. And this is, I'm pretty much quoting here, verbatim.

This microwave is large enough to accommodate the big dishes, right? So the idea is this is sort of family style, right? This is not a small microwave just for a frozen meals. This is-- you should be able to put a big casserole in it. And reheat meals and so forth. So the idea that what are the things you're going to use in the microwave. What's the use case, right? CONOPS. CONOPS for the microwave. You know, family, for kids, both parents are working, busy, you know, not time to spend two hours preparing dinner. Therefore, big dishes, a lot of people. It has to be quick, right? That's a CONOPS. And the requirements, this description, is essentially the requirement.

1,200 watts of power to reheat food quickly. So time is important. And then one touch settings for different food types, rice, pizza, frozen meals. And that, what is that? That's automation, right? Rather than having to guess how long and at what power level to reheat, there's some partial automation built in. That's essentially requirements, very user centric. Do you see that?

And then when you look under specification, it says the following things: stainless steel exterior, right? Again, you don't want it to rust. The dimensions, the weight. There's a general warranty one year. The power cord is included. It's very different. Those are things that describe how it's made, the form of it, and so forth. So make sure you keep those separate.

OK, so let me talk about the NASA requirements process. And then we'll talk about challenges.

So getting back to the system engineering engine. That's sort of the heart of the NASA system engineering process. You remember, this is the-- this happens at every level of decomposition. After stakeholder expectations. The second step is technical requirements definition. And there's some pretty strong language in the handbook that this really has to be done well. So the center directors or their designees shall establish and maintain a process to include activities, requirements, guidelines, documentation for the definition of technical requirements.

So I think I've already said this, but I just want to make it clear again, this is kind of-- I like this cartoon. This is Moses, right? Up on thee-- Moses just got the tablets, right? The stone tablets. They-- the 10 commandments. And one of them is, thou shalt not steal. And God says, out of the clouds, no, they're requirements, not goals, right? So what God is saying is that the 10 commandments are, shall, right? And not should. Even though, I think, some of us don't always succeed at that. But that's basically the idea. Shall is a very hard constraint. And that's what you will be judged against. And should is essentially a desirable goal. But the degree of attainment is somewhat flexible.

Why are we doing this? Why are we spending our time writing technical requirements? It's essentially to transform those stakeholder expectations we talked about last time, transform them into measurable technical requirements. Requirements come in different flavors. And I'll mention those flavors. And we express them in these shall statements.

They also provide a basis for agreement among the stakeholders and developers. So you will often find requirements part of contracts, right? Now it becomes serious, you know when the requirements set actually has legal implications. You're legally signing up to develop a system that will meet these requirements. That's pretty serious stuff.

By writing good technical requirements, you can reduce the development effort, because of less rework. So a lot of rework and iterations and confusion is based on missing or poorly written requirement, right? And writing those early and before the design begins is helpful.

A requirements set is also a basis for cost and schedule estimates. And so some of these missions that overran. Do you remember I showed you this chart last time. We analyzed 40 missions, earth and space science missions. Like 20% of them were responsible for 80% of the overruns. A lot of that had to do with unrealistic goals or expectations and requirements.

And then the next point here is that the requirements provide the basis for verification. In other words, the better, the more crisp, the better written your requirements are, the easier it is to test the system and to check whether these-- whether the system is in compliance with the requirements. And then, eventually, the basis for acceptance. Acceptance is also a big deal, right? It basically means, I accept your design. I take ownership of it. And I say, you, as the developer of the system, have done your job properly. And there's a legal transfer of the assets that happens. So facilitates the transfer of the product to the users.

And then even later, if you're going to do it like a version 2 or a block upgrade, a next generation product, it's much easier to do when you have a clear requirements, because it tells you what the original system or the earlier version was able to do or not do.

Graphically. So this is figure 4.0.1. I briefly talked about this last time. We start, essentially, here at the development. We have mission authority. We do the stakeholder expectations. We talked about that last time. And then here, right away, comes a high level requirement. So that means your level 0, level 1 requirement. And then as you try to get more detailed in the requirements, what do you think happens?

Ideally, you want to write all the requirements upfront, right? That would be great. But you try to do that, you hit a wall. Why is that? What's the issue? Why can't we just write all the requirements and then be done with it in one shot? Yes. Go ahead.

AUDIENCE: Well, your system changes over time. And some of the requirements clash. And you can't achieve all of them simultaneously.

PROFESSOR: Yes. so there's two things you mentioned. So one is the sort of-- and I'll talk. This is known as, requirements volatility, like the requirements are changing as you learn more about the problem. And then the other is you detect conflict between requirements. And you have to clean those up. Those are two very valid issues. But it's not quite what I was going for.

AUDIENCE: There's another one, requirements creep, in which your customer levies these new requirements on you, once you've started the process.

PROFESSOR: Yes, so new requirements get added. Hopefully, you get more budget, too. That doesn't always happen, right? So that's another issue. But it's a little different. Let's see, EPFL, you guys. Why don't we write like all four or five levels of requirements all at once? Why can't we do that, typically? Why do you think?

AUDIENCE: Usually, the other requirements aren't clear. They don't exist yet. Later on in the process, they become clear. And you start to realize the details, which at first, you don't.

PROFESSOR: That's-- I think that's pretty close to what I'm looking for. So the issue is you do your level 0, level 1 requirements. And then sort of as you get to level 2, you can't really write that level 2 requirement until you've made some key design decisions. Are we going to use electric propulsion or are we going to use chemical propulsion? You know, that's a huge decision in space system design. And unless you've made that decision, you can't really write lower level requirements, because the fundamental working principles of chemical and electrical propulsion are quite different.

So that's the key issue is that you can only do the high level requirements in a solution neutral space. And then you hit the wall, because you've got to make some key concept technology selection decision. And that's shown here by this red box called functional and logical composition. I don't like that nomenclature a lot. This should really say, system architecture or concept selection, which we'll get into in the next couple weeks.

Once you've chosen a high level architecture and concept, then you say, OK, we're going to go for ion propulsion. Well, then you can write the requirements for the ion propulsion system, which are we through the find in this yellow box here. So this is your design and product structure, derived an allocated requirements at lower levels. You see that? That's the fundament-- all the things you said, requirements creep requirements conflict. All those things are true. But the fundamental reason why we can't write all the requirements upfront, because, at some point, the lower level requirements depend on design decisions made. That's the fundamental issue.

OK, any questions about that point? Yes?

AUDIENCE: It's not totally about that point. But it's still like-- So requirements versus specification. So if you're like buying a component from a vendor, some piece of hardware, and you want identify like the specific locations where it should attach to things, it's more of like a form as opposed to really-- so does that fall into requirements or is that like a specification?

PROFESSOR: Great point. So there are-- what you're describing is a peculiar type of requirement that we call interface requirements. And it's a perfect segue to this next-- you know, if I could only include like I don't five slides in this lecture, this would be one of them. This basically is what are the different flavors of requirements or types of requirements. And there are six of them here.

So first of all, the functional requirements. I think we've sort of talked about those, right? Define the functions that need to be done to accomplish the mission objectives. There's some examples here around thrust vector control. So basically, the idea here is that you have a thrusting system. And it has or you can actually direct the thrust. And in this case, you should control the thrust. You shall provide thrust control around pitch and your axes.

So this statement is a high level functional statement. And it's written in the actor verb, object form, right? So that's sort of the classic, you know, the classic requirement and the functional requirement. And then we have performance requirements. The performance requirements are, in a sense, qualifiers on the functional requirements. So a performance requirement will specify how well the function should be performed, how fast should it fly, how much thrust. You know, this is where you have to actually put numbers in.

So in this case, this thrust vector controller shall gimbal the engine 9 degrees, right? That's the deflection angle, at least 9 degrees, plus or minus 1 degree, degree. 0.1 degree. That's the performance requirement.

Then we have constraints. OK, yeah?

STUDENT: Isn't the performance department saying that the engine has to gimbal 9 degrees, isn't that kind of pushing toward the specification. Or is that? I mean, I guess, is can also be a requirement. But isn't that?

PROFESSOR: Right, in this case, we have a set, and we're not specifying how those 9 degrees are achieved, you know, whether it's through a gimbal or the actual mechanism or how it's not described here. All that's described is the angular [? range, ?] essentially, that this. And that is a performance requirement. But you'll see, there will be some examples of things that are putting limits on the form, which looks more like a specification.

So then we have constraints. Constraints are things on like weight, mass, power, things like that. So constraints are requirements that cannot be traded off with respect that cost, schedule, or performance. So for example, the prospector controller unit module shall weigh less than 120 pounds. So that's a-- that's not, if you think about it, that is not functional, right? The weight of the thrust vector controller shall not be more than 100-- that is not performance. It's not functional requirement, but it's a constraint on the form, essentially. So this looks more like what we would call a specification constraint.

The fourth one is what [? Marissa ?] brought up. This is an interface requirement. OK, so in this case, our thrust vector controller shall interface with the J-2x The J-2x is a very famous engine. And J-2x is a kind of-- this is sort of, this was written during the constellation days of the constellation program at NASA is the idea of a new generation of the J-2 engine. So the idea is that whatever you do, however you design your thrust vector controller, it must be able to interface with the J-2x engine, according to conditions specified in this interface control document. So this is called an interface requirement.

Then the fifth category are environmental requirements. So the TVC shall use [? Biber ?] acoustic shocks and loads according, again, to some environmental document. And by the way, for the CanSat competition, we have that, right? There's two documents. There's the mission guide. And then there's this environmental testing guide.

So what this essentially says is under what conditions shall the performance, and functional-- the functions and performance that are specified in the first two type of requirements, under what conditions shall that be performed, right? And if anything you think about it, designing whether it's a sensor or anything to operate between 0 degrees Celsius and 30 degrees Celsius or between minus 60 and plus 80, is a huge difference, right? You can write that down. But what that actually means to open up the range of environmental conditions, it has a big, big impact on the design. And so this is a big deal in practice. And then, at least in Space Systems design, you know a lot of these environmental requirements are of course, driven by the space environment or the launch environment. If you're designing airplanes, whether you're flying in a small mountainous country like Switzerland or on the ocean off of an aircraft carrier, those are very different environments. And they're going to influence. You have to specify the operating requirement. The bigger the envelope that you make for the environmental requirements, the more complex the system will be.

Also medical-- anybody working on medical devices here? EPFL. Anybody? Medical devices? So in medical devices, it's the same thing. Is this medical device going to be used in a hospital setting, where everything is kind of clean. You have clean power. The nurses, everybody is very well-trained. That's one thing. Or is his medical device going to be used in the field, you know? In Africa, in India, in a rural area, where people are not, maybe not trained, medically and professionally and so forth. Very different. The function may be the same. But the environmental conditions are very different. You have to really specify those.

And then we have-- the last category is kind of the other. It's sort of a catchall. But it can be very important. So this includes a lot of the human factors, reliability and safety requirements. Those are-- and you know, they're listed here as other. And I think it's really important to say that just because they're listed here doesn't mean they're less important. These are often neglected, unfortunately. And it really can hurt you in the long term. So pay attention to those human factors, reliability, and safety requirements. So six types of requirements.

So let's talk about what makes good or acceptable requirements. And there's a distinction here between a single requirement statement and then sets of a requirements. So first of all, requirements should be written in natural language. They should be complete sentences. And each of the requirement statements should be clear and consistent, meaning that it's not a novel or it's not a poem. But it's clear. It's understandable. It's well-written. It's correct. There's no errors in it. It's feasible. Now that's a really tricky one. That's the first thing here that's really tricky, when you think about it.

Feasible means, what? It means this requirement can be satisfied within the laws of physics and state of the art technologies and other project constraints. So why is that a tricky one?

Go ahead.

AUDIENCE: I was going to ask a question regarding that, in terms of how do you deal with a program where you're working on things or you're trying to actually maybe define the state of the art or figure out what is feasible.

PROFESSOR: Right. so if you're basically designing a product or a project or a system that's a repeat of what's already been done, then you can have pretty good confidence, right, that those poles are feasible. But what if you're doing, let's say the-- I think I mentioned this last time. You're going to Europa. And you're going to drill through the ice. And you're going to explore the ocean under the ice in Europa. It's never been done before. You know, can we actually do this? So this is the tricky thing. How ambitious, how ambitious can the requirements be and you still claim feasibility?

And that's also one of the big reasons why programs get in trouble is when they're actually defining requirements that are not really feasible within-- they're definitely way beyond the state of the art. And within the time frame and budget allocated, you can't get there. And many, many programs that run into this problem are the ones where the technologies that you're going to use are not really ready yet. You know, there-- we'll talk later about technology readiness levels scale. You're not really ready yet to do this, but you're going to try anyway. So that's a tricky one, feasibility.

Flexibility is, you know, don't over specify how things should be done. So don't say how it should be satisfied. Without ambiguity. That means if 10 people read this requirement, they should have the same or very similar interpretation. Singular statement, one actor [? verb ?] object. And then the last point here is verifiability. How are you going to check whether or not this requirement will, in fact, satisfy you.

AUDIENCE: With regard to that, the feasibility again for some of these programs I had large, [? overrun ?] schedule, overruns. I mean, would it be almost better in a sense to have some of the requirements be more shalls, like-- or goal. In other words, you know, if you can do this, go for it. But if you're going to run over 10 years, maybe back off a couple of percent.

PROFESSOR: That's right. And what-- we'll talk about this a little bit. But if you-- all of them are shall statements. They're all hard constraints. The objective space that I showed you may, in fact, have 0 feasible space. So really knowing where, what is a hard constraint, what is a hard requirement, and what is flexible, that's very tricky. And that's why it's important to actually not just accept requirements. You know, if you're going to run a project, every requirement, you want to really understand it. And if you think this requirement is infeasible, you have to negotiate. That's where the upfront negotiation becomes really important. Did we lose our EPFL? OK.

GUEST SPEAKER: Hello?

PROFESSOR: Go ahead, please.

GUEST SPEAKER: [INAUDIBLE]

PROFESSOR: Please, go for it.

AUDIENCE: So in 1990, we got the requirements from NASA to build a space [? bioreactor. ?] And all the students will love this. It was the smallest brewery that ever flew in space. And the initial requirements was that all fluid containers had to be solid with double walls. And this meant that we had another solution with bladders. [INAUDIBLE] bladders.

So we had a real fight up front in the proposal phase to demonstrate the compliancy to the requirement of going the cell culture, yeast cell culture, and still being non-compliant, actually, to this requirement of hard double-walled fluid containers. And so this is exactly [? the point, finding these ?] [INAUDIBLE] since the last 15 to 20 years. And this was a breakthrough in technology. And there, you will always have these challenges with the agencies, with your customers. They are [INAUDIBLE] set in their ways. And you have to demonstrate the feasibility to them to make them change the requirement that allows you to change the specification.

PROFESSOR: No, I think that's a great example. So in the end, you were successful to argue for the bladder the bladder solution.

GUEST SPEAKER: Well, the bladder was just how to keep the fresh medium and the used medium, meaning the beer. The technology was to put in [INAUDIBLE] And actually, it needed to have flexibility on the pressure in the reservoir. That's why the argument to put [INAUDIBLE] in space finally won the day, and allowed to relax the other requirements.

PROFESSOR: Yeah, thank you, thank you. A great example there. Any other comments?

AUDIENCE: [COUGHING]

PROFESSOR: OK, so so all this is a pretty long list. And this applies to single requirements. And then there's a set of-- this is really important. Then there's a set of characteristics that we want to see when you look at sets of requirements, groups that require.

Absence of redundancy. This means that each requirement is specified only once, right? You don't want to have redundancy. Redundancy can be good in system design, but not in the requirements. Consistency, using terms. Completeness, this basically means not missing key requirements. And then this idea of absence of conflict. And this is also similar to the feasibility. This is a tricky one.

Requirements can be in tension with each other, particularly their should goals. But they shouldn't be in direct conflict with each other, like you know you shall use aluminum for this unit. And then another requirements says, no metals are allowed to be used in this unit. You can't. That conflict is not solvable. That's a direct contradiction. That's different from having competing requirements or requirements in tension.

So let's do a quick exercise. And then we'll actually take a break, as well. So this is a turn to your partner exercise. And then we'll have a break. And we'll restart in like about seven minutes.

So here's what I'd like you to do. I have three systems here. They're very different in scale and complexity. So A is sticky tape. And I'll tell you this quick story here. I grew up in Switzerland surrounded by farms, you know. And I spent all my time at the farms and you know, big tables, big families. And this is-- they have these things here. This is basically-- these are flies sticking on tape. This is to keep the flies off the dinner table. It's called Mr. sticky tape for trapping flies. Really kind of gross. But I remember it.

B is I just a couple of weeks ago had a test drive and the new I3. This is the BMW small electric city car. Very cool. And then C is something that at EPFL, you guys know very well. This is the Rolex center. It looks kind of like Swiss cheese, when you look from the top. This is the equivalent of W-20 here at MIT. This is the student center. So there's a library there. There's a cafeteria there and so forth.

So what I'd like you to do is turn to your partner, pick one of those three, and come up with one single statement, one good requirement that you think was possibly used in the development of that solution, whichever one you pick, OK? So pick one of those three. And then jointly discuss and write a requirement that you think led to this design, OK?

So take about five minutes. Take a break. And then we'll sample what you came up with.

So let's hear from EPFL first. did anybody do A?

AUDIENCE: We did A.

PROFESSOR: OK, go for it. Speak up.

AUDIENCE: We had four requirements for.

PROFESSOR: OK, go for it.

AUDIENCE: All right. So The tape shows [INAUDIBLE] of the tape should be less than 4 grand. The tape should be able to catch up to 60 insects. And the sticky tape should not be toxic for humans.

PROFESSOR: OK, I like, yeah, the toxicity. That's good. Excellent. Very good. ow who did A here at MIT. Anybody? A? Go for it.

AUDIENCE: We said if greater than 10% of the surface area of the fly contacts the paper, it shall not be able to release itself.

PROFESSOR: Ah, I see. So this is a trapping requirement.

AUDIENCE: Yeah, how effective should it--

PROFESSOR: There are different, very different flies, right? There like these little day flies. And then there's huge horseflies. So which type of fly did this apply to.

AUDIENCE: We said 10% of the surface area of the fly.

PROFESSOR: Oh, any type of fly. Any different fly species.

AUDIENCE: Yeah.

PROFESSOR: OK.

All right, cool. So go ahead. Well, you know the point of this. You get the point of this is, right? A is like the sort of you think trivial system. But once you really start thinking about it, it's pretty tricky, right? Who else wants to, A-- something that hasn't been mentioned yet on A. Sam, go for it. Make sure you push the button.

AUDIENCE: Yeah, for the sticky trap we said that the product shall fit on a store shelf when packaged.

PROFESSOR: OK, so that's kind of packaging, logistics, distribution requirement. Very good. Mike?

AUDIENCE: They kind of already touched on it, but the sticky tape shall not be toxic and allow for-- allow for removal of human skin without bodily harm.

PROFESSOR: OK, great. So that's in the same-- you know, human factors requirement, basically. Yeah. Very good. Anything else on A at EPFL?

AUDIENCE: [INAUDIBLE]

PROFESSOR: OK, so installation requirement. OK. Nobody mentioned the ones I remember as a child are bigger than this. They were really long. So capacity, right? You could sort of have a length or capacity requirement, as well. Good. All right. I think we want to move on from the sticky flies to BMW i3.

So we had a little discussion here during the break. [? Lucy, ?] go for it.

AUDIENCE: So the car shell meet environmental regulations through mechanical or software tweaking with a proposal.

PROFESSOR: Could you guys hear this at EPFL? You've been following the news, right? With Volkswagon.

So what happened? Why did Volks-- the CEO just step down, right? It's kind of a big deal. Trust in the company has eroded. What happened there?

AUDIENCE: So the requirements that were set at the start. So the car shell meet environmental regulations on emissions. This requirement was probably not met. But the realization that it wasn't met was probably too late in the design process, such that it cannot be changed. And so the easy or cheap way to meet environmental regulations, in that case, was to tweak the software, I guess.

PROFESSOR: Right. So by the way this is kind of interesting. But how do you measure environmental compliance of emissions for cars? Do you know how that's done in practice? Do you guys know?

AUDIENCE: So it's having [? the car ?] run on a-- having the engine run, but the car is not rolling. And there's, behind the [FRENCH] the exhaust. Behind the exhaust, you measure whatever is emitted.

PROFESSOR: And it's like another rolling carpet, right? It's a dynamo, basically. And the way they do it is they have so-called drive cycles, like the [? FT6 ?] drive cycle. You know, the highway, the city cycle, which was a lot of on and off. And those drive cycles are actually different in Europe and the US and other countries. Every country has different drive cycles. So that's-- and what is a drive cycle, essentially? What word would we, as systems engineers, what word would we put on it?

AUDIENCE: CONOPS.

PROFESSOR: A drive cycle is just an, over time, accelerations velocity of the car, right?

STUDENT: It's a CONOPS.

PROFESSOR: It's a CONOPS A drive cycle is a CONOPS. And so for diesel engines, this issue that happened with Volkswagen, it's only an issue with the diesel, the TDI engines, right, not the gasoline engine.

So the issue is that the CONOPS, the drive cycle, in the US with TDI engines, they couldn't meet it. So they came up with this trick, right? Whereas in Europe, they didn't have to do that, because the European drive cycle, there's a lot more diesel engines use in European cars. They didn't have to do that in Europe, because the CONOPS, the drive cycle it's used for checking the environmental compliance is different in Europe. So great.

Anybody else on the I-3. Now the I3 is interesting, because that's actually an electric car, right? And so it doesn't have an engine, a diesel engine or a combustion engine, except if you get the range extender. So it's all electric, but you can actually, as an option get the range extender, which does use fuel. OK, EPFL, the i3, any other requirements there?

AUDIENCE: So we have four [INAUDIBLE]

PROFESSOR: Yeah.

AUDIENCE: As a third one, the car shall carry [INAUDIBLE]

PROFESSOR: OK, so recharging. The third requirement is interesting. You said of average build, right? That's the word you use.

AUDIENCE: Yes.

PROFESSOR: Now that's great. That's a human factors requirement. Now of average build is a little fuzzy, right? How would you make that more verifiable?

AUDIENCE: [INAUDIBLE]

PROFESSOR: Yeah, so there's actually people that, you know, the size distribution, male, female, you know, weight.

AUDIENCE: [INAUDIBLE]

PROFESSOR: And [INAUDIBLE] the metric measurements are actually being recorded and updated. People are getting taller around the world. People are getting heavier. We know that, right? So the way you would write that third requirement to be verifiable is that the car shall accommodate for passengers in a, say, P10 male or P5 female and a P90 male, right? And if you write it that way, then you know the actual weight and dimensions of the human body can actually be traced to a database that's pretty well known. So then instead of saying average build, you say it's a PT50, P50 female. And that's something that's very verifiable. Does that make sense?

AUDIENCE: Yes.

PROFESSOR: OK, great. So what about the last one? So by the way, here at MIT, anybody who's been to EPFL? Been to the-- [INAUDIBLE] He has a Master's from there. [INAUDIBLE] been there? This is a very cool building. It's pretty unusual. I mean, we have some very unusual building on campus, too, here. But if you get a chance, it's pretty. Unusual so let's hear from you guys. So what do you think was a requirement for the [? Rolex ?] center design?

AUDIENCE: The building should be a recognizable structure, that would be memorable for EPSL.

PROFESSOR: Ah, interesting. A recognizable structure that should be memorable. So that's-- I think I know where you're going with this. But it's a little-- you know, recognizable. Every building is recognizable in a sense, right? I think-- I like it. I know where you're going with this. But it's a little fuzzy still, right?

So why do you think it has holes in it? Why do you think the holes?

AUDIENCE: [INAUDIBLE] unique might be a better word. [INAUDIBLE]

PROFESSOR: Yeah. So that's really. The holes are, in some sense, inefficient, right? Because you're putting holes in the middle of a building. But they provide natural lighting. And there's a symbolism there, right? There's a symbolism, the Swiss cheese symbolism. So if the holes, in a sense, have at least two functions, right? That's good. I like that. That's very good. What else? Another example of a requirement for the [? Rolex ?] center?

AUDIENCE: You're taking and making [INAUDIBLE] category. [INAUDIBLE]

PROFESSOR: Good. No, that was great. So you have functional requirement, you had interface requirements. You had a lot of those six categories we talked about, right? Good. Excellent. Yeah? Go ahead.

AUDIENCE: So how do you write a requirement about something aesthetic in a way that's not fuzzy or is there a way to do that?

PROFESSOR: That's a great question. I'm not sure I'm the best person to answer that. What I can't tell you is, in the automotive world, the aesthetics of automobiles and how people judge whether a car is beautiful or appealing, that's actually moved from being kind of just a very fuzzy thing to quite measurable. You know, there's different shapes and then the building blocks of shapes and streamlines. Those things are-- that's really a science today.

And eventually, you know, there's ratings. These are people rate vehicles for aesthetics and so forth. And usually, it's a five point scale, like a Likert scale, like JD Power and associates is a very well-known marketing firm. And so they'll say, this looks-- this will prob-- they can actually, at this point, you can show them a-- not a sketch, but a model. And based on past data and information, they'll tell you, this car will probably score between a 4.2 and 4.4 on the 5 point aesthetic scale, JD Power scale. It's really pretty remarkable.

But I guess the bigger point is there's some things that really delight us, that have an artistic quality and surprise us in aesthetic quality. And it's true. That is one of the tensions is yet-- system engineering should-- you know, this very precise. Write it down. Make sure there is no fuzziness there or as little as possible. And then on the other hand, we want delightful, surprising things that have an artistic nature to them. And that is absolutely a tension. And we just acknowledge that.

OK, any questions? Comments before we move on?

AUDIENCE: I had a question about--?

PROFESSOR: Hang on. Just one second. OK, go ahead. At EPFL?

AUDIENCE: And to which extent can we refer [? to norms ?] and [? loads ?] in the requirements?

PROFESSOR: Yeah, you should do that. So compliance, being compliant with standards and just to make clear, standards and regulations are not the same, right? A standard, like an IEEE standard or an ISO standard, it's not a law. It's not a legal thing. It's-- a standard it is something that maybe a group of companies or a group of organizations have agreed to. This is how we will do it, right? The IEEE Wi-Fi standard, what is it? 802.11g. And that's not a law. That's a standard. And if you're going to be 802.11g compliant, you write that in the requirements.

The environmental emissions standards we talked about, those are actually laws. If you are going to sell a vehicle in country x, it has to comply legally with these regulations. But you're absolutely right, if you need to comply with these things, it needs to be part of the requirements set, because otherwise, it will not happen just automatically. [? Weston? ?]

AUDIENCE: Yeah, it's kind of along that vein. If you have to comply, say, with ADA, instead you have to be called out, specifically, or do you say must comply with building codes or building laws? And it's sort of a blanket requirement?

PROFESSOR: No, you have to be specific, because building codes are, first of all, a lot of these are local, as well. And it's very chaotic. So and some of these might be conflicting. So you should be as specific as possible.

OK, let's move on here. My sense is you're getting it just for what requirements are. And why they're important.

So let me talk briefly about requirements, decomposition, allocation, and validation. This is a figure from the NASA handbook. And basically, what it talks about is the high level system functional requirements are broken down into the performance requirements. And then as you make design decisions, as you decompose your system into different subsystems, each subsystem will have its own functional and performance requirements. And then the important thing is the difference between allocated and derived requirements.

So allocated requirements are requirements that you choose to allocate. And then derived requirements are calculated based on the dependent requirements, based on the allocated requirements. And I'll get into this in a minute. So requirements are hierarchical. We talked about this. Functional performance requirements are allocated. And then from these, we can further decompose and derive requirements. And then the total set of these requirements needs to be verified and then validated against the stakeholder expectations.

So let me briefly talk about requirements margins management. So because you don't know everything upfront, there's uncertainty. We typically build in reserves into our requirements. And those are called margins. So we put in margins for mass, power, maybe memory in computer systems. So margins are essentially reserves that are not allocated to particular subsystems, but are controlled by the project managers or at a higher level.

So the idea is that you write the requirement in a way that is a little bit more stringent than it really needs to be. And then by being more stringent, you've built some reserve into the system to handle unexpected things.

So I'll just give you the example with mass growth. You know, this is very typical in aerospace vehicles. Mass growth can range between, here, 10 to 60%. I'll show you some examples. And a lot of it depends on the novelty of the project. So a typical guideline, specifically for mass margins, is about 30% reserve at the SRR, 20% PDR, 10% CPR, and keep about 5% right before you operate the system. IOC is initial operating capability.

So here's some historical data. This is for manned or crude vehicles, starting with Mercury, Gemini, Apollo, Skylab, and then the shuttle. You can see the mass growth from the concept stage, which is phase A or prephase A, all the way to operations, you know, between 10 and 60%. The new Orion spacecraft is not yet included on this chart.

So what you do is you essentially write the requirement, knowing that this growth will happen during the design process. That's the basic idea of margins. And then the next thing you get is that you monitor the satisfaction of the requirements during the design process.

And so let's say you have, in a performance requirement, you say that the system shall not emit more than x number of [? NOX ?] emissions, or the systems shall not be heavier than such and such. That's on the y-axis here. That's your technical performance measure. And then you move through time and, you know, as the design gets more detailed, usually it gets heavier. You add more things. And you monitor that. And then you have your final current estimate of where you will be at the end of the project. And as you do that, your limits, your reserves, your margins, and here there is an upper and lower margin shown, is going to be narrowing down.

I'll give you a quick example. When I was at McDonnell Douglas, the F18 EF version, the Super Hornet, was being developed. And the key thing there was GTOW, GTOW, gross take off weight. It's basically the weight of the plane with crew, fuel, any payloads all in. The gross take off weight of the airplane, very important, because it determines the range. It determines a lot of things. And the number, not to exceed number, which is shown here on this chart as the maximum contract or allocated requirements threshold, was contractually specified. Not only that, but there were penalties, financial penalties, associated with every kilogram that you would be over.

So this was a big deal. And they had a huge the wall chart in the hallway, the main hallway, of the engineering building. And every day somebody would actually manually update that day's best estimate of what the gross take off weight of the airplane would be. And it's like a Brownian motion thing. And as soon as you hit some critical threshold, you would see there'd be people with would come together and say, we've got to take weight out of the airplane somehow, again, right? And then basically try to get the design to comply with that requirement as you move through the design process. You can't do that with too many of the requirements. But the most important technical performance measures, that's what you do. It's a big deal.

So here's the flow chart, basically, for requirements. I'm not going to go through this in detail. But the basic idea is the inputs come from the stakeholder expectations, the stakeholder work we talked about a lot last time. You go through the requirements definition process and outcomes invalidated set of technical requirements, measures of performance that you can measure, and then these technical performance measures that you can then track and validate against later.

Here's a question that I often get asked. Well, OK, so we write these requirements. You guys write them on paper or your tablet. But how do these requirements actually get recorded, right? And managed. So I would say there's sort of two-- there's the low cost, and then there's sort of the professional version of doing this.

The easy way to do it is you just write them, you capture them in a document. So that means Microsoft Word, Excel, Google Docs, just a document, a well written, organized document. And then you capture and revise your requirements. And the one thing I strongly recommend is using hyperlinks to link requirements. And this is the idea that every requirement has to be linked to some other requirement. So if it's a low level requirement, you want to ask, well, where does that come from? Why did we write that requirement? Well, it has a parent requirement. You want to have a hyperlink there to get you from one to the other. And I have a little example for that.

And I think this is OK for smaller projects, where you have dozens or a few hundred requirements, right? And so here's my rule of thumb for this. Do you remember the magic number 7? So we talked last time, where does the world of really complex systems start. And the argument was, well, if you need more than three levels of the decomposition. What does that mean? Well, 7 plus, minus 2 to the third power is somewhere between 125 and 729, right? So if you're sort of in that world or fewer, right? If a few hundred, a few dozen, or few hundred requirements kind of what we have in CanSat. It's OK to do it this way. It's still going to be a lot of requirements. And you have to do a good job. But you can do it that way.

If you have more than that, and that typically means more than 1,000 requirements to handle, and there are big projects that have 5,000, 10,000 requirements, there is no way you can manage that effectively in a kind of document based way. So what you need then is a database. You basically capture the requirements in a relational database where that allows you to link each requirement to other requirements.

And so this is not meant as an advertisement, but one of the most heavily used requirements tools out there is called, DOORS. And this was relatively recently bought by IBM. This was a separate company. It was bought by IBM and included it in a suite of software tools called IBM Rational for System Development. And so DOORS allows you. It's a database, relational database, that allows you to write requirements, share requirements. And the latest version of DOORS is actually web based, so you can have people in India, in Europe, in the US, you're co-developing a system. You can all write requirements and manage them on this common database, right? Because if you have a document, very quickly it's going to be confusing, as what's the latest version, who has the latest update. Version management becomes a nightmare.

So just so you're aware of this. We're not going to be using DOORS in this class. We'll just do it document based. But you know the rule of thumb here is, more than 1,000 requirements, you've got to go to some professional solution.

So here's a very sort of trivial example of hierarchical requirements with links. Requirement one, the systems shall fit into a volume not exceeding one cubic meter. And then we have sub-requirements. The system's width shall be between 0.5 and 1 meter. The height, the depth. The system shall be made entirely from aluminum 60/60 alloy. A sub-requirement here is the system shall not contain any internal voids or cavities. Requirement three, the shape of the system must be a cube. And then a sub-requirement, the angles between the sides shall be 90 degrees plus or minus 1 degree.

And so I did this here just in the slides. But if you click on this, it'll actually transport you into another requirement. This is the requirement four. The mass of the system shall not exceed 2,700 kilograms, right? Aluminum has a density of about 2,700 kilograms per cubic meter. So I click back, it transports me back to the earlier requirement. So the fact that it's made of aluminum and the volume cannot exceed one cubic meter, then this requirement four, the mass shall not exceed. It's not an independent requirement. It's an dependent or derived requirement based on the first two. And therefore, they're linked. Do you see how this works?

And to really manage requirements well and then link them, use these hyperlinks. It's very, very effective.

So what would be an object that satisfies these requirements? So here's our one cubic meter envelope. So an aluminum cube with a side length of 60 centimeters this volume and this mass will satisfy the requirements. It's not the only thing. There's a lot of other geometries that would satisfy it. But this particular instantiation would satisfy these requirements. So that's the idea hierarchical requirements, linking them to hyperlinks.

OK, so let me talk briefly about the challenges now of requirements definition. And there's-- this is not easy. There's a lot of challenges. The first one is requirements allocation. You know, there's composition and flowing requirements to the lower levels. And then the idea is that, whatever requirements you derive at a lower level, if you satisfy the lower level requirements, that should guarantee that you then automatically satisfy a higher level requirements from which the lower level requirements were derived. That's the basic idea of requirements allocation.

And so the way you can think of this, graphically, is we start out at the high level. Here's our stakeholders. Stakeholder needs requirements. This is level 0. You set the system boundary. What's the lifecycle? And then we apply it. That's our first application. And then we apply it by decomposing the system into its function.

And so that's the second application. And then you say, well, how do these-- how will these companies be carried out? So we define subsystems. And essentially, then, the subsystem requirements are derived from the functional requirements. And you put numbers, key system performance parameters, behind these. And depending on the complexity of the system, you may have to go multiple layers down. But that's the basic requirements allocation process.

And I think I said this already. It's difficult to do and stay solution neutral the deeper you go into this.

Let me briefly mention, this will not be, we will not sort of test you on this. But I want to make you aware of this. A methodology called ISO performance. And that was actually the topic of my dissertation. How do you allocate requirements to lower level parameters in systems, when a higher level requirement is defined, is clear.

So the idea is that you have a vector of desired performance requirements. And you want to understand, first of all, you want to understand are those requirements feasible. And if they are feasible, it usually means there is more than one way that these requirements could be satisfied, that the higher level requirements could be satisfied. So find different non-unique feasible combinations to satisfy the high level requirements. And so this is one of the readings. Very quickly, we have our design space. We have our objective space. And then we have this cost risk objective space.

And so the idea is that, in the performance space, you have the shall statements. You shall perform at that level. And that's this point here. That's your performance target. And if it's in this gray area, it's actually feasible. And it usually means there's more than one way to do it. So if you can then map backwards to the design space, these points here are all ISO performance, meaning they all satisfy and provide this level of performance. But they do it in different ways. And then in order to select the final design or final requirements set, you want to look at other objectives. This is where the should statements come in. And these are typically cost and risk related objectives.

So let me give you, this sounds pretty abstract and theoretical. Let me give you a very specific example. This was my case study, the Space Telescope. This is the actually this has now become the James Webb Space Telescope. Hasn't launched yet. This is 20 years ago. We've been working on the James Webb for a long time. But if it works, it will be exciting, because it's going to get us very, very close to the Big Bang, right? That's what James Webb will look in the highly redshifted infrared to really see the formation of the earliest proto-galaxies in the universe. So if this works, it will be very exciting.

So here's, essentially, a model of the spacecraft. This is a precursor to James Webb. And the big thing you need to do is you need to point and be very, very stable for a long time to take in these very, very faint images. So we have wavefront error phasing requirements. And then we have these pointing requirements. You've got to a point very stable and in order to achieve this optical pointing performance, we have the structure of the spacecraft. We have reaction wheels. We have controllers. And there is noise, different kinds of noise sources that are trying to basically prevent us from pointing with this precision.

So very quickly, this is what this Nexus precursor spacecraft looks like in the deploy configuration, here on the upper right in the stowed configuration. Initial performance assessment. So this is really trying to define the requirements for deriving the requirements for the structure, for the optics, for the controller, knowing that this is the point. If you want to have this science happen, you've got a point with that precision. That is known. So let's flow that down.

So if we look at the pointing, for example, here on the right, this is kind of fuzzy furball. What does that represent? That's a time domain simulation of the centroid of the image, right? The telescope is now observing a part of the sky, trying to get these early proto-galaxies. And it's flexible. It's a very lightweight telescope. It has these reaction wheels are turning, trying to keep it stable. You have electronic sources of noise.

So the blue furball here predicts that we would not meet the requirements. This is some initial design, some initial set of requirements. We need to find a way to get down to the-- this is about 15 microns-- [? root mean ?] square error. So it's about three times worse than what we need to achieve. And the requirement is we need to get down to 5 microns of pointing or jitter precision.

So how do we do this? So what ISO performance does is it looks at the sensitivities in the system. What are all the things that influence the pointing performance of the telescope. And you can see here. These are the two key performance measures on the left, wavefront error, and then line of sight. And the bars essentially tell you what are the really sensitive parameters that drive performance. So disturbance parameters, planned structural parameters, optics, and then controls. So it's really multi-disciplinary.

And what's neat about it is you can, if you know these sensitivities, you can essentially calculate the Jacobian a matrix. The Jacobian matrix is essentially the partial derivatives of your performance, which is your higher level requirement, with respect to these lower level parameters or requirements. And you can then find, using this essentially the null space of the Jacobian matrix, that will tell you how do you move in that space to keep the performance fixed at the requirement level.

Let me explain this just using two parameters. And this was a big deal in the Hubble Space Telescope. So the two parameters I'm going to use are KR ISO and UD, the dynamic wheel and balance. So these spacecrafts have reaction wheels that are turning to point the spacecraft and counteract any momentum that you get from, for example, from solar pressure. So UD is the amount of imbalance that you have in these wheels. If you have imbalance, that will cause chatter. It will cost torques, which will cause that jitter. And then KR ISO is the vibration isolation of the reaction wheel assembly. How stiff or soft is the vibration isolation.

And what you can see in this clock is that, our initial design-- this is based on a simulation-- does not satisfy a higher level requirement. In order to satisfy that, we need to go down to the blue line, labelled with 5 microns appointing precision. And what you can see is that there are different ways to achieve that 5 microns.

We could go over here. This is labeled as HST. That's what Hubble Space Telescope is. The Hubble Space Telescope basically went for ultra, ultra, ultra quiet reaction wheels, very, very low dynamic imbalance. So [? Marissa, ?] you talked about buying sensors from a supplier and putting them in. These reactors, there's companies that really specialize in making reaction wheels and things like that.

So if you're going to go for this point here. Let me point that out again, so you guys can see it at EPFL. If you're going to go, if you're going to derive and allocate this requirement, it means you put a lot of pressure on your supplier to achieve that level of dynamic wheel imbalance. If they can do it, that's great. But it could be very expensive. But it makes your job easier as the spacecraft integrator.

Or you can go straight down to this point here called spec. So you're essentially tolerating a noisier reaction wheel. But then you need a very, very soft, very capable isolation stage, very soft isolator. What's the disadvantage of having very soft isolation? What do you think is the big issue?

AUDIENCE: [INAUDIBLE]

PROFESSOR: So the launch. You probably have to lock it down during launch. You have a big displacements. You need, if you have a very soft isolation stage, you need volume, because the isolator is going to move a lot, right? And you may not have that volume. Or you could do a little bit of each.

So this test point here. We're going to have quieter wheels, but not ultra quiet. And we're going to have a soft isolator. But we have the right combination of the two. And we're going to go for that point there. So now if you go for that point, you're going to satisfy your pointing requirement, bu you've allocate at the lower level requirement, in this case, to the isolation stage and the dynamic wheel imbalance in a kind of balanced way. So everybody's job is roughly equally difficult. That's the sort of idea here. Yes?

AUDIENCE: Does this model assume that all of these variables are independent and, I guess, kind of continuous in terms of you can incrementally work better?

PROFESSOR: So they're not independent in the sense that they're coupled through the performance of the system. But you can choose-- the assumption is you can choose these independently. But they're coupled, because you need to achieve that requirement. And yes, in this case, they're continuous. But you can think of this as a discrete, as well.

So for example, the reaction wheels could be, you're picking from a catalog, in which case now you're really picking specifications for components that are off the shelf.

OK, so let me-- I'm going to skip here for time. So basically, following this ISO performance process, you can go from some initial requirements, derived requirements that are infeasible, to, in blue here I'm showing you the results of this. It's very close to 5. There's some numerical tolerance here. But by but essentially rebalancing the requirements within the system, we're achieving a higher level requirement. But in a way that this [INAUDIBLE] sort of the challenge equitably across sub-systems.

Does that make sense? At EPFL, did you guys follow this? I know this was a bit fast. But that's the basic idea of ISO performance. Any questions on your side?

AUDIENCE: [INAUDIBLE]

AUDIENCE: Maybe I have one. So given that you have [? distance ?] requirements and you probably have [INAUDIBLE] for each one, is there a way that we would integrate all those [? lines, ?] that you could see the [INAUDIBLE] for those? If you don't mind, maybe it's a little bit [? softer, ?] but maybe there's another requirement where [INAUDIBLE]

PROFESSOR: [INAUDIBLE]

AUDIENCE: We don't hear you.

PROFESSOR: Sorry, guys, ran out of battery here. Can you hear me again? Can you hear me? Yeah? So the question was, well if you have multiple of these performance, ISO performance lines, that's exactly right. If you have a vector of higher level requirements, you're going to have ISO performance surfaces. And so it gets, you know, the more of these you have to satisfy at the same time, the more complex this gets. But we can handle that computationally. So you have to do some simulation and computation upfront to make sure you pick. These requirements are not just wild guesses. They're actually based on some calculation and simulation. OK?

All right. So let's do this. Let's do this in a kind of simplified way. This is going to be our last concept question for today. Here's the higher level requirement is a balloon. Those of you that have done unified engineering here, you've done this, right? We did this in unified. A balloon shall lift the payload of 1,000 kilograms, which includes its own mass.

You can use either helium, which has a density of 0.2 kilograms per cubic meters. This is in standard atmosphere conditions. Or hydrogen, 0.1. I've rounded these numbers, as a lift gas. The standard density of air is 1.3. Which of the following requirements is infeasible? A, the balloon shall have a radius of 6.1 meters and the balloon shall use 99.9 percent pure helium. B, a radius of 5.9 and the balloon shall use 99.99 point percent hydrogen as a lift gas. And then 5.9 meters helium, 6.1 meters hydrogen, all these requirements actually are OK. Or none of these requirements are feasible.

OK, so I'll give you I'll give you three minutes to try and figure this out. And then I'll show you the solution. Don't cheat. Don't go to the next chart.

So think about this the high level requirement is the balloon shall lift 1,000 kilograms, including its own mass. And we're trying to allocate lower level requirements for the size of the balloon and the gas that we're going to use. So try to figure this out.

All right, I think we probably need-- who needs more time for this?

OK, so we're going to leave this as a cliffhanger, OK? We'll do the solution next time. And take a little time to figure this out. Try not to look at the next slide, OK?

So I'm going to skip this just for time. And I want to talk briefly about the SRR, what it is, and then kick off assignment 2. So SRR. So the idea is you've really been working on these requirements hard, you know, as a team, with your customers. And this takes-- this is not a quick thing. This is not just two or three days. Typically, writing your level 0, level 1 requirements is a process that takes weeks, months, sometimes at least a year. But typically, it's on the order of three to six months in many projects, roughly.

And once you have your high level requirements, SRR is the milestone where you review those, right? So here's an example. So it's a social. It's a peer review process. And the main goal of SBAR is to vet the requirements as they were written to see if you have any missing, misstated, redundant, or otherwise unsatisfactory requirements.

This is a picture from JPL, from MSL, actually, mission. And I want to just point out a good friend of mine who is a graduate here of our department, Richard Kornfeld. [? Voelker ?] knows him, met him last summer. He's been working on three different Mars missions over the last decade. And we're going to hear from Richard later this semester about verification of requirements, because he verified the entry descent and landing requirements for MSL.

So here's essentially what it says in the NASA handbook. SRR happens during phase A, before you go into phase B. And you need at least your top two level requirements written before you can do the SRR.

I do want to mention the second reading post reading. This is about requirements volatility. So just because you past the SRR doesn't mean that the requirements are completely frozen. First of all, you don't have a lot of lower level requirements yet, right? Those are going to be added post SRR. and even some of the-- you pointed out, some of you, the requirements creep and these things. So this second reading is about requirements volatility, which you can actually quantify. What are the sources of requirements volatility? That's what this figure shows you. And then what is the impact of requirements volatility?

What is the impact of requirements volatility on a project? So specifically, on the number of system requirements, on rework, on project schedule, and so forth. Really, it's a very, very recent paper on requirements volatility.

So let me just kick off assignment 2. And then we'll be done. So assignment 2 goes out today and is due in two weeks. So that's October 9. And it's very focused on requirements. Basically, what I want you-- and it's the same teams that you're in for all the assignments. Is essentially, first of all, first task is find a project or program where poorly written or managed requirements were a major problem. So as a team, discuss an example and discuss that example as a team.

The second task is look at those CanSat 2016 requirements, those 47 base requirements and analyze those critically. So that means are they feasible, are they well-written. Classify them. What type of requirement is it? Is it an interface requirement? Is it a performance requirement? And then figure out whether there's a hierarchy there. And basically, then, from that, generate your own set of requirements for the CanSat competition. So you're going to either rewrite or organize these requirements in a way that's better and that works for you as a team.

And then the fourth requirement is to figure out where you want your margins, where do you think you need to have reserves and margins in these requirements. So it's very much looking and reorganizing and critically analyzing the CanSat 2016 requirements set.

So let me summarize. Good requirements are really essential. It's the starting point for system design, system engineering. It is a challenging thing, especially the flow down is challenging. There are some methods and commercial tools for doing formal requirements management. So I mentioned ISO performance. And then I mentioned DOORS, these commercial tools.

And then the last point here is just because you passed SRR, and you have high level requirements approved, doesn't mean that's the end of the story. The requirements will continue to be updated, refined. But you have to be you have to be very disciplined to keep that in check. If your requirements volatility is too high, then bad things can happen to your project. And I really recommend the reading on requirements volatility, some very, very recent data on that, OK?

So that's the end of the session for today. I'm going to be online on the WebEx in about 10 minutes. If any of you have questions, or any comments, or you want to dive into this further. I know this is not a great time for you at EPFL, because it's Friday night for you guys. So I think what we're going to do, we'll figure this out with [? Leighs ?] and [? Johana. ?] We'll see if we want to do a separate time, a different time during the week for the office hours. I'm happy to do this at a better time, if this doesn't work for you guys, because it's happy hour time for you.

So anyway. OK, so great. Have a great week. And we'll see you next Friday.