Capturing Requirements
Requirements were captured as use cases. Each use case described the interaction of a user with the system as a sequence of steps that led to some outcome of value to the user. The use cases contained more formal descriptions of system behaviour than the original envisaging scenarios. Part of the use cases analysis was to identify the actors and stakeholders of the system. Actors were people or computer systems that would use the system and require services of the system. Stakeholders were people for whom the system would have an impact even if they did not directly use the system. It was important to identify both Actors and Stakeholders so that the needs of both could be addressed.
Use cases were used to describe requirements because they captured descriptions of the system in a way that could easily be understood by all users of the system. The use case-driven aspect of the RUP approach then ensured that the system was implemented as realizations of the use cases so only features of value to users were developed.
Identifying Actors, Stakeholders and Use Cases
The actors and use cases were identified by working through the envisaging scenarios to extract interactions with the system. Most scenarios gave rise to multiple use cases. Stakeholders were identified by thinking about the impact the system would have on other systems or processes and procedures in the institutions.
An example Use Case and the scenario it was derived from is shown below. The scenario mentions the ability of the user to see personal information and make a request to have it changed, The Use Case was derived from the scenario by thinking about the steps the user and the system needed to take in order to achieve the desired behaviour. These steps were captured as text in a formal Use Case description.
The Use Case Description includes a brief description of the use case; descriptions of the actors who participate in the use case; any preconditions that must be satisfied at the start of the use case; a basic flow of events which describes the normal operation of the use case; and alternative flows which describe different paths through the use case when exceptional events happen.
Excerpt from Scenario 1:
“…I can also see my personal details, such as address, transcript, etc, as held by the University. I have just changed my phone number so I click on a button and enter the new number. (This is sent to the relevant people at the University who change the entry in the MIS system)”.
Use-Case Description: View and Change University Personal Information
Brief Description
This use case describes how a Learner uses the system to view the personal information held by the University and submit a request to change the personal information.
Actor Brief Descriptions
Learner
The Learner is registered on a course at the University and can view personal information about the Learner held by the University.
Learner Information Manager
User of College MIS system who receives requests to change personal information and can make the changes.
Student Information System
The system storing the student personal information.
Preconditions
The Learner must be registered as a student with the University. The Learner must have a username and password to access University systems.
Basic Flow of Events
{Launch System}
The use case begins when the actor Learner launches the URL of the system in a web browser.
{Authenticate Learner}
Include use case Authenticate Learner to authenticate the use of the system by the Learner.
{Display Personal Information}
The system displays personal information and an option to change personal information.
{Change Personal Information}
The Learner selects to change personal information.
The system displays editable personal information and options to cancel or submit a change request.
{Edit Personal Information}
The Learner edits the personal information.
{Submit Change Request}
The Learner selects to submit a change request.
The system submits a change request to the Learner Information Manager and a copy of the change request to the Learner.
{Update Personal Information}
The Learner Information Manager updates the Student Information System with the changed personal information for the Learner. NOTE: In reality this will happen sometime after the receipt of the request by the LIM. Need to know how to best capture the asynchronous nature of this step in the use case.
{Acknowledge Change Request Submission}
The system displays a message to inform the Learner that a change request has been submitted and an acknowledgement option.
The Learner selects to acknowledge the change request message.
The system displays the personal information and an option to change the personal information.
{Use Case Ends}
The use case ends.
Alternative Flows
Change Request Cancelled.
At {Edit Personal Information} or {Submit Change Request} if the Learner selects to cancel the change request,
The use case resumes from {Display Personal Information}.
Handle communication failures
At {Display Personal Information} if the Student Information System cannot be contacted or does not reply within the set communication time-out period,
And if the communication link has failed more times than the communication retry number, then communication is abandoned and the system informs the Learner of the communication error.
The system will attempt to contact the Student Information System until it has completed the number of retry attempts indicated by the communication retry number.
If communications are re-established, the basic flow is resumed at {Display Personal Information}.
If there is still no response from the Student Information System, the system creates an event log entry to record the failure of the communications link to the Student Information System. The event log entry includes the type of failure.
The system sends the event log to the Service Administrator to inform it that communication with the Student Information System has been lost.
Resume the basic flow at {Use Case Ends}.