Capturing Requirements as Use Cases

1
Capturing Requirements as Use Cases
2
Primary artifact - use case model

• Model of system containing actors use cases
  their relationships
  
• can introduce packages to manage complexity

3
Actor

• Each type of user (including system) represented
  as one or more actors
  
• once identified all actors - identified external
  environment of system
  
• actors - correspond to workers
• role that workers play - lead to role that actors
  play
  
• actor - plays one role for each use case

4
Use case

• Way actors use system
• sequence of actions including alternatives that
  system can perform
  
• ? specification
• UML - classifier
• can have operations attributes
• can include statechart diagrams, activity
  diagrams, collaborations, sequence diagrams

5

• Statechart diagrams - specify life cycle of use
  case instances in terms of state transitions
  between states
  
• transition - sequence of actions
• activity diagram - describe sequence of actions
  occurring within each transition
  
• collaboration diagrams sequence diagrams -
  describe interaction between components of
  system
  
• use case instance - performance of a use case
• typical use case instance
• use case instance initiated put in start state
• invoked by external message from actor
• transitions to another state by performing
  sequence of actions
  
• waits for another external message from actor

6

• Could be invoked internally (timer) as well as by
  actor
  
• attributes - values that use case instance uses
• use case instances - do not interact with other
  use case instances (only between actor instances
  use case instances)
  
• ? maintain simplicity
• flow of events
• captured in a separate textual description
• specifies how system interacts with use case
• single unit wrt modification, review, design,
  implementation, testing
  
• special requirements
• textual description - nonfunctional requirements

7

• Architecture description (view of use case
  model)
  
• architecturally significant use cases
• critical functionality that must be developed
  early
  
• glossary
• define important common terms used to describe
  system
  
• can be derived from business model or domain
  model
  
• user interface prototype
• helps understanding interactions between human
  actors system

8
Workers

• Position to which real people can be assigned
• description of responsibilities expected
  behavior
  
• represents knowledge abilities that someone
  needs to perform taks

9
System analyst

• Responsible for whole set of requirements that
  are modeled as use cases
  
• finding actors use cases
• ensuring use case model is complete
• help establish common glossary
• not responsible for each individual use case
• coordinator

10

• In practice - not necessary to be lockstep with
  diagram
  
• activity may be revisited not necessary to do
  entire activity each visit
  
• find actors use cases
• purposes
• delimit system from environment
• outline which actors interact with system
  expected functionality
  
• business model - fairly easy to generate first
  cut
  
• domain model
• requirements document (in various degrees of
  completeness

11
Subtasks - no particular order

• Finding the actors
• depends upon starting point
• business model - straightforward
• actor for each worker in business
• actor for each business actor
• no business model - system analyst customers
  identify users then determine actors
  
• criteria
• possible to find at least 1 user who can interact
  with candidate actor
  
• minimum overlap between roles that instances of
  different actors play
  
• system analyst - names actors briefly describes
  roles of each
  
• outline needs responsibilities

12

• Finding the use cases
• depends upon the starting point
• business model - use case for every role of each
  worker who participates in business use case
  realization
  
• no business model - workshops with customers
  users
  
• storyboarding
• actor - need use cases to support operations on
  business objects
  
• actor system - communicate about some external
  events
  
• some candidates - may be parts of other use
  cases
  
• name of use case - often starts with verb
• guideline for determining good use cases
• result of value
• each successfully performed use case provides
  some value to actor
  
• applies to initiating actor if more than 1 actor
  is involved
  
• helps eliminate potential use cases which are too
  small
  
• particular actor
• value to real user ? use case will not become too
  large
  
• restructuring before get stability in use case
  model

13

• Briefly describing each use case
• first - phrase
• later - step by step description of what system
  does when interacting with actors
  
• describing use case model as a whole
• no set rule for what to include - most clearly
  describe system
  
• could be flat or hierarchical
• reviewed by users customers
• all necessary functional requirements captured as
  use cases
  
• sequence of actions is correct, complete,
  understandable for each use case
  
• any use case providing little or no value
  identified

14
Prioritize use cases

• Results captured in architectural view of use
  case model

15
Detail a use case

• Describe flow of events in detail
• starting from use case model - individual use
  case specifiers describe use case in detail
  
• work closely with users of use case
• structuring use case description
• use case - defines states that use case instances
  may enter possible transitions between those
  states
  
• transition - sequence of actions performed by use
  case instance when triggered by an event

16

• Choose 1 complete path from start state to end
  state
  
• rest - alternatives or deviations from this path
• reasons for alternatives
• choice of actor
• actions of 1 actor may affect actions of other
  actors
  
• erroneous input
• malfunctioning system
• components of use case description
• start state - precondition
• action which starts use case
• required order of actions to be performed
• action which stops use case
• every possible end state - postcondition

17

• Paths of execution not allowed
• alternate path descriptions for inlined paths
• alternate path descriptions for separated paths
• system interaction with actors what data is
  interchanged
  
• usage of objects, values, resources by system
• describe completely what system does what actor
  does
  
• nonfunctional requirements - separate section
• interaction with other systems - usually involves
  communication protocol - should be in use case
  
• finished when understandable, correct, complete,
  consistent

18

• Formalizing use case description
• simple use cases - handled informally
• more complex - require structure
• statecharts
• describe states transitions between states
• activity diagrams
• more detail than statecharts
• similar to flowcharts except can handle
  concurrency
  
• interaction diagrams
• show how instance of a use case interacts with
  instance of actor

19
Prototype user interface

• Creating logical user interface design
• user interface - involve user interface elements
  which represent attributes from use cases
  
• identify all elements 1 actor at a time - look at
  all appropriate use cases
  
• for each actor
• which user interface elements necessary to enable
  user case?
  
• How should these elements be related to each
  other?

20

• How will these elements be used in different use
  cases?
  
• What should they look like?
• How should they be manipulated?
• To determine which user interface elements
• which domain classes, business entities -
  suitable as user interface element?
  
• What user interface elements does actor work
  with?
  
• What actions can actor invoke?
• What decisions can actor make?
• What information does actor need?
• What information does system need?
• What are sizes of input output parameters?
• Use sticky notes on a whiteboard

21

• Creating physical user interface
• first prepare rough sketches of collections of
  user interface elements that form logical
  grouping for user
  
• add additional elements to create complete user
  interface
  
• windows, folders,
• build executable prototype
• could have more than 1 prototype - even one for
  each actor
  
• need to validate prototypes early
• criteria for user interface
• allow actor to navigate properly
• consistent look feel
• complies with standards - type of placement of
  widgets

22
Structured use case model

• Identifying shared descriptions of functionality
• look for actions common to several use cases
• can extract into a separate use case
• use generalization notation uses relationship
• concrete use cases
• complete use cases
• abstract use cases
• cannot be instantiated
• templates for use cases

23

• Identifying additional optional description of
  functionality
  
• extends relationship
• additions to use cases sequence of actions
• B extends A if an instance of B may include
  actions specified in A
  
• ? need a condition to determine whether inclusion
  does occur
  
• real use cases - obtained by applying the use
  extends relationship to the use cases in the
  model
  
• concrete use cases
• should not describe behavior shared with other
  concrete use cases
  
• identify other relationships between use cases
• include relationship - reverse of extend
• provides explicit unconditional extension