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

 

step1

 

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

 

step2

 

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

 

step3
5 Steps to Starting a Software Security Requirements Program

5 Steps to Starting a Software Security Requirements Program

LEARN MORE