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

25
(No Transcript)
26
Activity Prioritize Use Cases

• Determine which use cases to be developed in
  early iterations
• Captured in architectural view of the use case
  model
• Used for project planning

27
Detailed Specification of Use Case

• Use case defines the states that its instances
  may enter and possible transitions (sequence of
  actions) between the states
• Structuring use case using basic and alternative
  paths
• Naturally viewed as state-transitions

28
Example Pay Invoice Use Case

• Precondition The buyer has received the
  goods/services ordered and at least one invoice
  from the system. The buyer now plans to schedule
  the invoice(s) for payment.
• Flow of Events
• Basic Path
• 1. The buyer invokes the use case by beginning
  to browse the invoices received by the system.
  The system checks that the content of each
  invoice is consistent with order confirmation
  received earlier (as part of the Confirmation
  Order) and somehow indicate this to the buyer.
  The order confirmation describes which items will
  be delivered, when, where, and at what price.
• 2. The buyer decides to schedule an invoice for
  payment by the bank, and the system generate a
  payment request to transfer money to sellers
  account. Notice that the buyer cannot schedule
  the same invoice for payment twice.

29
Continued ...

• 3. Later, if there is enough money in the
  buyers account, a payment transaction is made on
  the scheduled date. During the transaction, money
  is transferred from the buyers account to the
  sellers account, as described by (abstract) use
  case Perform Transaction (which is used by Pay
  Invoice). The buyer and the seller are notified
  of the result of the transaction. The bank
  collects a fee for the transaction, which is
  withdrawn from the buyers account by the system.
• 4. The use case instance terminates.
• Alternative Paths
• 1) In S2, the buyer may instead ask the system
  to send an invoice rejection back to the seller.
• 2) in S3, if there is no enough money in the
  account, the use case will cancel the payment and
  notify the buyer.
• Postcondition The use case instance ends when
  the invoice has been paid or when the invoice
  payment was cancelled and no money was
  transferred.

30
Necessary Elements of Use Case Description

• Define start state as precondition
• How and when the use case starts (S1)
• Order actions are performed
• How and when the use case ends (S4)
• Path of execution not allowed (S2)
• Alternative path descriptions that are inlined in
  the basic path description (S3 is performed only
  if
• Other alternative path descriptions
• Interactions between actors and systems (S2 3)
• Usage of objects, values and resources in the
  system (S3)
• Explicitly describe what actors and the system do
  (define system boundary)

31
Non functional Requirement

• When a buyer issues an invoice for payment, the
  system should respond with a verification of the
  request within 1.0 second in 90 of the cases.
  The time for the verification must never exceed
  10.0 seconds, unless the network connection is
  broken (in which case the user should be
  notified).
• Use case descriptions are finished when they are
  understandable, complete and consistent!

32
Formalizing Use Case Descriptions

• More formal and structure mechanisms to handle
  complexity
• Startchart diagrams to describe state-transitions
  of the use cases
• Activity diagrams to describe the transitions
  between states in more detailed action sequences
• Interaction diagrams to describe how an instance
  of use case interact with an instance of an actor

33
Example Pay Invoice
34
Review

• Identify actors
• Identify use cases
• Brief description of use cases
• Put them together
• Refine use cases
• Detailed description of use cases
• Check completeness and consistency

35
Activity Prototype User Interface

• Creating a logical UI design
• Creating UI for each actor
• Which UI elements are needed to enable the use
  cases (that are relevant to the actor)
• How should they be related to each other
• How will they be used in different use cases
• What should they look like
• How should they be manipulated

36
Prototype UI

• Identify UI elements
• which of the domain classes, business entities,
  or work units are suitable as UI elements for the
  use case
• What UI elements does the actor work with? (often
  these are terms from the glossary, e.g. account
  balance, due date, etc.)
• What actions can the actor invoke what decisions
  can actor make
• What guidance and information does the actor need
  before invoking each action in the use case
• What information does the actor need to supply to
  the system
• What information does the system need to supply
  to the actor
• What are average values for all I/O parameters,
  e.g. how many invoices will an actor normally
  deal with

37
Example Pay Invoice

• UI elements Invoice (amount, due date,)
• Additional information Account

38
Prototype UI

• Creating Physical UI Design and Prototype
• creating UI sketch
• validating UI design
• allow for proper navigation
• consistent look and feel
• complies with relevant standards
• rapid prototyping executable UI

39
Activity Structure Use Case Model

• Goal A more consistent and concise description
• Identify shared description of functionality and
  perform generalization if proper

40
Structure Use Case Model

• Identify additional and operational descriptions
  of functionality
• Identify other relationships between use cases

41
(No Transcript)