Certain requirements for the system under construction are not about a specific functionality that can be assigned to a
team member and implemented in one time box. These requirements typically impose constraints on the system in terms of,
for example, how fast, reliable, scalable, useful, portable, or easy to maintain a system should be. Such
requirements generally span across multiple user stories of the system and are referred to
as nonfunctional requirements, system-wide requirements, technical requirements, or
constraints. See System-Wide Requirements for more information.
Approaches to capturing nonfunctional requirements
There are different approaches to capturing nonfunctional requirements as part of user story-driven
development, as described in the three sections that follow.
Approach 1. Write individual stories
One way to capture nonfunctional requirements or constraints on the system is to write them as
individual stories, which are often referred to as technical stories [COH08].
For example, consider this technical story:
As the bank CTO, I want the ATM system to respond to user operations in no more than 2 seconds, so
we can adhere to XPTO Standard for banking systems.
This technical story captures what a legitimate user role wants from the system: the bank CTO wants the
system to comply with a banking standard related to system performance. Even though it is
legitimate, this technical story arguably violates the goal of stories being valuable and, at the same
time, sized to be finished in one iteration. This technical story affects or constrains many user stories in
the system. Considering that many iterations will pass until all user stories are developed, it is clear that
this technical story can't be assigned to one team member and finished in one iteration if it is to show
value to all stakeholders - not only to the bank CTO, but also ATM users.
Approach 2. Include the details in each user story
Another approach is to capture nonfunctional requirements as part of the details of each user story. This way,
each user story clearly contains the acceptance criteria that defines the level of completeness.
Let's take the following user story as an example:
As an ATM user, I want to use an ATM to withdraw cash.
In the details part of that user story, you could capture the nonfunctional requirement this way:
After the user selects and confirms the amount to be withdrawn, the system should complete the operation in no more
than 2 seconds.
In this version, when the user story is implemented, tests need to be created. This includes having the appropriate
test environment to simulate the operational environment so that both the functionality (the ability to
withdraw cash from a bank account) and the performance (how fast the back end operations run) can be tested.
Approach 3. Combine both methods
While conversing with stakeholders to flesh out the details of a user story or prioritizing the user stories and
developing them, the team might inadvertently miss that a given user story, for example, is constrained by the
adherence to XPTO Standard.
A combined approach to capturing the nonfunctional requirements seems the best option: capture the nonfunctional
requirements as technical stories (or another notation or free-format text, if that makes sense), and make
that list of technical stories visible to the team and stakeholders at all times when prioritization and
detailing of user stories is happening. In this way, the team and stakeholders make sure to capture the nonfunctional
requirement as an acceptance criterion within the details of each and every user story where that constraint applies.
Another advantage of keeping all of the technical stories on a consolidated list is that if there is a
requirement change or a new requirement is added, it becomes visible to the stakeholders and team right away. For
example, you might get this change to the performance requirement:
As the bank CTO, I want the ATM system to respond to user operations in no more than 1
second, so we can adhere to XPTOplus Standard for banking systems.
That one-second change and the stricter standard should alert the team to revisit all affected user stories.
Scheduling nonfunctional requirements
Based on the previous discussion, a nonfunctional requirement that is captured as an individual technical
story may be hard to treat (prioritize, assign to a team member, and implement in one iteration).
These technical stories are not prioritized with the user stories, but they typically serve as a reminder
that, for example, the system is constrained or needs to adhere to some standard.
On the other hand, stakeholders will most likely prefer to give high priority to user stories that have high business
value, which is acceptable from the stakeholders' perspective. However, the team needs to make sure that the
user stories that are affected by constraints take precedence over other non-constrained user stories. The team and
stakeholders need to find this balance when prioritizing user stories. This is the same as thinking which user
stories impact the architecture of the system being developed. Those user stories should be scheduled to be implemented
early in the project to help the team build and validate the system architecture early, which
helps minimize project risks early.
|