Information Systems Analysis and Design Requirements and Use Case Modeling - PowerPoint PPT Presentation

1 / 84
About This Presentation
Title:

Information Systems Analysis and Design Requirements and Use Case Modeling

Description:

The Primary Actor is generally human, unless some external system is automated ... are from the point of view of the actor describe only what they see or do ... – PowerPoint PPT presentation

Number of Views:674
Avg rating:3.0/5.0
Slides: 85
Provided by: gle9
Category:

less

Transcript and Presenter's Notes

Title: Information Systems Analysis and Design Requirements and Use Case Modeling


1
Information Systems Analysis and
DesignRequirements and Use Case Modeling
  • INFO 620
  • Glenn Booker

2
Requirements Analysis
  • Like all modern software life cycles, the
    Rational Unified Process (RUP) advocates
    management of system requirements
  • Requirements include the capabilities of the
    system (functions or features), as well as
    conditional or limitations on how those
    capabilities are achieved

3
Requirements Change
  • Unlike the waterfall life cycle, the RUP
    recognizes that requirements, and our
    understanding of them, change during practically
    every project
  • Hence a key is to capture our current
    understanding of requirements as clearly as
    possible

4
FURPS Model
  • One way to help identify requirements is to use
    the FURPS model
  • Functional
  • Usability
  • Reliability
  • Performance
  • Supportability
  • everything else

5
Functional Requirements
  • The biggest category is Functional requirements
    what the system can do
  • To help identify Functional requirements, first
    identify the kinds of users your system might have

6
Users
  • Users might come from the general public (e.g.
    anyone on the Internet)
  • Your organization might have managers or
    administrators who have special needs
  • The developers of the system might be a user
    type
  • Different departments within your organization
    might be users (finance, sales)

7
Functional Requirements
  • Then identify what kinds of functions each type
    of user needs to perform
  • Think of a detailed job description for each type
    of user does it include enter invoices or
    generate reports or analyze customers or ???
  • A general function may be broken down into more
    detail e.g. what kind of reports?

8
Functional Requirements
  • Dont obsess with getting every functional
    requirement on the first try this is an
    iterative process, and youll probably find more
    requirements later
  • For now, write down requirements grouped by user
    this will feed into Use Case documentation soon

9
Usability Requirements
  • The U stands for Usability which includes
  • Human factors what characteristics of your
    system will make it more pleasant to use?
  • Help what Help will the user have available?
    F1? Context sensitive? Online books?
  • Documentation what documentation will be created
    to help the users learn how to use this product?
    Tutorials? Users manual?

10
Reliability Requirements
  • Reliability is often critical for many systems
  • Reliability requirements are measured e.g.
  • Mean Time Between Failures (MTBF) how long can a
    user use the system before it crashes
  • Mean Time To Repair (MTTR) how long does it take
    to fix the system once it crashes? (though this
    could be a maintainability issue)
  • Availability is under Performance requirements

11
Performance Requirements
  • Most measures of performance can be made into
    requirements
  • Response time for queries (average, maximum)
  • Throughput (number of records processed per hour
    or day, transactions per second (TPS))
  • Accuracy (scanning or data entry correctness)
  • Resource usage (CPU or disk space used, network
    traffic)

12
Performance Requirements
Availability is a common performance requirement
13
Supportability Requirements
  • Supportability requirements include
  • Maintenance issues do you provide
    troubleshooting guides? MTTR could be here
  • How easy is it to maintain the system? This
    could include installation of software or
    hardware upgrades
  • Internationalization is your system usable in
    many languages?
  • Can your system be reconfigured easily?

14
The Requirements
  • The other requirements in FURPS include
  • Implementation
  • Interface
  • Operations
  • Packaging
  • Legal
  • And anything else you think of!

15
Implementation Requirements
  • Implementation requirements are limitations on
    how the system may be implemented
  • Resource limitations (cost, schedule, staffing)
  • Languages and tools (programming environment to
    be used for development)
  • Hardware (e.g. must use IBM equipment)
  • Software (e.g. must use Oracle database)
  • User hardware limits (must run on PII with 32 MB
    RAM on Windows 98)

16
Interface Requirements
  • Interface requirements are that your system may
    communicate with external systems
  • Legacy systems in your organization
  • Vendors or suppliers
  • Teammates or corporate partners
  • External organizations (IRS, SBA, FDA, etc.)

17
Operations Requirements
  • Your system must be managed while its in
    operational use
  • What functions will the managers need?
  • Add users or groups
  • Define permissions for users or groups
  • Monitor resource usage (CPU, disk, network)
  • Monitor physical environment (temperature)

18
Packaging Requirements
  • How will your product be packaged?
  • Distribution medium? CD-ROM? DVD?
  • What documentation is written vs. electronic?
  • Who will the users contact for help?
  • Are different distributions needed for different
    countries? Languages?

19
Legal Requirements
  • How is your product licensed?
  • By user? By site?
  • By computer?
  • By processor?
  • Are there different versions of your product?
    (academic vs. commercial)
  • Are there places where your product cant be
    sold? (export restrictions)

20
Requirements
  • So the FURPS categories can help identify many
    kinds of requirements
  • Will need to establish priorities for
    requirements (esp. the functional ones), to help
    put them into timeboxes later
  • Required, Desired, Optional is one basic set of
    priorities, kind of like High, Medium, Low

21
More Requirements Sources
  • For more info, see
  • Cockburns Writing Effective Use Cases, Addison
    Wesley (2001)
  • Software Engineering Body of Knowledge
    (www.swebok.org)

22
Use Case Modeling
  • Use Case modeling is a major tool for capturing
    requirements
  • It is not object oriented, just very useful
  • The use case diagram captures functional
    requirements the rest only show up in use case
    documentation
  • So dont forget the documentation!!!

23
Use Case Model
  • A use case is a description of how some user uses
    the system more formally
  • The specification of a sequence of actions,
    including variants, that a system (or other
    entity) can perform, interacting with actors of
    the system. (UML 1.5 spec)
  • Focus here is on what the system can do, not how

24
We get to Act?
  • Actor is the UML term for type of user in the
    context of a use case
  • A coherent set of roles that users of use cases
    play when interacting with these use cases. An
    actor has one role for each use case with which
    it communicates. (UML 1.5 spec)
  • An Actor can be a person (by role, e.g. cashier),
    external system, or organization

25
Brief Format Use Case
  • One way to describe a use case is with a written
    narrative describing how the actor interacts with
    the system (p. 46)
  • BTW, use cases (actually usage cases) were first
    defined by Ivar Jacobson in 1986

26
Scenarios
  • A scenario is a description of one use case,
    a.k.a. a use case instance
  • A scenario can have a good (intended) outcome a
    success scenario
  • Customer purchased books
  • If not, there might be a failure scenario
  • Customers credit card was rejected

27
Scenarios
  • The main intent of a use case is the Main
    Success Scenario, which should satisfy some user
    goal or need
  • But there may be several Alternate Scenarios,
    both successful and not
  • Alternate scenarios are variations on what might
    happen, e.g. paying with various methods, or
    failing to complete the transaction

28
Use Case Objective
  • The assumption isIf all use cases have been
    identified, then all system functional
    requirements have been identified
  • Use cases should avoid all implementation
    concepts keep all options open for the design
    of the system
  • This is the black box use case concept

29
Use Case Description Formality
  • There are three levels of formality for
    describing use cases
  • Brief (one paragraph for the main success
    scenario), p. 46
  • Casual (a few paragraphs including alternate
    scenarios), p. 47
  • Fully dressed (complete), p. 50-53

30
Use Case Formatting
  • One-column format uses one narrative, where each
    paragraph is another action by an actor or the
    system, p. 50
  • Two-column format uses the left column for all
    actor actions, and the right column for all
    system actions, p. 53
  • Generally easier to generate the one-column
    format (preferred, but not required)

31
Use Case Description
  • The written description for one use case can
    include the following sections
  • Primary Actor
  • Stakeholders and Interests
  • Preconditions
  • Postconditions
  • Main Success Scenario

32
Use Case Description
  • Extensions
  • Special Requirements
  • Technology and Data Variations List
  • Frequency of Occurrence
  • Open Issues
  • See also the template from http//www.usecases.org
    /

33
Primary Actor
  • The Primary Actor for a use case is the actor
    (type of user) who starts using the system to
    achieve some goal
  • Hence it is the initiator of the use case
  • The Primary Actor is generally human, unless some
    external system is automated to prompt your
    system for some reason

34
Stakeholders and Interests
  • This section is a list of all actors involved in
    this use case, and a description of what they
    want to get from the main success scenario
  • Usually one or two sentences per actor is
    adequate

35
Preconditions
  • Preconditions are the entry conditions for
    starting this use case
  • This should describe any assumptions about what
    the primary actor has already done (or not done),
    and what action on the part of the primary actor
    motivates them to use the system for this purpose

36
Postconditions
  • Postconditions, or Success Guarantee, is a
    summary of the desired outcomes at the end of
    this use case
  • Again, this applies to the main success scenario
    if everything goes well what will the end of
    use case achieve?

37
Main Success Scenario
  • The main success scenario is a step-by-step
    description of the use case if everything goes
    well
  • This describes the intended purpose of the use
    case
  • All steps are from the point of view of the actor
    describe only what they see or do

38
Extensions
  • Extensions, or Alternate Flows, describe what
    might happen to alter or clarify the main success
    scenario
  • This includes things going wrong (credit card
    failed validation), and merely different options
    to achieve success (pay with cash versus paying
    with a check)

39
Extensions
  • Extensions are numbered by adding letters to the
    step in the main success scenario where the
    different behavior happened
  • Main success scenario 3. Cashier enters item
    identifier
  • Extension 3a. Invalid identifier
  • Then describe the steps for the extension

40
Extensions
  • Hence extensions have two parts for each entry
    the condition which flags use of that extension,
    and the handling of that extension (what to do as
    a result)
  • Condition 3a. Invalid item identifierHandling
    1. System shows error and rejects item entry.

41
Special Requirements
  • Special requirements can include non-functional
    requirements or other constraints on the use
    case
  • Performance, reliability, usability, and design
    constraints might get mentioned in this area, if
    they specifically apply to this use case
  • General constraints go in the Supplementary
    Specification

42
Technology and Data Variations List
  • This section describes different types of
    technology which may be applied for performing
    the steps
  • Data format or input device options
  • Only applies if the differences do NOT result in
    different steps being followed then it would be
    an Extension

43
Frequency of Occurrence
  • This is a straightforward section to indicate how
    often this use case will be exercised
  • 1000 times per day?
  • Once per month?
  • Helps sort out priorities for use cases, and may
    affect design issues later

44
Open Issues
  • This section is to flag uncertain assumptions,
    likely changes in technology, or any other issues
    which are not fully resolved
  • Unresolved legal, process, or interface issues
    could also go here

45
How Find Use Cases?
  • Two methods for finding use cases
  • Business Use CasesBoundaries are typically
    organizations. Each use case is an Elementary
    Business Process. Actors are business
    organizations.
  • System Use CasesBoundaries are the system were
    creating. Each use case is a way of using the
    system. Actors are users of the system. We will
    use this.

46
Good Use Cases
  • Good, or primary use cases satisfy some user
    goal
  • A use case starts and finishes some task
  • Secondary use cases are needed for the system to
    work, but are not fulfilling goals
  • Log in, log out, and shut down the system are
    secondary use cases
  • Optional use cases may not be implemented

47
Secondary Actors
  • Secondary, or supporting actors are those which
    wait for the system to tell to do something
  • They do not initiate any use case
  • Often an external system which provides a needed
    service (printing, data, etc.)

48
Actor-Goal List
  • For each primary actor, list all of the goals
    they need to fulfill in their job
  • A simple 2-column table will do (p. 65)
  • Each Primary actor is something that interacts
    directly with the system so in a retail
    environment, Customer may not be a primary actor!

49
Name Use Cases
  • Give use cases a brief name, generally of the
    form verb adjective(s) noun
  • Rent items
  • Generate status report
  • Maintain inventory
  • etc.

50
Essential Style
  • Try to focus use case descriptions on the intent
    of the actor, not how it is implemented through
    the interface
  • Instead of log in maybe the purpose is to
    identify and authenticate user
  • Describing the interface limits how the system is
    implemented

51
Time for Pictures!!!
  • Remember that the written use case description is
    the main tool for capturing requirements the
    use case diagram is just a high level summary of
    it
  • At a high level, a use case diagram has similar
    ideas as a context diagram, but with more of a
    process focus

52
Use Case Diagram
  • A use case diagram shows
  • Use cases (one per bubble)
  • Actors (all kinds, human and not)
  • Which actors can apply which use cases (lines
    connecting actors to use cases)
  • System boundary (a box called System, for
    example)

53
Use Case Diagram
Borrowed from p. 71
54
Use Case Diagram
  • So the use case diagram just shows the names of
    all the use cases, and what actors are involved
    in which use cases
  • It does not show the logic or sequence in which
    use cases are applied (if any exists)
  • Use case diagram does not show TIME

55
Planning Use Cases
  • Once the use cases have been identified, can
  • Define criticality (biz value) for each
  • Assess risks of implementing each use case
  • Importance of that use case to the systems
    structure (architectural significance)
  • Can score each of these factors from 0-3 to
    determine use cases priority (see p. 577)
  • Add (scoreweight) for each use case

56
Planning Use Cases
  • Based on this analysis, determine which use cases
    need to be implemented first
  • These could feed the high level Phase Plan, then
    each Iteration Plan within those phases
  • This is what we mean by use case driven
    development (which the RUP is)

57
Global Use Case Documentation
  • The Supplementary Specification captures
    non-functional requirements which apply to many
    use cases, or the system as a whole
  • The Glossary captures terms and definitions
    later it is also a data dictionary
  • The Vision captures the purpose and intent of the
    project

58
Supplementary Specification
Adapted from pp. 84-87
  • The Supplementary Specification (SS) mostly
    follows the FURPS structure to identify global
    or common requirements
  • Sections within the SS include
  • Revision History since the SS captures
    requirements, it needs to be controlled like any
    other part of the system
  • Introduction explain purpose of the SS

59
Supplementary Specification
  • Functionality (those requirements common across
    many or all use cases)
  • Usability
  • Reliability
  • Performance
  • Supportability
  • Implementation Constraints
  • Purchased Components

60
Supplementary Specification
  • Open Source Components
  • Interfaces description of unusual input output
    devices, interfaces to external systems
  • Operations
  • Packaging
  • Legal Issues
  • Business Rules see next slide
  • Additional Domain Information

61
Business Rules
  • Business (or Domain) Rules describe rules which
    will affect how various functions are
    implemented
  • Often based on your organizations way of doing
    business (hence the name), but some are also
    legally imposed (charging sales tax)
  • For each business rule, also define how
    frequently it changes, and who defined it

62
Additional Domain Information
  • Called Information in Domains of Interest in
    the text
  • This section is used to provide additional
    information on various concepts or aspects of
    system functionality
  • May provide links to detailed technical
    information for interfaces or regulations

63
Vision
  • The Vision statement is a summary business case
    for your product
  • What do you want to do, and why is it worth
    doing?
  • Vision sections include
  • Revision History
  • Introduction provide 1-2 sentence summary of
    what needs your product will fulfill (objective)

64
Vision
  • Positioning provide a description of what is
    wrong with the existing market for your type of
    product, who your product is intended for, and
    what the major competition can and cant do
  • Stakeholder Descriptions more general than the
    use case description, this should identify
    demographics skills for users of your product,
    and identify what goals and problems they face

65
Vision
  • Product Overview summarize the use case diagram
    into one use case for the entire system, and show
    all the actors which use or support it. This is a
    System Context Diagram.Provide a summary of the
    main features of the product, and how they will
    benefit the stakeholders
  • Summary of System Features may be somewhat
    redundant with the previous section

66
Glossary
  • The Glossary is a dictionary for the project
  • Identify terms and acronyms, and write
    definitions of them
  • Definitions may be your own, or from an external
    source
  • Might include hyperlinks for more information

67
Glossary
  • Glossary includes only three sections
  • Revision History
  • Definitions a table with the definitions (see
    next slide), and sources where available
  • Sources a bulleted list of sources used for
    definitions

68
Glossary
A term unique to your project
69
Glossary
  • Later will expand Glossary into a data dictionary
    to identify specific attributes used for this
    project
  • Keep in mind what units apply to attributes (,
    feet, degrees, etc.)
  • Glossary also can define larger ideas (composite
    terms) such as sale or order

70
Connection to RUP Life Cycle
  • The Supplementary Specification, Vision, and
    Glossary should all be started early in the life
    cycle, in the Inception phase
  • They will be mostly finalized during the
    Elaboration phase, though adjustments may be
    needed during the Construction phase

71
Elaboration Phase
  • The Elaboration phase is when
  • The requirements are defined,
  • Major risks are identified (and mitigated
    wherever possible), and
  • The core architectural elements of the system
    are implemented

72
Inception Review
  • From the Inception phase, we should have
  • Identified key functional and non-functional
    requirements, using interface prototypes where
    needed
  • Identified actors, goals, and major use cases
  • Written most use cases in at least brief format,
    and fully documented critical ones

73
Inception Review
  • Written drafts of the Supplementary
    Specification, Vision, and Glossary
  • Conducted proof of concept for key technical
    concepts (risk reduction)
  • Determined which major components will be
    obtained elsewhere
  • Started thinking about high level architecture
  • Planned the first iteration

74
Elaboration Phase
  • Key concepts during elaboration include
  • Do timeboxed iterations
  • Start programming early
  • Design, implement, and test core parts of system
    architecture
  • Test early and test often
  • Use feedback, especially from users
  • Complete most use cases in detail

75
Core Architecture?
  • Focus on making sure the subsystems can
    communicate with each other, even if their
    contents dont exist yet (wide shallow)
  • Designing at the seams (Booch)
  • Integrate and test interfaces early, especially
    external systems
  • Implement significant scenarios
  • Test key usability, exception, or stress
    situations

76
Plan Next Iteration
  • Use the Risk, Coverage, and Criticality to
    determine the next iteration
  • Technical or other risk
  • Covering all major parts of the system (also
    called architectural significance last week)
  • Business value criticality
  • Large use cases may take multiple iterations

77
Relating Use Cases
  • After use cases have been identified, it may be
    possible to isolate some activities
  • These subfunctions can be described as extended,
    included, or generalized use cases
  • They are closely related concepts we prefer to
    focus on included use cases
  • These are never used for business modeling (too
    detailed)

78
Warning!
  • Much time can be wasted arguing over included use
    cases
  • If in doubt whether it really is an included use
    case, leave it out
  • When it is used, included use cases can simplify
    your system and encourage reuse

79
How to Find Included Use Cases
  • Look for activities which are
  • A clearly defined subset
  • Used by at least two use cases
  • The point of included use cases is to identify
    functions which can be called by more than one
    other use case
  • Classic example is making a payment with a
    credit card

80
How to Find Included Use Cases
  • Use include when you are repeating yourself in
    two or more separate use cases to avoid
    repetition (Fowler00)
  • Another special case is when a function can be
    used any time during another use case
  • That function can be an included use case, e.g.
    check spelling

81
Special Use Case Terms
  • A concrete use case is done entirely by the
    primary actor (Process Sale)
  • An abstract use case is never done by itself
    (Handle Credit Payment)
  • The use case which invokes an included, extended,
    or generalized use case is the base use case
  • The invokee is an addition use case

82
Extended Use Case
  • If you find special scenarios for a use case, and
    dont want to amend the base use cases
    description, an extended use case can be added
  • An extended use case still has clear start and
    stop, but the base use case may or may not need
    it
  • Nearly identical to an included use case

83
Generalized Use Cases
  • Generalized use cases are not yet well defined
  • This is the same generalization concept as
    applied to classes, namely
  • A taxonomic relationship between a more general
    element and a more specific element. The more
    specific element is fully consistent with the
    more general element and contains additional
    information. An instance of the more specific
    element may be used where the more general
    element is allowed. (UML 1.5 spec)

84
Stereotypes
  • These special use cases have stereotypes in the
    use case diagram to show their special status
  • or
  • or
  • An unfilled arrow points TO the included or
    extended use case (NOT the base use case)

p. 391
Write a Comment
User Comments (0)
About PowerShow.com