A Basic Non-Functional Requirements Checklist

The following appeared on my previous blog site on January 6th 2014 and received in excess of 16K hits per annum - so reposting on new site. 

Earlier today, while reviewing a document I produced some time ago, I discovered a useful Non-Functional Requirements (NFR) checklist and thought I would simplify , ‘repackage’ and share via this blog.

NFR checklists are not unique products, they are easily found on the web with numerous examples available for reuse, one such example can be found at the Open Group’s website under the ToGAF Requirements Management section.

Most of you are probably familiar with NFR’s – However if not, you can consider them a set of requirements/criteria used during the run-time operation of a system and not the specific behaviours that the system must exert.

The NFR’s vary in importance and are usually  aligned to the context of the system e.g. Operational Safety could be classed as a NFR, especially when working in hazardous conditions (Oil Rigs, Gas Plants etc.), but not a common NFR in most system designs I have come across.

The diagram above highlights most common NFR’s, and are presented together with typical examples in the table below;

NON FUNCTIONAL COMPONENTS

NFA	NFR –   Examples
Security (define key security requirements)	Login / Access levels   Create, Read, Update, and Delete (CRUD) levels.   Access permissions for application data may only be   changed by the system’s data administrator   Password requirements –   length, special characters, expiry, recycling policies, 2FA   Inactivity timeouts   – durations, actions, traceability   System data backed up every x hours and copies stored in a secure off-site location   Encryption (data in flight   and at rest) – All external communications between the system’s data server   and clients must be encrypted   Data Classification   / System Accreditation: All Data must be protectively marked and stored / protected.
Audit  (Define the level of traceability for   transactions required)	System must maintain full traceability of transactions   Audited Objects   are defined   Audited database fields – which data fields require audit   info?   File characteristics   – size before, size after, structure   User and transactional time stamps, etc
Capacity (Provisioning for growth)	Throughput – how many   transactions at peak timedoes the   system need to be able to handle   Storage – (memory/disk) –  volume of data the system will page /  persist at run time to disk   Year-on-year growth   requirements  (users, processing & storage)   e-channel growth projections
Performance	Response times – application   loading, browser refresh times, etc.   Processing times – functions,   calculations, imports, exports   Query and Reporting times – initial loads and   subsequent loads, ETL times   Interoperbility
Availability  (uptime)	Hours of operation   holidays, maintenance times, etc   • Locations of operation – where should it be available   from, what are the connection requirements?
Reliability	The ability of a system to perform its required   functions under stated conditions for a specific period of time.   Mean Time Between Failures – What is the acceptable   threshold for down-time?   Mean Time To Recovery – if broken, how much time is   available to get the system back up again?
Recoverability  (in the event of failure..)	Recovery process   Recovery Point Objectives (RPO)   Recovery Time Objectives (RTO)   Backup frequencies – how often is the transaction data,   config data, code backed-up?
Robustness	The ability of the system to resist change without   adapting its initial stable configuration – operational characteristics with growth?   Fault trapping (I/O) , Application Hooks, SMNP – how to   handle failures ?
Integrity  (Consistency of events, values, methods, measures, expectations & outcomes)	Application Integrity   Data integrity – referential integrity in database   tables and interfaces   Information Integrity – during transformation
Maintainability  (The ease with which the system can be maintained)	Conformance to Enterprise Architecture standards   Conformance to Technical design standards   Conformance to coding standards   Conformance to best practices.
Usability	User Standards (Look   / Feel)   Internationalization / localization requirements –   languages, spellings, keyboards, etc
Documentation	User Documentation   System Documentation (Production Acceptance?)   Help?   Training Material

The above has been replicated in my new book