Title: Information Systems Analysis and Design Requirements and Use Case Modeling
1Information Systems Analysis and
DesignRequirements and Use Case Modeling
2Requirements 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
3Requirements 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
4FURPS Model
- One way to help identify requirements is to use
the FURPS model
- Functional
- Usability
- Reliability
- Performance
- Supportability
- everything else
5Functional 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
6Users
- 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)
7Functional 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?
8Functional 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
9Usability 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?
10Reliability 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
11Performance 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)
12Performance Requirements
Availability is a common performance requirement
13Supportability 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?
14The Requirements
- The other requirements in FURPS include
- Implementation
- Interface
- Operations
- Packaging
- Legal
- And anything else you think of!
15Implementation 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)
16Interface 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.)
17Operations 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)
18Packaging 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?
19Legal 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)
20Requirements
- 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
21More Requirements Sources
- For more info, see
- Cockburns Writing Effective Use Cases, Addison
Wesley (2001)
- Software Engineering Body of Knowledge
(www.swebok.org)
22Use 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!!!
23Use 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
24We 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
25Brief 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
26Scenarios
- 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
27Scenarios
- 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
28Use 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
29Use 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
30Use 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)
31Use Case Description
- The written description for one use case can
include the following sections
- Primary Actor
- Stakeholders and Interests
- Preconditions
- Postconditions
- Main Success Scenario
32Use Case Description
- Extensions
- Special Requirements
- Technology and Data Variations List
- Frequency of Occurrence
- Open Issues
- See also the template from http//www.usecases.org
/
33Primary 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
34Stakeholders 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
35Preconditions
- 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
36Postconditions
- 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?
37Main 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
38Extensions
- 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)
39Extensions
- 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
40Extensions
- 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.
41Special 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
42Technology 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
43Frequency 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
44Open 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
45How 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.
46Good 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
47Secondary 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.)
48Actor-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!
49Name Use Cases
- Give use cases a brief name, generally of the
form verb adjective(s) noun
- Rent items
- Generate status report
- Maintain inventory
- etc.
50Essential 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
51Time 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
52Use 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)
53Use Case Diagram
Borrowed from p. 71
54Use 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
55Planning 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
56Planning 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)
57Global 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
58Supplementary 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
59Supplementary Specification
- Functionality (those requirements common across
many or all use cases)
- Usability
- Reliability
- Performance
- Supportability
- Implementation Constraints
- Purchased Components
60Supplementary 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
61Business 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
62Additional 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
63Vision
- 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)
64Vision
- 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
65Vision
- 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
66Glossary
- 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
67Glossary
- 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
68Glossary
A term unique to your project
69Glossary
- 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
70Connection 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
71Elaboration 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
72Inception 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
73Inception 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
74Elaboration 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
75Core 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
76Plan 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
77Relating 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)
78Warning!
- 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
79How 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
80How 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
81Special 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
82Extended 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
83Generalized 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)
84Stereotypes
- 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