15 Areas to Think About When Writing Non-Functional Requirements

Server room cabling by someone who cares

Non-functional requirements should be defined when you are also creating and writing functional requirements. These are requirements that detail the constraints and quality standards that the system you are building should adhere to. You can find out what these non-functional requirements should be by your experience, interviews, and industry standards. Also, you can use functional use cases to try and discover what non-functional requirements should be.

Here are some areas that you should have in your non-functional requirements document:

  1. Reliability - Reliability is the chance that the system processes work correctly without being aborted. Some of the potential resulting losses that you should consider are:
    • Complete or partial loss of the ability to perform a mission-critical function
    • Loss or corruption of data Loss of user productivity
    • Time between failures
  2. Recoverability - Recoverability is the ability to restore function and data in the event of a disaster, either natural or man-made. Recoverability ensures that if any kind of system failure occurs, regardless of the reason, the system will operate with minimal interruption. You should think about:
    • Where backup copies of the system and data held within it will be stored
    • Discuss plans to have a Continuity of Operations Plan (COOP) and procedures for the system
    • How soon after a failure is detected must function be restored
    • How soon after corruption is detected must function be restored
  3. Data Backup/Restore – Data Backup/Restore is a measure of how frequently data is backed up and the speed of data restore from backup. You should think about:
    • If the hardware, data, and onsite backup are destroyed, how soon must the application be restored
    • Do you have another site that has a full backup of the data?
    • How many backups do you have?
    • If one server goes down, how many backup servers do you have?
  4. Availability – System availability is the time when the application must be available for use. Required system availability is used in determining when maintenance may be performed. Definitely think about time zones, schedules, and user location.
  5. System Maintenance – There should always be regular system maintenance.  You should think about how much time you need to do maintenance, and how and when you will notify users.
  6. Performance – Performance details the way the system will perform for users. Think about:
    • What is the response time for reports, queries, and updates?
    • What is the total number of user sessions open for the entire application?
    • What is the total number of concurrent sessions that can be opened by a single user?
    • What is the total amount of idle time before the user session is forced to terminate?
  7. Usability – Usability is the system support of the execution of user tasks (i.e., presentation of information and management of user interaction). Think about:
    • How easy it is for user to learn the system
    • How easy it is for user to memorize steps
    • How efficient is the system
  8. Visibility – Visibility discusses how the system looks to user.  Is it easy for them to see the font, screens, reports, etc.
  9. Data Retention - Data Retention details the length of time that various data will be retained in the system.
  10. Fault Tolerance – Fault Tolerance is a measure of how well the system can maintain normal operations when defects are encountered. Think about:
    • How every threat will be identified
    • How will you warn the user
    • Will you disable the feature
    • Will you remove the feature
  11. Maintainability – Maintainability is a measure of how easy it is to correct defects in the software.
  12. Interoperability – Interoperability is a measure of how easy it is to integrate the software with other systems.
  13. Error Handling – Error Handling will be in place to respond to reports of security flaws in the system. Reported vulnerabilities must be tracked throughout the process to ensure they are triaged, corrected, and tested. When a security flaw is discovered in an application deployed in a production environment, notification to users must take place as quickly as possible.
  14. Threat Modeling – Threat Modeling is the process of identifying potential threats to the application, risk ranking these threats, and selecting appropriate countermeasures or mitigations for the threats. Threat modeling is a critical step in securing an application from attack. The threat model will be reviewed for each application release and updated as required to reflect the changes in application design and functionality. As potential threats are discovered and the implementation details of the application become known, the threat model will be updated.
  15. Reusability – You should think about having a system that parts of it can be easily reused in other systems.  This will save the company them and money in future projects.

What are some of the non-functional requirements you think about when designing a system?

Reblog this post [with Zemanta]

Tags: , , , , , , , ,

  • Wong Ching Ya

    I’m in awe with your work Shevonne. I read your post as a layman and wow, you obviously know what you’re saying. Could be the first time I drop in a lady’s blog full of technical terms. :) I was able to know a few of the terms since I used to work for an IT company but nothing technical about my work, except backing up data from my PC. I try to absorb your information by assuming you’re writing about blogging/our OS, at least I manage to get something out of it too so I’m really thankful!

    Keep up the good work and pleasure to be here.

    @wchingya
    Social/Blogging Tracker

  • Shevonne Polastre

    Wow, thank you so much! I’ve work very hard to achieve everything that I have at this point, and I hope to achieve more. I love your blog, and I am always sharing it with others on Google Reader. I just followed you on Twitter, so I hope to interact more. :)

  • Mabel Tshwale

    Thanks very much for the informative blog…this will really help me in my Business Analysis careers, I have never came across the well explained non-functional requirements as this one.

    Would you please write a blog about the distinctive difference between User Requirements Specification and Functional Specification document.

    Please keep us feed our minds wotk knowledge….

    • http://www.dcfemella.com dcfemella

      You will see a post about User Requirements and Functional Requirements docs next week :) Thank you for visiting my site!

      • kamran pervaiz

        hi dcfmella, can u please help me with non functional requirements for CASE Tools i need to give atleast 2 examples please 2 weeks left to submit it….

        solideagle@hotmail.com is my email please drop an email and i will send u my word document…. it would be really really great thanks

        • http://www.dcfemella.com dcfemella

          Some non-functional requirements areas you might want to look at are reliability of the system, usability, and performance. Which ones do you have so far?

      • kamran pervaiz

        hi dcfmella, can u please help me with non functional requirements for CASE Tools i need to give atleast 2 examples please 2 weeks left to submit it….

        solideagle@hotmail.com is my email please drop an email and i will send u my word document…. it would be really really great thanks

      • kamran pervaiz

        hi dcfmella, can u please help me with non functional requirements for CASE Tools i need to give atleast 2 examples please 2 weeks left to submit it….

        solideagle@hotmail.com is my email please drop an email and i will send u my word document…. it would be really really great thanks

      • kamran pervaiz

        hi dcfmella, can u please help me with non functional requirements for CASE Tools i need to give atleast 2 examples please 2 weeks left to submit it….

        solideagle@hotmail.com is my email please drop an email and i will send u my word document…. it would be really really great thanks

  • Pingback: Requirements Gathering and Analysis: Non-Functional Requirements | Chicwriter | Chicwriter

%d bloggers like this: