Engineering is all about solving needs (and wants), problems, and opportunities (the problem space). Since there is an infinite number of needs, wants, problems, and opportunities, the requirements and specifications define which particular set of items in the problem space the solution will solve or implement. Your functional requirements definition was pretty good, but you forgot a large section of the requirements space - constraints. The "I want blue" customer comment is not in the solution space, but is, in fact, in the requirements space. However, you are correct that it is not a functional requirement. Instead it is a constraint. The problem space is infinite. The solution space for a particular set of problems, while not infinite, is quite large. For example, the problem is the customer's need for a widget. The requirements specify what the widget needs to do. However, there are nearly an infinite number of solutions and each of those solutions could have a nearly infinite number of colors that widget could be. Saying "I want blue," is a constraint that defines the color space to choose for the widget. But this is not the only constraint. For the widget there could be dozens of constraints, such as, desired price, average cost, widget size, left-handed versus right-handed, materials used, weight, power requirements, interfaces, and so on. While constraints are not functional requirements, they are an integral part of the requirements definition and therefore part of the requirements space. It might be that a customer has a solution in mind when they define a constraint. That's what the next part of the project is about - requirements analysis. Why does the customer require a specific constraint? That constraint may define a critical feature of their desired system. For example, they want to sell their blue widget to people whose favorite color is blue. Or, they may want blue because it will fit existing decor (in which case, a Feng Sui designer may help on getting the correct color). Maybe there are other reasons. The requirements analysis needs to examine the constraints and potentially change a constraint to a functional requirement. Still, constraints are part of the requirements and not even on the edge but smack in the center. Sometimes a constraint will drive most of the other requirements. For example, a left-handed constraint will drive the material shape, parts used and more. Often, constraints may be way more important then functional requirements. For example, a power or size constraint may mean that many functional requirements must be removed so the system can meet the constraint. The "I want blue," constraint on a light bulb eliminates all of the other colors and many potential technologies. (An incandescent bulb generates light in a large range of colors. Therefore, a "blue" light may eliminate incandescent bulbs due to the need to color the bulb (an another constraint might be using a clear bulb or generating a certain amount of light.) Please leave constraints where they belong - coming from the problem space to drive requirements and solutions.
I like your analysis and I think you can see that constraints are truly DESIGN constraints. Somebody in the problem space has made a design decision for you. Live with it. Is it a requirements (a true problem like I was to sell to people who love blue) or a solution that they decided for you? I call it a solution. Same with many standards and regulations: solutions decided for you. I agree that they come from the problem space but they are solutions. Name them for what they truly are.
Thank you! The presentation is condensed and easy to understand unlike the resources on the internet.
What a nice way to explain it! Thanks for sharing
Its really a good presentation - thanks!
I laughed when you said beer is basic human needs
Engineering is all about solving needs (and wants), problems, and opportunities (the problem space). Since there is an infinite number of needs, wants, problems, and opportunities, the requirements and specifications define which particular set of items in the problem space the solution will solve or implement. Your functional requirements definition was pretty good, but you forgot a large section of the requirements space - constraints. The "I want blue" customer comment is not in the solution space, but is, in fact, in the requirements space. However, you are correct that it is not a functional requirement. Instead it is a constraint.
The problem space is infinite. The solution space for a particular set of problems, while not infinite, is quite large. For example, the problem is the customer's need for a widget. The requirements specify what the widget needs to do. However, there are nearly an infinite number of solutions and each of those solutions could have a nearly infinite number of colors that widget could be. Saying "I want blue," is a constraint that defines the color space to choose for the widget. But this is not the only constraint. For the widget there could be dozens of constraints, such as, desired price, average cost, widget size, left-handed versus right-handed, materials used, weight, power requirements, interfaces, and so on.
While constraints are not functional requirements, they are an integral part of the requirements definition and therefore part of the requirements space.
It might be that a customer has a solution in mind when they define a constraint. That's what the next part of the project is about - requirements analysis. Why does the customer require a specific constraint? That constraint may define a critical feature of their desired system. For example, they want to sell their blue widget to people whose favorite color is blue. Or, they may want blue because it will fit existing decor (in which case, a Feng Sui designer may help on getting the correct color). Maybe there are other reasons. The requirements analysis needs to examine the constraints and potentially change a constraint to a functional requirement. Still, constraints are part of the requirements and not even on the edge but smack in the center. Sometimes a constraint will drive most of the other requirements. For example, a left-handed constraint will drive the material shape, parts used and more.
Often, constraints may be way more important then functional requirements. For example, a power or size constraint may mean that many functional requirements must be removed so the system can meet the constraint. The "I want blue," constraint on a light bulb eliminates all of the other colors and many potential technologies. (An incandescent bulb generates light in a large range of colors. Therefore, a "blue" light may eliminate incandescent bulbs due to the need to color the bulb (an another constraint might be using a clear bulb or generating a certain amount of light.)
Please leave constraints where they belong - coming from the problem space to drive requirements and solutions.
I like your analysis and I think you can see that constraints are truly DESIGN constraints. Somebody in the problem space has made a design decision for you. Live with it. Is it a requirements (a true problem like I was to sell to people who love blue) or a solution that they decided for you? I call it a solution. Same with many standards and regulations: solutions decided for you. I agree that they come from the problem space but they are solutions. Name them for what they truly are.
Beer is a Functional Requirement for the human body? Can I have a copy of that document please for my wife.
This is cute & good~ Thx!
excellent videoooooooo
Interesting - thank you.
BEER !
very helpful
That loud bang at the very start was too loud.