concept nonfunctional requirement in category software development

This is an excerpt from Manning's book Writing Great Specifications: Using Specification by Example and Gherkin. Login to get full access to this book.

8.3.2. Can Gherkin specify nonfunctional requirements?

Throughout the book, I’ve treated Gherkin scenarios as behavioral requirements. As behaviors, scenarios should by definition be functional requirements. But the relationship between behaviors, functional requirements, and nonfunctional requirements is more complicated than it may seem. For example, security requirements may imply a two-factor authentication function; in this case, a nonfunctional requirement is generating a functional requirement. And some nonfunctional requirements can be phrased as behaviors, like this scenario:

Given a search form
 When the user submits a query
 Then the user should see the result in less than 100 seconds

copy

I’ll agree that, in this case, the nonfunctional requirement sounds like it’s being forced into the template. That’s because I mixed two domains—the search domain and the performance domain—while trying to write the scenario in the outside-in style you’ve been practicing throughout the book. Unfortunately, only the search domain fits the outside-in style meant for stakeholders; the performance domain, which is the main domain of this scenario, must be written in another style. But is that possible? I’m playing devil’s advocate right now, but let’s think about that for a moment.

Whereas functional requirements define the utility of a system, nonfunctional requirements define its architecture. They aren’t related to any particular vertical functionality. So, if we said that a specification suite is like a map of requirements, should nonfunctional requirements be on the map, too? The answer isn’t unequivocal. In this section, we’ll look at the question from two angles:

How to handle nonfunctional requirements according to SBE’s key patterns

The difficulty of writing nonfunctional requirements in Gherkin

I have to admit that conveying nonfunctional requirements in Gherkin isn’t an established practice. I haven’t seen any Gherkin thought leaders advising this approach. Other than one practical use case, which you’ll see in section 8.3.4, most of the ideas outlined in this case are theoretical. So if you’re only interested in learning practical techniques, go straight to section 8.3.4.

I was even advised to drop the terms functional and nonfunctional requirements, because the differences between them can cause confusion. I decided to keep the terminology intact, because I assume that many readers are already familiar with it. There’s no point in pretending the terms and the controversy don’t exist. This is also an interesting topic to explore. With some hesitation, I decided to include it here so that you can build a more complete understanding of requirements in your specification suites.

Figure 9.3. A specification suite with both abilities and business needs becomes a map of functional requirements and stakeholders who find them important, as well as functional aspects of nonfunctional requirements important to the entire system.

This is an excerpt from Manning's book Specification by Example: How Successful Teams Deliver the Right Software. Login to get full access to this book.

“At the moment we’re working on a component that’s been there for a long time and adding more messages to it. There is not really much need for the whole team to know what that involves; we can wait until we pick up the story card. Some other teams are building a new GUI, completely new functionality, and then it might be more appropriate for the whole team to sit down and discuss this in depth and try to work out what needs to be done. At that point we might also discuss nonfunctional requirements, architecture, etc.”

So far, I haven’t seen a single nonfunctional requirement that couldn’t be illustrated using examples. Even usability, perhaps the vaguest and most subjective concept in software development, can be illustrated. Ask your usability expert to show you a website that she likes; that’s a good, realistic example. The validation of such examples might not be automatable, but the example is realistic and precise enough to spark a good discussion. Here are some ideas that will help you capture nonfunctional requirements with examples.

This is an excerpt from Manning's book Becoming Agile ...in an imperfect world. Login to get full access to this book.

The planning phase is followed by the productionizing phase, during which the code is certified for release. Certified means the code passes all customer tests plus nonfunctional requirements such as load testing, service-level requirements, and response-time requirements. You can see an overview of XP in figure 3.3.

21.2.4. Validation of nonfunctional requirements

Before you release, you need to make sure the underlying system performs as required. System requirements are frequently overlooked by the customer, and the project team can coach the customer in determining nonfunctional requirements.

System requirements don’t match up to a user story or specific functionality; instead, they represent the overarching ability to support service requirements. For example, Dairy Queen may have to support a user story where a customer orders and receives an ice cream cone. The user story steps may include customer orders the cone, employee creates the cone with the ice cream machine, and the employee delivers the cone. The user story meets the needs of one user, but it doesn’t say how many ice cream cones the system can support during a day. How many cones you must deliver in a day is an example of a nonfunctional requirement.

Nonfunctional requirements are as critical as the ability to support a specific user story. If the system fails, you won’t be able to support any user stories.

Experienced customers understand the importance of nonfunctional requirements, usually because they have paid the price for not specifying them in the past. These customers provide service-level requirements that are used to create a service-level agreement (SLA). The SLA helps the customer and the team reach agreement about realistic expectations of the system.

Figure 21.2. Nonfunctional requirements, such as the maximum number of users that can be supported, are just as important as the features themselves. Macy’s probably has a great user experience behind this screen; too bad the system can’t take any more customers at this time.

In many cases, nonfunctional requirements are determined by the company providing the service (you) versus an individual customer. For example, Acme Media’s product manager identifies the nonfunctional requirements for Acme Media’s platform based on what he feels will be acceptable to customers.