Non-Functional Requirements: Do User Stories Really Help?
Rachel Davies
Agile software development relies on bringing business people and developers together to deliver better software. We understand requirements by building working software and seeking user feedback on whether the latest solution meets their needs. This enables us to deliver business value early and to improve software in subsequent development cycles.
Agile teams focus on identifying user facing features that can form the basis of incremental deliveries. Often these are expressed as User Stories, slices of functionality that enable a user to achieve a specific goal. Developers work closely with stakeholders to understand what user stories must be satisfied by the product that they are developing. A flaw in this approach can be that users don't mention non-functional requirements and developers don't push to understand what quality attributes the software should satisfy.
So how does a team make sure they don't lose sight of "non-functional requirements"? Are user stories of any use in making these special kind of requirements visible to the team? This article explores how teams applying agile techniques go about resolving these concerns.
Types of Non-functional Requirements
Let's start with what people mean when they talk about non-functional requirements. Basically, non-functional requirements relate to qualities of the system that cut across user facing features, such as security, reliability, and performance. Non-functional is probably a bad name because it sounds like these requirements are intangible, simply properties of a static system. However, these requirements do affect the function of the system and it is possible to design tests that these qualities are present.
The difference from functional requirements is that these qualities must be present throughout the system rather than delivered in one-shot like a user facing feature. Alternative terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements" but let's stick to calling them "non-functional requirement" (NFR) for now. So they have to be considered in every development cycle and factored into our test strategy.
NFR can be grouped into:
Agile teams need to consider both categories of NFR so how do we ensure that these don't get missed?
Taking Responsibility
When asked for user stories, stakeholders often forget to mention the NFR assuming that these will simply be there. This may be a fair assumption, if the organisation employs skilled software developers then surely they should always build software that runs well and is built to last. Unfortunately, the team cannot telepathically know what the business needs and when pressure seems to be about delivering features consideration of NFR gets neglected.
I notice that developers who have been working on traditional waterfall projects are used to requirements being handed over fully specified and consider that their job is simply to build the requirements presented. On waterfall projects, NFR will have been considered upstream by architects and designers and already been factored into requirements presented to the development team. On an agile project, we can't make these lazy assumptions. As Dave Nicolette says "Many development teams don't grasp the fact that accountability for getting the requirements (all the requirements) right falls to them." [1]
An agile team has to take a more proactive role regarding requirements. User stories are not simply mini-requirements specifications that are handed over to development fully formed. Writing stories on cards is a very interactive process that involves the technical team asking questions about acceptance criteria that includes NFR. We must take responsibility for flushing out NFR so my first tip for capturing NFR is to actively start looking for them!
Consider Non-functional Requirements from the Start
Agile teams usually take an evolutionary approach to architecture and design. Agile approaches do not specify what roles need to be on the project because this depends on what kind of system you are making. Make sure that you engage with technical stakeholders in your organisation, such as architects, user experience designers, and operations teams. These people can help an agile team spot NFR that are not captured in your user stories.
The development phases is a short time in the lifetime of the product, most software systems are in use for many more times longer than they take to build. Make time to understand the user context better by learning about the different types of users and the situation in which they will use the software. Start conversations about the operating environment and user expectations early. Talk about the capabilities of the system, like quality of service and longevity, at the start of the project. You can do this by organising a vision workshop and create a project charter that includes system non-functional goals as core success criteria.
You can also hold a session with the team to brainstorm risks to consider what are the things that can go wrong once the system is live? Many potential risks can be mitigated by identifying NFR to prevent failures. Another benefit of linking NFR to risks is that you can identify costs of missing NFR and this information can be used to prioritise work on NFR against user facing features. For example, how much will it cost the business if the site goes down? How many users will we lose if the system is too slow? Estimating such costs helps to show that work on the system NFR is often just as valuable to the business as the more obvious value generating features.
Using Stories for Non-Functional Requirements
How does an Agile team factor work on NFR into their plans for incremental releases? Is it helpful to try and describe these as user stories or not? I've talked to many experienced agile teams and found different approaches advocated. Let's take a look at some of the pros and cons.
Lots of teams use a user story template like this: As a <user role> I want <goal> so that <business value>
Some teams like to use this template for everything that they work on including NFR because that's a consistent format.
The beauty of this approach is that all requirements look the same, can be understood by everyone including non-technical folk, and therefore have the same visibility as other stories. What's surprising about this approach is that normally elaborating requirements as user stories help a development team understand user needs better. However, user stories expressing NFR don't necessarily help the development team understand what needs to be build better. Instead, shaping NFR into user stories helps people outside the team understand the benefits better.
The advantage of managing NFR this way is that they are visible to stakeholders. Unfortunately, this can also become a disadvantage, if these requirements may be seen by business stakeholders as optional or "nice to have". It's important to include the "so that" part to make it easy to see why such NFR stories are important from a business perspective to help ensure that they don't get de-prioritized simply because they are not understood.
Other teams keep it simple and simply factor NFR into acceptance criteria for affected user stories. This effectively makes work on NFR invisible. The odd thing about doing this is that any stories which imply significant architecture work have higher estimates than others but because the architectural piece is below the surface it the estimate belongs to whichever story that gets worked on first. This can be difficult to explain to stakeholders.
Another approach is to introduce "technical stories" to cover anything that needs to be built or restructured but is too difficult to explain to business people. These story cards are typically free format and expressed in language that only the development team understands. The developers are trusted to include only those technical stories that make sense often working within an allowance of such stories per iteration. The benefit is that these don't get de-prioritized by business people and yet these stories explicitly appear on the team board and progress on them gets discussed in daily stand-up meetings. This approach is often popular for teams working on legacy systems with many complexities that need to be cleaned up and made testable. Teams at BSkyB have even called this allowance for technical stories a "Quality tax."
One worry with this approach is that this excludes the business from deciding what the project budget is spent on. Henrik Kniberg's advice is "Try to avoid tech stories. Look hard for a way to transform a tech story into a normal story with measurable business value. That way the product owner has a better chance to make correct tradeoffs." [2]
Testing Matters
Sometimes checking for NFR requires specialised "expensive" testing so you may need to plan in additional testing periods. Watch out that these test periods don't become an excuse to defer work on NFR as this may put release dates in jeopardy.
Agile teams cannot rely on manually checking that user stories meet agreed acceptance criteria. Look for ways to automate system tests so that these can be run daily (or more frequently). Build checking that NFR have been addressed into the team definition of Done so that these remain visible for the whole team whatever feature they're working on.
Summary
Waterfall has got many developers into bad habits. When requirements come from someone else and someone else tests my work, I don't need to know the environment that my software will be running in. Agile developers need to challenge this attitude and work with a variety of stakeholders to understand the world that their software will exist in and bear that in mind for each story that is deployed.
There is no magical agile practice that helps you uncover NFR. The first step is to take responsibility. NFR can be represented as User Stories if the team finds a that this helps to keep these visible. However, be aware that surfacing such stories may create issues around the priority of work done on them against more obvious features.
References
1. "Managing non-functional requirements and enterprise standards" blog by Dave Nicolette
2. "XP and Scrum from the Trenches" by Henrik Kniberg, https://www.crisp.se/bocker-och-produkter/scrum-and-xp-from-the-trenches
Further Reading and Watching
Non-Functional Requirements: Do User Stories Help? Video and PDF, Rachel Davies presentation at DevOpsDays 2009
Related Agile Requirements articles
Agile, Multidisciplinary Teamwork
More Agile Requirements Knowledge
Click here to view the complete list of archived articles
This article was originally published in the Winter 2010 issue of Methods & Tools