How to Handle Complex Non-Functional Requirements in Agile Projects

posted on Mar 20, 2013 by Rohit Sethi

Development teams rarely define specific software security requirements. This is not surprising: many software teams struggle to define non-functional requirements (NFRs). This problem is particularly severe for agile teams because most agile process guidance does not acknowledge the complexity of NFRs in real production environments.

There are two types of NFRs:

  • Non-functional requirement user stories: Blocks of testable functionality written in user story format. The actors in these user stories may be internal IT staff. For example: “As a security analyst I want the system to throttle unsuccessful authentication attempts so that the application is not vulnerable to brute force attacks”.
  • Non-functional requirement constraints: These are cross-cutting concerns that may have an effect on several other user stories. They are a sort of “tax” on all relevant development efforts. For example, requiring that all developers validate data from HTTP form fields in a web application is a constraint.

Last year I wrote an article on InfoQ about a generalized method of managing security in agile projects. The process also applies to other non-functional domains: accessibility, scalability, regulatory compliance, etc but not domain-specific requirements. It works by building filterable libraries of reusable non-functional requirements: one library for user stories and another library for constraints. The libraries themselves can be as simple as Excel spreadsheets with filters, or as complex as Sharepoint sites or commercial Secure Application Lifecycle Management systems. Here’s a graphical representation of the process in three steps:

Step 1: Build non-functional requirements libraries




Step 2: Use non-functional requirements user story library in backlog




Step 3: Use non-functional requirements constraint library in iterations



Health Care Provider

  • Konaruki Hirasawa

    Which one usually comes first when one develops a system or product, functional or non-functional requirements?