CASE STUDY

 

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 x and rename it Week2AssignmentDraftSRSUseCasesLastnameFirstname replacing the name with your name.

2. Complete SRS Sections 1-4.

2.1 Use SRS Template 2021 x (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 d

iagrams.ne

t  (

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:

1. The customer inserts a bank card.
2. The system validates the card and prompts the person to enter a personal identification number (PIN).
3. The customer enters a PIN.
4. The system validates the PIN and prompts the customer to select an action.
5. The customer selects Withdraw Cash.
6. The system prompts the customer to choose which account.
7. The customer selects the checking account.
8. The system prompts for an amount.
9. The customer enters the amount to withdraw.
10. The system validates the amount (assuming sufficient funds), and then issues cash and a receipt.
11. The customer takes the cash and receipt, and then retrieves the bank card.
12. 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.

.

Software Requirements
Specification Draft

for

Version 1.0 approved

Prepared by

date created>

.

Revision History

Name Date Reason for Changes Version
Your name MM DD,

202x
Include reason

Draft Software Requirements Specification Draft
Page iii

Contents

1. Introduction

………………………………………………………………………………………………………………1

1.1 Purpose ………………………………………………………………………………………………………………………. 1
1.2 Document Conventions ………………………………………………………………………………………………… 1
1.3 Intended Audience and Reading Suggestions…………………………………………………………………… 1
1.4 Product Scope ……………………………………………………………………………………………………………… 1
1.5 References ………………………………………………………………………………………………………………….. 2

2. Overall Description

……………………………………………………………………………………………………3
2.1 Product Perspective ……………………………………………………………………………………………………… 3
2.2 Product Functions ………………………………………………………………………………………………………… 3
2.3 User Classes and Characteristics ……………………………………………………………………………………. 3
2.4 Operating Environment ………………………………………………………………………………………………… 4
2.5 Design and Implementation Constraints ………………………………………………………………………….. 4
2.6 User Documentation …………………………………………………………………………………………………….. 4
2.7 Assumptions and Dependencies …………………………………………………………………………………….. 4

3. External Interface Requirements

……………………………………………………………………………….5
3.1 User Interfaces …………………………………………………………………………………………………………….. 5
3.2 Hardware Interfaces ……………………………………………………………………………………………………… 5
3.3 Software Interfaces ………………………………………………………………………………………………………. 5
3.4 Communications Interfaces …………………………………………………………………………………………… 6

4. System Features

………………………………………………………………………………………………………..7
4.1 System Feature 1 …………………………………………………………………………………………………………. 7
4.2 System Feature 2 …………………………………………………………………………………………………………. 8
4.3 Use Cases ……………………………………………………………………………………………………………………. 8

5. Other Nonfunctional Requirements

………………………………………………………………………….10
5.1 Safety Requirements …………………………………………………………………………………………………… 10
5.2 Security Requirements ………………………………………………………………………………………………… 10
5.3 Software Quality Attributes …………………………………………………………………………………………. 11
5.4 Business Rules …………………………………………………………………………………………………………… 11

6. Other Requirements

………………………………………………………………………………………………..12
6.1 Performance Requirements ………………………………………………………………………………………….. 12

Appendix

………………………………………………………………………………………………………………………13

Appendix A: Glossary

……………………………………………………………………………………………………13

Appendix B: Use Case Models

……………………………………………………………………………………….14

Appendix C: DataFlow Diagrams

………………………………………………………………………………….17

Appendix D: Entity Relationship Diagram

…………………………………………………………………….19

Appendix E: Class Diagram

…………………………………………………………………………………………..20

1. Introduction

Remove these directions after completing the section.>

1.1 Purpose

Remove these directions after completing the section.>

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Product Scope

Software Requirements Specification for Page 2

corporate goals or business strategies. If a separate vision and scope
document is available, refer to it rather than duplicating its contents here.

Remove these directions after completing the section.>

1.5 References

Software Requirements Specification for Page 3

2. Overall Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Classes and Characteristics

Software Requirements Specification for Page 4

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 User Documentation

2.7 Assumptions and Dependencies

Software Requirements Specification for Page 5

3. External Interface Requirements

3.1 User Interfaces

3.2 Hardware Interfaces

3.3 Software Interfaces

Software Requirements Specification for Page 6

3.4 Communications Interfaces

Software Requirements Specification for Page 7

4. System Features

4.1 System Feature 1

4.1.1 Description and Priority

4.1.2 Stimulus/Response Sequences

4.1.3 Functional Requirements

Software Requirements Specification for Page 8

not yet available. Each requirement must use the word “shall” in
the statement like “The system shall…”>

REQ-1:

Description:

Use Case Reference:

case that applies to this requirement. Include all applicable
use cases.>

Remove these directions after completing the section.>

REQ-2:

Remove these directions after completing the section.>

4.2 System Feature 2

4.3 Use Cases

like “Make appointment”.>

Description:

Use Case 2.

Description:

Software Requirements Specification for Page 9

Note that in the appendix there are additional entries for use cases.

Remove these directions after completing the section.>

Software Requirements Specification for Page 10

5. Other Nonfunctional Requirements

• Safety 1, Safety 2, etc.
• Security 1, Security 2, etc.
• Quality 1, Quality 2, etc.
• Business Rule 1, Business Rule 2, etc.

Include a description of the requirement. For example:

Safety 1.

Description:

Remove these directions after completing the section.>

5.1 Safety Requirements

5.2 Security Requirements

Software Requirements Specification for Page 11

5.3 Software Quality Attributes

5.4 Business Rules

Software Requirements Specification for Page 12

6. Other Requirements

6.1 Performance Requirements

Description:

Performance 2.

Description:

Remove these directions after completing the section.>

Software Requirements Specification for Page 13

Appendix

Appendix A: Glossary

Remove these directions after completing the section.

Software Requirements Specification for Page 14

Appendix B: Use Case Models

B1. FCS Use Case Diagram

B2. Use Case and Actor Descriptions

Actor Table

Use Case Table
Use Case Name Use Case Description
… …
… …

Actor Name Actor Definition
… …
… …

Software Requirements Specification for Page 15

B3. Detailed Use Cases

Detailed Use Case Template

Based on Figure 4-1 (p 151) and Figure 4-3 on p (155) in your textbook.
Use Case Name:

ID: Priority:

Actors:

Description:

Trigger:

Preconditions:

Normal Course: (Alternate Actor Response with System Response)

1. This use case begins when….
2.
3.

Alternative Course: (Alternate Actor Response with System
Response

1.
2.

Software Requirements Specification for Page 16

3.

Postconditions:

Exceptions:

Software Requirements Specification for Page 17

Appendix C: DataFlow Diagrams

C.1. Context DFD

Context DFD for Case Study

Discussion of Context DFE for FCS Case Study

C2. Level 0 DFD

C2.1 Level 0 DFD for the Case Study

C2.2 Discussion of Level 0 DFD for FCS Case Study

Software Requirements Specification for Page 18

C.3. Data Dictionary for DFDs.

C.3.1 Process Table

Process
Number
Name

Process
Description

Input DataFlows and
Source

Output DataFlows and
Destination

DataFlows DataFlow
Source

DataFlows DataFlow
Destination

C.3.2 External Entity Table

External Entity Name External Entity Description

C.3.3 DataStore Table

DataStore
Number and
Name

DataStore Description List of Elements in the
DataStore

C.3.4 DataFlow Table

DataFlow
Name

DataFlow Description List of Elements in the
DataFlow

Software Requirements Specification for Page 19

Appendix D: Entity Relationship Diagram

D.1 Case Study ERD

D.2 Case Study Entity Definitions

Entity Definitions

Entity Name Definition

Doctor A Doctor is a person who
provides services to Patients of
FCS.

D.3 Discussion of the ERD for the Case Study

D.4 Corrections for previous SRS.

< List any corrections made for previous SRS. Remove these directions after completing the section.>

Software Requirements Specification for Page 20

Appendix E: Class Diagram

E.1 FCS Class Diagram

E.2 Class Definitions

Class Definitions
Class Name Definition

Patient A Patient is a person who is
registered with FCS and receives
services.

E.3 FCS Class Diagram Discussion

Add additional sections as needed.

1. Introduction

1.1 Purpose

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Product Scope

1.5 References

2. Overall Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Classes and Characteristics

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 User Documentation

2.7 Assumptions and Dependencies

3. External Interface Requirements

3.1 User Interfaces

3.2 Hardware Interfaces

3.3 Software Interfaces

3.4 Communications Interfaces

4. System Features

4.1 System Feature 1

4.2 System Feature 2

4.3 Use Cases

5. Other Nonfunctional Requirements

5.1 Safety Requirements

5.2 Security Requirements

5.3 Software Quality Attributes

5.4 Business Rules

6. Other Requirements

6.1 Performance Requirements

Appendix

Appendix A: Glossary

Appendix B: Use Case Models

Appendix C: DataFlow Diagrams

Appendix D: Entity Relationship Diagram

Appendix E: Class Diagram