Date post: | 05-Jan-2016 |
Category: |
Documents |
Upload: | lee-butler |
View: | 215 times |
Download: | 0 times |
1
Modeling System Requirements with Use Cases
2
Why Do We Need Use Cases?
• Primary challenge in a system design process – ability to elicit correct and necessary system
requirements from stakeholders– specify requirements in a manner
understandable to users so they can be verified and validated.
– SDLC models understood by designers not by users.– Leads to scope creep, schedule creep, cost overruns.
3
IS Development Project Track Record
Source: The Standish Group International, Inc., “Chaos: A Recipe for Success”
canceled before
completion
Over budget, late, or without needed features
4
Introduction
Use-case modeling – the process of modeling a system’s functions in terms of business events, who initiated the events, and how the system responds to those events.– roots in object-oriented modeling (question1 )– Gained popularity in non-object development
environments because of its usefulness in communicating with users
– Compliments traditional modeling tools• Focuses on Users and their tasks• Logical model
5
Role of Use Cases
• Describes how system reacts to an event that triggers the system– Trigger – event that causes the use case to
be executed (opening the app, pushing a button)
– Event-driven modeling • All possible system responses are
documented
6
Use Case
• Process– Gather requirements from users– Prepare Use-Case Diagram– Prepare Use-Case Narratives (describes what
happens in each step in the app)• Deliverables:
– Use-Case Diagram– Use-Case Narratives
7
Advantages (question 2)• Tool for capturing and tracking functional requirements• System scope decomposition• Easily understood user communication of
functionality(primary advantage)• Incremental and iterative development.• Aids estimating project scope• Provides testing baseline (test plans and test cases)• Provides documentation baseline (user and system)• Aids in data object or entity identification & db access• Provides functional specifications for user and system
interface design
8
DefinitionsUse-case diagram – a diagram that depicts the
interactions between the system and external systems and users. – It graphically describes who will use the system and in what
ways the user expects to interact with the system.
Use-case narrative – a textual description of the business even and how the user will interact with the system to accomplish the task.
Use case – a behaviorally related sequence of steps (a scenario), both automated and manual, for the purpose of completing a single business task.– Description of system functions from the perspective of external
users in terminology they understand.
9
Sample Use-Case Diagram
10Use-Case Diagram for a Hoosier Burger’s System
11
Basic Use-Case Symbols
Use case – subset of the overall system functionality– Represented graphically by a horizontal
ellipse with the name of the use case appearing above, below, or inside the ellipse.
– Describes ONE and ONLY ONE function– Associated with ONE and ONLY ONE role
that a user can play
12
Basic Use Case Symbols
Actor – anything that needs to interact with the system to exchange information. – Could be a human, an organization, another
information system, an external device, or even time.
Temporal event – a system event triggered by time.– The actor is time.
13
Four Types of Actors
• Primary business actors• Primary system actors• External server actor• External receiver actor• Remember an Actor is a ROLE not an
individual– A given individual can have multiple roles– Multiple individuals can have the same role
14
Relationships
• Association – relationship between an actor and a use case – only one we will use
• Others – Extend – relationship between use cases– Includes – relationship between use cases– Depends-on – relationship between use
cases
15
Association RelationshipDefinition and modeling rules– Modeled as a solid line connecting the actor and the
use case.– Association with an arrowhead touching the use case
indicates that the use case was initiated by the actor.– Association lacking arrowhead indicates a receiver
actor.– Associations may be bidirectional or unidirectional.
16
Objectives of Use-Case Modeling
• Elicit and analyze enough requirements & information to prepare a model that:– Communicates what is required from a user
perspective.– Is free of specific details about how the
system will be built or implemented.
17
Use-Case Technique Steps
• Steps1.Identify business actors.
2.Identify business use cases.
3.Construct use-case model diagram.
4.Documents business requirements use-case narratives
18
Identifying Business Actors
• Ask the following questions:– Who or what provides inputs to the system– Who or what receives output from the system– Are there interfaces with other Information Systems– Are there automatically triggered events (temporal
events)– Who will maintain the information in the system
• Create an Actor Glossary
19
Sample Actor Glossary
20
Identifying Business Requirements Use Cases
• Identify and document critical or important use cases, often called essential use cases.
• Ask questions on next slide• Look at DFD (good match between them)• Summarize information in a Use Case
Glossary
21
Use Case Identification
• Ask the following questions:– What are the main tasks of the actor– What information does the actor need from
the system– Does the system need to inform the actor of
any changes or events that have occurred– Does the actor need to inform the system of
any changes or events that have occurred
22
Sample Use Case Glossary
23
Sample Use Case Glossary Continued
24
Sample Use Case Glossary Continued
25
Event Response List
• Prepare for your Use Case Diagram and Use Case Narrative by creating an Event Response list.– Actor– Event (or use case)– Trigger (typically an input)– Reponses (system responses)
• Sample on Moodle
26
Construct Use-Case Diagram
• Depicts Scope and Boundaries of system• Outside system boundaries – draw and
label primary actors• Inside system boundaries – draw and label
primary use cases• Show relationships between actors and
use cases and between the use cases
27
Guidelines for Use-CaseDiagram Construction
• Identify system’s boundaries – scope• List primary actors (stakeholders & users is
good place to start) – remember actors are ROLES
• List goals of primary actors – Functionality required of system – Tasks (update, read, create, delete)– Communication of external conditions to system– Extraction of information from system
• Identify major use cases• Use glossaries and event table to help you• Review (iterative process)
28
Sample Use Case Diagram
29
Create Use-Case Narratives
• Document first at high level to quickly obtain an understanding of the events and magnitude of the system.
• Then expand to a fully-documented business requirement narrative.– Include the use case’s typical course of
events and its alternate courses.
30
Sample Use-Case Narrative
31continued
Sample Expanded Use-Case Narrative
32continued
Sample Expanded Use-Case Narrative
33
Sample Expanded Use-Case Narrative
34
Guidelines for Writing Use Cases
• Focus on Flow of Events – critical to get it right (Event table should help)
• Write each step in form of Subject-Verb-Direct Object– The patient contacts the office regarding an
appointment• Identify initiator (trigger) of the action and
the receiver of the action
35
Guidelines continued
• Write each step from an independent observer perspective
• Write each step at same level of abstraction (try to accomplish equal amounts in each step)
• Sensible set of actions• KISS• Iterate until comfortable
36
Parts of a Use Case
• Think of each one as a ‘transaction’• Should have 4 parts
– Primary actor triggers (sends data or request)– System ensures request/data sent is valid– System processes request/data – may result
in a change to the internal state of system– System sends result of processing to an actor
(results may include data)
37
Expanding Use Case Narratives
• Choose major use case and expand it• Fill in details
– Identify all stakeholders– Identify all relationships
• Expand on the normal flow of events• Identify all alternate or exception flows• Confirm (typically with user)
38
Expanding Use Case Narratives
• Simplify– Decompose into smaller use cases– Combine or merge too simple or too small use
cases– Look for generic, common or general syntax– Look for ways to extend, include or generalize
use cases• Iterate
39
Extension of Use Cases
• Use the basic Use Case diagram and some of the Use Case narratives to build DFDs (that is where we will go next)
• Identify data required by each use case – use to build data models
• Refer to Use Cases and data models when doing form and report design and system navigation
40
Use Cases and Project Management
• Use-case model can drive the entire development effort.
• Project manager or systems analyst uses business requirements use cases to plan (estimate and schedule) the build cycles of the project.– Build cycles are scoped on the basis of the
importance of the use case and the time it takes to implement the use case.