Every time that we plan around a software project, we tend to only think about main functionalities and final goals, minimizing the perspective of what it really takes to be accomplish; Although it is totally fine and natural, specially if you are planning to go for a LEAN software development approach. In many cases, what is not good about it, is that the final product is only measured in terms of our primary needs and goals, but those needs and awesome functionalities imply a lot of non-functional requirements that are not usually contemplated, usually underestimated or taken for granted.

For those who are not familiar with non-functional requirements. Here is a little explanation to get you into the same page:

Non-functional requirement specifies how the system behaves in terms of constraints or prerequisites. You can list them with expressions like: it should be fast, should be secure, should be multi-platform, should be portable, should be scalable, etc.

We, as professionals, need to keep all these non-functional requirements always into account, especially during the estimation/cost phase. It is part of our job to guide team members that are new to the estimation and planning process. No matter what is the hurry, because even we can defer some of them, we should never forget them as they also take time and money to be fulfil. So we do not want surprises when we think we are about to be done with our project. I have seen many projects fail because a neglected budget estimation due to non-functional requirements.

Fortunately, in the up side, they generally repeat from project to project, so we can make them part of our planning process and estimations.

Here is a little list of 7 non-functional requirements that I highly recommend you to figure out during your planning. Ask yourself and the entire team for them:

1. Security:
   • Does your system need to control the user access and session?
   • Does it need to store the data in a secure location, stored in a secure format?
   • Does it require a secure communication channel for the data?
2. Concurrency and Capacity:
   • Is the system going to be able to handle multiple computations executing simultaneously, and potentially interacting with each other?
   • What is the minimum, average and maximum number of concurrent users?
   • How much data can the system store and for how long? Are the data constraint validations contemplated?
   • Is there a threshold for data transmission quota?
3. Performance
   • Is it any quantitative metric for the system to meet?
   • Performance is generally perceived as a time expectation. This is one of the most important considerations especially when the project is in the architecturing phase. Choosing the right technology is crucial at this point.
4. Reliability
   • Is it necessary to ensure and notify about the system transactions and processing? As simple as keep a system log will increase the time and effort to get it done from the very beginning.
   • Is the data transferred in a reliable way and using trustfull protocols?
5. Maintainability
   • Well done system is meant to be up and running for long time. So it will  regularly need preventive and corrective maintenance.
   • Maintenance might signify scalability to grow and improve the system features and functionalities.
6. Usability
   • End user satisfaction and acceptance is one of the key pillars that support a project success. Taking the user experience requirements into account from the project conception is a win bet, and it will especially save a lot of time at the project release as the user won’t ask for changes or even worst misunderstandings.
7. Documentation
   • Last but not least, all projects require a minimum of documentation at different levels. In many cases the users might even need training on it, so keeping good documentation practices and standards will do this task spread along the project development; but as well this must be establish since the project planning to include this task in the list

As you see, these are some of the things that we usually underestimate or take for granted, but might have a big impact on a project cost and resources planning. It is always better ask and be safe than sorry.