Catching a Cloud, Pinning it Down: How to Capture Non Functional Requirements in Agile

Catching a Cloud, Pinning it Down: How to Capture Non Functional Requirements in Agile

You’ve probably heard the expression that “the best things in life aren’t things at all.” Some of our favorite things, such as nights out at the movies, evening walks in the snow and road trips to national parks, wouldn’t mean a whole lot if they didn’t include “things” like laughter, connection, friendship and love.

What do warm fuzzies have to do with non functional requirements in agile? As it turns out these two things are very much alike.

Not a few agile teams have banged away on a big project–planning iterations, completing user stories, producing increment in every sprint–only to discover during testing (or even later) that the product is not in line with the client’s expectations.

The client ordered a pizza, and the team delivered it, exactly to specifications: 16”, pepperoni, piping hot. Yet it lacked something fundamental. Maybe the service was lousy, the restaurant too noisy, the delivery time too long. The team thought it provided just what the customer ordered, yet it wasn’t what they ordered at all.

This leaves the team frustrated and flummoxed. When you play by all the agile rules, such as meet requirements, hold retrospectives and study the burn down chart, how can things go wrong? And how do you change things going forward?

If you’ve learned the hard way that non functional requirements cannot be ignored, even while they cannot be measured, then this post is for you. We’re going to look at how these hazy requirements butt heads with agile, and how to capture and measure their “uncapturable” qualities each iteration.

The Definition of Functional & Non Functional Requirements

Let’s start by defining just what functional and non functional requirements are.

Functional Requirements

A functional requirement is a measurable quality or characteristic in a completed project. It’s concrete and often can be seen.

For example, if the project is building a website, a functional requirement may be to build a registration page that includes inputs for both name and email. If the project is to write a song, a functional requirement may be that it includes four stanzas and a chorus.

Since they’re quantifiable and measurable, it’s easy to tell whether or not a functional requirement has been met. It’s as simple as checking something off a list.

Non Functional Requirement

A non functional requirement is a quality or characteristic of a completed project that isn’t directly related to its functionality. It’s neither tangible or measurable, but related to overall qualities the project possesses, or the conditions under which the project must be met.

Non functional requirements (NFRs) include characteristics such as usability, scalability, security, compatibility and performance.

For example, a non functional requirement of “usability” for a website would affect several facets of the project. Copy that’s easy to read, pages that load quickly and a layout that makes navigation between web pages intuitive all contribute to “usability.” However, each of these requirements is quite diverse, and none of them has measurable specifications.

Since they’re nebulous and indefinable and bleed into all parts of a project, then, it’s difficult to determine when a non functional requirement has been met. It’s not so simple as checking a box on a list and pronouncing it “done.”

Further Distinctions between Functional and Non Functional Requirements

Non functional requirements are executive level, big picture goals, whereas functional requirements are easily measurable, definable goals that get into the granular and specifics of the project at hand.

Requirements in the real world aren’t always so cut and dry as to fall into either of these two categories. Many exist in a grey area between the two.

Another distinction between these two requirements is that there are multiple ways to meet an NFR, whereas meeting a functional requirement is clear and straightforward. For example, say a project has a NFR to “increase sales.” This increase may be achieved in one of several ways, including improving the software, increasing the hardware capability or by hiring more employees.

Now that we’ve defined each term, let’s look at how capturing NFRs in agile iterations is a bit like fitting a square peg into a round hole.

The Problem With Mixing NFRs & Agile

Agile teams work efficiently. The agile method is brilliant in part because it ensures a team dedicates its time and energy to increasing the business value of the end project. To this end, each iteration produces increment that meets specific, measurable criteria. Many scrum teams have even developed a “definition of done” that covers all the criteria a task must meet before the user story is complete.

Some agile teams use a system known as “Elephant Carpaccio” which breaks down a long-term project into individual tasks, each of which can be completed in a day. This way, each and every day the team takes another step toward its stated goal.

Everything the team does is a step toward a measurable goal. It doesn’t spend a lot of time going down rabbit holes or building something that has no business value to the client.

A nearly exclusive emphasis on concrete, measurable goals, however, doesn’t jibe with NFRs. Just like two opposite personalities in a workplace, it’s tempting for the agile method to try and sideline NFRs, or even run them out entirely.

Because how can a product manager create user stories and groom a backlog around requirements as vague as “security”? And how does a team assign story points to a requirement as nebulous as “productivity”? How does a team produce increment if the entire sprint it’s working on the foggy notion of “usability”?

The acceptance criteria for a user story entails meeting the “definition of done.” It’s a tactical accomplishment that’s measurable. And non functional requests cannot meet this criteria.

Yet, as we’ve discussed, ignoring NFRs can mean entirely missing the project’s objective. Consider, for example, someone who seeks to improve their health by losing weight. “Overall health,” in this instance, is a non functional requirement, and “losing weight” a functional requirement.

If after a few months this person has lost 50 pounds, it may appear he’s achieving his goal. However, if you look at the larger picture and discover he continues to smoke five packs of cigarettes a day and eats mostly red meat and carbs, he’s not achieving the overall objective at all.

And so as difficult as they are to fit into a backlog or a sprint, ignoring NFRs isn’t an option.

Double-Edged Sword

All this is to say is that the danger of a team focusing only on NFRs is that they’ll go into a “black hole.” They have no increment to present at the end of an iteration. Since they haven’t achieved anything that adds specific business value, they don’t have any need to communicate with the client or with anyone.

On the flip side, the risk of a team focusing only on functional requirements is that they aren’t incorporating larger, big picture thinking into the project. They’re fixated on completing the daily tasks, on the minutia, and may well end up creating something that’s completely missed the mark.

How does a team mitigate both these risks, and marry these two extremes? Let’s go there next!

The Three Steps to Capture NFRs in Sprint Planning

Claiming to capture non functional requirements may seem like saying unicorns exist and that Bigfoot lives in the woods behind your house. But it’s not like that. It really can be done.

It starts by approaching NFRs differently from functional requirements. In a broader sense, NFRs are more like constraints than requirements. They’re the boundaries under which a project is executed, the parameters it works within at all times. The functional requirements are executed and completed within these constraints.

NFRs are like company culture in this sense. Although it’s difficult to see and sometimes to define, company culture in fact affects every aspect of the business: from the layout of the workplace, to the attire people wear to work, to the criteria for receiving bonuses and promotions, to the location where the holiday party is held.

Since they’re fundamental to the outcome of a project, NFRs are woven into the entire project, from the planning to the execution to the completion. Without them, something fundamental is missing from the project. And so NFRs are brought into consideration in every sprint planning session.

Yet how do you measure them and determine if they’ve been met? Here’s a simple three-step approach.

1) Prioritize the Non Functional Requirements

The first step is to determine what the NFRs really are. Don’t assume that usability is at the top of the list. Maybe the client values scalability first and foremost.

Completing this first step entails having an open discussion with executives and project stakeholders to get a clear idea of what they are looking to see in the end product.

2) Break the NFR Down

Recall that NFRs are so big and broad that they have many possible solutions. Once you know which NFRs are the most important, at this point it’s necessary to determine how they’ll be executed.

This is demonstrated more clearly with an example. Let’s say an executive wants to increase sales by 10,000 each day. This is a high-level NFR to increase productivity.

The team then determines if this goal is best solved by improving software, increasing the capacity of hardware, or hiring more employees.

Once a path is chosen, the team breaks it down further and determines the individual steps it needs to take. If it decides to hire more employees, this is executed by recruiting, interviewing, training, then hiring new people to do the job.

3) Include NFRs in Sprint Planning

When an NFR has been defined and broken down, it’s much easier to measure and achieve. In this final step, the team creates user stories around these individual steps and includes them in sprints.

For example, if the team decides to hire more people in order to achieve the NFR of increased productivity, then the user stories in the first sprint might be to define the job duties, write a job description and determine the pay. For the upcoming sprints, the team would create user stories around posting and promoting the job, then reviewing applications, and finally interviewing and hiring recruits.

It works the same with other non functional requirements as well. For example, if the NFR is security, and the team is building the registration page, then the user story might be to increase the strength requirement of the password. If the NFR is usability, then the user story might be to create a metric around how long it takes for a page to load. If the NFR is aesthetics, then a user story might be to coordinate fonts and colors within the website.

At this third step, a NFR starts to look very similar to a functional requirement. It can be evaluated per the criteria in the “definition of done” and checked off a list.

Although putting metrics around something like “user-friendly” seems vague, it is possible. As you can see, when broken down, NFRs have metrics and look concrete. This three-step method allows teams to incorporate NFRs into the backlog and assign them user points. They won’t be overlooked. Because they can’t afford to be!