Below is the transcript of the "Understanding Requirements Concepts" webinar I presented in January. You can also find it, along with links to the video and audio, here.
Roger Cauvin: All right; thank you. Again, I’m Roger Cauvin with Cauvin, Inc. It’s a product management and research firm in Austin, Texas.
Today as Suzannah mentioned, we’re talking about requirements concepts. The purpose of the presentation is going to be to clarify the concepts and terminology related to requirements.
I’m going to do three things. First, I’m going to show how existing requirements terminology is actually contradictory. Second, I am going to show how confusion leads to product development failures, and third, I am going to clarify the concepts to remove the contradictions.
I recently participated in an on-line debate about requirements terminology, and in that debate one of the other participants drew a distinction between external and internal aspects of products.
The idea is that the line between requirements and design can be drawn in the same way as between external and internal aspects of a product. So a requirement would specify the external behavior of the product, and the design specifies the internal details.
That sounds like a great distinction and a great way of drawing that line between requirements and design. Unfortunately it leads to contradictions.
What does a UI designer do? A UI designer specifies only the external aspects of the product when that UI designer produces a user interface spec. Well, if it’s only the external aspects of the product, then you would think they would be requirements. But then we’re led to the conclusion that UI designers do not design user interfaces. Which is a contradiction in terms.
Another example is FRSs, which are called "functional requirement specifications". We’ll talk a little bit later about what functional requirements are vs nonfunctional requirements but for now, you would think that a functional requirement specification would contain functional requirements and not contain nonfunctional requirements.
When I talk to colleagues who actually produce these documents, they insist that their functional requirement specifications include nonfunctional requirements. So we’re led to the conclusion – the contradictory conclusion again – that functional requirement specifications contain nonfunctional requirements.
You may be asking, well, this is all semantics. Why does this matter? Does this have any impact on how we do our requirements, and whether it impacts our product development processes, and whether we have successful products?
I argue that it does. Just about any problem solving expert that you talk to will say that the most neglected and the most important part of the problem solving process is first understanding and defining the problems you are trying to solve clearly.
When we fail to understand the distinction between requirements and design, we are essentially failing to understand the distinction between the problem and the solution and we therefore end up, very often, failing to clearly understand and define the problem. That leads to product failure.
Toyota understands this. Toyota is renowned for their process improvement practices. I recently read an article about Toyota’s process improvement practices, and in that article Toyota executive said the quote that is on the screen right now. That quote essentially says that one of the keys to Toyota’s process improvement successes has been their emphasis on first trying to understand clearly the problems they are trying to solve and what they are trying to improve, before jumping into possible solutions and ideas about how to achieve that.
I am going to introduce you now to the conceptual model which you see on your screen. A conceptual model depicts concepts and the associations among those concepts. The rectangles you see represent the concepts, and the lines you see between them represent the associations among those concepts.
Above each line or associated with each line, is a text description as well as what’s called multiplicity. Let’s look at product and problem.
A product solves or avoids problems. The multiplicities are the 1 and the asterisk you see. The asterisk means "any number of"; it could be zero to infinity. So we read that as, "one product solves or avoids any number of problems".
If you look under the stakeholder concept, you see a hollow triangle. The hollow triangle on the end of an association link depicts specialization; it is a special kind of association.
The way you read this is "an internal stakeholder is a kind of stakeholder". A user is a kind of stakeholder. A buyer is a kind of stakeholder. So what I’d like you to take away from this slide in the end, is the emphasis on solving problems.
Some of you may be familiar with Pragmatic Marketing – with whom I have no affiliation – but I respect what they teach and what they preach a lot – which is they talk about product managers’ primary responsibility being identifying problems in the market. If a product doesn’t solve or avoid problems in the market, then it’s probably not going to be a success in the market.
This diagram shows that product solves or avoids problems that stakeholders face.
That brings us to the definition of requirement. The definition of requirement is it specifies the least stringent conditions that must hold to solve or avoid a problem that a prospective customer or other stakeholder faces.
The requirements are [integrally] linked to problems. Requirements are all about defining what it means; defining the conditions that must exist before we would say that the problem has been solved.
That brings to mind an article I recently read by Steve Johnson of Pragmatic Marketing, in which he stated flatly "the requirement is the problem".
What that meant was a statement of a problem, and a statement of the conditions that must exist for us to say the problem is not there, is the requirement.
There are two types of requirements. Functional requirements and nonfunctional requirements. A functional requirement specifies what the system or the product will do or enable it to do. So it specifies a function. An example would be – let’s say our product is a car. A functional requirement for the car, would be that it enables users to travel from their origin to their destination.
Associated with that functional goal, that function, are sequences of interaction that may occur between the user and the product in order to achieve that goal. That’s what the use case is.
What’s important to recognize, though, is that a use case – it’s really the end goal of the use case – of the top level use cases of a product – that represent the functional requirements. The individual steps within the use case are a form of interaction design. They can also be functions but they are not functional requirements. They are design functions.
That brings us to nonfunctional requirements. You may ask, well, it seems like the steps in a use case really are important because the user is interacting with the system. They are the ones who are actually carrying out those steps.
In a sense, that’s true. But what they are trying to accomplish is things like not just the functional goal, but they’re trying to do it within – let’s take the car example – where they are traveling from origin to destination. When they are dong that, they want to make sure they are doing it fast enough; that it’s easy enough for them – those kinds of things.
Those are the nonfunctional requirements. Things like usability, speed, reliability, comfort, fuel efficiency—all of those things are attributes. If you look in the diagram, attributes characterize functions. So in the context of traveling from your origin to your destination, you want it to be fast, reliable, comfortable, etc.
When you do that, though, in order to make that a requirement, it has to be measurable. So you have to have metrics associated with each attribute.
A metric, for example, might be, for the fuel efficiency attribute, miles per gallon. It’s the way you measure fuel efficiency. Then you place constraints on that metric. So you specify that the product should get at least 50 mpg, let’s say. And there’s your nonfunctional requirement.
Another question that may be entering your mind - or may have entered your mind long ago - is wow, this is a very high level conceptualization of requirements. So high level that developers would not know what to build if they were given a thorough and comprehensive requirements document, using this conception of requirements.
You’d be right. Requirements aren’t enough to dump in the lap of a developer and expect them to be able to code from it. Design specifications are important too.
The lesson here is that a specification is not synonymous with requirement. There are two types of specifications; design specifications and requirements specifications. Requirements specifications are very important because they are all about that problem-, that all important problem-solving activity which is defining the problem you are trying to solve.
Design specifications are important too, though. Those include things like user interface specifications, use cases, the fleshed out steps in the use cases and things like that. They are definitely essential; they’re just not requirements.
Finally, here is the entire conceptual model. It may be a little small for some of you to read. I’d urge you to visit the entry on my blog where you can view a larger version of the model or print it out for your own purposes.
This screen is a combination of the other screens that I showed you. With that, I guess I’ll turn it over to Suzannah.
Questions and Answers
Q: How does viewing requirements this way fit in with Agile Software Development?
A: It fits in well but the thing to recognize, is that when you – one of the premises behind Agile – is that it’s almost impossible to fully understand all of the problems you are trying to solve before you actually start implementing your product.
In the context of an Agile product management and development environment, what you do is you develop an initial set of solutions for your requirements. But don’t try to be 100% about it because you never can be until you move into design, do some design and implementation, and get some feedback from your customers. That will typically shed light on some problems. Some problems will come to light that you hadn’t recognized before.
Q: What is the difference between acceptance tests and requirements?
A: Acceptance tests and requirements are [integrally] related. An acceptance test, however, is something that is practical to implement. Sometimes the problem that a customer wants solved is not readily, in practice, testable. It always should be, in principle, testable. It always should be something you can measure but in practice, sometimes that measurement is hard to make.
For example, let’s say the customer wants the car to last 7 years. In order to directly test that requirement, which is something we have to fulfill – it is something important to fulfill – we can’t just ignore it because it’s not easy to test – in order to test that directly, we would have to wait 7 years.
We would have to devise an acceptance test which would take 7 years for us to find the results.
So instead what we do is devise acceptance tests that approximate or give us a good idea or simulate the requirement we are trying to test.
Q: What are the key steps to coach and educate traditional business owners and product managers, to trust and think Agile on storycards instead of requirement documents?
A: I would say the first thing to do is to get buy-in for the notion that traditional Waterfall requirements documentation, where you assume you are going to get all the requirements right up front and throw them over the wall to the designers and the developers – doesn’t work.
One way to do it, is to gather the evidence and present the evidence about how that doesn’t work. And get buy-in for the notion that it doesn’t work. I think that’s the main prerequisite to getting them to think that maybe there is another way. Maybe you can use a little bit more Agile requirements documentation, such as storycards.
But I don’t know. I’m not personally endorsing the idea of storycards. But I do endorse the notion of an Agile approach to requirements which means that you don’t try to produce 100% of detail and accuracy up front and assume that it’s going to hold for the rest of the project.
Q: You mentioned you have to have metrics for your nonfunctional requirements but many times nonfunctional requirements are qualitative in nature. What are your feelings about this?
A: I guess an example would be good there – I’ve encountered an example before and used one before when trying to explain this, and that might be – a metric tends to imply a number.
Of course, sometimes an attribute is not measured in terms of a number. Sometimes it could be a color – a range of colors— of languages or something like that. That’s fine; I’m including that in the notion of a metric.
Q: If a customer says they want a button to be blue, is that a requirement?
A: It could be, but in all likelihood it’s not. Our responsibility as product managers is to ask "why". If the customer says they want the button to be blue, we need to understand why they want it to be blue. We can’t just say okay, we’ll make the button blue. We’re really shirking our responsibilities to understand what lies beneath that.
What we might find out, for example, is that they wanted it to be blue because that’s the traditional color scheme they are used to, where maybe blue buttons are okay buttons and red buttons are their cancel buttons – and they are afraid if you change that scheme on them, that they’re going to press the wrong button and possibly lose data, possibly result in the death of somebody – or other negative consequences.
We need to understand what that is. Once we do that, we can formulate it in terms of a nonfunctional requirement, like safety, and put metrics around it – like the likelihood that a user with a certain profile is going to lose data, cause death or whatever they are trying to avoid.
Thank you very much, Roger, for the extremely insightful presentation.
Roger Cauvin: All right; thank you. Again, I’m Roger Cauvin with Cauvin, Inc. It’s a product management and research firm in Austin, Texas.
Today as Suzannah mentioned, we’re talking about requirements concepts. The purpose of the presentation is going to be to clarify the concepts and terminology related to requirements.
I’m going to do three things. First, I’m going to show how existing requirements terminology is actually contradictory. Second, I am going to show how confusion leads to product development failures, and third, I am going to clarify the concepts to remove the contradictions.
I recently participated in an on-line debate about requirements terminology, and in that debate one of the other participants drew a distinction between external and internal aspects of products.
The idea is that the line between requirements and design can be drawn in the same way as between external and internal aspects of a product. So a requirement would specify the external behavior of the product, and the design specifies the internal details.
That sounds like a great distinction and a great way of drawing that line between requirements and design. Unfortunately it leads to contradictions.
What does a UI designer do? A UI designer specifies only the external aspects of the product when that UI designer produces a user interface spec. Well, if it’s only the external aspects of the product, then you would think they would be requirements. But then we’re led to the conclusion that UI designers do not design user interfaces. Which is a contradiction in terms.
Another example is FRSs, which are called "functional requirement specifications". We’ll talk a little bit later about what functional requirements are vs nonfunctional requirements but for now, you would think that a functional requirement specification would contain functional requirements and not contain nonfunctional requirements.
When I talk to colleagues who actually produce these documents, they insist that their functional requirement specifications include nonfunctional requirements. So we’re led to the conclusion – the contradictory conclusion again – that functional requirement specifications contain nonfunctional requirements.
You may be asking, well, this is all semantics. Why does this matter? Does this have any impact on how we do our requirements, and whether it impacts our product development processes, and whether we have successful products?
I argue that it does. Just about any problem solving expert that you talk to will say that the most neglected and the most important part of the problem solving process is first understanding and defining the problems you are trying to solve clearly.
When we fail to understand the distinction between requirements and design, we are essentially failing to understand the distinction between the problem and the solution and we therefore end up, very often, failing to clearly understand and define the problem. That leads to product failure.
Toyota understands this. Toyota is renowned for their process improvement practices. I recently read an article about Toyota’s process improvement practices, and in that article Toyota executive said the quote that is on the screen right now. That quote essentially says that one of the keys to Toyota’s process improvement successes has been their emphasis on first trying to understand clearly the problems they are trying to solve and what they are trying to improve, before jumping into possible solutions and ideas about how to achieve that.
I am going to introduce you now to the conceptual model which you see on your screen. A conceptual model depicts concepts and the associations among those concepts. The rectangles you see represent the concepts, and the lines you see between them represent the associations among those concepts.
Above each line or associated with each line, is a text description as well as what’s called multiplicity. Let’s look at product and problem.
A product solves or avoids problems. The multiplicities are the 1 and the asterisk you see. The asterisk means "any number of"; it could be zero to infinity. So we read that as, "one product solves or avoids any number of problems".
If you look under the stakeholder concept, you see a hollow triangle. The hollow triangle on the end of an association link depicts specialization; it is a special kind of association.
The way you read this is "an internal stakeholder is a kind of stakeholder". A user is a kind of stakeholder. A buyer is a kind of stakeholder. So what I’d like you to take away from this slide in the end, is the emphasis on solving problems.
Some of you may be familiar with Pragmatic Marketing – with whom I have no affiliation – but I respect what they teach and what they preach a lot – which is they talk about product managers’ primary responsibility being identifying problems in the market. If a product doesn’t solve or avoid problems in the market, then it’s probably not going to be a success in the market.
This diagram shows that product solves or avoids problems that stakeholders face.
That brings us to the definition of requirement. The definition of requirement is it specifies the least stringent conditions that must hold to solve or avoid a problem that a prospective customer or other stakeholder faces.
The requirements are [integrally] linked to problems. Requirements are all about defining what it means; defining the conditions that must exist before we would say that the problem has been solved.
That brings to mind an article I recently read by Steve Johnson of Pragmatic Marketing, in which he stated flatly "the requirement is the problem".
What that meant was a statement of a problem, and a statement of the conditions that must exist for us to say the problem is not there, is the requirement.
There are two types of requirements. Functional requirements and nonfunctional requirements. A functional requirement specifies what the system or the product will do or enable it to do. So it specifies a function. An example would be – let’s say our product is a car. A functional requirement for the car, would be that it enables users to travel from their origin to their destination.
Associated with that functional goal, that function, are sequences of interaction that may occur between the user and the product in order to achieve that goal. That’s what the use case is.
What’s important to recognize, though, is that a use case – it’s really the end goal of the use case – of the top level use cases of a product – that represent the functional requirements. The individual steps within the use case are a form of interaction design. They can also be functions but they are not functional requirements. They are design functions.
That brings us to nonfunctional requirements. You may ask, well, it seems like the steps in a use case really are important because the user is interacting with the system. They are the ones who are actually carrying out those steps.
In a sense, that’s true. But what they are trying to accomplish is things like not just the functional goal, but they’re trying to do it within – let’s take the car example – where they are traveling from origin to destination. When they are dong that, they want to make sure they are doing it fast enough; that it’s easy enough for them – those kinds of things.
Those are the nonfunctional requirements. Things like usability, speed, reliability, comfort, fuel efficiency—all of those things are attributes. If you look in the diagram, attributes characterize functions. So in the context of traveling from your origin to your destination, you want it to be fast, reliable, comfortable, etc.
When you do that, though, in order to make that a requirement, it has to be measurable. So you have to have metrics associated with each attribute.
A metric, for example, might be, for the fuel efficiency attribute, miles per gallon. It’s the way you measure fuel efficiency. Then you place constraints on that metric. So you specify that the product should get at least 50 mpg, let’s say. And there’s your nonfunctional requirement.
Another question that may be entering your mind - or may have entered your mind long ago - is wow, this is a very high level conceptualization of requirements. So high level that developers would not know what to build if they were given a thorough and comprehensive requirements document, using this conception of requirements.
You’d be right. Requirements aren’t enough to dump in the lap of a developer and expect them to be able to code from it. Design specifications are important too.
The lesson here is that a specification is not synonymous with requirement. There are two types of specifications; design specifications and requirements specifications. Requirements specifications are very important because they are all about that problem-, that all important problem-solving activity which is defining the problem you are trying to solve.
Design specifications are important too, though. Those include things like user interface specifications, use cases, the fleshed out steps in the use cases and things like that. They are definitely essential; they’re just not requirements.
Finally, here is the entire conceptual model. It may be a little small for some of you to read. I’d urge you to visit the entry on my blog where you can view a larger version of the model or print it out for your own purposes.
This screen is a combination of the other screens that I showed you. With that, I guess I’ll turn it over to Suzannah.
Questions and Answers
Q: How does viewing requirements this way fit in with Agile Software Development?
A: It fits in well but the thing to recognize, is that when you – one of the premises behind Agile – is that it’s almost impossible to fully understand all of the problems you are trying to solve before you actually start implementing your product.
In the context of an Agile product management and development environment, what you do is you develop an initial set of solutions for your requirements. But don’t try to be 100% about it because you never can be until you move into design, do some design and implementation, and get some feedback from your customers. That will typically shed light on some problems. Some problems will come to light that you hadn’t recognized before.
Q: What is the difference between acceptance tests and requirements?
A: Acceptance tests and requirements are [integrally] related. An acceptance test, however, is something that is practical to implement. Sometimes the problem that a customer wants solved is not readily, in practice, testable. It always should be, in principle, testable. It always should be something you can measure but in practice, sometimes that measurement is hard to make.
For example, let’s say the customer wants the car to last 7 years. In order to directly test that requirement, which is something we have to fulfill – it is something important to fulfill – we can’t just ignore it because it’s not easy to test – in order to test that directly, we would have to wait 7 years.
We would have to devise an acceptance test which would take 7 years for us to find the results.
So instead what we do is devise acceptance tests that approximate or give us a good idea or simulate the requirement we are trying to test.
Q: What are the key steps to coach and educate traditional business owners and product managers, to trust and think Agile on storycards instead of requirement documents?
A: I would say the first thing to do is to get buy-in for the notion that traditional Waterfall requirements documentation, where you assume you are going to get all the requirements right up front and throw them over the wall to the designers and the developers – doesn’t work.
One way to do it, is to gather the evidence and present the evidence about how that doesn’t work. And get buy-in for the notion that it doesn’t work. I think that’s the main prerequisite to getting them to think that maybe there is another way. Maybe you can use a little bit more Agile requirements documentation, such as storycards.
But I don’t know. I’m not personally endorsing the idea of storycards. But I do endorse the notion of an Agile approach to requirements which means that you don’t try to produce 100% of detail and accuracy up front and assume that it’s going to hold for the rest of the project.
Q: You mentioned you have to have metrics for your nonfunctional requirements but many times nonfunctional requirements are qualitative in nature. What are your feelings about this?
A: I guess an example would be good there – I’ve encountered an example before and used one before when trying to explain this, and that might be – a metric tends to imply a number.
Of course, sometimes an attribute is not measured in terms of a number. Sometimes it could be a color – a range of colors— of languages or something like that. That’s fine; I’m including that in the notion of a metric.
Q: If a customer says they want a button to be blue, is that a requirement?
A: It could be, but in all likelihood it’s not. Our responsibility as product managers is to ask "why". If the customer says they want the button to be blue, we need to understand why they want it to be blue. We can’t just say okay, we’ll make the button blue. We’re really shirking our responsibilities to understand what lies beneath that.
What we might find out, for example, is that they wanted it to be blue because that’s the traditional color scheme they are used to, where maybe blue buttons are okay buttons and red buttons are their cancel buttons – and they are afraid if you change that scheme on them, that they’re going to press the wrong button and possibly lose data, possibly result in the death of somebody – or other negative consequences.
We need to understand what that is. Once we do that, we can formulate it in terms of a nonfunctional requirement, like safety, and put metrics around it – like the likelihood that a user with a certain profile is going to lose data, cause death or whatever they are trying to avoid.
Thank you very much, Roger, for the extremely insightful presentation.
Comments