The purpose of this assignment is to develop portions of the SRS (Software Requirements Specification); identify use cases with actors and connections; and create a detailed use case specification for the use case “Schedule Appointment” based on the Case Study. Assignment Directions

Assignment 2 Analysis: Preliminary SRS and Use Case

Purpose

The purpose of this assignment is to develop portions of the SRS (Software Requirements Specification); identify use cases with actors and connections; and create a detailed use case specification for the use case “Schedule Appointment” based on the Case Study.

Assignment Directions

1. Download the SRS Template 2021.docx and rename it Week2AssignmentDraftSRSUseCasesLastnameFirstname replacing the name with your name.

2. Complete SRS Sections 1-4.

2.1 Use SRS Template 2021.docx (available in Course Organization) and complete all parts of the following sections:

Section 1. Introduction

Section 2. Overall Description

Section 3. External Interface Requirements

Section 4. System Features

Most of the content is in our Case Study and your Vision Document or other resources. We will complete more of the SRS later in the course as we learn about the other topics in the SRS. Normally the complete SRS is finished during Analysis, but we need to learn about a few more topics before we can complete it fully. Submit the entire SRS document—do not remove any content as you will be re-submitting your latest version of the SRS with other sections completed in later assignments. Do not change any of the heading formatting as they will help you to navigate the document. See the example SRS for the Cafeteria Ordering System. It is similar in format to our SRS.

3. Identify Use Cases

3.1 Using the techniques identified in the readings and your textbook and your Case Study, create a list of use cases identifying the use case, actors who will use the use cases, and a brief description of the use case.

3.2 Complete the Actor table in SRS Appendix B.2.

For each actor include a definition using the phrase “A (name of your actor) is a …” and complete the phrase. Substitute names for each of your actors in the phrase. For example, “A Student is a Person who is enrolled in the university.”

3.3 Complete the Use Case table in SRS Section Appendix B.2.

For each use case list the name and description. Remember that Use Cases are named as verb phrases and indicate what the system has to provide for users of the system. Add all use cases from your use case table to Section 4.3 of your SRS. Include the unique ID, name, and description

3.4 Complete Use Case Diagram in SRS Appendix B.1.

Using diagrams.net (https://www.diagrams.net/index.html) create a Use Case Diagram. See Figures 14-11 on p. 518 , Figure 14-12 on p. 519, and Figure 1-13 on p. 520 in your textbook on creating a use case diagram. See the Drawing Tool section in the Course Overview and Introduction module. Add a UML compliant Use Case Diagram based on the Case Study to Appendix B.1 in the SRS. See Graphic Tools for Models in the Course Overview & Introduction Module and Additional Resources for videos on using diagrams.net.

3.5 Complete SRS Appendix B3 Detailed Use Case Template for the use case “Schedule Appointment”. The SRS is a Word file so you can edit tables as needed. We are only doing one detailed use case!

See Appendix B in the SRS for more details.

More information

Finding Actors
Find the external entities with which the system under development must interact. Candidates include groups of users who will require help from the system to perform their tasks and to execute the system’s primary or secondary functions, as well as external hardware, software, and other systems.

Define each candidate Actor by naming it and writing a brief description. Include the Actor’s area of responsibility and the goals that the Actor will attempt to accomplish when using the system. Eliminate Actor candidates who do not have any goals. For more information on Actors and their properties, see Concept: Actor.

These questions are useful for identifying Actors:

Who will supply, use, or remove information from the system?
Who will use the system?
Who is interested in a certain feature or service provided by the system?
Who will support and maintain the system?
What are the system’s external resources?
What other systems will need to interact with the system under development?
Review the list of stakeholders that you captured in the Vision Statement. Not all stakeholders will be Actors (meaning, they will not all interact directly with the system under development), but this list of stakeholders is useful for identifying candidates for Actors.

Finding likely use cases
The best way to find use cases is to consider what each Actor requires of the system. For each Actor, human or not, ask:

What are the goals that the Actor will attempt to achieve with the system?
What are the primary tasks that the Actor wants the system to perform?
Will the Actor create, store, change, remove, or read data in the system?
Will the Actor need to inform the system about sudden external changes?
Does the Actor need to be informed about certain occurrences in the system, such as unavailability of a network?
Will the Actor perform a system startup or shutdown?
Understanding how the target organization works and how this information system might be incorporated into existing operations gives an idea of system’s surroundings. That information may reveal other use case candidates.

Give a unique name and brief description that clearly describes the goals for each use case. If the candidate use case does not have goals, ask yourself why it exists, and then either identify a purpose for it or eliminate the use case. For more information on use cases and their properties, see Concept: Use Case.

Outlining use cases
Without going into details, write a first draft of the flow of events of the use cases identified as high-priority. Initially, write a simple step-by-step description of the basic flow of the use case. The step-by-step description is a simple ordered list of interactions between the Actor and the system. For example, the description of the basic flow of the Withdraw Cash use case of an automated teller machine (ATM) would be something like this:

The customer inserts a bank card.
The system validates the card and prompts the person to enter a personal identification number (PIN).
The customer enters a PIN.
The system validates the PIN and prompts the customer to select an action.
The customer selects Withdraw Cash.
The system prompts the customer to choose which account.
The customer selects the checking account.
The system prompts for an amount.
The customer enters the amount to withdraw.
The system validates the amount (assuming sufficient funds), and then issues cash and a receipt.
The customer takes the cash and receipt, and then retrieves the bank card.
The use case ends.
As you create this step-by-step description of the basic flow of events, you may discover alternative and exceptional flows. For example, what happens if the customer enters an invalid PIN? Capture each alternative flow that you identified so that you don’t forget them. You can fill in the details later. See Example: Evolution of the Use-Case Model for more information on how the use cases evolve.