It is often argued that business analysts prefer functional requirements, therefore, they naturally tend to gravitate towards these. On the other hand, humble non-functional requirements are left in the shadows and are rarely given second thought until the last moment. Doing so, it causes a lot of problems when you are going to live with a system. Although the system / product may look great, no one will use it if there is no performance. It will have a much greater impact on the business if a feature is not included in the final product.
Functional requirements fall into the ‘key’ that the product is trying to do while non-functional requirements are going to ‘how’. Thus, it is natural to understand why BAs prefer to focus on functional requirements – you can show users, customers and managers what the product is going to do. It’s much harder to get excited about the non-functional needs of managers or customers.
Although it can be argued that non-functional requirements are not as glamorous as functional requirements. I’m not sure why non-functional requirements are dropped until the last minute. When I buy a take-way coffee, I want the company that made the container to pay the same attention to how it will be transported and what will be in that container. Let’s take it further I access the BBC website regularly, the reason I use this product is not only because of the content but also because of how well it works i.e. how fast the pages load.
There are many high-profile cases where the business has not paid full attention to non-functional requirements. You will often hear of how a website crashed because the business did not fully meet the required capabilities. If you use Twitter in its early days, you will see this whale, when Twitter was more powerful and therefore unable to cope with the demand. This naturally led to a high level of frustration with the service and they were very vocal about their illness. Twitter is a great example of what happens when a failed whale business doesn’t accurately predict the level of power or understand the scalability of its products.
What things to look for
If you are new to non-functional requirements, the following are different areas of non-functional requirements that you should look at when you are meeting these requirements.
Performance: What should be the response times of the system, measured from any point, under what circumstances?
Size: What is the volume of users that the system is going to access?
Scalability: What is the maximum transaction amount? Peak user level?
Power: What is the volume of users that the system is going to access?
Presence: What are the hours and days that the system is going to be available?
Reliability: What reliability (excluding planned deviations) is required?
Maintainability: How is the system going to be maintained? Who is responsible for maintenance /
Security: How is the system going to be protected from hacking? What if it is hacked?
Auditing: How long do you need to hold your data? Do you need to know who is accessing the system and what they are accessing?
Recoverability: What is the disaster recovery policy if the system is down?
There are other non-functional requirements that I did not mention above that you may want to see; Interoperability, regulator, serviceability, usability
Expressing non-functional requirements
Finding non-functional requirements is not as easy as asking the business what you think is a ‘maintenance requirement’. You need to talk to other members of the project team, for example, the technical architect will be able to help you with most of these needs.
If you are unable or unable to speak to a technical architect, talk to end-users of the system to get a baseline of what the current ‘as is’ situation is. Getting a baseline will enable you to categorize information. For example, a sales assistant comes up with a sales order screen while talking to a customer
Purpose: What is the purpose behind this scene
Process requirements: Retrieve customer details
Ineffective requirements: How fast the screen should load
By categorizing the information in the above manner, it allows you to analyze and evaluate whether a need is needed and what priority it has for that need.
When you see non-functional requirements, it is important that you do not disclose them in isolation.
The project method you are using will depend on the artwork you are going to use for the document. For the waterfall project, you will use the required catalog to document the invalid requirements. Quickly, you should record them on the back of a card.
So, next time you are going to express a requirement, start with non-functional first.