Valuable and Functional Requirements

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 build

But 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?

Roger Cauvin

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.