Capturing Requirements As Use Cases

1
Capturing Requirements As Use Cases

• To be discussed
• Artifacts created in the requirements workflow
• Workers participating in the requirements
  workflow
• Requirements capture workflow, including detailed
  activities

2
Requirements Workflow
3
Artifact Use Case Model

• Allows developer and customer to agree on
  requirements, I.e. conditions and capabilities to
  which the system must conform
• A model of system containing actors and use cases
  and their relationships

4
Artifact Actor

• Represents user type, external system
• Each type of users may be represented by one or
  more actors
• Often corresponds to worker in a business
• A role of a worker defines what the worker does
  in a particular business process
• The roles can be used to derive corresponding
  actors will play
• An actor plays one role in each use case

5
Use Case

• Each use case represents a way the actors use the
  system
• A use case specifies a sequence of actions,
  including alternatives of the sequence, that the
  system can perform
• Is a specification of the behavior of all
  possible instances of that use case
• E.g. withdraw money (granted, denied, different
  amounts, etc)
• Purpose to define a piece of coherent behavior
  without revealing the internal structure of the
  system, hence it is not a manifest construct in
  the implementation of the system
• in UML term, a classifier that has operations and
  attributes, thus can include startchart,
  activity, collaboration and/or sequence diagrams

6
Use Case Instance

• Is the execution of a use case
• It is one path through the use case
• An sequence of interactions between an actor
  instance and the use case
• Use case instance does not interact with other
  use case instances
• only kind of interaction is between actor and use
  case instances
• dont deal with interfaces between use cases,
  concurrency, and other conflicts (e.g. sharing of
  objects) between different use case instances
  (Note this does not mean interference between
  different instances does not exist.)
• Use Case instance is atomic
• either performed completely or not at all

7
Description of Use Case

• Statecharts specifies lifecycle of use case
  instances
• each transition is a sequence of actions
• Activity diagrams describe the lifecycle in more
  detail by describing sequence of actions that
  occur within each transition
• Collaboration/sequence diagrams are used to
  describe between a typical actor instance and a
  typical use case instance
• Such formal description may or may not be
  necessary depending on the complexity of a use
  case
• Textual description can be used if appropriate

8
Example Global Network Systems

• Largest system in the world, composed of systems
  of systems across different areas and countries
• Made of different technologies (local and
  international switches, land and satellite
  transmission systems
• Each system is a large scale one (e.g. 1000
  man-years)
• Main reason of success precisely defined
  interfaces (both structural and semantic)
• via provide-require mechanism
• is in fact use case specification

9
Architecture Description - View of Use Case Model

• Architecture view (of use case model) describes
  architecturally significant use cases
• use cases describing important and critical
  functionality
• involving important requirement that must be
  developed early in the softwares lifecycle
• used as input when use cases are prioritized to
  be developed within an iteration
• Usually corresponding use case realizations can
  be found in the architectural views of analysis,
  design models

10
Use Case Glossary

• Used to define important and common terms used in
  describing the system
• Useful for reaching consensus between different
  stakeholders regarding definition of various
  concepts and notions
• especially important for large development effort
• Can be derived from domain or business models

11
Overview of Use Case Diagram
12
Use Case Relationships
13
Use Case Relationship
14
Worker

• Refer to a position (in a project) to which a
  person can be assigned, who are responsible for
  building the use cases
• Three types of workers
• system analyst
• use case specifier
• user interface designer

15
System Analyst

• System analyst responsible for the whole set of
  requirements (functional and nonfunctional)
  modeled as use cases
• responsible for delimiting the system
• for finding actors and use cases and for defining
  glossary
• for ensuring that the use case model is complete
  and consistent
• Assisted by use case specifier and interface
  designer

16
Use Case Specifier and Interface Designer

• Assist system analyst
• Use case specifier responsible for detailed
  description of one or more use cases
• need to work closely with real users
• User interface designer responsible for UI
• usually one interface prototype for each use case

17
Workflow for Capturing Requirements
18
Find Use Cases and Actors

• We identify use cases and actors to
• define system boundary
• outline who and what (actors) will interact with
  the system and what functionality (use cases) is
  expected from the system
• capture and define in a glossary common terms
  that are essential for creating detailed
  descriptions of the systems functionality

19
Identify Use Case and Actors
20
Basic Steps

• Finding the actors
• Finding the use cases
• Briefly describing each use case
• Describing the use case model (including
  glossary) as a whole
• Describe use cases in detail
• Steps does not have to be performed in any
  particular order

21
Detailing Use Cases
22
Finding Actors

• If a business model known, use each worker in the
  business as an actor initially
• Criteria for enlisting actors
• should be possible to identify at least one user
  who can play the candidate actor
• minimal overlap between roles that instances of
  different actors play in relation to the system
• Example
• buyer, seller, accounting system (page 147)
• Brief description of actors, used as starting
  point for finding use cases

23
Finding Use Cases

• Interviewing or analyzing each actors to enlist
  candidate use cases
• Analyze, revise and combine use uses
• some candidates wont become use cases
  themselves, but rather better be part of others
• choose name and define scope for the use cases
• a sequence of user-system interaction may be
  specified as one or more use cases
• consider if a use case is complete by itself or
  if it always follows as a kind of continuation of
  another use case.
• Guideline a use case delivers an observable
  result that is of value to a particular customer
• Example Pay Invoice use case (page 149)

24
Constructing Use Cases

• Initial brief description of use cases
• Example page 150
• Describe use case model as a whole
• relationship between uses cases and actors
• model consistency develop system glossary
• Output survey description of the use case model
  (example, page 151), describing how actors and
  use cases interact and how use cases related to
  each other