[Top Rated] - The purpose of this assignment is to develop portions of the SRS (Software Requirements Specification); identify use cases with actors and connections; a

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 d iagrams.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.

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

1.1 Purpose

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Product Scope

<Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to

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 <Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is

Software Requirements Specification for Page 8

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

<Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.

REQ-1: Description: Use Case Reference: <Provide the unique ID and name of the use

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

Remove these directions after completing the section.>

REQ-2: <Follow the same format as above for REQ1..

Remove these directions after completing the section.>

4.2 System Feature 2

4.3 Use Cases

<List all use cases including their unique ID (like Use Case 1) and description like the following example: Use Case 1. <Enter the name of the use case. Names are verb plus object

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

<Describe the contents of this section. Note that for each category, the number of the requirement must be unique. For example use

• 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

Software Requirements Specification for Page 13

Appendix

<Include any additional documents in this section. Remove these directions after completing the section.

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