Agile Requirements Information Model (5) – For Agile Programs (b): Nonfunctional Requirements

Note: This is the fifth in a series of posts describing, in more rigorous terms, A Lean, Scalable Requirements Information Model for the Agile Enterprise (AE RIM) that underlies the Big Picture Series. In this series, I’ve been collaborating with Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software Unit, where a variant of the model is being developed and applied on a very large scale development project.

In the last post, the Agile Requirements Information Model For Agile Programs we described those elements of the model, Features and Feature Backlog that are relevant to the Program Level of the Big Picture. (see graphic).


Agile Enterprise Big Picture with Program Level Highlighted

In this post, we complete that discussion with a discussion of Non-functional Requirements. For reference, the basic information model is below, with the elements relevant to agile programs highlighted.


Non-functional Requirements in Agile Development

From a requirements perspective, the User Story form of expression used by the agile team is used to describe the functional requirements of the system; those system behaviors whereby some combination of inputs produces a meaningful output (result) for the user. With all due respect to that nifty agile invention, however, little has been described in agile as to how to handle the Non-functional Requirements (NFRs) for the system.

Traditionally, these were often described as the “ilities” – quality, reliability, scalability, etc. – and the thought of “don’t forget the ilities” is intended to remind us that these are important and critical elements of system behavior. Indeed, they are often as or more import as the sum total of all the functionality. For if a system isn’t reliable (crashes) or marketable (failure to meet some imposed regulatory standard) or scalable (doesn’t support the number of users required) then, agile or not, we will fail just as badly as if we forgot some critical functional requirement.

Non-functional Requirements have been explored and described in texts such as Managing Software Requirements: A Use Case Approach (Leffingwell), and it isn’t necessary to re-explore all that territory here. However, as a reminder of all these considerations, I like to think that teams who do a good job of understanding and addressing these requirements are SCRUPLED, in that they responsibly consider at least the following types of NFRs:

  • Security, Licensing, Installation– access privileges, security requirements, installation and licensing requirements
  • Copyright, legal notices and other items – required corporate representations and legal protections
  • Reliability – defects, Mean Time Between Failures, availability
  • Usability – ease of use requirements – presentation design guidelines, UE standards, accessibility standards, training standards, sheets, help systems etc.
  • Performance – quantitative performance requirements
  • Localization and Internationalization – foreign language operating systems, localization enablement, specific localizations
  • Essential standards
    industry, regulatory
    and other externally imposed standards
  • Design Constraints – other constraints on the system or development technologies. Mandated programming languages and standards, platforms, common components, etc.

Aren’t These Non-functional Requirements Just Backlog Constraints?

In one perspective, all of these items can be considered to be constraints on new development, in that each eliminates some degree of design freedom on the part of those building the system.

For example: “yes, we need to implement Single Sign-On (SSO) functionality in our accounting suite, (a new Feature) but we still have to be compliant with Sarbanes Oxley (constraint) “. Example: “For compatibility with our partners, we have agreed to implement SAML-based SSO (constraint) for all products in the suite”. And “every product in the suite has to be internationalized (constraint), but only the Order Entry module must be localized to Korean (constraint) for this release.”

So in the information model, we have modeled them as such:

Association Between Backlog Items and NFRs

Association Between Backlog Items and NFRs

We see that a) some Backlog Items may be constrained by zero or more Non-functional Requirements (0…*) and b) Non-functional Requirements apply to zero or more backlog items (0..*).

Once identified, ALL relevant Non-functional Requirements must be captured and communicated to ALL teams who may be affected by the constraints. One way to do this is to create a repository of these items in the requirements or agile project management tool the team is using. While our model is tooling independent and doesn’t address the “where this stuff is persisted”, we’ll just call them Backlog Constraints and represent them pictorially in the Big Picture as follows:

A Backlog with its Backlog Constraints

A Backlog with its Backlog Constraints

Ok, well maybe this looks like a “bucket of backlog constraints”. But then again, maybe that’s what it is!

Testing Backlog Constraints

When we look at the long list of list of potential Backlog Constraints – Security, Copyright, Reliability, Usability, Performance , Localization, Essential standards and Design Constraints – the question naturally arises as to whether these constraints are testable.

If we adhere to the agile mantra that “all code is tested code”, then the answer is assuredly yes, as most of most all of these constraints (Performance for example) can be objectively tested. Indeed, system compliance to these requirements is just as critical as it is to meeting functional requirements. However, up until this point the model hasn’t reflected testing Backlog Constraints as explicitly as it has called out testing the functionality implemented in Features and Stories via Acceptance Tests. But that is easily remedied in the extension below:


Rather than calling these tests Acceptance Tests (a word generally used in agile to indicate the acceptance of a Feature or Story by the customer or Product owner) and further overloading that term, we’ve called them System Validation Tests. This is intended to better describe how this set of tests help assure that the system is validated to be in compliance with its Nonfunctional Requirements. The multiplicity (1..* and 0..*) further indicates that

  • Not every NFR has a validation test. For example, some design constraints such as “Program in Python” simply aren’t worth testing (other than perhaps by one-time inspection or acknowledgment).
  • However most are (..*) and one would expect that most nonfunctional requirements have at least one objective test associated with them. Moreover, some NFRs (“Compatibility with IE 8 Beta”, for example), might require an entire test suite to assure conformance.
  • Every system validation test should be associated with some NFR (1..*) (otherwise there would be no way to tell whether it passes!), and
  • Some System Validation tests could assure compliance with more than one NFR.

Do all Backlogs Have Such Constraints?

In earlier versions of the Big Picture, I described most non-functional requirements as an addendum to the Vision. That was a simplification however, as the information model and the Big Picture illustrates three backlogs: the Epic, Feature and Story backlogs, each of which can have associated Backlog Constraints.

For example, internationalization and regulatory requirements may affect many or all project teams, so these NFRs live at the Feature level. However, I recently saw another circumstance whereby a very complex system, which was in turn composed of many applications, platforms and subsystems, needed a substantive investment in overall performance and reliability. So in this case, this was an Epic level Backlog Constraint (“substantively increase performance and reliability “) and it fit conveniently right next to all the other Epics that warranted investment. So the model supports, but does not require, Backlog Constraints (sets of NFRs) at all levels of the hierarchy.

The Big Picture, now updated with Backlog Constraints buckets, looks like this:



Big Picture Updated with Backlog Constraints

Big Picture Updated with Backlog Constraints

With the addition of System Validation Tests, we now have elevated NFRs (called Backlog Constraints) to be first class citizens of the lean and scalable Agile Enterprise Requirements Information Model, thereby reemphasizing the importance of these types of requirements when building large scale systems in an agile manner.


This completes the discussion of Non-functional Requirements, which we are describing as sets of Backlog Constraints which govern development of new Backlog Items. In turn, this completes the discussion of the Agile Enterprise Information Model for Programs. In the next post, we’ll describe the last element of the hierarchy, the Portfolio level.

5 thoughts on “Agile Requirements Information Model (5) – For Agile Programs (b): Nonfunctional Requirements

  1. I like how you related Non-Functional requirements to backlog items, I think the concept of constraints make sense.

    May I propose a way to further investigate the components of Non-Functional requirements? Here’s my recent blog post discussing a way to model quality attributes that would be in line with your model.

    Enjoy, let me know what you think.


  2. Interesting – The constraint approach enables you to associate long living constraints that apply to one or more items. This eliminates the need to create new stories each time such as “performance testing”.

    The one thing to monitor though would be the potential have creating a catch all bucket. Efforts such as usability could easily fall into that trap.

    How do you handle a constraint that is considered new? For example, the team is working on a system that doesn’t support web services properly. The company has declared that all systems moving forward must be truly modularized and SOA based (the old buzz word that means everything to everyone). The constraint in theory can’t really take place until a certain level of functionality exists in the system. Once that functionality exists, a “story” could then be promoted to a constraint for all future efforts. Building on this, on or more teams would have:
    * Stories: Web Services Infrastructure like versioning, security, … (global)
    * Stories: Support Model for External Users (doc, training…)

    Once the basic web services infrastructure existed, teams would then have stories based on functionality areas. Like:
    * Stories: Implementation of Web Services for Legacy module FOO
    * Stories: Implementation of new module called BAR that inherently supports web services
    * Constraint: Must follow WS guidelines
    * Constraint: Must run on WS infrastructure

    Is above correct?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s