Document Sample
					Use-case Model: Writing Requirements In


  Identify and write use cases.
  Relate use cases to user goals and elementary
   business processes.
  Use the brief, casual, and fully dressed formats, in
   an essential style.
  Relate use case work to iterative development.

Use case = “Story”
  Writing use cases—stories of using a system—is
   an excellent technique to understand and
   describe requirements.

What is use case?
  Use Cases are to discover and record functional
  A use case captures a contract between the
   stakeholders of a system about its behavior.
  The use case describes the system’s behavior
   under various conditions as it responds to a
   request from one of the stakeholders, called the
   primary actor.
  A Use Case is a collection of related success and
   failure scenarios that describe actors using a
   system to fulfill (or support) a goal.
  A scenario is a specific sequence of actions and
   interactions between actors and the system under
Major Concepts in Use-Case Modeling
  An actor represents anything that interacts with
   the system.


  A use case is a sequence of actions a system
   performs that yields an observable result of
   value to a particular actor.

                       Use Case

Use Case

  The name of a Use Case should be the main goal
   of the Use Case.
  Use cases are fundamentally a text form,
   although they can be written using graphic form.
  In UML use-case diagrams, a use case is
   rendered as an ellipse.

                     Process Loan

Use Cases

  Use cases document system behavior from point
   of view of the user

  A user means anything that is
    external to the system under development and
     which interacts with the system

Use Cases and Functional Requirements

  Use cases are requirements (not all requirements).
  Primarily they are functional requirements that
   indicate what the system will do. Use cases define
   a promise or contract of how a system will behave.
  Use cases provide a structured way to help with
   requirements capture
     Identify the actors
     Find out what actors need from the system
     Find out any other interactions the actors expect
      to have with the system

Use Cases Basics

  An actor is something with behavior, such as a person
   (identified by role), computer system, or organization; for
   example, a cashier

  The actor initiates an interaction with the system to accomplish
   some goal. The system responds, protecting the interests of all
   the stakeholders.

  A scenario is a specific sequence of actions and interactions
   between actors and the system under discussion. It is one
   particular story of using a system, or one path through the use

  A use case is a collection of related success and failure
   scenarios that describe actors using a system to support a goal

Example of UC

 Example of POS Use Case – Handle Returns

 Handle Returns
 Main Success Scenario:
 A customer arrives at a checkout with
 items to return. The cashier uses the POS system to record each
 returned item ...

 Alternate Scenarios:
 If the credit authorization is reject, inform the customer and ask for an
     alternate payment method.
 If the item identifier is not found in the system, notify the Cashier and
     suggest manual entry of the identifier code (perhaps it is corrupted). If
     the system detects failure to communicate with the external tax
     calculator system, ...


  An actor is anything with behavior, including the
   system under discussion itself when it calls upon
   the services of other systems.

  Primary and supporting actors will appear in the
   action steps of the use case text.

  Actors are not only roles played by people, but
   organizations, software, and machines.

Type of Actors
  Primary actor has user goals fulfilled through
   using services of the system.
     For example, the cashier.

  Supporting actor provides a service (for example,
   information) to the system. Often a computer
   system, but could be an organization or person.
     For example, the automated payment authorization

  Offstage actor has an interest in the behavior of
   the use case, but is not primary or supporting
     For example, a government tax agency.
UC Names
  Every use case must have a name that distinguishes it
   from other use cases.
  Rules of naming Use Case:
   Verb + Noun

          Place Order              Validate User

Goals and Brief Format Use Cases
  Customers and end users have goals (needs/requirements) and want
   computer systems to help meet them. The goals are primarily the
   starting point of finding out use case

  Brief format Use cases are a mechanism to help keep it simple and
   understandable for all stakeholders.
     Informally, they are stories of using a system to meet goals.

 Here is an example brief format use case:
 Process Sale: A customer arrives at a checkout with items to purchase.
   The cashier uses the POS system to record each purchased item. The
   system presents a running total and line-item details. The customer
   enters payment information, which the system validates and records.
   The system updates inventory. The customer receives a receipt from
   the system and then leaves with the items.

  Use cases are text documents, not diagrams, and use-case modeling is
   primarily an act of writing text, not drawing. However, the UML defines a use
   case diagram to illustrate the names of use cases and actors, and their
               A Video Clerk who wants to rent a video to a customer
                 will communicate with the use case Rent A Video.

 Video Clerk                                           Rent A Video

Use Case Diagram (a Library System)

                Reserve book
                 Borrow copy
    Book         of book                      Browser
                Return copy of

                Extend loan
     Journal      Return
     Borrower     Journal

What Is a Use-Case Model?
  A model that describes a system’s functional
   requirements in terms of use cases
  A model of the system’s intended functionality
   (use cases) and its environment (actors)

                                View Report Card

                               Register for Courses


Use Case Model
 The Use Case Model is described by the following constructs:
  Actors (name, description, status, subclass, superclass, and
  Use cases (number, subject area, business event, name, overview,
   preconditions, description, associations, inputs, outputs, traceable to,
   usability index, and notes)
  Communication-associations between actors and uses cases
  Relationships between use cases (same as use case associations)
  Termination outcomes
  Conditions affecting termination outcomes
  Termination outcomes decision table
  Use case scenarios (number, termination outcome, description, and
  Problem domain concept definitions
  System steps decision table
  Flow of events table
  System sequence diagram
Use Case model(2)

                                                Use Case                                                     Actor
          Subject Area:                                                                                       Description:
          Business Event:                                                                                     Status:
          Name:                                                                                               Subclass:
          Overview:                                            Scenario Number                                Superclass:
          Preconditions:                                       Use Case Number                                Associations:
                                                               Termination Outcome
          Description:                                         Scenario Notes
          Associations:                                        Scenario Describption
          Traceable To:
          Usability Index:
                        Decision Table
                                                              Termination Outcome:
                       xxxxxxxxxxxx T T F

                       xxxxxxxxxxxx F F F
                                                              Conditions Affecting:
                                     xxxxxxxxxxxx   F T   T

                                     xxxxxxxxxxxx         T

           Decision Table                                     Flow of Events                             System Sequence Diagram
          xxxxxxxxxxxx   T T     F       STEP A/S ACTION               DATA         VALIDATION NOTES
          xxxxxxxxxxxx   F   F F         xxxx xx xxxxxxxxxxxxxxx   xxxx       xxxxxxxxxxx   xxxxxxxxxx
                                         xxxx xx xxxxxxxxxxxxxxx   xxxx       xxxxxxxxxxx   xxxxxxxxxx
          xxxxxxxxxxxx   F   T   T
                                         xxxx xx xxxxxxxxxxxxxxx   xxxx       xxxxxxxxxxx   xxxxxxxxxx
          xxxxxxxxxxxx           T       xxxx xx xxxxxxxxxxxxxxx   xxxx       xxxxxxxxxxx   xxxxxxxxxx
                                         xxxx xx xxxxxxxxxxxxxxx   xxxx       xxxxxxxxxxx   xxxxxxxxxx

UC Formality Types
  Use cases are written in different formats, depending on
   need. Use cases are written in varying degrees of formality:

  Brief - terse one-paragraph summary, usually of the main
   success scenario. (The prior Process Sale example was
  Casual - informal paragraph format. Multiple paragraphs
   that cover various scenarios. (The prior Handle Returns
   example was casual.)
  Fully dressed - the most elaborate. All steps and
   variations are written in detail, and there are supporting
   sections, such as preconditions and success guarantees.

Use-Case Specifications
  Name                                 Use-Case Model
  Brief description
  Flow of Events
  Relationships               Actors
  Activity diagrams                         Use Cases
  Use-Case diagrams
  Special
  Pre-conditions                                  ...
  Post-conditions
                                        Use-Case Specifications
  Other diagrams

Use-Case Flow of Events
  Has one normal, basic flow
  Several alternative flows
     Regular variants
     Odd cases
     Exceptional flows for handling error situations

What Is a Scenario?
  A scenario is an instance of a use case.

Case Study: Use Case - Process Sale

  See appendix for details

My Recommendation: The Two-Column Format

 Main Success Scenario:
 Actor Action (or Intention)                     System Responsibility

 1. Customer arrives at a POS checkout
 with goods and/or services to purchase.
 2. Cashier starts a new sale.                   4. Records each sale line item and presents
                                                     item description and running total.
 3. Cashier enters item identifier..             5. System presents total with taxes
 Cashier repeats steps 3-4 until
 6. Cashier tells Customer the total, and
 asks for payment.                               8. Handles payment
                                                 9. Logs the completed sale and sends
 7. Customer pays.
                                                 information to the external accounting
                                                 and inventory systems (to update inventory).
                                                 System presents receipt.

Extensions (or Alternate Flows)
  Extensions are very important. They indicate all the other
   scenarios or branches, both success and failure.
  Extension scenarios are branches from the main success
   scenario, and so can be notated with respect to it. For
             3a. Invalid identifier:
             1. System signals error and rejects entry.

    7b. Paying by credit:
              1. Customer enters their credit account information.
              2. System requests payment validation from external Payment
              Authorization Service System.
              2a. System detects failure to collaborate with external system:
                         1. System signals error to Cashier.
                         2. Cashier asks Customer for alternate payment.
              3. ...

Use Case Template

 Use Case                                   { name }                         Identifier             { id }
 Summary              { Brief text summary of the use case. }
 Actors               { Names of actors involved in the use case. }
 Description          { Text description of the use case. }
 Preconditions        { Things that must be true for the use case to be executed, i.e. start state S0.}
 Normal Paths         1. First step of the use case.
                      2. Second step of the use case.
                      . { includes extension points, inclusions, etc. }
                      n. Last step of the use case.
 Postconditions       { Things that will be true after the use case has executed, i.e. final states Sf. }
 Exceptions           { Any known exceptions that may interrupt normal flow of events. }
 Alternate Paths      { Alternative paths through the case – should include responses to exceptions. }
 Requirements         { Trace back to requirements realized by this use case. }
 Outstanding Issues   { Text description of any issues concerning this use case needing resolution.
                      Should include identity of responsible party.}

USE CASE #X           <Use Case Name: An active verb phrase (or gerund phrase) that describes the particular usage of the
                      system. See criteria governing use case granularity for cross-referring nouns used in the use case
Subject Area          <A grouping mechanism, used to group use cases>
Business Event        < Business events are triggers that stimulate activity within the business. They are the stimuli that
                      prompt the business to act. Many business events occur at the interface point between the business and
                      one of the external entities that it interacts with. Other business events are internal triggers based on
                      conditions or predefined time intervals. Business events must be atomic (cannot be decomposed into
                      two or more events) and detectable (observable). Furthermore, it is not possible for a business event to
                      have partially happen.>
Actor(s)              <The actor initiating this use case. See criteria governing use case granularity when using more than
                      one actor.>
Use case              <Brief description -- one or two sentences -- that describes in a declarative style the overall scope and
Overview              content of the use case. Does not describe the flow of events, business or data validation rules. See
                      criteria governing use case granularity for cross-referring nouns used in the use case overview.>
Preconditions         <Constraints that must be met for the use case to be executed. The system may have to be in a certain
                      state before the initiation of the use case is enabled. This may include required sequencing of use
                      cases; for instance, one or more other use cases may have to have been executed successfully for this
                      use case to begin.>
Termination Outcome                      Condition Affecting Termination Outcome
<Alternative ways that the use           < The condition or conditions under which the corresponding termination outcome
case may terminate. Sometimes            occurs. Many times there is a straight one-to-one correspondence between
this means successful and                termination outcomes and conditions. However, often there are multiple conditions
unsuccessful and sometimes there         and/or Boolean logic operators needed to express the right conditions. In these
are multiple successful ways in          instances, a decision table is often useful for communicating the termination
which the use case can end.>             outcomes and the conditions under which they can occur.>
<termination outcome #2>                 <condition(s) for termination outcome #2>
Use Case         <A simple, brief description of the series of events (conversation) of the most likely to occur termination
Description      outcome (a/k/a main course). Should be expressed in terms of what the actor does and how system
                 responds. Should not be complicated by too many conditionals. In addition, should not include looping.>
Use Case         <A list of other use cases that this use case is extended by or is used by.>
Traceability     <Other related work products, models, or documents that this use case is traceable to. This may include
To:              business rules, data validation rules, a traditional functional requirements document, business objectives,
                 GUI sketches/mockups/screens/prototypes, use case scenarios, etc….>
Inputs           <Summary level listing of data input by the actor. Can be all inclusive but doesn’t have to be.>
Output           <Summary level listing of data output by the system. Can be all inclusive but doesn’t have to be.>
Usability        <How the use case ranked in terms of satisfaction, importance and frequency.>
Use Case         <Information that is not directly part of the use case but arises while working
Notes            on the use case. For example, questions, actions-items, design notes.>
How to Find Use Cases

  1. Choose the system boundary. Is it just a software
   application, the hardware and application as a unit, that
   plus a person using it, or an entire organization?

  2. Identify the primary actors. Those that have user
   goals fulfilled through using services of the system.

  3. For each, identify their user goals. Raise them to the
   highest user goal level that satisfies the EBP guideline.

  4. Define use cases that satisfy user goals; name them
   according to their goal. Usually, user goal-level use cases
   will be one-to-one with user goals, but there is at least one
   exception, as will be examined.
Identifying Actors

  When developing a use case model, identify the
   different roles played by the potential human users
   of the system
     People play different roles at different times
     E.g. A person can play the role of book borrower,
      librarian, browser or journal borrower at different times
     Any person who interacts with the system will be
      represented by at least one actor in use case model

  Typical Actors:
     Roles that people play
     Computer systems
     Electrical or mechanical devices
Identifying Non–Human Actors

  Which external systems or devices that interact
   with the system should be shown on a use case

  These external systems or devices can either be
    at all times,
    when the other system or device initiates contact, or
    when the other system or device gets value from the

Identifying Use Cases

  Actor-Based Approach:
     Identify actors related to a system or organization
     Then, for each actor, identify the process they initiate or
      participate in
  Event-Based Approach:
     Identify external events that a system must respond to
     Relate events to actors and use cases
  Yet Another approach:
     Express business processes in terms of specific
      scenarios, then generalize

A Common Mistake

  Representing individual steps, operations, or
   transactions as use cases
  Question: In POS system, is there a use case
   called “printing receipt”?
  Tip:
    Use case is relatively large end-to-end process
     description that typically includes many steps or

Case Study: Writing Use Case - Step 1: Choosing the System Boundary

  For this case study, the POS system itself is the
   system under design; everything outside of it is
   outside the system boundary, including the
   cashier, payment authorization service, and so on.

  If it is not clear, defining the boundary of the
   system under design can be clarified by defining
   what is outside the external primary and
   supporting actors.

  Once the external actors are identified, the
   boundary becomes clearer.


                                                   Enterprise Selling Things

                                                              Checkout Service
                      Sales Tax
                                                                       POS System
      Goal: Collect
    taxes on sales                Sales Activity
                                    System             Cashier


   Goal: Buy items                 Goal: Analyze sales           Goal: Process sales
                                   and performance data

Steps 2 and 3: Finding Primary Actors and Goals

  Primary actors have user goals fulfilled through using services of
   the system. (Supporting actors provide services to the system under
  Brainstorm the primary actors! The primary actor is the framework for
   further investigation.
  Think of goals of the system
  Be suspicious if no primary actors are external computer systems.
  Reminder Questions to Find Actors and Goals:

  ho starts and stops the system?
  Who does system administration?
  Who does user and security management?
  Is "time" an actor because the system does something in response to a time event?
  Is there a monitoring process that restarts the system if it fails?
  Who evaluates system activity or performance?
  How are software updates handled? Push or pull update?
  Who evaluates logs?
  Are they remotely retrieved?

(Continue) Work out The Actor-Goal List

 Actor      Goal                        Actor            Goal
 Cashier    process sales               System           add users
            process rentals             Administrator    modify users
            handle returns                               delete users
            cash in                                      manage security
            cash out
   …                  …
 Manager    start up shut down …        Sales Activity
                                        System           analyze sales and
                                                         performance data

Step 4: Define Use Cases

  Name the use case similar to the user goal
   (name use cases starting with a verb).
    For example, Goal: process a sale; Use Case:
     Process Sale

Steps to write a use case (Important)
  Step 1: Find the boundaries of the system
   (Context diagram, In/out list).
  Step 2: Brainstorm and list the primary actors.
   (Actor List)
  Step 3: Brainstorm and list the primary actors'
   goals against the system. (Actor-Goal List)
  Step 4: Write the outermost summary level use
   cases covering all the above.
  Step 5: Reconsider & revise the strategic use
   cases. Add, subtract, merge goals.
  Step 6: Pick a use case to expand or write a
   narrative to get acquainted with the material.

Steps to write a use case (Continue)
  Step 7: Fill in the stakeholders, interests,
   preconditions and guarantees. Double check them.
  Step 8: Write the main success scenario. Check it
   against the interests and the guarantees.
  Step 9: Brainstorm and list possible failure
   conditions and alternate success conditions.
  Step 10: Write how the actors and system should
   behave in each extension.
  Step 11: Break out any sub use case that needs
   its own space.
  Step 12: Start from the top and readjust the use
   cases. Add, subtract, merge. Double check for
   completeness, readability, failure conditions.
Use Case Diagrams

  The UML provides
   use case diagram         system boundary            NextGen                communication

   notation to illustrate                       Process Sale                                alternate

   the names of use                                                          Payment
                                                                                            notation for
                                                                                            a computer
                                                                                            system actor
   cases, actors, and
                                 Cashier      Handle Returns               Authorization

   the relationships         actor
                                                 Process Rental
                                                                           Tax Calculator

   between them                                                               «actor»
                                                      Cash In                Accounting
                             Sales Activity
                               System                                         «actor»
                                               Analyze Activity
                                                                             HR System

                                                 Manage Security

                              System          Manage Users
                            Administrator                                use case

Discussion of UCD

  A common sign of a novice (or academic) use-
   case modeler is a preoccupation with use case
   diagrams and use case relationships, rather than
   writing text.

  Suggestion: Draw a simple use case diagram in
   conjunction with an actor-goal list.

  A use case diagram is an excellent picture of the
   system context; it makes a good context diagram,
   that is, showing the boundary of a system, what
   lies outside of it, and how it gets used.

UC Diagram Suggestions

    For a use case context                                 Show computer system actors
    diagram, limit the use cases to                        with an alternate notation to
    user-goal level use cases.                             human actors.


                                  Process Sale                             Payment
                                                                          The class box style can be
                                                                          used for any actor, computer or
                                                                          human. Using it for computer
                                                                          actors provides visual
            primary actors on                         supporting actors
            the left                                  on the right

Splitting Use Cases

  Write major steps or branching activities of a use
   case as a separate one when:
     They are duplicated in other use cases
     They are complex and long and separating them helps
      factor the use cases into manageable pieces

UML: Include Relationship
• A include relationship from use case A to use case B
indicates that A will also include the behavior as specified by
• similar behavior across use cases is identified after the use
cases are specified

                                 Buy Items
                     <<include>> <<include>> <<include>>

                 Pay By Credit   Pay By Cash      Pay By Check
      Cashier                                                    Customer

Another Example

              Use ATM

                             Withdraw Case

                              Deposit Case

                             Transfer Account

UML: Extend Relationship

  sometimes use cases are complex because they
   have many steps
  Used when a second use case story follows the
   story of a prior use case
  Extending a use case is, effectively, an alternate
   course of base use case
  Introduce an extending use case whenever logic
   for an alternate course of action is at a complexity
   level similar to that of your basic course of action

  An extends relationship from use case A to use case B
   indicates that an instance of B may include (subject to
   specific conditions) the behavior specified by A

                                  University Enrolment System

           Registrar                                                          Applicant
                                           Enroll In
                                           University     <<include>>
                                                                  Enroll in
        Student                                                   Seminar

                                                  Enroll Family
                                                   Member in
                        Perform Security
        International                              University

Another Example

              Enter Text


                       <<extend>>        Check Spelling


                                        Change Template

                                           Find Word

Requirements Considerations

  The use case idea is the consideration and organization of
   requirements in the context of the goals and scenarios
   of using a system
  Use cases capture detailed, low-level system feature
  Use Cases are not Object-Oriented
  Use cases are not the only necessary requirements artifact.
   Some non-functional requirements, domain rules and
   context, and other hard-to-place elements are better
   captured in the Supplementary Specification
  It is useful to summarize system functionality with a high-
   level feature list called system features in a Vision

Use Cases through Development

  Planning:
    List all the use cases for the system
    Have a good idea of what each means
    Understand who wants each and how much
    Know which use cases carry the most risk
    Plan which should take to implement

  Determine the order of implementation of the use
   cases, and which ones belong in which iteration of
   the system

Use-case Driven Development
  Requirements are primarily recorded in use cases (the
   Use-Case Model); other requirements techniques (such as
   functions lists) are secondary
  Use cases are an important part of iterative planning. The
   work of an iteration is defined by choosing some use case
   scenarios, or entire use cases. And use cases are a key
   input to estimation
  Use case realizations drive the design. That is, the team
   designs collaborating objects and subsystems in order to
   perform or realize the use cases
  Use cases often influence the organization of user

Business Use Case
  Business use cases are less commonly written. If done,
   they are created in the Business Modeling discipline as
   part of a large-scale business process reengineering effort,
   or to help understand the context of a new system in the
  Business use case describes a sequence of actions of a
   business as a whole to fulfill a goal of a business actor (an
   actor in the business environment, such as a customer or

 For example, in a restaurant, one business use case is
   Serve a Meal.

Problems with Use Cases (1 of 2)

  Use case modeling should be used with caution
  Danger of building a non-object oriented system
     To lessen this danger, carefully manage the beginning of each
     Do not add any new functionality if the previous iteration was
  Danger of mistaking design for requirements
     Design can involve different sequences of interactions which
      achieve the same goal but may be “new” to the users
     Requirements can be met in many different ways through design

Problems with Use Cases (2 of 2)

  Danger of missing requirements
    Relying too heavily on process of finding actors first,
     then finding use cases each needs
    Lessen this danger by doing use case analysis and
     conceptual class modeling in parallel

Use Case Traps

    Too many use cases
    Highly complex use cases
    GUI-containing use cases
    Data definitions or algorithms in use cases
    Use cases users don’t understand
    New business processes

Case Study - Use Case: Body shop free estimate

  The dealership's body shop offers free estimates.
   In this Use Case, the body shop estimator
   provides an estimate of parts, labor, and schedule
   for a customer with a damaged vehicle.
  The primary actor is the body shop employee
   performing the estimate (the "estimator").

Sample brief Use Case

 Body Shop Free Estimate

 A customer shows up at the body shop with a
   damaged vehicle. The estimator enters the
   customer's information and the vehicle
   identification (VIN, license, etc). He then enters
   each damaged part or labor task into the system,
   which accumulates them. When he is finished
   entering data, the system creates and stores the
   estimate. A copy of the estimate is printed for the

 Estimator -- Wants software support to generate an accurate
 Customer -- Wants to know how much it will cost him to fix his
    car, and when the work will be completed.
 Parts department -- Wants advanced notice of long-lead-time
 Body shop -- May need to schedule this job.
 Paint shop -- May need to schedule this job.
 Service department -- May need to schedule this job.
 Accounting & payroll -- May need to charge the estimator's time
    to a different account.
 Insurance company -- Keeps tabs on estimates generated.
 Rental organization -- Is a loaner vehicle available? What is
    pricing for this customer?
 Sales organization -- May be an opportunity to sell another car.

  System is preloaded with parts lists and
   diagrams for all major makes and models of
  System is preloaded with the dealership's
   database of labor and shop time charges.

 Estimate is generated.
 Estimate is retained for use when/if customer
  chooses to have work performed.

Main scenario
1. Customer arrives with damaged car (or it is towed in).
2. Estimator enters customer identification into system.
3. Estimator enters vehicle information (make, model, year, VIN,
   etc) into system.
4. Estimator enters into system either a part for repair/replacement
   or a labor item (e.g., "paint front fender").
5. System accumulates cost of replacement part and/or labor
   Repeat steps 4-5 for all damaged or missing parts or shop tasks.
6. Estimator indicates end of parts & labor data entry.
7. System generates estimate (parts list, labor total, and estimated
   completion date). Estimate is saved (for comparison with actual
   work, in case of dispute with customer, and for statistics).
8. System prints estimate for customer.

Alternate flows

  5b. System has no record of the specified part or labor item.
     5b1. System notifies estimator that database contains no
      record for this item.
     5b2. Estimator enters manual estimate for that item.
     5b3. System accumulates manual estimate and notes this
      line item as such.
     5b4. System files this manual estimate for later review and
      'official' entry into database.
  8a. Customer chooses to have work performed.
     8a1. See Use Case BS2, "Body Shop Open Repair Order"

What Is an Activity Diagram?
  An activity diagram in the Use-Case Model can be used to
   capture the activities in a use case.
  It is essentially a flow chart, showing flow of control from
   one activity or action to another.

    Flow of Events

    This use case starts when the Registrar requests that
    the system close registration.

    1. The system checks to see if registration is in                          Activity2
    progress. If it is, then a message is displayed to the
    Registrar and the use case terminates. The Close
    Registration processing cannot be performed if
    registration is in progress.
                                                                   Activity1   Activity3
    2. For each course offering, the system checks if a
    professor has signed up to teach the course offering
    and at least three students have registered. If so, the
    system commits the course offering for each schedule
    that contains it.

Example: Activity Diagram
                                Select Course                                              Activity/Action
     Threads                                      [ delete course ]
                                                                      Delete Course
                                 [ add course ]

                                                                                      Bar (Fork)
                      Check                         Check
   Guard             Schedule                     Pre-requisites
                [ checks completed ]      [ checks failed ]                           Bar (Join)

                    Assign to                       Resolve
                     Course                         Conflicts


               Sales              Fulfillment


              Take Order

                                    Fill Order
             Setup Payment

             Deliver Order

Summary: SW Development Artifacts and Use Case Model

                                                    Domain                  Partial artifacts,
            Business                                Model                   refined in each
            Modeling                                                            iteration.

                                      Vision                                      Glossary

                                     Design Model                                Software
                                                                             Architecture Doc.

                                   Dev. Plan

                          Test                                           Development
                          Plan                                              Case
                 Test                           Environment

Case Study: Course Registration System Use-Case Model

  Investigate Course Registration
   Requirements artifacts:
     Problem statement
     Glossary
     Supplementary Specification
  And now how do we produce:
     Use-Case Model main diagram
     Write use cases


Exercise 1: Payroll System Use-Case Model
  Given the following Payroll Requirements
     Problem statement
     Glossary
     Supplementary Specification
  Produce the following:
     Use-Case Model main diagram
     Write any of three use cases


Shared By: