Having defined the key system functions and the user population it is now necessary to define how the users place a functional demand on the system. (The online version of this article has more detail again.) The first part of this definition is to lay out how the usage of the system varies over time. Thus the relative usage of the system needs to be defined. The initial definitions are on an intra-hour, hourly, daily, weekly and monthly basis. These figures effectively have no units and simply provide a relative level of usage. Thus any metrics that are available to allow calibration of this data can be used. As an example, estimated percentage utilisation of the system for the time period could be provided. Alternatively, there may be historical data available from a production system.
In the majority of the usage profile sheets the data entry allows a default profile to be entered at the top of the sheet. This can then be varied for individual user sections where they vary significantly. Thus, for example, most of the user sections have similar behaviour this would be used for the default profile. The significant variations from this behaviour would then be entered individually for the separate user section rows that this was required for.
Usage definition by user section on an annual basis
There is a further possibility of varying the use of different functions within a time period, in our example there is likely to be a bias in the number of payments created and approved around the cut off times for making those payments.
Behaviour type function usage specification
The facility extends to a monthly and weekly specification:
Monthly usage specification
The “Intrahour” entry is different. In this case a simple ratio is provided between the peak activity within an hour and the average activity for the hour. This value represents the relative activity instability of the system under consideration, with a higher value representing a system with very unstable usage within any given hour.
Intra-hour usage specification
The “Annual” data entry is different again. In this case a reference year for the modelling is defined, and the modelling extends for ten years including this starting year. The number of working days per year is also entered in this sheet, and then the size of the user population for each user segment in each year. Thus, the expected population growth for each of the user segments may be defined over a ten year period.
Note:In this exmple it is worth noting that the “User population” count for the email and standing order systems has been set to the expected number of items per day. This is a useful modelling mechanism in the case of batch oriented processes.
Usage definition by user section on an annual basis
Lastly in the definition of the system demand by the system’s behaviour types (“Behaviour type function usage”). In this case the average use of each function by each user per day broken down by behaviour type. Using all of this information it is possible to calculate a detailed profile of the expected system demand. This information and its usage will be examined next.
Usage definition by function on an hourly basis
Sarquol Ltd 