Why Non-Functional Requirements Matter

I’d always thought that if the ICT Department delivered a system that satisfied all the functional requirements of users, one could call it a successful system. I thought that if the system worked exactly the way stakeholders said they wanted it to work, everyone could call it a day. You can imagine my reaction when I came across an article that challenged this view. The author argued that you could build a system that has all the functionalities in the world...if it’s not used however, the system is a failure. User adoption is one of the main factors that influence project success. 

This does not imply that the adoption of a system automatically makes a project successful. It’s possible to have a widely adopted system and still have project failure. It all depends on all the other factors you consider in defining success. Success can only be clearly determined if it is measured using clearly defined criteria, outlined at the beginning of the project. 

WIth that said, what's the point of building a system no one wants to use? Until analysts can specify systems that stakeholders can use effectively, one that exceeds their expectations (functional requirements), they are like architects building houses no one wants to live in.

Analysts should go beyond what stakeholders say and explore non-functional requirements (NFRs) at the beginning of every project when such requirements can still be accommodated. It’s better to start thinking about security or performance long before the code is written, or the software is bought instead of waiting till the system is ready. At this point, it does become exceedingly costly.

Users rarely request for non-functional requirements but they implicitly expect these features to be part of any system they use. For example, a user could easily say, “I want the system to store different formulae for calculations". Rarely will you hear them say, “the system should be able to perform calculations on 1000 records in 20s”, even though they expect it to work this way.

Non-Functional Requirements represent the constraints placed on a system and are an essential category of requirements that should not be overlooked. They have a strong impact on user experience and can influence whether the system is adopted or not. They are thus, essential to producing good quality software that can stand the test of time.

Some recommend that non-functional requirements be treated like other requirements by sticking them on index cards and using them as a basis for lightweight planning. Others recommend writing them in the form of user stories. Regardless of the tools or techniques used for their documentation, non-functional requirements should be defined precisely, stating the specific measurements (test criteria) for determining their successful implementation.

According to BABOK V2, NFRs may be developed for the user community or the developer community. While users worry about usability, learnability and reliability, the developer community are mostly concerned about scaleability, maintainability and the like.

The list below represents a summary of NFRs you can consider:

• Performance: This is related to response and processing time. How long will the application take to load? How long will it take to process the volume of data that is available? How long will reports and searches take?
• Capability & Scalability: How much will the system need to cope with in the future?
• Throughput: How many transactions will the system handle?
• Storage: How much data will need to be stored?
• Growth Requirements: The system should be built for expansion and growth. Will the system be able to accommodate the anticipated growth?
• Availability: Will the system need to be available at all times? Will it need to be available to everyone?
• Locations: Where will the users be located? Will they be in the same country or dispersed across international locations? Will they experience any network connection restrictions?
• Standards: What standards of use will your system meet? Are there any coding standards developers should stick to?
• Reliability: Will the software be available when needed? How will it recover from errors or failures?
• Operability: Refers to the ease of learning to use the system and its usability. Will the stakeholders find it easy to use?
• Security: How will the system protect the confidentiality, integrity and availability of data? How will the system authenticate users and maintain audit trails?
• Compatibility: Refers to the ability of the system to interact or coexist with other applications. Will compatibility with other applications be a problem?
• Maintainability:  Systems are meant to be maintained and should be built with that in mind. Maintainability refers to the ability to change the features of the application after implementation without any negative effects. It involves re-using components and making improvements.
• Transferability: Refers to the ease of migrating the application to a new environment, installing and uninstalling it when necessary.

What has been your experience with non-functional requirements?