1. Requirements – Scenarios and Use Cases
CS 560
Lecture 6

2. System modeling
System modeling is the process of developing abstract components of a project based on detailed requirements.
It has come to mean representing a system using some kind of graphical notation
almost always based on Unified Modeling Language (UML).
System modeling
Helps the client/team members understand system functionality.
Used to communicate with customers.

3. UML diagram types Use case diagrams Activity diagrams
Interactions between a system and its environment.
Activity diagrams
Flow of control between components
Sequence diagrams
Interactions between actors and the system and between system components.
Class diagrams
Object classes in the system and the associations between these classes.
State diagrams
Shows how the system reacts to internal and external events.

4. Use of graphical models
Means of discussion about an existing or proposed system
Incomplete (missing req. info.) models are OK as their role is to support discussion.
Although these incomplete models must be updated when more details about the requirements are given.
Model revision is generally necessary throughout the project.
A way of documenting an existing system
Models should be an accurate representation

5. System boundaries model (documentation)
Defines what the system should and should not do.
Shows other systems that uses or depends on the system being developed.
Identifies where the system begins and ends.
Ex:
System scalability (20 node cluster vs. 200 node cluster)
UAV drone system for surveying a specific geographical region
Defining system boundaries
Physical boundaries – infrastructure, geographical, arrangement of resources
Logical boundaries – data types, software component interfaces, responsibility
Social boundaries – religions, traditions, behavioral change
Economic boundaries – allocation of limited resources, benefits to society
Political boundaries – community concern, legal issues, personal rights

6. Scenarios
A scenario is a scene that illustrates some interaction with a proposed system.
User logging into website
Robot making decisions based on environment
User uploading a video to a website
Used during requirements analysis to describe a specific use of a proposed system.
Captures system use, based on a viewpoint, by using specific examples.

7. Describing a Scenario
Some organizations have complex documentation standards for describing a scenario.
At the very least, the description should include:
A statement of purpose of the scenario
The individual user or transaction that is being followed
Assumptions and/or features about hardware/software
The steps of the scenario

8. Developing a scenario with the client (Documentation)
Example of how to develop a scenario:
The requirements are being developed for a system that will enable university students to take online exams from home.
Create a scenario for how a typical student interacts with the exam system.
In the next few slides, the questions in blue are typical of the questions to ask the client while developing the scenario.

9. Developing a scenario with the client:
Purpose: Scenario that describes the use of an online Exam system by a representative student
Individual: [Who is a typical student?] Student A, junior at WKU, major in computer science. [Where can the student be located?]
Equipment/component: Any computer with a supported browser. [Is there a list of supported browsers? Are there any network restrictions?]
Scenario:
Student A starts browser and types URL of Exam system. [How does the student know the URL?]
Student A authenticates. [How does a WKU student authenticate?]
Exam system displays list of options. [Is the list tailored to the individual user?]

10. Developing a scenario with the client: (continued)
Student A selects CS 221 Exam 1 [Can the student view older exams?].
A list of questions is displayed, each marked to indicate whether completed or not. [Can the questions be answered in any order?]
Student A selects a question and chooses whether to submit a new answer or edit a previous answer. [Is it always possible to edit a previous answer? Are there other options?]
[What types of questions: text, multiple choice, etc.?]
The first question requires a written answer.
Student A is submitting a new answer.
The student has a choice whether to type the solution into the browser or to attach a separate file. Student A decides to attach a file. [What types of file are accepted?]

11. Developing a scenario with the client: (continued)
For the second question, the student chooses to edit a previous answer.
Student A chooses to delete a solution previously typed into the browser, and to replace it with an attached file. [Can the student edit a previous answer, or must it always be replaced with a new answer?]
As an alternative to completing the entire exam in a single session, Student A decides to saves the completed questions work to continue later. [Is this always permitted? Time limits?]
Student A logs off.
Later Student A log in, finishes the exam, submits the answers, and logs out. [Is this process any different from the initial work on this exam?]
The Student A has now completed the exam.
The student selects an option that submits the exam to the grading system. [What if the student has not attempted every question? Is the grader notified? Is the student notified?]

12. Developing a scenario with the client: (continued)
Student A now wishes to change a solution.
The system does not permit changes once the solution has been submitted. [Can the student still see the solutions?]
Later Student A logins in to check the grades. [When are grades made available? How does the student know?]
Student A requests a regrade. [What are the policies? What are the procedures?]

13. Developing a scenario with the client: (continued)
Developing a scenario with a client clarifies many functional and non-functional requirements.
Scenarios should demonstrate functionality, not define how the functionality is accomplished.
Although this scenario is quite simple, many details have been left out.

14. Modeling scenarios as use cases
Scenarios are useful in discussing a proposed system with a client, but requirements need to be made more precise before a system is fully understood.
This is the purpose of requirements modeling.
A use case provides such a model.
There is a good discussion of use cases in Wikipedia.

15. Actor and use case diagram (documentation)
An actor is a user of a system in a particular role.
Can be human or an external system.
A use case is a task that an actor needs to perform with the help of the system

16. Two simple use cases

17. Use cases and actors Actor is a role, not an individual
Ex: librarian can have many roles
Web client
Database
An actor must be a beneficiary of the use case
Person who borrows a book
Not the librarian who processes book when borrowed
While naming actors, choose names that describe the role, not generic names, such as "user" or "client".

18. Use case Diagrams Use case diagrams
A use case diagram shows the rela1onships between actors and their interactions with a system.
It does not show the logic of those interactions.

19. Use cases for exam system

20. Describing a use case
The description of each use case diagram should include (at least):
The name of the use case, which should summarize its purpose
The actor or actors
The flow of events
Assumptions about entry conditions (boundaries)

21. Outline of take exam use case (documentation)
Name of Use Case: Take Exam
Actor(s): ExamTaker
Flow of events:
ExamTaker connects to the Exam server.
Exam server checks whether ExamTaker is already authenticated and runs authentication process if necessary.
ExamTaker selects a exam from a list of options.
ExamTaker repeatedly selects a question and either types in a solution, attaches a file with a solution, edits a solution or attaches a replacement file.

22. Outline of take exam use case (continued)
Flow of events (continued):
ExamTaker either submits completed exam or saves current state.
When a completed exam is submitted, Exam server authenticates.
ExamTaker logs out.
Entry conditions:
ExamTaker must have authentication credentials.
Computing requirements:
supported browser.

23. Relationships between use cases: <<includes>>
The Authenticate use case may be used in many contexts
<<includes>> is used for use cases that are in the normal flow of events of the main use case.

24. Relationships between use cases: <<extends>>
<<extends>> is used for exceptional conditions, especially those that can occur at any time.
Continues the behavior of a base use case by inserting additional functionality into the base use case.

25. Scenarios and use cases in the development cycle
Scenarios and use cases are both intuitive
Easy to discuss with clients
Scenarios are a tool for requirements analysis.
They can be used as test cases for acceptance testing.
How?
Basically each step maps back to a requirement.
Use cases are a tool for modeling requirements.
A set of use cases can provide a framework for the requirements specification.

26. Use cases with several actors
This restaurant example is based on a use case diagram from Wikipedia.

27. Project Prototype Demo 1 Grading Rubric
Component
Pass/Fail
Compiled document of the components given in this prototype demonstration grading rubric (can be added to your project documentation)
List of requirements used to guide development of this prototype
Ability to explain requirements in sufficient detail that allows for generation of models/diagrams
List of models/diagrams used to guide development of this prototype
Ability to explain models/diagrams and show how they map back to requirements
List of software/hardware components included in the prototype
Demonstration of independent software/hardware modules and/or integrated software modules
List and explain test procedures of independent software/hardware modules and/or integrated software modules
List and explain data generated and/or used by the prototype
List areas of focus for next prototype demonstration