Non-Functional Requirements - Minimal Checklist
March 29, 2009
All IT systems at some point in their lifecycle need to consider non-functional requirements and their testing. For some projects these requirements warrant extensive work and for other project domains a quick check through may be sufficient. As a minimum, the following list can be a helpful reminder to ensure you have covered the basics. Based on your own project characteristics, I would recommend the topics are converted into SMART (Specific, Measurable, Attainable, Realisable, Timeboxed / Traceable) requirements with the detail and rigour appropriate to your project.
The list is also available at the bottom of the article as a one-page PDF document. While it is easy to make the list longer by adding more items, I would really like to hear how to make the list better while keeping it on one page (and readable) to share with other visitors here.
• Login requirements - access levels, CRUD levels
• Password requirements - length, special characters, expiry, recycling policies
• Inactivity timeouts – durations, actions
• Audited elements – what business elements will be audited?
• Audited fields – which data fields will be audited?
• Audit file characteristics - before image, after image, user and time stamp, etc
• Response times - application loading, screen open and refresh times, etc
• Processing times – functions, calculations, imports, exports
• Query and Reporting times – initial loads and subsequent loads
• Throughput – how many transactions per hour does the system need to be able to handle?
• Storage – how much data does the system need to be able to store?
• Year-on-year growth requirements
• Hours of operation – when is it available? Consider weekends, holidays, maintenance times, etc
• Locations of operation – where should it be available from, what are the connection requirements?
• Mean Time Between Failures – What is the acceptable threshold for down-time? e.g. one a year, 4,000 hours
• Mean Time To Recovery – if broken, how much time is available to get the system back up again?
• Fault trapping (I/O) – how to handle electronic interface failures, etc
• Bad data trapping - data imports, flag-and-continue or stop the import policies, etc
• Data integrity – referential integrity in database tables and interfaces
• Image compression and decompression standards
• Recovery process – how do recoveries work, what is the process?
• Recovery time scales – how quickly should a recovery take to perform?
• Backup frequencies – how often is the transaction data, set-up data, and system (code) backed-up?
• Backup generations - what are the requirements for restoring to previous instance(s)?
• Compatibility with shared applications – What other systems does it need to talk to?
• Compatibility with 3rd party applications – What other systems does it have to live with amicably?
• Compatibility on different operating systems – What does it have to be able to run on?
• Compatibility on different platforms – What are the hardware platforms it needs to work on?
• Conformance to architecture standards – What are the standards it needs to conform to or have exclusions from?
• Conformance to design standards – What design standards must be adhered to or exclusions created?
• Conformance to coding standards – What coding standards must be adhered to or exclusions created?
• Look and feel standards - screen element density, layout and flow, colours, UI metaphors, keyboard shortcuts
• Internationalization / localization requirements – languages, spellings, keyboards, paper sizes, etc
• Required documentation items and audiences for each item
Full list as a one page PDF. Download Non functional Requiements
Why Just One Page?
One page lists are easier to comprehend, follow and distribute. Forcing ourselves to summarise things onto one page requires prioritization, consideration of value, and the need to make tradeoffs. See here for more information on one-pagers and the bottom of this list here for more one page summaries.
Very nice list Mike. I just finished creating an RFP for a client for an enterprise system and this list matches what I identified. I think Compatibility is a new one...and I like it (I've usually handled this with interface requirements).
May I suggest you use Planguage to define your SMART requirements? Here's an example for Availability:
For each non-functional requirement, define:
Scale: "What is measured"
Meter: "How to measure (method)"
Target: "Level we're aiming for. Success"
Constraint: "Level we're seeking to avoid. Failure"
Benchmark: "Where we are today"
This can even be applied to business objectives, see my article here for how to define "Increase Market Share" using these same concepts:
Posted by: Ryan Shriver | April 01, 2009 at 05:35 AM
Thanks for the feedback and pointer to Planguage, this was new to me and looks very useful.
Posted by: Mike Griffiths | April 01, 2009 at 09:24 AM
Nice list of nonfunctional attributes and associated metrics. I would look for different security attributes and metrics, as the ones you've listed assume particular designs. A pure requirement would not reference passwords and time-outs, as they are common but not necessary solutions to security problems (see http://cauvin.blogspot.com/2007/05/requirements-and-functional.html ).
Posted by: Roger L. Cauvin | April 06, 2009 at 09:45 AM
Good point, these requiremsnts make an assumption about the implementation. Please help me improve the list then; what 2 lines should better replace what I have?
Posted by: Mike Griffiths | April 06, 2009 at 09:58 AM
So this is all your are going to test for? Or, are you aiming at just a list of broad test categories?
Posted by: David Locke | April 06, 2009 at 10:13 AM
No this is not all I am going to test for. The list is entitled "Minimal Checklist" to help outline a few broad categories, the extent and detail will be driven by your project and organizational domain. My current business project has a 8-10 pages of non-functional requirements and the same for testing, the last military project I worked on had >300 pages on performance characteristics alone. It varies a great deal from project to project, my intent with the checklist was a one page reminder of areas to think about. I hope this helps clarify.
Posted by: Mike Griffiths | April 06, 2009 at 10:18 AM