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.

  • How important is security?  If there is a breach, how will it reflect upon the brand?
  • How important is performance?  Exactly how important is it that transactions be completed quickly?
  • How important is convenience?  Is it more important for the system to be secure or to be convenient?
  • How important is accessibility?  What percentage of the user base will require accessibility allowances?
  • Are there any compliance or environmental regulations pressing on the buyers of this product?
  • What requirements are placed on the product because of the platform it must sit on?
RELATED:  What Qualifies As a Minimum Viable Product?

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:

  • Accessibility
  • Audit and control
  • Availability (see service level agreement)
  • Backup
  • Capacity, current and forecast
  • Certification
  • Compliance
  • Configuration management
  • Dependency on other parties
  • Deployment
  • Documentation
  • Disaster recovery
  • Efficiency (resource consumption for given load)
  • Effectiveness (resulting performance in relation to effort)
  • Emotional factors (like fun or absorbing)
  • Environmental protection
  • Escrow
  • Exploitability
  • Extensibility (adding features, and carry-forward of customizations at next major version upgrade)
  • Failure management
  • Fault tolerance (e.g. Operational System Monitoring, Measuring, and Management)
  • Legal and licensing issues or patent-infringement-avoidability
  • Interoperability
  • Maintainability
  • Modifiability
  • Network topology
  • Open source
  • Operability
  • Performance / response time (performance engineering)
  • Platform compatibility
  • Price
  • Privacy
  • Portability
  • Quality (e.g. faults discovered, faults delivered, fault removal efficacy)
  • Recovery / recoverability (e.g. mean time to recovery – MTTR)
  • Reliability (e.g. mean time between failures – MTBF)
  • Reporting
  • Resilience
  • Resource constraints (processor speed, memory, disk space, network bandwidth, etc.)
  • Response time
  • Reusability
  • Robustness
  • Safety or Factor of safety
  • Scalability (horizontal, vertical)
  • Security
  • Software, tools, standards etc. Compatibility
  • Stability
  • Supportability
  • Testability
  • Usability by target user community

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

Image courtesy: Pexels