Non Functional Requirements

Non Functional Requirements have also been called the 'ilities' because they are most simply expressed like this:

usability reliability interoperability scalability security

There are other ones (In my Humble Opinion)

Time to market
Cost
Speed
[RAM]
[secondary storage]

In what sense could the last two be requirements, non-functional or otherwise?

In some environments, RAM utilization and secondary storage (or lack of it) are very real restrictions. There are many other restrictions that may be imposed by particular hardware environments, but it is probably not beneficial to individually identify them.

Functional Requirements are either met or not met. Non-functional requirements tend to be things that you can measure.

It helps if you can translate each one into some measurable property of the final product otherwise the client can always claim that the product is not good enough.

It helps a lot if you know what is the ``most critical`` non-functional requirement because this can dominate the best choice of development technique and internal design. For example: If reliability is critical because a bug will kill a lot of people then you might use more peer review, independent validation, multi-version, etc. If time to market is the critical thing, then you might do something quite different.

Unfortunately, the criticality of requirements vary. For example, as reliability increases, performance or cost may overtake it as the most critical requirement. One has determine a balance between requirements addressing them as a whole; one cannot go down a checklist addressing them one at a time. To carry the "balance" analogy further, hold a broom on end in your open hand. What is the "most critical" adjustment? Is it left, right, forward, or back? Or is balance maintained through constant adjustment through all?

Now that you can measure your success when its done, perhaps you should also have a way of predicting the ilities before you finish the product. And that gets us to SoftwareMetrics.

I think scalability should also be considered a NonFunctionalRequirement. My question to the community is: how does XP deal with non-functional requirements? Should they be brought into the dev process as user-stories? engineering tasks? -- AlejandroGoyen

I tend to call the Non-Functional requirements qualities and functions/user-stories/use-cases purposes. I see them as two out of five types of constraint that act while developing software.

the other three being...

UserAntiStories (if they exist) are another kind of non-functional requirement. A UserAntiStory describes something that must not happen whereas a function describes something that must be done. Also see ThereAreNoUserAntiStories. -- DickBotting

"Functional Requirements are either met or not met. Non-functional requirements tend to be things that you can measure."

I think these sorts of nonfunctional requirements are only strictly nonfunctional if there are not rigidly defined areas of success and failure, or if the requirement is a subjective evaluation, such as usability. Scalability, speed, RAM usage etc can all be measured, and appropriate values can be assigned to denote such a requirement "being met" or not. This would, by the statement above, make them more akin to functional requirements. -- JacobCohen

Well FunctionalRequirements define what the system needs to do whereas NonFunctionalRequirements describe how (adverbially) the system will do it. The functional requirement is to produce an employee's pay slip for an employee, the non-functional requirement is to print a pay slip per employee (up to, say, 10,000) in, say, 48 hours elapsed. The non-functional requirement may be one of the CriticalSuccessFactors, it may even be the prime driver for the development, but it is still non-functional.

It is true that all requirements can be specified in measurable terms. The rub lies in measuring. For instance, a client may ask for something that is "higher quality than the previous product," without really specifying how that quality is to be measured. We then ask leading questions about mean time between failures, rate of repair calls, hours of tech time to fix field failures, cost of maintenance, etc. Perhaps the client says he wants the new product to be "smarter" than the old one. We then ask about decisions the user had to make with the old product and compare that to inputs the new product has and the decision capability we can now put into the new product. The client will probably ask for it to be "easier to use" than the old one. A toughie, but how about setting up measurements with off-the-street testers to see if they can use the new box easier or get work done in less time than the old product?

All requirements that seem to be qualitative instead of quantitative can still be expressed as hard numbers if the client and developers are willing to work together to establish measurements.

This is not quite true. You can provide measurements as surrogates for the quality you are trying to improve, but do not forget that the measurement is only a very small piece of the desired quality. It is too easy to destroy the system while improving the measure.

Then how about making sure that the client's requirements incorporate everything he thinks is a characteristic of value? In this way we avoid having measurement as "a very small piece of the desired quality." If the "desired quality" is stated as some objective characteristic that can be quantified then we can assign measurements to that quality. Otherwise, how are we ever going to know what we're talking about?

BenKovitz's PracticalSoftwareRequirements has some very useful sections on different types of requirements, what they're useful for, and how to represent them in text. One helpful suggestion is that, if you can't specify how the product can behave ("easy to use" -- huh?), you can still usually describe the people and things around the product.

"The client has high staff turnover, and expects to provide one hour's training on the product for new employees." This will help the UI team design the interface.

Or even better: "The total package shipment time from request to delivery is several hours. Request notifications can take several minutes to arrive in the warehouse without any ill effect, but anything beyond 30 minutes causes noticeable delays downstream. A one hour request notification risks violating the customer's Service Level Agreements." That gives the architecture team more flexibility in how to set up the request delivery system and what contingency plans to put into place.

Concept Engineering

Concept Engineering was an approach I was introduced to in the 1990s. The focus of this approach was to rely less on numeric requirements and instead focus on the operational environment. Instead of using requirements such as "Open a new page in 8 seconds or less", make use of descriptive statements such as "I have a long line of people who I need to process before lunch."

Part of the point is that the numeric values associated with traditional requirements are often arbitrary. Does "8 seconds" mean never more than 8 seconds, or to average less than 8 seconds? Would pages opening in 9 seconds have any real affect on the user in the environment described above? The end user will probably be unconcerned with the value "8 seconds", rather the user's concern will be "Am I having to wait for pages to load, rather than doing my job?"

I have become convinced that the true factors that decide user acceptance are subjective, and relying on numeric surrogates masks the truth. If that is true, most if not all requirements would seem to fall in the category of NonFunctionalRequirements.

That has a nice ring to it, but it still bothers me that engineers can hide their performance woes behind a wall of "non-functional" excuses. "No, it can't open a page in under 15 seconds, ever, but it doesn't need to because the user has to wait for blah blah blah anyway, and the 15 seconds is inconsequential compared to that." Uh, oh. Now we're approaching a sort of ScheduleChicken in reverse, where individual components of the system start tacking on more time than they need to because "everybody's doing it." Oy!

I'm not certain there's any real break down here between FunctionalRequirements and NonFunctionalRequirements. I assume that requirements like 'must be coded in Java' is a NonFunctionalRequirement, but I don't see how that's captured in any definition here. Other NonFunctionalRequirements not capture here are 'must follow this particular coding standard', 'must have 1000 reasonable unit tests'. -- RandyCharlesMorin

I agree. Firstly, the grey areas between functional and non-functional requirements can be debated interminably. For example, "the number of angels that can dance on the head of a pin" is definitely functional, right? Secondly, it doesn't help. If it's a requirement, you must meet it, and you must satisfy the stakeholder for that requirement. This can be done without either of you ever caring whether it is functional or non-functional. For what it's worth, I personally regard security and performance as being functional (usually), whereas several of my colleagues disagree. As long as we agree to restrict this debate to the pub, the project will get along just fine. --DominicCronin

See: PutaNumberOnIt, DontPutaNumberOnIt (these and other requirements pages could perhaps be refactored together into point/counterpoint presentations)

CategoryRequirements, CategoryMetrics