Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Requirements Analysis and Specification
This material was covered during lectures on January 13, 1997.
The following material is presented in more detail (and additional useful material can be found) in
R. S. Pressman, Software Engineering: A Practitioner's ApproachDepending on which edition of this book you have, you might find this material in a chapter whose title is either ``Requirements Analysis Fundamentals'' or ``Analysis Concepts and Principles.''
A requirements specification states what software will be expected to do, and not how it needs to do it. It is started before software design and implementation can begin; indeed, it should be (nearly) completed, and should be reviewed and ``accepted'' before software design and implementation. However, if the software to be developed is large or complex, or is to be used or maintained for a long period of time, then the requirements specification probably will be changed at some point.
A requirements specification
Pressman identifies three different aspects or components of the information that should be included and that can be modeled (almost) independently:
This includes the individual data and control objects that comprise some larger collection of information that is transformed by the software.
For example, in a payroll system, a data object ``paycheck'' is probably composed of several simpler (important) pieces of information, including an employee's name (or ID), a net amount paid, possibly a bank account number, and so on. The paycheck might also be ``related to'' several other (complex) data objects, including an ``employee'' and possibly a ``bank.''
This refers to the manner which data and control objects (state information) is ``transformed'' as it moves (or ``flows'') through the software system to be developed - and, how it is manipulated by system functions.
For example, in a payroll system, this might include information about ``salary,'' ``number of hours worked,'' and data related to ``taxation'' are combined in order to determine the ``net amount paid.''
This refers to the internal organization of data and control objects. For example, it might include the information that a particular (complex) collection of data should be stored and accessed using a (randomly accessible) ``array'' structure, or that is should be organized in a hierarchical way (using a ``tree'').
According to Pressman, you can think of ``data structures'' (which you learned about in CPSC 331) as being related to the design and implementation of ``information structure.''
Models are abstractions that highlight important system requirements. Typically, several models are developed during requirements analysis and included in a requirements specification.
Many models use a graphical notation that depicts information to be maintained, required system behaviour, and other characteristics using distinct and recognizable symbols.
These (and other) models generally often include textual information, sometimes to ``annotate'' the graphical component of the model. This textual information might used a structured language (such as a kind of ``pseudocode'') or it might be written using a Natural language (such as English).
Functional Models focus on the functions - transformations of data - that the software must include.
Behavioural Models focus on system state and important external events: Most software must respond to events which occur outside the system (and which we will assume to be ``instantaneous''). The software always exists in some state - an externally observable mode of behaviour, that affects the way the system will repond to events, and that can only be changed when some event occurs.
For example, a very simple ``traffic light control system'' might only have four possible states - ``light off,'' ``light showing red,'' ``light showing green,'' and ``light showing yellow.'' There might be (only) two important kinds of external events that cause state changes - a request from outside the system to turn the light on or off, and a request from outside the system to change the colour of the light. The first kind of event probably causes the system to change its state from ``showing red'' (or ``green'' or ``yellow'') to ``light off'', and it would also cause the system to change its state from ``light off'' to ``light showing red.'' The second kind of event probably causes a state change from ``showing red'' to ``showing green,'' from ``showing green'' to ``showing yellow,'' and from ``showing yellow'' to ``showing red,'' and it is probably ignored (that is, causes no change) when the system is in state ``light off.''
Problems are often too large and complex to be understood all at once. Therefore will will try to partition (or ``divide up'') problems into pieces that can be understood easily, and establish any necessary interfaces between these subsystems that correspond to these pieces, and then specify requirements for (and develop) these pieces, largely independently.
We will ``partition'' requirements by using different models to represent each of the different aspects of the information domain.
For example, if structured development is being used, then we will use
Furthermore, it will often be possible to ``partition'' requirements further, by organizing components of each model.
Some models are hierarchical - organized in a ``tree'' structure, with a top view giving an overall picture of (some aspect of) the entire system, without much detail, and with views corresponding to lower levels of the tree giving more detailed pictures of smaller subsystems. For example, data flow diagrams are often organized this way when used in structured development.
Other models can be viewed in a layered fashion, with different kinds of information separated into different layers of the model. Some CASE tools allow users to choose which layers of the model will be shown when the model is displayed. For example, entity-relationship diagrams can be viewed in this way.
``Essential Information'' includes the requirements about what needs to be done (not how) that would remain relevant even if perfect technology were available:
...but still assuming that the human beings and other systems that the software-to-be-developed must communicate with are ``imperfect''
``Implementation detail'' includes more information about how things are to be done (if it is appropriate to determine this during requirements specification, instead of delaying the decision until system design) as well as well as requirements that are necessary because the software is to be developed using ``real'' (limited, and imperfect) technology.
Here are some examples of ``implementation details'' or ``implementation requirements'':
On the other hand, checks on the syntactic and semantical correctness of inputs received by people or external systems are likely to be ``essential requirements,'' because we can't assume that ``people'' or external systems are ``perfect.''
Once again, this splits one big job into two smaller and simpler ones. As well, if software is to be developed and used and maintained over a substantial length of time, then it's possible (even likely) that the environment on which the software it to run - processor, I/O devices, operating system, and so on - will all change, and that the software will need to be modified accordingly. When this kind of change is made, it's possible that virtually all the ``essential requirements'' will stay the same, while many (or even all) ``implementation details'' will need to be modified.
Finally, implementation requirements that aren't separated from essential requirements tend to be ``cast in stone'' - and included in redesigns and reimplementations, even after the circumstances that made those ``implementation requirements'' necessary or desirable have changed.
The above principles are motivated by the fact that requirements are generally too complex to be specified by a single person in a small amount of time, or to be understood as a whole, and that a requirements specification must be easy to create, read, and change.
The next lectures will introduce a number of models for specification, and will describe how to develop and use them for both structured and object-oriented development. It might be worthwhile to read this introduction again (and to try to see how the principles apply) after the models have been introduced and their use has been described.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Requirements Analysis and Specification