Software Engineering for Students A Programming Approach

48 Chapter 4 ■ Requirements engineering
4.3 Appendix A gives specifications for several systems. For each specification identify any
problems with the specification, such as ambiguities, inconsistencies and vagueness.
4.4 Group exercise. One way of understanding more clearly the difficulties of carrying out
requirements elicitation is to carry out a role-playing exercise. Students can split up
into groups of four people, in which two act as users (or clients), while the other two
act as software analysts.
The users spend ten minutes in deciding together what they want. Meanwhile the
analysts spend the ten minutes deciding how they are going to go about eliciting the
requirements from the users.
The users and analysts then spend 15 minutes together, during which the analysts
try to elicit requirements. At the end of this period an attempt is made to get all parties
to sign the requirements specification.
After the role play is complete, everyone discusses what has been learned from
the exercise.
Possible scenarios are the systems already specified in Appendix A.
4.5 Requirements specifications are sometimes very long – they can be as long as a
book. Suggest a software tool that could be used (in addition to a word processor) to
assist in writing, checking, browsing and maintaining a specification. Consider, for
example, using a web browser and including hyperlinks in a specification to promote
cross-referencing.
4.6 Who should be consulted when collecting the requirements of a computer-based system
to replace an existing information system?
4.7 Who should be consulted when collecting the requirements for a process control system
or an embedded system? (It is not immediately obvious who the users of these
systems will be.)
4.8 Define the terms completeness and consistency in a specification. How can we
achieve them?
4.9 What are the skills required to collect, analyze and record software requirements?
4.10 Explain the difficulties in using natural language for describing requirements.
4.11 Why is requirements engineering so important and why is it so difficult?
Answers to self-test questions
4.1 If something is ambiguous it cannot be clearly understandable. So ambiguity
has to be removed to help achieve an understandable specification.
4.2 Check balance. The user offers up their card. The system prompts for the
PIN. The user enters the PIN. The system checks the PIN. If the card and
PIN are valid, the system prompts the user for their choice of function. The
user selects check balance. The system displays the current balance.