An Introduction to Requirements | Systems Engineering: Managing System Complexity, Part 4

In this video, I want to introduce a very popular if not infamous topic within systems engineering; requirements. Now, like most things within systems engineering, there is a lot to cover, as well as a lot of nuance that unfortunately has to be skipped over in a short video like this one.  Therefore, we shouldn’t treat this as everything you need to know, but rather we’re going to cover a few important and interesting ideas behind requirements.  We’re going to talk about what they are, we’ll describe what makes a good requirement, and then we’ll briefly show how they contribute to the system design process.  I hope you stick around for it.  I’m Brian, and welcome to a MATLAB Tech Talk.

There is a quote that is probably misattributed to Albert Einstein that goes something like this, "Given 1 hour to save the world, I would spend 55 minutes defining the problem and 5 minutes resolving it."  Even though this is a bit exaggerated, the idea is that time spent understanding and agreeing on what the problem even is can be more useful than the time spent actually solving it because it ensures that you are solving the right problem.  And we’ve talked about how the systems engineering process is set up to do just this, to spend a lot of time defining the problem first.  And this is where requirements come in. Requirements and their associated constraints and assumptions are a means for quantifying the problem to be solved. They are a way to record and describe what needs to be designed and they provide how project success will be determined.

A requirement consists of three things, a description of a particular need, a rationale for why the requirement is valid, and a way to verify the system meets that requirement. So, in other words, we write down what the system needs to accomplish, we make sure what we wrote is actually worth doing, and we make sure that there will be a way to prove that the system meets it.

We’re going to get into the details of each of these in just a bit, but for now I want to highlight some of the different types of requirements so that you can get a feel for the needs that we may levy on a system throughout the project.

First off, we may write requirements that specify which functions the system needs to perform, and there are performance requirements which describe how well a system must perform a function. And there are constraint requirements that cover which parameters a system shouldn’t exceed, and environmental requirements, and human factors, and reliability, and safety, and so on. They cover every aspect of the design where you have specific needs that must be met.

Let’s go through a few examples with the toaster that we introduced in the last video to show you some of the different types of requirements in action.  A functional requirement specifies functions. So for the toaster we might have "The toaster shall convert electrical energy into thermal energy". This is a requirement that we can verify by inspecting the toaster design and seeing that that function exists.

For a performance requirement we might say that the toaster shall be capable of converting up to 100 Watts of electrical power into thermal power. And again this requirement could be verified by analyzing the design and ultimately through test once the toaster is built.

A constraint requirement might be something like the toaster mass shall be less than 5 kg which we verify by analyzing the mass budget early in the design and then through inspection by weighing the actual toaster.

So those are three of the requirements that we claim the toaster must satisfy and a few different ways to verify that the design will meet those requirements.  But beyond just the description and the verification method, we also have to think about their validity. That is, are these valid requirements, and if so, what is the rationale for each of them?  There are two broad categories that a requirement must satisfy in order for it to be valid.  Firstly, the requirement must be something that we actually want to levy on the system, and secondly, the requirement must be written in a way that conveys the right message.  Let’s dive into both of these.

We need to make sure that we are designing and building the right thing, the thing that the stakeholder actually wants.  Therefore, the requirements have to specify needs that help achieve the end goals.  For example, a good requirement for a toaster might be that the volume of the toaster must be less than 1 cubic foot.  This is valid because we can trace it directly to a stakeholder need that says that it has to fit on a standard kitchen counter top.  Therefore, we feel good about constraining the design to this size. On the other hand, a requirement that says the toaster shall be able to simultaneously toast 10 slices of bread probably isn’t valid.  I mean, it’s a perfectly legitimate requirement, we could create a design that accomplishes this, but it’s one that we wouldn’t want to levy on the design for at least two reasons. It doesn’t trace back to meeting any of the stakeholder needs so there’s no higher level requirement or objective we can point to as to why this requirement exists, but worse than that, it’s probably inconsistent with the toaster volume requirement because it complicates our ability to meet it.

This is kind of a silly example, but inconsistent requirements are, unfortunately, easy to create because two individual requirements could appear to be valid on their own and even trace up to the stakeholder needs.  But it’s only after looking across the requirement set as a whole can we determine if there are inconsistencies in the definition of the system that need to be addressed. And finding this out as part of the requirements validation effort is preferred over finding it out after you’ve designed the system.

Now, even if we have a valid rationale for a requirement, it’s technically and programmatically feasible and they are all consistent, a requirement still might not be valid if it’s poorly written.  To understand what that means, let’s go through some examples.

A requirement must be clear, concise, and unambiguous.  That is, it conveys a single thought, can only have a single interpretation, and doesn’t contain unnecessary information.  For example, a poorly written requirement might be "The toaster shall have a removable crumb tray and it should weigh less than 5 kg".  This is poorly written because not only are there two thoughts here, the crumb tray and the weight, but it’s not entirely clear whether it’s the tray or the toaster that has to be below 5 kg. It’s better to split this up into two requirements, that are clear and can each be independently verified.

Another way a requirement could be poorly written is if it is unverifiable.  Being unverifiable might come from the use of words like minimize, and maximize, and user-friendly to describe the need.  I mean, you could write a requirement that says that the toaster shall be user friendly, but verifying that would be very subjective.  A better approach would be to perform product research ahead of time where various design choices are ranked by the potential users based on how user friendly it is and then write requirements for the features that are desired.  Any requirements that you have that can’t be verified should be removed or revised because you won’t have a way of guaranteeing the system meets it in the end.

The last sort of requirement pitfall that I want to discuss here is that of specifying implementation.  Requirements, like functions from the last video, typically describe what the system should do, and what it’s constrained by, and not describe how it should be done.  For example, we have the requirement that says the toaster shall be capable of converting up to 100 Watts of electrical power into thermal power.  This defines a particular aspect of the design.  What it has to do. It has to convert up to 100W. But how does it do that? Well, the requirement doesn’t say. It could be with coils or some other heating element. The domain experts within the engineering team should have the flexibility to meet that requirement with an implementation of their choice.   

As a quick side note, there is a bit into a grey area in terms of specifying implementation with a requirement. It’s not as straight forward as just saying don’t do it.  If a particular implementation is required, and you don’t want flexibility in the design, then it can be specified as a requirement.  For example, there might be some government regulation that says you can only use electric heating coils in a residential toaster, in which case you would write this as a requirement.  But in general, we try to stay away from forcing a particular implementation through requirements and just focus on defining the characteristics and features of the design.

Alright, once we have requirements that have been validated and reviewed, we allocate them to an implementation.  That is, we link the requirements to the particular widget that they define the features of. And conversely, the widget design traces back to the requirements that it implements.   So we’re left with a traceability map that connects the as-designed system with the requirements. This requirements tracing does at least three things, it provides a way to audit the requirement list to determine if any were missed in the design, it provides a way to audit the implementation and make sure there is a justification for each widget, and it provides a list of requirements for a particular implementation that can be used to design a verification test. Which we’ll talk more about in the next video.

Ok now that we have a basic understanding of what requirements are and how they contribute to the design process, the last thing I want to talk about in this video is requirement hierarchy.  Requirements don’t exist as single disconnected entities, but are often grouped and organized into a hierarchy.  Lower level, or child requirements refine the needs of the parent requirement.

At the top level, and near the beginning of the program we start with the key programatic requirements which formalize the stakeholder needs.  Then we flow those down to functional requirements where we determine the functions that the system must accomplish.  And then we create performance requirements at the system level, and then begin flowing then down to subsystems, components, and parts until we have a complete set. Your program might call these levels by different names but the idea is the same, refine the higher level requirements by writing more detailed lower-level ones.

You might be thinking, "wait a second"! I thought you said requirements don’t specify implementation, then how can we develop requirements for the lower levels without having an implementation? Well, there’s a difference between forcing an implementation through a requirement, and defining the needs of a particular chosen implementation. Some design work and implementation details need to be determined in order to continue refining the requirements.  So, we can think of it as an iterative approach where the high-level requirements allow the design team to investigate and choose a specific concept to pursue. And once we have a concept, we can write lower-level requirements specific to that concept which allows the design team to further refine the implementation.

As an example, in the last video we talked about how a toaster could be a residential toaster, or a commercial toaster, or a camping toaster.  The high-level needs of the stakeholder, drove us down the path of creating a residential toaster.  This was a concept that we chose to pursue and once we decided on this path we were able to further refine the functional requirements.   We have a functional requirement that the toaster must manage and store the mechanical energy that is generated when the bread is lowered into the toaster.  This requirement only makes sense to levy on the design for the residential toaster, so it’s implementation specific, but it still isn’t forcing an implementation because it’s not telling us how to manage and store mechanical energy.

And we can take this further.  We may make a design choice to store the mechanical energy in a spring.  That’s an implementation we’ve decided on.  In which case, we could write lower level requirements for the spring that state performance measures like the maximum distance the spring can travel and how much energy it needs to store. This would give us an idea of what kind of a spring we need to design or purchase.  So, hopefully you can start to see the back and forth between further refining the requirements and further refining the design.

Stacking all of these parent and child requirements together forms a hierarchy.  You can see how spring Length and Spring Energy storage are both child requirements to managing mechanical energy.  And this hierarchy, which we’ve already alluded to, can help us with the validation effort. The rationale for a requirement could be determined by showing that it’s necessary in order to for the system to meet its parent requirement.

But again validation is more than just looking at individual requirements.  We have to think about validation as a system and a hierarchy can help us with because we can look at the set of requirements for a component and determine if they are valid as a group.  We can see if they are complete - that is we’re not missing a requirement in the definition. We can see that they are consistent with each other - so they don’t contradict or cause others to be infeasible.  And we can see that they are necessary, that is we’re not removing flexibility or forcing an inconsistency by over-constraining the design.

Ok, so that’s a quick overview of requirements and the benefits of a requirement hierarchy and traceability.  However, there is a larger story to be told here.  In the next video, we’re going to expand on system verification and validation and show how systems engineering and requirements help ensure that we built the right system and we built it correctly.

So if you don’t want to miss that or any other future Tech Talk videos, don’t forget to subscribe to this channel.  Also, check out my channel if you are interested in other control theory topics as well.  Thanks for watching and I’ll see you next time.