Database Reference
In-Depth Information
Requirements Analysis
Simply put, a
requirements analysis
defines the aim of an application and therefore what it is expected to achieve.
To do a requirements analysis, it is quite common to interview several stakeholders. This is necessary because it is
unlikely that only one person can define all the business and technical requirements. Because requirements come
from several sources, they must be carefully analyzed, especially to find out whether they potentially conflict. It
is crucial when performing a requirements analysis to not only focus on the functionalities the application has to
provide but also to carefully define their utilization. For each specific function, it is essential to know how many users
1
are expected to interact with it, how often they are expected to use it, and what the expected response time is for one
usage. In other words, you must define the expected performance figures.
reSpONSe tIMe
the time interval between the moment a request enters a system or functional unit and the moment it leaves
is called
response time.
the response time can be further broken down into the time needed by the system to
process the request, which is called
service time
, and the time the request is waiting to be processed, which is
called
wait time
(or
queueing delay
in queueing theory).
response time = service time + wait time
If you consider that a request enters a system when a user performs an action, such as clicking a button, and
goes out of the system when the user receives an answer in response to the action, you can call that interval
user response time
. In other words, the user response time is the time required to process a request from the
user's perspective.
In some situations, like for web applications, considering user response time is uncommon because it is usually
not possible to track the requests before they hit the first component of the application (typically a web server).
In addition, most of the time guaranteeing a user response time is not possible because the provider of the
application is not responsible for the network between the user's application, typically a browser, and the first
component of the application. In such situations, it is more sensible to measure and guarantee the interval
between the entry of requests into the first component of the system and when they exit. this elapsed time is
called
system response time.
Table
1-1
shows an example of the expected performance figures for the actions provided by JPetStore.
2
For each
action, the guaranteed system response times for 90% and 99.99% of the requests entering the system are given. Most
of the time, guaranteeing performance for all requests (in other words, 100%) is either not possible or too expensive.
It is quite common, therefore, to define that a small number of requests may not achieve the requested response time.
Because the workload on the system changes during the day, two values are specified for the maximum arrival rate.
In this specific case, the highest transaction rate is expected during the day, but in other situations—for example,
when batch jobs are scheduled for nights—it could be different.
1
Note that a user is not always a human being. For example, if you are defining requirements for a web service, it is likely that only
other applications will use it.
