Show notes
In this Lightning Cast, you’ll discover how to make non-functional requirements visible when working on Agile projects.
A Lightning Cast is a shorter form episode modeled after lightning talks. You’ll get valuable content in 8 minutes or less.
Non-functional requirements are the quality characteristics of a solution. They’re the constraints that apply to a set of functional requirements and allow you to judge the attributes of a solution rather than its functional behaviors.
The non-functional requirements (NFRs) define attributes such as availability, maintainability, performance, reliability, scalability, security, and usability. They serve as constraints on the design of the solution and state which qualities are needed or valuable.
As example of a non-functional requirement in a waterfall context is: The payment screen shall be available to customers within 10 seconds 97% of the time it’s requested.
There are several ways we can make non-functional requirements visible in an Agile context. The most common ways of doing this are with an explicit backlog item, as Acceptance Criteria, or as part of the team’s Definition of Done.
Non-Functional Requirements as a Backlog Item
We can make non-functional requirements visible by creating an independent backlog item (such as a User Story or Technical Enabler) for that requirement. This implies that the non-functional requirement would be developed and tested before that backlog item is considered “done”.
Examples of non-functional requirements as User Stories include:
As a shopper, I want the website to be available 98% of the time I try to access it so that I can make my purchase and don’t need to find somewhere else to purchase the product.
As an online banking customer, I want my checking account balance to display within 5 seconds on my request so that I don’t get frustrated and can see if I have the funds to pay my bills.
Non-Functional Requirements as Acceptance Criteria
Another way to visualize and track non-functional requirements is by adding them as Acceptance Criteria for the backlog item. Acceptance Criteria are the conditions of satisfaction that must be met for that item to be accepted.
A User Story may have several Acceptance Criteria and some of those may be non-functional requirements. An example of using Acceptance Criteria for non-functional requirements is:
As a Financial Analyst, I want to see the monthly transactions for my customers so that I can advise them on their financial health.
Acceptance Criteria
• System displays all transactions meeting the search parameters within 10 seconds of receiving the request.
• Transactions for customers tagged as confidential are only displayed to users with Level 2 security
Non-Functional Requirements as part of the Definition of Done
If you have certain non-functional requirements that are applicable across the entire solution, you may choose to include those requirements in the team’s Definition of Done.
Think of the Definition of Done as a consistent set of Acceptance Criteria that applies to all backlog items. It’s a comprehensive checklist indicating what “Done” looks like both in terms of functionality and non-functional quality attributes.
These might be requirements around accessibility, performance, security, or usability.
Which Should You Choose?
When you’re trying to determine which option to use for making your non-functional requirements visible, consider how well it’s understood, the effort needed, and whether or not it applies to all backlog items.
If a non-functional requirement is well understood, is of relatively low effort, and applies to most of your backlog items, it may be best to include it in your Definition of Done. Here, you need the effort to be small and well understood so that it doesn’t create a bottleneck and stop teams from developing complete solutions.
If the requirement is fairly well understood and is low effort but it only applies to specific backlog items, it may be better to include it as Acceptance Criteria. Because the Acceptance Criteria are the conditions of satisfaction that must be met before a backlog item is acceptable, it needs to be small; something that we can develop and test quickly so that we can have fast feedback loops.
For non-functional requirements that are a bit more complex. it may be better as an independent backlog item; either a User Story or technical enabler. Using this approach for non-functional requirements allows the team to experiment and learn. It also creates an opportunity to build incrementally.
Build Incrementally
Imagine that you’re building a website to sell a product. Does your first iteration of the website need to be able to handle one million concurrent users or can you build a simpler version? Does it need 99.9% up-time availability right away or is 90% availability good enough when you’re first starting out?
Perhaps you can build a simple, lightweight version of your product to make sure the functionality works and that it’s valuable to your customers before adding some of your non-functional requirements.
To develop incrementally, you can use backlog items to make the functional and non-functional aspects of your product visible and determine which to do first and which to do later (or not at all).
Listen to the full episode to understand how to use non-functional requirements in Agile.
http://traffic.libsyn.com/masteringbusinessanalysis/MBALC030.mp3
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
.
The post Lightning Cast: Non-Functional Requirements in Agile appeared first on Mastering Business Analysis.
Our TOPPODCAST Picks 
Stay Connected
