Week 13 (starting 7 Jan 2008)

Once the information is gathered from the customers about what they wanted of a software system, the requirements can be documented by:

• Constructing a use case diagram showing the use cases and the actors (human users and external system)
• Writing the use case description for each use case

The use case diagram will give you an overview of the software system to be developed. It indicates :

1. What are the functions to be provided (each one is represented by a use case)
2. Who are using the system (i.e. the actors)
3. Any external system to interface with

An example is shown below. It shows a Course Management System to be developed with 4 intended functions and the people using it are the students, the professors and the registrar. There is one existing system at the customer's office to interface with and that is Billing System.

The use case descriptions will give you step-by-step instructions of how each use case is being executed. The description will also indicate how these users interact with the system and eventually with the expected outcome.

A good use case description will give you an idea how a use case will be executed. It describes:

1. What inputs are needed
2. How the system will process the request
3. What is the expected outcome if the use case is executed successfully
4. What are 'exceptions' to handle (in the alternate flow)

An example is shown below to describe how to

Use Case Title : Register for Course Pre-condition: The student must log in successfully to the system before this use case begins. Post-condition : The student schedule is created upon successfully registering the course. Basic Flow:

1. The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student.
2. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of available offerings.
3. Once the student has made his/her selections, the system creates a schedule for the student containing the selected course offerings.
4. For each selected course offering on the schedule not already marked as “enrolled in”, the system verifies that the Student has the necessary prerequisites, that the course offering is open, and that there are no schedule conflicts.
5. The system then adds the Student to the selected course offering. The course offering is marked as “enrolled in” in the schedule.
6. The schedule is saved by the system.

Alternate Flow:

1a. Course Registration is closed. A message is displayed to inform the student that no registration is allowed and the use case terminates. 4a. Unfulfilled Prerequisites, Course Full, or Schedule Conflicts A message is displayed to allow the student to re-select other course offering and submit the registration.

With all these, you will be able to document user requirements. Next week, we will look into use case analysis - i.e. to further understand what really needs to be done for the use case.