Abstraction And “Requirements”

Roger had some good comments in our previous article – we’ll try and address one of his points here. His point, I believe, is that using the word “requirements” to describe multiple levels of abstraction in the definition of a product is a bad thing.

Part of Roger’s Comment

Hopefully, this is the main point, not taken out of context by me. Check out the Requirements Naming for full context.

My real point is that I don’t think it’s possible to reconcile all of the terminology (”market requirement”, “product requirement”, “functional requirement”, “nonfunctional requirement”, “software requirement”) associated with these documents.

I believe we agree that there are different levels of abstraction, and that they are valuable. Even smaller teams will benefit from a distinction between “where’s the value” and “how do we realize the value?” Roger also said:

I have no issue with two levels of documents, at least in theory. I just don’t see how you can reconcile the terminology.

Adjectives

I believe that adjectives act as sufficient modifiers to differentiate the applications of the term “requirement.” Roger argues that a linguist would search for names of things that are appropriate without causing confusion. His point, I believe, is that having the word “requirement” in both of the following names does irreconcilable harm : “product requirements document” and “software requirements specification.”

I think the re-use of the word is annoying, not harmful.

Abstraction

I believe there are some fundamental layers of abstraction that are critical to understand in order to achieve software product success.

• What value are we trying to create?
• What processes will people/systems follow to realize that value?
• What capabilities and characteristics must the product include to enable people to follow those processes?
• What design approach will be used to implement the capabilities with the required characteristics?

Different teams in different environments will formalize these elements differently. The decomposition approach from value to implementation is a good one – it separates different types of problem-solving and ideation in a way that makes the overall problem more tractable. Our article, Software Requirements – Process and Roles, takes a detailed look at precisely this point.

Naming The Abstractions

We could come up with terminology for each level of abstraction that do not re-use words. As my grandpa would have said, “You’re closing the barn-doors after the horses got out!” I believe it is pointless to try and re-name things that already have established names. There are millions of hits in Google alone for these terms. Our best bet is to try and share an understanding of what is intended by each name.

The issues around the naming of functional and non-functional requirements are different, as they are not variations in abstraction, but rather classification of elements at the same level of abstraction.

Non-Functional Requirements

There is value in maintaining the classification of non-functional requirements. Requirements that represent different aspects of what shall be done should be separated, but they should also be treated with equal importance.

• Functional requirements define what the system must be able to do, without defining how this is to be accomplished. The system shall store contact information. The system shall apply shipping and tax charges when billing customers.
• Non-functional requirements define measurable, characterizing aspects of what the system must be able to do. The system shall return search results in under ten seconds. The system shall process at least 10,000 orders per minute.

Non-Functional Requirements Equal Rights Amendment

These two types of requirements should be separated to assure atomicity of our requirements. This separation allows our developers to do things like deliver the functionality first, and improve the performance second. This benefit alone requires (hah!) us to treat them separately.

Using different names to classify these two types of mandates provides minimal value, sure. I believe it also does minimal damage. The benefit of having different modifiers (functional versus non-functional) is that it reminds us to write them differently. Some authors have distinguished these as “what” versus “how well.”

I also believe that the distinction between the two is well defined and understood in the context of “those things you write to assure that software enables use cases to be executed.” To the best of my knowledge, that is the only context in which the term is commonly used (aside from your questions in an earlier article on product requirements).

Conclusion

I don’t know how many of our readers have reached a conclusion to this debate, but we have for now. Thanks to everyone who has contributed to, enjoyed, or at least tolerated this ongoing discussion.

• Different terminology exists for describing requirements at different levels of abstraction.
• There are choices of documentation approaches to use at each level of abstraction (MRD or PRD, FRS or SRS).
• Having the different levels of abstraction is valuable as an organizational approach to creating great software.
• Functional and Non-functional requirements are different things with precise definitions in a single context.