To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
Expert Robin F. Goldsmith responds...
Many of the difficulties encountered in defining requirements relate to the functional-nonfunctional distinction. As so often happens, some of those difficulties are things of which people are aware, largely realizing after-the-fact that nonfunctional requirements were missed. However, perhaps more, and certainly the more insidious difficulties, involve other issues of which people may not be aware and often may be incurring intentionally due to mistaken understandings.
Functional Requirements
Most requirements definition focuses mainly on functional requirements, which are based upon the expected functioning of the product or system to be created. Functioning, typically is equated with product/system features for which you might have a menu or button choice, such as: identify a customer, select an item to order, and calculate the amount due.
All things considered, requirements definers probably are best at identifying functional requirements, although they often overlook and get wrong more of the functional requirements than they ordinarily recognize. On hindsight reflection, they frequently do realize that many of the problems which surface later, and thus are harder and more expensive to fix, are attributable to inadequately addressed nonfunctional requirements.
Nonfunctional Requirements
Nonfunctional requirements refer to a whole slew (I've identified more than 30) of attributes including performance levels, security, and the various "ilities," such as usability, reliability, and availability. Invariably, requirements definers get wrapped up in how the product/system is expected to function and lose sight of these added elements.
When such factors are not addressed adequately, seemingly proper product/system functioning in fact fails to function. For example, a system may identify customers in such a slow, insecure, and difficult to use manner that it can cause mistakes which make data unreliable, provoke frustration-based attempted work-arounds that can create further problems, and ultimately lead to abandonment.
That's the recognized way in which nonfunctional requirements impact product/system success. Other often unrecognized issues also need to be appreciated.
"Nonfunctional" is misleading
First, I would encourage calling them "quality factors" or "quality attributes" rather than "nonfunctional requirements," which I believe is misleading. "Nonfunctional" implies they exist in the abstract or can be pigeon-holed, which can only lead to nonsensical questions such as, "How much usability do you need?" You don't need a bunch of usability. Rather, these requirements are relevant only with respect to functionality. For example, usability requirements pertain to particular usage situations; and a given product or system can have many different usability requirements—for each of the respective usage situations.
Also I'll caution against calling them a common alternative term, "quality requirements," which implies erroneously that these factors by themselves are what is meant by "quality." Instead, quality first and foremost comes from suitable functionality. Speed, ease of use, and the like contribute to quality if and only if associated with useful functionality.
Templates and checklists are helpful for remembering to find out about these factors but should not dictate the manner in which they are stored. That is, you shouldn't just have a group of usability requirements, a group of security requirements, and so on. Rather, all the relevant quality factors modifying a particular requirement should be captured with it.
Both Are Really Design
A second, far less recognized but very important issue with functional and nonfunctional requirements is that they actually are forms of high-level design pertaining to a product or system which is expected to be created. A tip off is that frequently they are called "specifications" instead of or in addition to "requirements." "Specification" is design.
Problems occur when the bulk of requirements definition is focused on specifying the product's functional and nonfunctional requirements, which is usually what happens. The product/system will provide value if and only if it actually satisfies the REAL, business requirements.
When most of the attention is directed toward the product/system presumed solution, there's too little understanding of what the product/system must accomplish to provide value; and what seems like a suitable product/system often turns out not to provide the value it should.
The key is first to discover the REAL, business requirements deliverable whats that provide value when met and then design a product/system how to satisfy the whats.
More Articles on Requirements:
Functional and nonfunctional requirements
Requirements may be functional or nonfunctional and both are essential to a successful software project. Expert Roxanne Miller explains the differences between these types.
Expert Response
Read Full Article
The Pareto principle for well-defined functional software requirements
Following the Pareto principle, 20% additional effort by the business department can result in requirements accuracy and completion improved by 80%.
Technical Tip
Read Full Article
Use functional and regression testing to validate SOA solutions
With service-oriented architecture (SOA) applications, the quality of the individual services does not necessarily translate into the overall quality of the business solution.
Technical Tip
Read Full Article
|
