The PM Vision

Non-functional Requirements Checklist

When developing a new software application or working to architect a new platform, the realm of non-functional requirements (as questionable a concept as the word “Requirements” is) poses a challenge.  It’s not simply a matter of what the system should do to solve the user’s problem, but the product manager must consider system requirements.

Exactly how fast should a screen display?  Should we say the screen should render in 1.0 seconds or 1.2 seconds, and how do we know which specification is correct?

What requirements do the user’s browser and system specifications put on the product, and vice versa?

What *should* the system requirements be?  It may be useful to think of functional requirements as market requirements representing the problem being solved, whereas system or non-functional requirements are product requirements representing how the problem is to be solved.

Market requirements represent the problem space, where the solution space is captured in product requirements.

If your new application is to be built to integrate with older software, you must keep an eye towards the languages and frameworks used.  Your new application may demand more resources than the older software you integrate with, which might demand a significant investment on the part of the users of your older application to upgrade.  In the B2B world, this might be a non-starter.

A meta requirement to consider is the tradeoff between scalability and development speed.  I’ve seen great variance in time to release new capabilities across technology stacks.  Technology stacks are frequently chosen based upon non-functional requirements such as number of users expected at one time; these decisions can have a surprising impact on the speed at which new features are developed, as additional application layers may be added to address the scalability requirements.

Agile Non-Functional Requirements

Before we go any further, I must confess:

I don’t actually like the word “requirements.”

I think requirements gathering is an old-school way of thinking. Requirements are ever-evolving and being ever-clarified; the whole concept of “gathering” requirements at the beginning of a project and starting after you find them all is laughable.

But some of you still have to fill out MRDs and PRDs that include requirements, therefore, we sit here today having this conversation. 🙂

Non-functional requirements, such as scalability, may not show up as a user story but are still vitally important.  Even in the Agile world.  As Scott Sehlhorst observes, consider the fail whale:

The Twitter fail whale has become famous, because twitter could not scale to meet the demands of a rapidly growing user base.  Maybe the Twitter team planned for scalability, but demand simply outstripped it.  Or maybe they failed to plan for it.  Either way, they failed to meet the non-functional requirements of supporting the growth that they did have.  (Un)Luckily, this type of problem self-corrects.  Scaling failures drive away users, reducing the need to scale, until balance is achieved.

Scott suggests building non-functional capabilities cumulatively, just as features are added–without breaking prior capabilities.  The entire post and comment thread is worth a read for additional background and framework.

IMPORTANT!  Non functional requirements do not automatically become user stories!  Some, such as Auditing, are capabilities of an application or of a platform.  Others impact choice of technology stack.

Working with emergent requirements, product owners should review this before starting a development effort, and adjust the user stories as appropriate.

High level questions to ask

Here are some high level questions you can ask to help elicit system requirements. These all have implications for software products.

And now, for the checklist.

I don’t use a checklist.  What I use is a list that triggers me to think about non-functional items.  I usually write one or more user stories based on the brainstorm that this list expedites.

I use a streamlined version of Mike Griffiths’ non-functional requirements checklist when starting a project.  I modified the list to shorten it and removed a few categories.

  1. Security – Passwords, auto-logout
  2. Audit – User actions, metadata (user ID, timestamp, etc)
  3. Performance – Response times, processing times, reporting response time
  4. Capacity – Throughput, storage, growth
  5. Availability – Uptime SLAs, etc.
  6. Regionalization – Does data cross international borders?
  7. Backup/Recovery – Frequency of backup, timescale of recovery
  8. Compatibility – with what systems?  platforms?  browsers?
  9. Conformance – what standards must be adhered to?

Here’s a list from Wikipedia that should provide a number of categories for you to consider:

What else should be in the list?  What other sources should be considered?

Image courtesy: Pexels