In this edition let's focus on "Volumes".
When a software system is being built it is designed with a specific set of end users in mind. Like for example a fruit vendor decides that he will sell only apples and bananas, likewise, the designer of a software system builds the system to cater to the needs of a specific subset of end-users.
The fruit vendor has a choice, he could go door to door and sell; OR he could sit in a market and offer his fruits whilst customers came to buy them from him. Similarly, the software system could be a single user application like Wordpad or Notepad; i.e. an application used by a single user at a time; OR it could be one that can be accessed by multiple users at once; for example a chat application or a website.
The fruit vendor could decide that he wanted to sell 20 kgs of fruits each day. Similarly, when we define volumes for a system, in a software performance engineering context, we really aim to define the number of end users that will use the software application.
The fruit vendor would typically know that most people would buy fruits from him in the market while they are going to work or during lunch time or later in the evening when they are returning back home. Similarly, define the usage pattern of end users. For eg. If there are 10 users in a small office who will access the "attendance" system; it is very clear that the "attendance" system will receive most of the usage when users come into office in the morning and when users go home in the evening. All through the remaining part of the day the system is "idle".
Today when everything is web based and the world is a global village wherein 2 users of the same application sit in different corners of the world to access the same application, it is imperative that usage is understood from a global perspective. Now let's think that this small office is operating from 2 locations; 5 employees in UK and 5 employees in India. Time zones come into picture here and you will see the access pattern different - Indian employees will access this attendance system in the morning and evening as per India time and employees in UK will do likewise in UK time; thereby making the usage pattern quite different.
If the fruit vendor aims to build a chain of shops that he owns, he needs to understand how many people in different parts of the town would like to have his fruits! So then, taking this analogy forward, we aim to understand how the end users of a software application will grow. Going back to our attendance system as an example, maybe the office is aiming to expand into other parts of the world with more employees. So, what are these plans as per estimates given by the business?
As the total user base grows; the total number of users accessing the system concurrently also grows. Obviously, if the fruit vendor became popular he can expect more people in his store at once! Usually these are directly propotional quantities/ metrics.
So then, to summarize, when we define requirements for a software system, "Volumes" now form an important measure to quantify; and this measure can be defined in terms of
- growing end-users year on year
- number of users using the software system concurrently and
- the pattern of peaks and troughs that is expected
