Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Performance Requirements
This material was covered, very briefly, during lectures on February 19, 1997; additional details have been included in these online notes.
A reference for most of the following material is Section 9.1 (``Collecting System Statistics'') in
M Page-Jones
The Practical Guide to Structured Systems Design
Prentice-Hall, 1988
Page-Jones also provides additional details, applies his checklist to small examples, and includes some figures and graphs that can be used to specify the performance requirements that one can obtain by asking the questions he suggests.
Page-Jones provides a simple checklist of information to obtain about the components of an ERD and set of data flow diagrams, in order to determine performance requirements for the system that is to be developed.
At present, I'm not aware of any similar list that could be used to do the same thing, for object-oriented analysis; please let me know about it if you discover one!
Note that at least some of this information can be included in data dictionary definitions, so that you might choose to add this information to these definitions before you continue on to design.
Some data flows represent reports or other complex inputs and outputs that contain ``repeating groups;'' you'd use curly brackets (``{'' and ``}'') to describe these in the data dictionary definitions for this ``composite'' data.
You should ask about the minimum, average, and maximum number of repetitions of this data within the ``report'' (or input, etc.) that the data flow represents. You should also ask about how often the maximum value is obtained.
As Page-Jones notes, this information may be of use for screen designs and report (or forms) design, so you may need to obtain this information before you've completely developed a human-computer interface. The information may be useful for data base design, as well.
Make sure that you've identified the format (numeric, alphanumeric, etc.) and allowable values for each data element (data flow on DFDs, or attribute of a component on an ERD). You may have discovered most of this information and included it in the data dictionary you prepared during ``structured analysis;'' check, at this point, that nothing's been missed.
These will also be useful for both completion of a human-computer interface, and data base design.
It's been noted already that some data flows can be used (or can ``fire'') more than once, when processes are invoked. Thus, you should determine the number of ``firings'' of each data flow (minimum, average, and maximum), for each data flow with this property.
Some input data flows act as ``stimuli'' that cause processes to be activated (that is, the process is invoked each time the data flow ``fires''). You should determine the rate of data flow - average, as well as peak - for each of these stimuli, as well. You should determine whether any output flow (or response) that a data flow represents must be generated within some time bound, after an input data flow (or stimulus) has been received.
Some data flow definitions include ``selection;'' this is shown in the data dictionary definitions using square brackets (``['' and ``]'') to enclose options, with vertical bars (``|'') separating the alternatives. For example, the ``type'' of a telephone number might be shown to be
[ local number | long distance number ]
It may be useful to determine the frequency with which each alternative arises. For example, one might ask which percentage of ``telephone numbers'' represented by the data flow are ``local numbers'' (and, therefore, which are ``long distance numbers,'' as well).
Try to determine the ``rate of firing'' of each process - that is, how frequently it is executed. If this process is activated when some input (or stimulus) received, then you may be able to determine this from the ``rate of firing'' for this input; if several ``stimuli'' could trigger the process, then the process's rate of firing could be computed as function of all these rates of firing for these stimuli.
Try to determine the expected (or required) response, or completion, times for the process as well. You might be able to determine this from the ``response times'' required for any outputs it is required to generate.
As Page-Jones notes, the actual execution time for a process may depend on things we have no control over, including operating-system overhead, telecommunications overhead, and data access time. Thus, we won't generally be able to predict precisely what execution times for processes will be. Instead, we'll need to use ``performance tests'' to measure these, using the nonfunctional requirements we're discovering now, to decide whether the system ``passes'' or ``fails'' such tests.
Page-Jones recommends that quite a few statistics be gathered for each data store on the system's data flow diagrams (and, therefore, for each component of the ERD).
You should try to determine the average (as well as minimum and, if possible, maximum) number of instances of each entity, etc. - that is, the average number of ``records'' in each data store.
Additional statistics should be gathered for each process that accesses a given data store - and for each key that the process uses to access it. Again, minimum, average, and maximum values for each will be useful, if they can be discovered.
Now, using this data, and the ``rate of firing'' you've determined for each process, try to compute each of the following.
This information might be useful for choosing the primary key for each entry (if several choices are possible). Thus, you may want to defer choosing the primary key (or reconsider an earlier choice) until this information has been gathered.
Information about system users that you should try to obtain includes the number of users, their pattern of use of the system, and their geographical distribution.
Page-Jones mentions additional ``miscellaneous'' information about users and the system's environment that you may need to consider, including temperature, noise limits, and so on.
Additional nonfunctional requirements are beyond the scope of this course. However, here is a short (and incomplete) list of other kinds of requirements you may need to consider:
These may affect human-computer interface design and data base design. They may also require the addition of processes (or modification of existing processes) on the system's data flow diagrams.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Performance Requirements