Business Analysts Embrace Non-Functional Requirements
It is often argued that business analysts like functional requirements, so, therefore, they tend to naturally gravitate towards these.
On the other hand, the humble non-functional requirements are left in the shadow and rarely given a second thought until the last minute. Doing, this causes many issues when you are about to go live with a system. While the system/product may look great, if the performance is not there then no one will use it. This will impact the business a lot more than if a nice to have a feature is not included in the final product.
Functional requirements fall into ‘WHAT’ the product is trying to do while the non-functional requirement falls into ‘HOW’ it is going to do it. So, it is naturally understandable why BAs like to focus on functional requirements- you can show the users, customers, and managers what the product is going to be doing. It is a lot more difficult to get the managers or the customers excited about non-functional requirements.
While it can be argued that non-functional requirements are not glamorous as functional requirements. I am just not sure really why non-functional requirements are left to the last minute. When I purchase a takeaway coffee, I want the company who created the container to have paid the same amount of attention to how it was going to be transported as well what is going to be in the container. Let’s, take this further I regularly access BBC website, the reason I use this product is not only because of the content but also how well it performs i.e. how quickly the pages load.
Twitter fail whale
There have been many high-profile cases where the business has not paid full attention to non-functional requirements. You will frequently hear about how a website has crashed because the business had not fully anticipated the capacity required. If you used Twitter in its early day you would have come across this whale, when Twitter was over capacity and therefore was unable to handle the demand. This naturally caused a high level of frustration of the service and they were very vocal about their unhappiness. Twitter fail whale is a great example of what happens when the business does not forecast correctly the level of capacity or understand the scalability of its product.
Key things to look for :
If you are new to non-functional requirements, the following are different areas of non-functional requirements that you need to look at when you are eliciting these requirements.
- Performance: What should system response times be, as measured from any point, under what circumstances?
- Volumetric: what is the volume of users that are going to be accessing the system?
- Scalability: what is the peak transaction volume? Peak user levels?
- Capacity: what is the volume of users that are going to be accessing the system?
- Availability: what are the hours and days that the system is going to be available?
- Reliability: what reliability (excluding planned outages) is needed?
- Maintainability: how is the system going to be maintained? Who is responsible for the maintenance
- Security: how is the system going to be protected from hacking? What will happen if it does get hacked
- Auditing: how long do you need to retain the data? Do you need to who is accessing the system and what they are accessing?
- Recoverability: what is the disaster recovery policy if the system goes down?
There are other non-functional requirements that I have not stated above that you may want to look at; Interoperability, regulatory, serviceability, usability
Eliciting non-functional requirements
Eliciting non-functional requirements is not easy as asking the business what do you think are the ‘maintainability requirements’. You will need to speak to other members of the project team, for example, the technical architect should be able to help you with most of these requirements.
If you do not or unable to speak to technical architect then speak to the end users of the system to get a baseline to what is current ‘As is’ situation. By getting a baseline you will be able to categorise the information. For example, a sale assistant has bring up a sale order screen when talking to customer
Process requirement: retrieve customer details
Non-functional requirement: how quickly should the screen load
By categorizing the information in the above manner, it allows you to analyze and assess whether there is a need for a requirement and what the priority is this for the requirement.
It is important when you are looking at non-functional requirements that you do not elicit them in isolation.
Dependent on the type of the project methodology that you are using will depend on the artifact that you are going to use for documents. For waterfall projects, you will use requirement catalogue to document the non-functional requirements. In Agile, you should document them on the back of a card.
So, next time when you are about to elicit requirements, start with the non-functional first.