Nonfunctional Requirements

Posted on Wednesday 13th March 2013

Summary

This post discusses nonfunctional requirements such as performance, robustness, and interoperability, and the Ford Shelby Mustang GT500.

2013-Ford-Mustang-Shelby-GT500-burnout

I don’t know about you, but every time I read the word “nonfunctional”, I feel a yawn coming on, and I start to look for something else to do. While nonfunctional requirements or quality attributes, as they are also called, may not be sexy, they are still important: They impact the user experience, and they influence architecture and design decisions.

Say you are looking for a new car, and you’ve found one that looks great. The car also has a powerful engine, lots of safety features, and a sat nav. But during a test drive, you discover that it’s noisy inside the cabin, the seats aren’t comfy, and the actual fuel consumption is surprisingly high. While the car has all the right features, the driving experience is not great – and that’s due to its poor nonfunctional properties.

Another example is the training part of my website. If the response time is sluggish, and it takes too long to receive a confirmation once a seat has been booked, then users are unlikely to have an enjoyable experience. Other common nonfunctional requirements include robustness, interoperability, usability, and compliance with a regulation or a standard.

Discovering Nonfunctionals

As important as they are, nonfunctional properties are sometimes overlooked, particularly in an agile context where we spend less time with upfront research and analysis. This can be particularly painful for those attributes that apply to the entire product. If, for instance, you forget to capture that your mobile app should be available on iOS and on Android, then this may require correcting fundamental architecture and technology choices, which is likely to delay the project or make it more expensive.

If you are unsure which nonfunctional requirements are important for your product, then I suggest you engage with the users and the development team. Try observing users, conducting problem interviews, and carrying out user tests using early product increments / prototypes. The tests allow you to discover new attributes and to understand if, for instance, the performance is acceptable.

The development team is a great partner for finding relevant nonfunctional requirements, particularly if the team members have worked on a similar product before or deal with support and production issues. If that’s not the case, then you should consider inviting members of the operations and customer services group to listen to their views on qualities such as robustness and availability.

Describing Nonfunctionals

I like to capture nonfunctional requirements as constraint stories. Here is an example:

Constraint Story

I call the story above a constraint, as it constraints other user stories. Just like a regular story, the constraint has two parts: a narrative and a list of acceptance criteria. The narrative describes the nonfunctional requirement from the perspective of the persona Mary. The criteria clarify the interaction and describe the environment. Both are required to validate the constraint. (Tom Gilb’s Planguage, which is an alternative approach to describing nonfunctional requirements, would call the first condition “scale” by the way. The narrative contains the “target” and the “gist”.)

Whatever format you choose to capture your nonfunctionals, ensure that the description precise and testable. If I say, for instance, that booking a training course on our website should be quick, then that’s a first step towards describing the attribute. But it would be too vague to characterise the desired user experience, to help the development team make the right architecture choices, and to validate the constraint. I will hence have to iterate over it, which is best done together with the development team.

Summary

Explore nonfunctional requirements that apply to the entire product or to important features early on. This helps you create a great user experience, and make the right architecture and technology decisions. Capture the requirements precisely to ensure testability. And don’t rush to test-drive a Ford Shelby Mustang GT500 depicted at the top of this post. It’s not the greatest sports car on the planet – at least according to Top Gear’s Jeremy Clarkson.

You can find out more about working with nonfunctional requirements by attending my Certified Scrum Product Owner training course. Unfortunately, I won’t be able to tell you more about Mustang cars: I’ve only driven one many years ago and only for a few miles. All I remember is: It was fast.

  • Pingback: A Product Canvas for Agile Product Management

  • Pingback: Epics and Ready Stories

  • Pingback: Five Steps to Successfully Groom your Product Backlog

  • Pingback: Top 10 Product Backlog Tips

  • Pingback: The Definition of Ready in Scrum

  • Pingback: Synesthesia

  • Pingback: How to Create your Initial Product Canvas

  • Pingback: 5 Common User Story Mistakes by Roman Pichler

  • ZS

    Given how you’ve suggested to describe NFRs, how do you propose the definition of ‘done’ should be for an NFR story? (since it’s never actually ‘done’ due to NFRs being a constant constraint for every story pretty much)

    • http://www.romanpichler.com Roman Pichler

      I consider a constraint story as “done” when its narrative has been implemented successfully and the acceptance criteria are met. You may want to state in your Definition of Done that the generic NFRs in your Product Canvas or product backlog – those NFRs that apply to all stories – have to be fulfilled. Does this help?

  • http://blog.cauvin.org Roger L. Cauvin

    As Gause and Weinberg wrote long ago, nonfunctional requirements are usually constraints on functional requirements. The context for a nonfunctional requirement is typically some set of system functions.

    Accordingly, I think it makes sense to capture the nonfunctional requirements as acceptance criteria for epics or user stories, without separate stories for nonfunctional requirements.

    • http://www.romanpichler.com Roman Pichler

      Hi Roger, Thanks a lot for your comment. I share your view, as long as an NFR or constraint is limited to an epic or story. But when nonfunctional properties constrain the entire product or several epics, I find the introduction of a separate constraint story helpful. Examples are generic performance requirements, or a robustness requirement that applies to all payment stories. Do you agree?

      • http://blog.cauvin.org Roger L. Cauvin

        It does seem like a judgment call. However, I find that nonfunctional requirements that apply to the entire system or more than one epic are a red flag. For example, it’s unlikely that the same performance constraint truly is “required” for all functionality of the system.