SYSTEMS ANALYSIS project
daven9947
07_SystemsAnalysis-Fall2019-Week71.pdf
1
ISMM1-UC 752: SYSTEMS ANALYSIS
Fall 2019 – Lecture 7 Instructor: Dr. Antonios Saravanos
1
Use-Cases • Schematic diagrams that show how various tasks are completed using
boxes and arrows to show the flow – Often grow out of the needs identified in a user story
• A form of requirements documentation • Allows us to build an abstract model of a system from the perspective of
the user
Source: Usable Usability: Simple Steps for Making Stuff Better
2
2
2
Use-Cases take Advantage of the Pareto Principle • In 1906 an Italian economist by the name of Vilfredo Pareto observed:
- that 80 percent of the land in Italy was owned by 20 percent of the people.
- that 20 percent of the pea pods in his garden contained 80 percent of the peas.
• The Pareto Principle (also know as the 80/20) rule can apply to use cases as about 80 percent of value is added by 20 percent of the requirements.
Source: Usable Usability: Simple Steps for Making Stuff Better
3
3
Use-Cases are not User Stories • A user story is to a use case as a gazelle is to a gazebo
-- Alistair Cockburn
4
4
3
So How are Use-Cases different from User Stories • A user story is a short description of something that a user will do when
they use your systems • A use case is a description of a set of interactions between a system and
one or more actors
Source: http://www.boost.co.nz/blog/agile/use-cases-or-user-stories/
5
5
Use-Case • Graphical
– Easy to read diagrams – Diagrams can help facilitate meetings
• Textual – Scenarios
• Essentially a story that describes an interaction with the system • Conceptual basis for use cases
6
6
4
Representing a Use-Case • An oval with a title that reflects something that a user wants in its centre
Create Report
7
7
Actors • Actors represent roles not individuals that interact with the system
– An actor is an agent that acts upon a use case • Remember it is impractical to represent every individual who may interact
with the system • Actors may represent groups of similar system usage
8
8
5
Representing an Actor
9
9
Use Case Template • Use Case Name • Summary • Primary Actor • Details • Sub Cases • Extensions
10
10
6
Level of Granularity • Use cases can be written ad different levels
– “Purchase Book” is very high-level – “Check out cart items” is mid-level – “Click on ‘confirm order’ button” is low level
11
11
Use Case Leveling Definitions • Cloud - Very high level, involve multiple user goals, e.g. "Operate a Bio-
specimen Repository" • Kite - High level, a process that takes place over several hours, days or
weeks involving many steps "Find Usable Samples" • Sea - User Goal, something the actor is trying to get done - "one person,
one sitting", involves several underwater or clam level • Underwater - Needed to accomplish user goals, typically can be used and
reused - "Save as a File" • Clam - Not usually written out in detail as a use case, "insert record into
database"
Source: https://wiki.nci.nih.gov/display/seminfra/Use+Case+Leveling+Definitions
12
12
7
Representing a Use-Case • An oval with a title that reflects something that a user wants in its centre
Create Report
13
13
Multiple Actors • An oval with a title that reflects something that a user wants in its centre
Create Report
14
14
8
Directed Association • An oval with a title that reflects something that a user wants in its centre
Create Report
15
15
«include» and «extend» Relationships • <<extend>>
– Shows an extension point in use case diagrams • <<include>>
– Shows a dependency in use case diagrams
16
16
9
Example of a Use-Case Diagram
Source: Usable Usability: Simple Steps for Making Stuff Better
17
17
Use Case Overview • http://www.youtube.com/watch?v=FNkuGEr1gB4
18
18
10
Requirements Definition Report
• Correct • Unambiguous • Complete • Consistent • Verifiable • Modifiable • Traceable • Ranked for importance
19
A Bad Requirement
Initial Specification: Software will not be loaded from unknown sources onto the system without first having the software tested and approved.
Critique: • Ambiguous – if the software is tested and approved, can it be
loaded from unknown sources? • (not) Testable – it is stated as a negative requirement making it
difficult to verify. • (not) Traceable – a unique identifier is missing.
Re-specification: 3.4.5.2 Software shall be loaded onto the operational system only after it has been tested and approved.
20
11
Determining Requirements
• Requirements are best determined by systems analysts and business people together
• Techniques available to the systems analyst: – Interviews – Questionnaires – Observation – Joint application development (JAD) – Document analysis
21
Activity Diagram Syntax
• Action or Activity – Represents action or set of actions
• Control Flow – Shows sequence of execution
• Initial Node – The beginning of a set of actions
• Final Node – Stops all flows in an activity
• Decision Node – Represents a test condition
22
12
Sample Activity Diagram
23
