MSc-IT Study Material
January 2011 Edition

Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |

Review

Questions

Review Question 1

What is requirements engineering?

A discussion of this question can be found at the end of this chapter.

Review Question 2

Supply the seven steps that make up requirements engineering and briefly describe them.

A discussion of this question can be found at the end of this chapter.

Review Question 3

What advice do you have to offer between the two different representations available for actors in a use case?

A discussion of this question can be found at the end of this chapter.

Review Question 4

Construct a use case model that shows the requirements of a computer system that will automate the services of a large lending library. Assume that the library has separate adult and child services, orders its own books stocks, can obtain books from other libraries on request, has a catalogue on public access, and charges fines for overdue returns. Try to envisage all the services and users of the library, and capture them all in the diagram. Do not include services that don't relate to books (e.g., Internet access).

A discussion of this question can be found at the end of this chapter.

Review Question 5

Can this use case model:

Figure 3.10. Without generalisation

Without generalisation

be simplified using generalisation into the model shown below?

Figure 3.11. With generalisation

With generalisation

What reasons are there for thinking one way or the other?

A discussion of this question can be found at the end of this chapter.

Review Question 6

In a real-world design exercise, it can often be difficult to obtain the information needed to construct a complete use-case model. Why? (Try to think of at least ten reasons, and possible ways the problems can be overcome). It may help to refer to some general software-engineering books, like Sommerville for information.

A discussion of this question can be found at the end of this chapter.

Answers

Discussion of Review Question 1

Requirements engineering is concerned with discovering what it is that should be developed. Its goal is to develop the software's specification.

Discussion of Review Question 2

  1. Inception, where the developers attempt to gain an understanding of the software and the problems that it has to solve.

  2. Elicitation attempts to propose solutions to the problems that the software has to solve.

  3. Elaboration expands the information from the previous two stages into an analysis model.

  4. Negotiation is used to resolve any conflicts between the stakeholders in the project.

  5. Specification involves producing the final specification from the previous steps.

  6. Validation concerns itself with ensuring that the specification is of a high enough quality to be useful.

  7. Management controls and tracks changes made to the specification.

Discussion of Review Question 3

The users of a system can be divided into two general classes: human users and other computer systems. Both of these are represented in use case diagrams. Representing human users using the standard stick figure can be very helpful, while representing other external computer systems as objects with the «actor» stereotype can help to make a useful distinction between people and automated systems.

Discussion of Review Question 4

There is no single correct answer to this question. You are encouraged to discuss your solution with your tutor and/or your classmates.

Discussion of Review Question 5

If the actor A2 is genuinely a sub-type of A1, then the generalisation shown is logically correct. However, it is not possible to infer whether a generalisation exists from what associations an entity exhibits. Generalisation exists when one entity inherits all the properties of another, not just its associations.

Discussion of Review Question 6

There are many reasons why use-cases can be difficult to construct, and many of these reasons are related to requirements never being completely stable. Some examples to think about:

Use cases are written from the software's point of view, and not that of the actors. For instance, use cases should always describe a user's goal, and not a function of the software.

How the software is interacted with is poorly understood. This easily happens when the requirements for the software are novel, or are themselves poorly understood.

Stakeholders disagree. If the clients wanting the software cannot agree on what they want from the software, use-cases cannot be constructed.