Roger asked some interesting questions on one of our previous posts about market and product requirements. In a couple recent articles, we presented some specific examples to clarify the semantics and language of different types of requirements. Roger asks six questions about functional and non-functional requirements in the comments on the last article. In this article, we answer them.
Roger’s Questions
We started with an example of a quantified market requirement. We then extended that example to show how to create product requirements from the market requirement. As part of the ongoing conversation, we clarified the semantics of our language with an article about context and perspective. Roger’s comments followed that article.
Okay, so if I understand your semantic framework correctly, we have:
market requirements – goals to achieve to solve market problems
product requirements – goals for the software or product to achieve
functional requirements – what developers should buildBut then:
1. Can a market requirement be functional?
2. Can a market requirement be nonfunctional?
3. Can a product requirement be functional?
4. Can a product requirement be nonfunctional?
5. Is it the case that every requirement is either functional or nonfunctional?
6. Are the functional requirements what the developers should build, or do they need both the functional and nonfunctional requirements to know what to build?
Valuable Requirements
Market requirements and product requirements are not about functional / non-functional distinctions. Market and product requirements are about value. These requirements are designed to identify opportunities (market requirements) and identify strategies for addressing them (product requirements). They do not specify how a particular implementation approach (product, process, etc) will achieve them.
Market requirements and product requirements are goals.
Goals can be driven by
- Hard ROI. In our example, we target a 50% reduction in food spoilage cost. Hard ROI goals are measurable.
- Soft ROI. Branding is a classic example of soft ROI. A strong brand will drive more (or better) sales of a product. But you can’t quantify how much a brand is improved or how much that improvement will improve your margins.
So, to answer the first five questions:
Market requirements and product requirements are neither functional nor non-functional. They are valuable, and the value is either measurable or not. Therefore, not all requirements can be classified along the functional/non-functional axis. Along that dimension, market and product requirements are undefined.
What Should Developers Use?
Roger’s final question is a bit unrelated to the first five. Developers should not be writing code (creating designs) directly from market or product requirements in a structured requirements framework. They should be building the solution relative to a functional requirements document or software requirements specification (FRS or SRS, respectively). We can see the continuum of documents in the following diagram from One Man’s Trash.
In that diagram, we describe five layers: market, requirements,specification,design, and implementation. The design should be built from the specification, and the implementation should be built from the design. Note that this framework holds true for both agile and waterfall processes.
Non-Functional Versus Functional
The FRS is unfortunately named, as people could infer that it therefore excludes non-functional requirements. Non-functional requirements are still requirements, and deserve equal attention. The following diagram shows that non-functional requirements are derived from (or created in support of) goals, just like functional requirements.
Both are components that drive design and therefore implementation.
As an aside, constraints don’t drive requirements, they drive design. An example of a constraint in the wild: Numenta, Inc. is creating memory systems modeled on the way human brains process information. Their software development choices, when creating applications (like robot navigation systems) are constrained to use this particular technology.
Summary
Market requirements and product requirements can be characterized based on value, but are undefined along the functional/non-functional axis. The requirements that make up a specification can be classified as functional or non-functional. And these are the requirements that drive design. Design boundaries are defined by constraints.
Thanks for continuing the discussion, Scott. Let me summarize some of your latest points:
1. Market requirements are neither functional nor nonfunctional. The distinction simply doesn’t apply to market requirements.
2. Similarly, product requirements are neither functional nor nonfunctional.
3. The document that some call an FRS (functional requirements specification) contains (or at least should contain) nonfunctional requirements and is therefore a misnomer.
Now, let’s examine an example you have given of a product requirement:
“The system shall recommend ingredient purchase amounts and timing that would reduce spoilage by at least 50% against the baseline.”
Since this statement specifies a product requirement, you would consider it neither functional nor nonfunctional. But it is equivalent to the combination of two requirements:
R1. The system shall recommend ingredient purchase amounts and timing.
R2. Spoilage stemming from the system’s purchase recommendations shall not exceed 50% of the baseline amount.
R1 specifies what the system should do. R2 specifies a measurable, characterizing aspect of R1.
In light of this analysis, why do you not consider your example of a product requirement a combination of a functional and nonfunctional requirement?
Good point in that I have combined both “what” and “how well” in the same requirement. Since I do not believe that the functional/non-functional (formal) designation has historically been applied to product requirements, I am not sure I like the idea of applying those particular lables to the product requirements.
I see the evolution of requirements terminology as follows:
1. The classical gurus, such as Donald Gause and Gerald Weinberg, put forth a coherent vocabulary for requirements concepts. They were not always perfectly consistent, but the inconsistencies were minor.
2. Confused people, heavyweight methodologies, and Conway’s Law distorted and expanded the classical vocabulary in a manner that produced glaring inconsistencies and incoherence (e.g. “functional requirements specifications” that contain nonfunctional requirements).
3. Folks like Karl Weigers attempted to account for all of the diverse terminologies but didn’t point out their flaws.
Merely noting and accounting for the terminology that’s out there is fine. But in your diagrams and posts, you’ve portrayed the terminology – at least implicitly – as consistent and coherent. I don’t think it’s proper to portray the notion of a requirement that describes what the product should do yet isn’t functional in that manner.
Hey Roger,
Somehow I missed this comment when it came in. Sorry about that.
Your background data helps clarify your perspective, and your point is valid. I’m still in more of the “make sense of the mess” mode than “try and force changes to fix it” mode. Maybe that will change.
Either way, thanks very much for helping create a community here and for keeping the discussion going on the stuff you are passionate about!