

REQ480 Mastering
Requirements
Management with
Use Cases
Student Workbook
Version 2003.06.00
Part# 800-026338-000
IBM Software Group
Rational University
REQ480 Mastering Requirements Management with Use Cases
Student Workbook
Version 2003.06.00
May, 2003

Copyright  International Business Machines Corporation, Rational Software 2003. All rights reserved.
This document may not be reproduced in whole or in part without the prior written permission of IBM.

The contents of this manual and the associated software are the property of Rational Software and/or its
licensors, and are protected by United States copyright laws, patent laws, and various international treaties. For
additional copies of this manual or software, please contact Rational Software.

Rational, the Rational logo, ClearQuest, ClearCase, ClearCase LT, ClearCase MultiSite, Unified Change
Management, Rational Developer Network, Rational Rose, Rational XDE, Purify, PureCoverage, Rational
Unified Process, ClearDDTS, and Quantify are trademarks or registered trademarks of Rational Software
Corporation in the United States and in other countries.

Microsoft Visual Basic, Windows NT, Windows 2000, Windows 95/98, Windows XP, Microsoft Word,
Windows Explorer, DOS, PowerPoint, and Visual SourceSafe, among others, are trademarks or registered
trademarks of Microsoft Corporation.
UNIX, Solaris, Motif, Java and all Java-based marks, among others, are trademarks or registered trademarks of
Sun Microsystems in the United States and/or other countries.

All other names are used for identification purposes only and are trademarks of their respective companies.

Printed in the United States of America.

 Contents
¾¾¾

EX: Exercises

EX3: Introduction to Use-case Modeling

Exercise 3.1: Identify Actors and Use Cases 1
EX4: Analyze the Problem
Exercise 4.1: The Problem Behind the Problem 7
Exercise 4.2: Describe the Problem 15
EX5: Understand Stakeholder Needs
Exercise 5.1: Review Customer Requirements Specifications 25
Exercise 5.2: Brainstorming 33
EX6: Define the System
Exercise 6.1: Identify the System Features 35
Exercise 6.2: Identify the Use Cases 43
Exercise 6.3: Outline them Use Cases 49
EX7: Manage Scope
Exercise 7.1: Prioritize Requirements Using Attributes 55
Exercise 7.2: Prioritize Scenarios 59
EX8: Refine the System Definition
Exercise 8.1: Choose A Style 65
Exercise 8.2: Detail the Flows 77
Exercise 8.3: Identify Nonfunctional Requirements 83

CRA: Course Registration Artifacts

CRA1: Initial Requests 1
CRA2: Use-Case Model Survey 3
CRA3: Use-Case Outlines 7
CRA4: Use-Case Reports 11

RUCS: RU e-st Case Study

RUCS1: RU e-st System Specification
RUCS2: Glossary
RUCS3: Vision Document
RUCS4: Use-Case Model Survey
RUCS5: Step-by-Step Outline
RUCS6: Use-Case Reports
RUCS7: Structured Use-Case Reports
RUCS8: Supplementary Specification
RUCS9: Software Development Plan
RUCS10: Requirements Management Plan
RUCS11: Use-Case Modeling Guidelines
WP: White Papers
WP1: The Five Levels of Requirements Management Maturity
WP2: Features, Use cases, Requirements, Oh My!
WP3: Using the RUP to Evolve a Legacy System
WP4: Generating Test Cases From Use Cases
WP5: Structuring the Use-Case Model
WP6: ACRE: Selecting Methods For Requirements Acquisition
► ► ► Contents

EX: Exercises

EX3: Introduction to Use-case Modeling

Exercise 3.1: Identify Actors and Use Cases .........................................1

EX4: Analyze the Problem

Exercise 4.1: The Problem Behind the Problem....................................7
Exercise 4.2: Describe the Problem .....................................................15

EX5: Understand Stakeholder Needs

Exercise 5.1: Review Customer Requirements Specification..............25
Exercise 5.2: Brainstorming.................................................................33

EX6: Define the System

Exercise 6.1: Identify the System Features..........................................35
Exercise 6.2: Identify the Use Cases....................................................43
Exercise 6.3: Outline the Use Cases ....................................................49

EX7: Manage Scope

Exercise 7.1: Prioritize Requirements Using Attributes ......................55
Exercise 7.2: Prioritize Scenarios ........................................................59

EX8: Refine the System Definition

Exercise 8.1: Choose A Style...............................................................65
Exercise 8.2: Detail the Flows .............................................................77
Exercise 8.3: Identify Nonfunctional Requirements............................83
 ¾¾¾
Exercise 3.1
Identify Actors and Use Cases
The purpose of this exercise is to identify actors and use cases for a simulated project.
You have been introduced to the online Course Registration System that is the case
study throughout this module. For this exercise, use information and artifacts from the
Course Registration System case study.
First identify the actors in the example system. “Student” is identified as an actor.
Who or what else interacts with this system? Refer to the questions for identifying
actors.
For each of these actors, identify the types of interactions each might have with our
system. Refer to the questions for identifying use cases and the guidelines for naming
use cases.

Objectives
In this exercise, complete the following tasks:
¾ Identify the actors who interact with the system.
¾ Identify the use cases.
¾ Sketch a use-case diagram for the system.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
You have just been assigned the job of lead system analyst for a new system. You
have been given a problem description (“Initial System Requests” below). Your first
task is to understand the requirements for the new system. From the Initial Requests,
you develop a use-case model of the requirements. In this first part of the modeling
process, you identify actors and use cases and develop a use-case diagram.
As you look at the initial requests for the system, note that the requirements are far
from complete. Note what assumptions you make, as well as what other information
you want to ask your customer.

Directions
1. Read the Initial System Requests document.

As a whole class with the instructor leading the activity:

1. Run a short use-case workshop to decide on actors and use cases.
2. Draw the use-case diagram on easel paper or the board.
• Show actors, use cases, and communicates-associations.
3. Compare the diagram with the sample solution.
4. Discuss the “Discussion Topics” at the end of this exercise.

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Identify Actors and Use Cases

Initial System Requests

Wylie College is planning to develop a new online Course Registration System. The
new Web-enabled system replaces its much older system developed around
mainframe technology. The new system allows students to register for courses from
any Internet browser. Professors use the system to register to teach courses and to
record grades.
Because of a decrease in federal funding, the college cannot afford to replace the
entire system at once. The college will keep the existing course catalog database
where all course information is maintained. This database is an Ingres relational
database running on a DEC VAX. The legacy system performance is poor, so the new
system accesses course information from the legacy database but does not update it.
The registrar’s office continues to maintain course information through another
system.
Students can request a printed course catalog containing a list of course offerings for
the semester. Students can also obtain the course information online at any time.
Information about each course, such as professor, department, credit hours, and
prerequisites assists students in making informed decisions.
The new system allows students to select four course offerings for the coming
semester. In addition, each student indicates two alternate choices in case the student
cannot be assigned to a primary selection. Courses have a maximum of ten and a
minimum of three students.
The registration process closes on the first or second day of classes for the semester.
Any course with fewer than three students enrolled on the day registration closes is
cancelled. All courses without an instructor on the day registration closes are
cancelled. Students enrolled in cancelled classes are notified that the course has been
cancelled, and the course is removed from their schedules. The registration system
sends information about all student enrollments to the Billing System so that the
students can be billed for the semester.
For the first two weeks of the semester, students are allowed to alter their course
schedules. Students may access the online system during this time to add or drop
courses. Changes in schedules are immediately sent to the Billing System so that an
updated bill can be sent to the student.
At the end of the semester, the student can access the system to view an electronic
report card. Since student grades are sensitive information, the system must employ
security measures to prevent unauthorized access. All students, professors, and
administrators have their own identification codes and passwords.
Professors must be able to access the online system to indicate which courses they
want to teach. They also need to see which students signed up for their course
offerings. In addition, professors can record the grades for the students in each class.

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

C o u r s e R e g is t r a t io n
S y s te m

Identify Actors
Who uses the system?
Who gets information from the system?
Who provides information to the system?
Where in the organization is the system used?
Who supports and maintains the system?
What other systems use this system?

Identify Use Cases

What are the goals of each actor?
• What will the actor use the system for?
• Will the actor create, store, change, remove, or read data in the system?
• Will the actor need to inform the system about external events or changes?
• Will the actor need to be informed about certain occurrences in the system?
Does the system supply the business with all of the correct behavior?

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Identify Actors and Use Cases

This page is intentionally left blank.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Sample Solution

Discussion Topics
How does your solution compare with the sample solution? What is different? What
is the same?
Are the use cases too small? Should some use cases be combined?
Does the diagram cover all activities? For example, which use cases do you think are
too small or should be canceled? Can you think of any activities not covered?
How do you know what is done in each use case?
What changes are you going to make to the bill if someone cancels three weeks
before the start of a course? Is it due to medical reasons, such as a broken leg?

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 

¾¾¾
Exercise 4.1
The Problem Behind the Problem
In this exercise, familiarize yourself with the RU Financial Services case study. This
case study is used throughout the course as an example of applying requirements
management concepts discussed in class. The class may decide to develop a different
class project. The directions for the exercises are written generically so that they
should be applicable for any class project you choose.
The purpose of this exercise is to apply problem analysis techniques. Identify any
hidden problems that may exist in the problem domain of your class project. The
“real” problem(s) may not be those most obvious at the beginning.

Objectives
In this exercise, complete the following tasks:
¾
Review the details for the RU e-st class project.

¾
Demonstrate how to use problem analysis techniques to find the root causes for
a problem.

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 The Problem Behind the Problem

Scenario
You have been given the role of project lead for the RU e-st project. The first task is
to validate that a stock trading system is, indeed, the best solution to solve the
business’ problems and help the business achieve its goals. To do this you must lead
your team through the activities of problem analysis.

Directions
Gain an understanding of the business by reading Parts 1, 2, and 3 of the business
problem and business background.
Once you have read these, work as a class to perform the problem analysis. The
directions for this are located on page 10.

Part 1: Business Problem

RU Financial Services is an investment management organization with 500 offices
located across every state. The head office is located in the nation’s capital. RU
Financial Services was the first to market with online stock trading in 1992. The
personal stock trading business exceeded all expectations and became a significant
part of RU Financial Services’ revenue for the next eight years. Since then the
company has had difficulty attracting new customers to their service, and existing
customers have been switching to rival companies at an alarming rate.
The goal is to see how RU Financial Services can regain its market share and continue
to grow the personal stock trading side of the business. The board members have
done some analysis and decided that the current stock trading system needs
replacing. Harold Smedley, the Vice-President of RU Financial Services, has asked
you to determine if this truly is the best course of action.
• Based on a recent customer satisfaction survey, 60% of customers were not
satisfied with how long it took for updates to the software to become available.
This dissatisfaction figure needs to be reduced to less than 5%.
• The current business model for RU Financial Services mandates that
infrastructure costs should not be more than 10% of the revenue generated by
the business. This is currently running at 40%.

• Maintenance costs of the software are currently running at 25% above the
average maintenance costs of other software in the company. This figure must be
reduced to no more than 15%.
• Based on a recent survey, it was found that 70% of customers require additional
services that the current system does not provide. The main requests were: real-
time stock quotes; ability to research stock, ability to fund trading account
directly from a savings account held in another financial institution, and Web
access instead of having to install client software.

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 The Problem Behind the Problem

• About 2% of customers have experienced errors in their trades in the last six
months. This figure must be reduced to 0%.

Part 2: The Business Background

RU Financial Services introduced their online trading system in 1992 before the birth
of e-commerce. At that time, the company had a corporate standard architecture of
VAX 6300 mainframe computers and DECstation 3100s for desktop machines. For
this project, the company chose to use a VAXft 3000, DIGITAL’s first fault tolerant
machine. The new corporate standard for desktops is a standard PC running
Microsoft Windows 2000. The server standard is a high-end PC running Windows
2000 Server or an IBM eServer iSeries 890.
The current stock trading system employs a client-server architecture. Updates to the
software are mailed to the customer for installation bi-annually. Critical bug fixes are
sent out on demand. The customer is required to install the client software on a
machine running Microsoft Windows 98 or higher or an Apple running Mac OS X.
The client software is written in QuickBasic and runs in a console window. The client
software communicates with a server application via a 56K dial-up connection.
The server application runs on a VAXft 3000. The server software is written in
COBOL and comprises 500,000 lines of code. The server application is the last
application that runs on a VAXft 3000. All other corporate applications have been
migrated to the new corporate standard platform. The VAXft 3000 is under a 24x7
maintenance contract. The cost of the maintenance contract is $200,000 per annum.

The company phased out the systems written in COBOL and QuickBasic some years
ago. All software in the company is written one of the following: C++, Java, or Visual
Basic. Due to the success of the system, the company did not want to rewrite the
stock trading system and risk the introduction of bugs and loss of revenue. The
current stock trading system is the only system that uses COBOL and QuickBasic.
The company has adopted the Rational Unified Process for developing and
maintaining all systems in the organization. All projects are required to use this
process. The company mentor for the RUP is Kelly Richardson.
There is no existing documentation for the client or server applications. None of the
original development team remains employed at the company; therefore, contract
programmers maintain the software. As a result, the code for both the client and the
server has become very unstructured and fragile. Recently, this has caused some
major bugs that have caused errors in trades and required multiple updates to the
client and server software.
A dedicated testing group performs testing of the system. Because the system runs in
a console window on the client PC, the testers are unable to use their automated
testing software. The test scripts are performed manually. New tests are rarely
designed because they are document based.

© Copyright IBM Corp. 2003 9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 The Problem Behind the Problem

Part 3 – Current System Architecture

Directions
Working together as a class:
1. Identify root causes of the problem using a fishbone diagram.
• Perform problem analysis, using the fishbone diagram technique. (Draw
the fishbone diagram on easel paper or board.)
• Identify the largest contributors to the problem.
• Discuss whether the proposed solution really is the best solution.
• Compare the class solution to the sample solution. (Only do this if you
use the RU e-st project.)

10 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 The Problem Behind the Problem

This page is intentionally left blank.

© Copyright IBM Corp. 2003 11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 The Problem Behind the Problem

Sample Solution: Identify Root Causes - The Problem Behind the Problem

This is a sample solution for the class project. Although there is no one correct answer
for this example, compare your results with the sample provided.

12 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 The Problem Behind the Problem

© Copyright IBM Corp. 2003 13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 The Problem Behind the Problem

14 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾
Exercise 4.2
Describe the Problem
The purpose of this exercise is to describe the problem and start defining the
boundaries of the solution in the Vision document.
Understand all the stakeholders in your project in addition to the customer who is
paying the bill. Make sure you consider all those affected by the outcome of the
system, including stock shareholders, system maintainers, and developers.

Objectives
In this exercise, complete the following tasks:
¾
Identify the stakeholders for the project

¾
Identify the actors who interact with our system.

¾
Use the standardized problem statement format provided to formulate a problem
statement for the class project.

© Copyright IBM Corp. 2003 15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
An analysis of the root causes during the problem analysis found that replacing the
current system is the best solution to solving the problems the company is
experiencing. You now start work creating a Vision document for the project.

Directions
In this exercise, complete the following tasks:
1. Work in your groups to start the Vision document.
a. Identify key stakeholders.
b. Define the system boundaries by identifying actors who interact with
the system. (Refer to exercise 4.1.)
c. Identify constraints on your project.
2. As a whole class:
a. Create a consolidated list of stakeholders from each group.
b. Create a consolidated list of actors from each group.
c. Together, write a problem statement to summarize the problem.
Note: If you are not using RU e-st as your class project, this scenario should be
adjusted accordingly.

Exercise completion
At the end of this exercise you should have the beginnings of your system Vision
document.
Remember, the Vision document is developed iteratively, and you should not expect
to complete it in one sitting.

16 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Analyze the Problem

Part 1: Identify Stakeholders (Section 3.2 of the Vision document)

Using the Vision document included in your student pack, complete Section 3.2:
Stakeholder Summary.
Who are the key stakeholders for the class problem?
Who are the stakeholders that will actually be using the system (potential actors)?
Which stakeholders will you seek to obtain requirements from? For the stakeholders
that are not sources of requirements, what should you do with them?
All users of the system are stakeholders because they are materially affected by the
system. But there are some stakeholders (for example, stockholders) who are
probably not actors because they will never use the system.

© Copyright IBM Corp. 2003 17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Part 2: Identify Actors and Boundaries

An actor is a user of the system. A user can either be an individual or an external
system. By definition, an actor is outside of the system, therefore; identifying the
actors helps to define the boundaries of the system.
Label some of the actors in the diagram below. Use the following questions to help
you determine if you have found them all.
Refer back to the business background in Exercise 4.1 to help you identify your initial
list of actors.
Actors
• Who uses the system?
• Who gets information from the system?
• Who provides information to the system?
• Where in the organization is the system used?
• Who supports and maintains the system?
• What other systems use this system?
Boundaries
• What are the interfaces to outside systems for our project?
• How can use cases help us figure out these boundaries?
• What is part of the system?
• What is not part of the system?

Our
System

18 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Analyze the Problem

Part 3: Identify Constraints (Section 6 of the Vision document)

Complete Section 6: Constraints of the Vision document.
What types of constraints might you encounter in your class project?

© Copyright IBM Corp. 2003 19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Part 4: Problem Statement (Section 2.2 of the Vision)

Complete Section 2.2: Problem Statement of the Vision document.
The problem statement table is a tool for gaining agreement on the problem being
solved. This is a simple technique to help articulate the problem and to ensure that
everyone agrees on the problem. Fill in the problem statement table for your class
project.
Below is a copy of the template and an example to help you get started.

The problem of
(describe the problem)

Affects
(the stakeholders affected by the problem)

The impact of which is

(what is the impact of the problem)

A successful solution
would
(list some key business benefits of a successful solution)

Example Problem Statement (for a customer support system)

The problem of untimely and improper resolution of customer service

issues

Affects our customers, customer support representatives, and

service technicians.

The impact of which is customer dissatisfaction, perceived lack of quality,

unhappy employees, and loss of revenue.

A successful solution provide real-time access to a trouble-shooting database

would by support representatives and facilitate dispatch of
service technicians, in a timely manner, only to those
locations that genuinely need their assistance.

20 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Analyze the Problem

This page is intentionally left blank.

© Copyright IBM Corp. 2003 21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Part 1 Sample Solution: Identify Stakeholders

Trading Customers
IRS
Securities and Exchange Commission
RU Financial Services
• Online Trading Business
• Customer support
• Finance Department
• IT Department
• Development Group
• Board of directors
• Stockholders

Part 2 Sample Solution: Identify Actors and Boundaries

Trading Customer Market Trading

System

System
Administrator

Broker
RU e-st
System

Web Content
Provider

Tech Support

22 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Analyze the Problem

Part 3 Sample Solution: Identify Constraints

Tax laws
Federal Trade Commission (FTC) rules
Securities and Exchange Commission (SEC) rules
Project schedule
Project budget
Security for financial information
System developed using Java
The project uses the Rational Unified Process

Part 4 Sample Solution: Problem Statement (Write in your Vision document)

a stock trading system that:

The problem of • Lacks features required by our customers.
• Has intermittent errors in trades.
• Is expensive to operate and maintain due to
labor and infrastructure costs.
• Is difficult to maintain due to:
o Client/server architecture
o Legacy code that lacks
documentation, structure, and
architecture
o Lack of developer knowledge of
current system

affects RU Financial Services.

The impact of which is We need to replace the current online stock-trading

system.
• Provide the feature set demanded by our customers.
A successful solution • Provide a reliable service that has no errors in
would trades.
• Reduce the operation and maintenance costs to no
more than 10% of the gross contribution margin of
the online trading business.
• Use a corporate standard architecture and
implementation language.

© Copyright IBM Corp. 2003 23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

24 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾
Exercise 5.1
Part 1: Review Customer Requirements
Specification
In this exercise, identify and itemize requirements from system specifications. This is a
system specification for the online stock trading system.
The goals of this exercise are for students to become familiar with requirements
expressed in traditional format and for them to begin to identify declarative
requirements.
As you review the system specification
• Refine your current list of actors from Exercise 4.2
• Identify new actors

Objectives
In this exercise, you do the following tasks:
¾ Review the Online Stock Trading System Specifications.
¾ Look for possible requirements.
¾ Mark and number each requirement.
¾ Refine the solution boundary by revisiting the list of actors.
¾ Review a sample list of stakeholder requests.
¾ Update the Vision with the stakeholder needs you have identified. (optional)

© Copyright IBM Corp. 2003 25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
The board of directors has decided that replacing the current online trading system is
the best way forward. In light of the decision to develop a new online stock trading
system, the following initial requests have been produced.

Directions

Part 1
Working individually:
1. Turn to the initial requests for the online stock trading system.
• Note that the specification is not complete.
2. Read through the specification.
3. Mark and number anything you think is a software requirement.

As a whole class:
1. Present the number of requirements you found.
2. Compare the number of requirements from different individuals in the class.
3. Discuss the “Discussion Topics” at the end of this exercise.

Discussion Topics
Why are the numbers so different? How should the differences be resolved?
What are the benefits of standard documents? What are the identification methods
for requirements? For example, “shall,” delimiters, and so on.
What do you do with a requirement spec that you received from your customer?
(Especially when you have no control of the content or the format.)
Were there any changes to your actor list?

26 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Review Customer Requirements Specification

RU E-ST SYSTEM SPECIFICATION

Note: The sample in this handout contains only pages 1 through 4 of

the specification.

Disclaimer: This is a fictitious system and does not claim to be a model for a good
Software Requirement Specification. It is used for exercise purposes only.

© Copyright IBM Corp. 2003 27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

INTRODUCTION
RU Financial Services is beginning an e-commerce project to develop software for a
Web-based stock and securities trading system. The new system has been tentatively
named the RU e-st system.

Purpose
The purpose of this SRS is to serve as a statement of understanding between the
Online Trading Business and Engineering Divisions of RU Financial Services. Any
desired departures from the specifications described herein must be negotiated by
the affected parties.
The audience for this SRS includes the engineers who are involved in the
development of the system, the marketers who are involved in its advertisement and
sale, and the testers who validate the system.

Scope
The overall objective of the RU e-st Stock Trading System is to provide our trading
customers with a convenient way to manage their stock portfolios. Managing a stock
portfolio includes such capabilities as buying and selling and researching stock in a
secure environment.

REQUIREMENTS
In this section, all of the functions that the RU e-st Stock Trading System Software is
to perform are specified. These specifications are first given from total system
perspective.
The RU e-st system shall provide all of the current functionality of the current stock
trading system, plus any additions specified in this document.

Trading Customer Requirements

The RU e-st system allows its users to trade securities online, using a Web interface
(an existing browser, such as Netscape or Internet Explorer). A trading customer can
log on to the Internet anywhere (hotel room, airport, and so on.) Users are able to
perform all the basic operations for securities trading: open accounts, trade stocks
and other securities, and transfer assets among RU e-st accounts. Users can also
obtain current and historical information about their accounts, such as the number of
shares held, the current price, and the account total value.
Customers are able to execute many types of trade orders: market trading (buy and
sell at current market prices), transfers from one mutual fund to another within one

28 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Review Customer Requirements Specification

account, and limit trading (buy and sell at a specific price). The RU e-st system uses
the existing Market Trading System to perform the securities trades. RU e-st also
allows users to transfer cash in an account to or from financial institutions such as
banks or credit card vendors, using the existing Financial Network System. The usual
restrictions apply:
• For online market sales, the securities to sell must be in the customer’s account.
• For market purchases, cash for the purchase must be in the account by the
settlement date.
• Transfers and purchases from an account are allowed only if, at the time the
transaction occurs, they have enough cash to fund the transaction in the account.
Trading customers are also able to obtain information about what is happening in the
securities markets. A trading customer can obtain price quotes and news headlines by
entering the trading symbol (for example, IBM) for a particular security. The RU e-st
system obtains current and historical quotes from the existing Quote System service
and news items from the existing News System. RU e-st also has a feature to
broadcast news headlines periodically on the trading customer’s screen without being
asked.

Regulatory Requirements
The system must report yearly tax information to the IRS and state tax boards. Tax
forms must be communicated to the IRS and copies mailed to the customer. The
information is also available online for customer viewing.

System Administration Requirements

Updates to the information on the Web pages must be possible without making the
system unavailable.

Development Requirements
The system must be written in one of the company’s approved programming
languages. Refer to document Enterprise Architecture and Development Standards
document EA-12341 for details.

Hardware Requirements
The hardware platform must be one supported by the enterprise hardware
maintenance contract. Supported platforms are specified in the Enterprise
Architecture and Development Standards document EA-1234.

1
This document is not supplied with the course.

© Copyright IBM Corp. 2003 29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

This page is intentionally left blank.

30 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Review Customer Requirements Specification

¾¾¾
Exercise 5.1
Part 2: Review Sample Stakeholder Requests
In this exercise, familiarize yourself with the list of sample stakeholder requests. This
list is used to illustrate traceability in subsequent exercises.
Note: The following is a sample list of stakeholder requests that were produced
during the workflow detail of Understand Stakeholder Needs. This list is included so
that the traceability from stakeholder requests to features and use cases can be
illustrated. The list is not intended to be exhaustive and there any many other
stakeholder requests that you may have elicited.

Directions

Part 2
1. Review the list of sample stakeholder requests. (This is used as input into the
next exercise.)
2. List the needs in section 3.7 of your Vision document (Optional).

© Copyright IBM Corp. 2003 31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Requirements Origin
STRQ1: Want to be able to transfer funds from other accounts (not necessarily held with this Trading Customer
firm) to a trading account.
STRQ2: State and federal regulations require monthly reports of account activity. Refer to Regulatory
specification RUFS-1234 for details of the information required.
STRQ3: The system should allow the use of any browser. Trading Customer
STRQ4: Customers want to manage their retirement funds. Trading Customer
STRQ5: Must be able to upgrade the system without taking it offline. On-line Trading
Business
STRQ6: The system should allow traders to trade in multiple markets across the world. Trading Customer
STRQ7: Must be able to provide convenient answers to customer’s most common questions. Customer Support
STRQ8: The system must provide a secure environment that prohibits fraudulent access. Trading Customer
STRQ9: Need a way to train customers in the use of the system quickly and conveniently. Customer Support
STRQ10: The system must operate on hardware that falls under the company’s current Finance Department
maintenance contracts.
STRQ11: Need to be able to maintain the system with our current IT hardware and skills. Refer System
to enterprise architecture document EA-1234 for details. Administration
STRQ12: Need account activity statements for tax reporting. Trading Customer
STRQ13: The system must provide all the basic capabilities of a normal stock broking firm. Trading Customer
STRQ14: Need to be able to perform research on any given stock. Trading Customer
STRQ15: The system must allow traders to obtain up-to-date news and alerts on nominated Trading Customer
stock.
STRQ16: The system must provide current and historical information on Trading Acounts. Trading Customer
Such as number of shares held, current price, total Trading Account value
STRQ17: The system shall provide the following types of trades: Market Trades (buy and sell), Trading Customer
Limit Trades (buy and sell), and transfers between mutual funds.
STRQ18: The system shall use the existing Market Trading System to perform securities Trading Customer
trades.
STRQ19: The system must report yearly tax information to the IRS and state tax boards. Regulatory
STRQ20: Tax forms will be sent electronically to the IRS and state tax authorities. Regulatory
STRQ21: Tax information can be viewed on-line by the Trading customer and printed if Regulatory
requested.
STRQ22: The system performance must be aceptable to customers that do not have high- Trading Customer
speed data access for their computers.

32 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾
Exercise 5.2
Brainstorming
In this exercise, come up with some high-level needs of the stakeholders for your
system.
The purpose is to:
• Try brainstorming as a requirements elicitation technique.
• Update the Vision document with the needs you identify.

Objectives
In this exercise, complete the following tasks:
¾ Gather a list of stakeholder needs using brainstorming techniques.
¾ Clarify and organize the ideas.
¾ Condense ideas.
¾ Prioritize remaining ideas.

© Copyright IBM Corp. 2003 33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
As project lead, you need to identify the needs of the stakeholders for your new
system. You have called your stakeholders together for a brainstorming session.
Remember: The needs you identify must help solve the business problem. If they do
not, why have them?
To do this exercise, put yourself in the shoes of the stakeholders you identified in
Exercise 4.2. Consider what they need from the system.
All stakeholders have all been trained on the rules of brainstorming:
• Clearly state the objective of the session.
• Generate as many ideas as possible.
• Criticism and debate are not allowed.
• Change and combine ideas.

Directions
1. Prepare.
• Stack of sticky notes for each participant.
• Large markers for all.
2. Gather ideas.
• Shout it out.
• Write it down (include the stakeholder name.)
• Facilitator posts each idea on the board.
3. Clarify and organize ideas.
• Describe each idea.
• Move the notes around.
• Organize by FURPS or by the stakeholder name.
4. Prune ideas.
• Discard redundant or outrageous ideas.
• Store “needs more development” ideas.
• Combine like or similar ideas.
5. Prioritize remaining ideas.
• Vote or apply evaluation criteria.

34 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾
Exercise 6.1
Identify the System Features
In this exercise, refine the Vision document. The content that has been covered in
previous modules is formalized in key portions of the Vision document.

Objectives
In this exercise, complete the following tasks:
¾ Brainstorm the system features based on the stakeholder requests elicited in
Exercise 5.1.
¾ Trace the features to stakeholder requests.
¾ Refine the Vision.
¾ Write a product position statement.
¾ List the features for the class project.

© Copyright IBM Corp. 2003 35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
As project lead, you are responsible for the Vision document for your project. Your
team has been working to describe the problem and how to address it, identify
stakeholders and users, elicit stakeholder/user needs, identify key product features,
and recognize constraints. Now, formalize this information in your Vision document.

Directions
Work in a small group.
1. Review exercise results.
• Problem statement (Module 4).
• Stakeholders and actors (Module 4).
• Fishbone diagram (Module 4).
• Key stakeholder and user needs (Module 5).
• Constraints (Module 4).
2. Brainstorm some product features.
• Look at the list of stakeholder requests.
• For each stakeholder request, identify some features that you would
include in the system that would satisfy these stakeholder requests.
• Give each feature a requirement tag (For example, FEAT1, FEAT2).
• For each feature, identify which stakeholder request it satisfies. (This is
your traceability matrix.)
3. Write a Product Position Statement.
4. Refine your Vision. (optional)
• Brief summary.
• Problem statement.
• Product position statement.
• Stakeholders and users.
• Stakeholder and user needs.
• Capture the features in Section 5 of the Vision document.
• Constraints.
As a whole class:
1. Compare your product position statements.

36 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Identify the System Features

Things To Consider
• Are there any stakeholder requests that do not trace to one or more features?
What should you do in this situation?
• How does the Product Position Statement differ from the Problem Statement?
Why is it useful to have both of them in your Vision document?
• How does viewing the results of putting together a Vision document influence
your perception of your project?

© Copyright IBM Corp. 2003 37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

1. Product Position Statement (Section 2.3 of the Vision)

Complete Section 2.3: Product Position Statement in your Vision document.
The product position statement is a tool for communicating the intent of the
application and the importance of the project to all concerned personnel.
Complete the product position statement table for your class project. Refer to the
Vision document for further instructions.
Below is an example to help you get started.

Product Position Statement

For Rational Software's existing and prospective customers
Who need to get timely solutions to their technical problems while using our
products
The is a Technical Support External Web Site
TSXWEB
That brings the latest technologies to the Web and allows for 24X7 technical
support, from finding solutions to participating in case activity, in a self-
help Web environment, thus passing the control to the customer.
Unlike the traditional non-Web alternative,
our product will provide easy-to-use, accessible, online product support that is not
dependent on human support personnel.

38 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Identify the System Features

This Page Is Intentionally Left Blank

© Copyright IBM Corp. 2003 39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Sample Solution: List of Features for the Project

Features
FEAT1: The system uses the Financial Services Network to enable transfer of funds between other financial
institutions and the customers Trading Account.
FEAT2: The system provides automatic reporting of tax-related information to the IRS and state tax boards.
FEAT3: The system supports the most common browsers: Microsoft Internet Explorer, (version 4 and higher) and
Netscape Navigator, (versions 4.72 through 4.75 and 6.2).
FEAT4: The system allows funds to be transferred to and from Mutual Fund accounts.
FEAT5: The system allows a customer to operate multiple Trading Accounts with a single login.
FEAT6: The system can be upgraded without taking services off-line.
FEAT7: During upgrades the system will preserve all "in-progress" transactions to ensure an error free experience
for the customer.
FEAT8: The system uses the Market Trading System to allow trading in any market worldwide.
FEAT9: The system provides an FAQ page to answer customer's most frequent questions quickly and simply.
FEAT10: The system provides an "I need help now" capability that will open a "chat window" with the next available
customer support representative. If there is no support personal available the system will inform the customer where
they are in the queue for help.
FEAT11: All Web pages shall be encrypted using 128 Bit SSL Security.
FEAT12: All personal and financial information shall be stored on a separate system with a secure network
connection between the systems.
FEAT13: The system provides comprehensive "how-to" documentation that is structured like a story of using the
system for a particular purpose. For example, "How to perform a Limit Buy."
FEAT14: The system runs on a corporate standard platform.
FEAT15: The system provides electronic and printed statements of account activity, including profit and loss
information, for yearly income tax reporting.
FEAT16: The system provides statements of Trading Account activity including transfers between Trading Accounts,
Trade summaries including: ticket code, number of shares traded and trade price.
FEAT17: Transfer cash from one customer trading account to another.
FEAT18: The system executes transactions in an Internet comfortable speed (less than 3 seconds, not counting
transmission times on a 56K modem).
FEAT19: Charge to a credit card and place funds in a customer's trading account.
FEAT20: Rollover from a retirement account in another institution in to a retirement account managed by the
system.
FEAT21: The system allows Market Buy and Sell transaction types.
FEAT22: The system allows Limit Buy and Sell transaction types.
FEAT23: The system allows mutual fund management.
FEAT24: The system allows stock research and alerts - online quotes, news flashes, and so on.

40 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Identify the System Features

Sample Solution: STRQ > FEAT Traceability Matrix

© Copyright IBM Corp. 2003 41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Sample Solution: Product Position Statement

For RU Financial Services
Who Need to replace the current stock trading system because
is losing profitability, customers, and market share in the e-
stock trading market.
The RU e-st is a Web-based securities trading system
That has full stock trading functionality demanded by our
customers.
Unlike Continuing with the current client-server-based system that
is:
• Running on unsupported hardware.
• Is difficult and expensive to maintain.
• Lacks some of the features required by our customers.
• Is prone to error.
• Requires our customers to install client software on
their machines.
Our product makes the business profitable again by:
• Providing error free trading that provides all of the most
popular features requested by our customers.
• Allowing bug fixes and upgrades to be applied quickly
and cheaply due to its Web-based architecture.
• Reducing operating costs by using supported hardware
and use standard maintenance contracts.
• Reducing maintenance costs by using corporate
standard programming languages and architecture.

42 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾
Exercise 6.2
Identify the Use Cases
The purpose of this exercise is to apply what you have learned about identifying
actors and use cases to the class project.

Objectives
In this exercise, complete the following tasks:
¾ Identify the use cases for the system.
¾ Create a brief description of the selected use cases.
¾ Create a use-case diagram for the system.

© Copyright IBM Corp. 2003 43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
As the project lead, you want to understand the system from the user’s perspective;
what the users want to be able to do using the system. Review the information you
have gathered thus far. From the information gathered, develop a use-case model of
the requirements. In this part of the use-case modeling process, identify use cases,
write a brief description for each use case, and develop a use-case diagram. In
subsequent exercises, you will create a detailed description for the use cases.
As you look at the Initial Requests and other information about the system, note that
the requirements are far from complete. Document your assumptions and any other
information you want to ask your customer.

Directions
Work in small groups.
As you begin this exercise, use the information gathered earlier to help complete Step
1.
• Problem description (Exercise 4.1).
• Stakeholder requests (refer to page 46).
• Vision document (Exercise 6.1).
• Actors (Exercise 4.2).

1. Discuss the requirements, revise the actors, and identify use cases.
2. Write a brief description for one to two use cases. (Pick use cases that you
think are the most important.)
3. Draw the use-case diagram on easel paper or the board.
• Show actors, use cases, and communicates-associations.
4. Post the use-case diagram.

As a whole class:
1. Present each solution.
2. Compare the use-case diagrams and brief descriptions from the different
groups.
3. Compare with the sample solution if using the RU e-st project.
• See RUCS4: Use-Case Model Survey.
4. Cover the “Discussion Topics” at the end of this exercise.

44 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Identify the Use Cases

Review Initial System Requests for Online Stock Trading System

See page 46

Identify Use Cases

What are the goals of each actor?

• What will the actor use the system for? Will the actor create, store, change,
remove, or read data in the system? If so, why?
• Will the actor need to inform the system about external events or changes?
• Will the actor need to be informed about certain occurrences in the system?
Does the system supply the business with all of the correct behavior?

Draw the Use-Case Diagram

Draw a use-case diagram for the class project.

Discussion Topics
How does your solution compare with the sample solution? What is different? What
is the same?
Are the use cases too small? Should some use cases be combined?
Does the brief description provide a good overview of the use cases purpose? Is there
too much detail, not enough detail, or just enough detail?
Does the diagram cover all activities? Can you think of any activities not covered?
How do you know what is done in each use case?
Does your use-case model satisfy the goals of all stakeholders?
Did you identify any new actors?

© Copyright IBM Corp. 2003 45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

RU e-st System Specification

Note: The sample in this handout contains only pages 1 through 4 of

the specification.

Disclaimer: This is a fictitious system and does not claim to be a model for a good
Software Requirement Specification. It is used for exercise purposes only.

46 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Identify the Use Cases

INTRODUCTION
RU Financial Services is beginning an e-commerce project to develop software for a
Web-based stock and securities trading system. The new system has been tentatively
named the RU e-st system.

Purpose
The purpose of this SRS is to serve as a statement of understanding between the
Online Trading Business and Engineering Divisions of RU Financial Services. Any
desired departures from the specifications described herein must be negotiated by
the affected parties.
The audience for this SRS includes the engineers who are involved in the
development of the system, the marketers who are involved in its advertisement and
sale, and the testers who validate the system.

Scope
The overall objective of the RU e-st Stock Trading System is to provide our trading
customers with a convenient way to manage their stock portfolios. Managing a stock
portfolio includes such capabilities as buying and selling and researching stock in a
secure environment.

REQUIREMENTS
In this section, all of the functions that the RU e-st Stock Trading System Software is
to perform are specified. These specifications are first given from total system
perspective.
The RU e-st system shall provide all of the current functionality of the current stock
trading system, plus any additions specified in this document.

Trading Customer Requirements

The RU e-st system allows its users to trade securities online, using a Web interface
(an existing browser, such as Netscape or Internet Explorer). A trading customer can
log on to the Internet anywhere (hotel room, airport, and so on.) Users are able to
perform all the basic operations for securities trading: open accounts, trade stocks
and other securities, and transfer assets among RU e-st accounts. Users can also
obtain current and historical information about their accounts, such as the number of
shares held, the current price, and the account total value.
Customers are able to execute many types of trade orders: market trading (buy and
sell at current market prices), transfers from one mutual fund to another within one

© Copyright IBM Corp. 2003 47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

account, and limit trading (buy and sell at a specific price). The RU e-st system uses
the existing Market Trading System to perform the securities trades. RU e-st also
allows users to transfer cash in an account to or from financial institutions such as
banks or credit card vendors, using the existing Financial Network System. The usual
restrictions apply:
• For online market sales, the securities to sell must be in the customer’s account.
• For market purchases, cash for the purchase must be in the account by the
settlement date.
• Transfers and purchases from an account are allowed only if, at the time the
transaction occurs, they have enough cash to fund the transaction in the account.
Trading customers are also able to obtain information about what is happening in the
securities markets. A trading customer can obtain price quotes and news headlines by
entering the trading symbol (for example, IBM) for a particular security. The RU e-st
system obtains current and historical quotes from the existing Quote System service
and news items from the existing News System. RU e-st also has a feature to
broadcast news headlines periodically on the trading customer’s screen without being
asked.

Regulatory Requirements
The system must report yearly tax information to the IRS and state tax boards. Tax
forms must be communicated to the IRS and copies mailed to the customer. The
information is also available online for customer viewing.

System Administration Requirements

Updates to the information on the Web pages must be possible without making the
system unavailable.

Development Requirements
The system must be written in one of the company’s approved programming
languages. Refer to document Enterprise Architecture and Development Standards
document EA-12341 for details.

Hardware Requirements
The hardware platform must be one supported by the enterprise hardware
maintenance contract. Supported platforms are specified in the Enterprise
Architecture and Development Standards document EA-1234.

1
This document is not supplied with the course.

48 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾
Exercise 6.3
Outline the Use Cases
Write a step-by-step outline for the flow of events in each selected project use case.
The purpose of this exercise is to practice outlining use cases to help understand what
functions are contained in them.

Objectives
In this exercise, complete the following tasks:
¾ Create a step-by-step outline of the flow of events for the selected use cases.
¾ Create a list of scenarios for the use cases.

© Copyright IBM Corp. 2003 49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
Your job as system analyst for the new system is progressing nicely. The stakeholders
have accepted your use-case diagram.

1. Create a step-by-step outline of the flow of events for use cases from the use-
case diagram of your new system.
2. Create a scenario list for each use case.

Directions
Work in small groups.
1. Focus on the use cases selected for you to outline.
• Review your use-case diagram (developed in Exercise 6.2.)
2. Create a step-by-step outline for the selected use cases.
• First, outline the flow of events for the basic flow.
• Second, identify three alternative flows.
• Write the outline neatly on lined paper or a flip chart.
• If possible, make copies of the outline(s) for the entire class.
3. Enumerate the scenarios for the use case. (Every flow should appear in at
least one scenario.)
4. If time permits, outline another selected use case and enumerate the
scenarios.

As a whole class:
1. Present each solution.
2. Compare the solutions between the different groups and the sample at the
end of this exercise.
If using the RU e-st project, see RUCS5: Step-by-Step Outlines.
3. Cover the “Discussion Topics” at the end of this exercise.

50 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Outline the Use Cases

Write a Step-by-Step Outline

Use Case Name:
Brief Description:

Basic Flow
1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

Alternative Flows
A1

A2

A3

Scenarios
S1

S2

S3

© Copyright IBM Corp. 2003 51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Write a Step-by-Step Outline

Use Case Name:
Brief Description:

Basic Flow
1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

Alternative Flows
A1

A2

A3

Scenarios
S1

S2

S3

52 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Outline the Use Cases

Discussion Topics

Do all the steps in your use-case outline reflect interactions with the system? Are
there some steps that are done manually outside the system and do not belong in the
use case?
Does your use-case outline show the basic flow from the beginning until the goal is
achieved?
Does each flow appear in at least one scenario?
Now that you see the outline of the Get Quote use case, do you think it should be
combined with the Execute Trade use case?
• Are they so related that they really belong together? If so, what would the
combined use case be called? What would it look like?
• If you think they should not be combined, why might you want to have them
separate?

© Copyright IBM Corp. 2003 53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Sample Brief Description and Step-by-Step Outline

Get Quote Use Case

Brief Description
The Trading Customer can get current or historical information about the trading
price of securities.

Basic Flow
1. Customer logs on.

2. Customer selects “Get Quote” function.

3. Customer selects stock trading symbol..

4. Get desired quote from Quote System.

5. Display quote.

6. Customer logs off.

Alternative Flows
A1 Get additional quotes.
A2 Unidentified Trading Customer.
A3 Quote System unavailable.
A4 Quit.
A5 Unknown trading symbol.
…
Scenarios
Get a Quote: Flows: Basic Flow.
Trading Customer Gets Additional Quotes: Basic Flow, Get Additional Quotes.
Invalid Login: Flows: Basic Flow, Unidentified Trading Customer.
Trading Customer Enters Unknown Trading Symbol: Flows: Basic Flow, Unknown Trading Symbol.
Trading Customer Quits: Flows: Basic Flow, Quit.

54 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Prioritize Requirements Using Attributes

¾¾¾
Exercise 7.1
Prioritize Requirements Using Attributes
The purpose of this exercise is to explore how you might use attributes of feature
requirements to make a decision about the relative importance of each and to
determine what to cut when managing scope.

Each group should come up with a ranking that shows the order in which the tasks
should be considered for inclusion in the release of the product, using the following
input (attributes):
• The text of the requirement
• Priority (input from the customer)
• Difficulty (input from development)
• Risk (to the project)
• Stability (of the requirement)

Objectives
In this exercise, complete the following tasks:
¾ Review the feature matrix and attributes.
¾ Determine the relative importance of the attributes.
¾ Prioritize the list of features.
¾ Decide on baseline scope of features.

© Copyright IBM Corp. 2003 55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario

You are the Vice President of Engineering for the product. The Development
Manager (the instructor) has just told you that you only have the resources to
accomplish two-thirds of the work shown on the feature list.

You have to catch a cab to the airport in 20 minutes, so you have no time to go back
to talk with the customer. What requirements would you recommend for the baseline
scope?

Directions
Work together in a small group.
1. Review the features matrix worksheet on the next page.
2. Discuss the relative importance of the attributes.
3. Rank the features based on their attributes.
• The text of the requirement
• Priority (input from the customer)
• Difficulty (input from development)
• Risk (to the project)
• Stability (of the requirement)
4. List the feature numbers in the order of priority on chart paper or a
transparency.

As a whole class:
1. Compare the feature rankings from the different groups.
2. Discuss reasoning.
3. Cover the “Discussion Topics” at the end of this exercise.

56 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Prioritize Requirements Using Attributes

Using Attributes in Managing Scope

Requirements Customer Difficulty Risk Stability Rank
Priority
FEAT1: The system uses the Financial Services Network to enable transfer of funds between other financial Desired Medium Medium High
institutions and the customers Trading Account.
FEAT2: The system provides automatic reporting of tax-related information to the IRS and state tax boards. Mandatory Medium Medium High
FEAT3: The system supports the most common browsers: Microsoft Internet Explorer, (version 4 and higher) and Mandatory Low Low High
Netscape Navigator, (versions 4.72 through 4.75 and 6.2).
FEAT4: The system allows funds to be transferred to and from Mutual Fund accounts. Desired Medium Low High
FEAT5: The system allows a customer to operate multiple Trading Accounts with a single login. Desired Medium Low Medium
FEAT6: The system can be upgraded without taking services off-line. Desired High High Medium
FEAT7: During upgrades the system will preserve all "in-progress" transactions to ensure an error free experience for Mandatory High Medium High
the customer.
FEAT8: The system uses the Market Trading System to allow trading in any market worldwide. Mandatory Medium High Medium
FEAT9: The system provides an FAQ page to answer customer's most frequent questions quickly and simply. Desired Low Low Low
FEAT10: The system provides an "I need help now" capability that will open a "chat window" with the next available Optional High Medium Medium
customer support representative. If there is no support personal available the system will inform the customer where
they are in the queue for help.
FEAT11: All Web pages shall be encrypted using 128 Bit SSL Security. Mandatory Low Medium High
FEAT12: All personal and financial information shall be stored on a separate system with a secure network Mandatory High High Low
connection between the systems.
FEAT13: The system provides comprehensive "how-to" documentation that is structured like a story of using the Desired Low Low Medium
system for a particular purpose. For example, "How to perform a Limit Buy."
FEAT14: The system runs on a corporate standard platform. Mandatory Low Low High
FEAT15: The system provides electronic and printed statements of account activity, including profit and loss Mandatory Medium Low Medium
information, for yearly income tax reporting.
FEAT16: The system provides statements of Trading Account activity including transfers between Trading Accounts, Mandatory Medium Low Medium
Trade summaries including: ticket code, number of shares traded and trade price.
FEAT17: Transfer cash from one customer trading account to another. Optional Medium Low High
FEAT18: The system executes transactions in an Internet comfortable speed (less than 3 seconds, not counting Desired High High Medium
transmission times on a 56K modem).
FEAT19: Charge to a credit card and place funds in a customer's trading account. Desired Medium High High
FEAT20: Rollover from a retirement account in another institution in to a retirement account managed by the system. Desired High High Low
FEAT21: The system allows Market Buy and Sell transaction types. Mandatory High Medium High
FEAT22: The system allows Limit Buy and Sell transaction types. Mandatory Medium Medium High
FEAT23: The system allows mutual fund management. Desired Medium Medium High
FEAT24: The system allows stock research and alerts - online quotes, news flashes, and so on. Desired High Medium Low

© Copyright IBM Corp. 2003 57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Discussion Topics

What method did you use to get the results?

What are the advantages of using a formula?

What different assumptions or methods led to the different results?

What other information would you like to help make your decisions?

How do you set scope now in your own organization?

© Copyright IBM Corp. 2003 58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾
Exercise 7.2
Prioritize Scenarios
The purpose of this exercise is to identify which scenarios you want to detail in this
iteration. You should use your prioritized list of feature requirements to make a
decision.

As a whole class, consider the ranking of each feature and describe the scenario it
traces to.

Objectives
In this exercise, complete the following tasks:
¾ Review the prioritized list of features.
¾ Trace the features into each scenario and use that to list the scenarios that you
detail in the next module.

© Copyright IBM Corp. 2003 59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
Based on the prioritized list of features from the previous exercise, list the scenarios
that should be detailed and implemented in this iteration.
For the purposes of this exercise, imagine you are in the first iteration of the
Construction Phase of the Rational Unified Process®. This means that all architectural
risks have been mitigated and that you are now focusing on removing the risks related
to not delivering system functionality that is important to the customer, as well as
getting the bulk of the work done.

Directions
Work together as a class.
1. Review the prioritized feature requirements form the previous exercise.
2. Use the use-case outlines provided at the end of this exercise (page 61) to
trace the features to flows.
3. For each flow that is traced to, identify a scenario that the flow is part of.
When identifying the scenario, consider the Analyst’s criteria for selecting
scenarios.
4. List the scenarios to detail in the next exercise.

Discussion Topics
Were there any features that you could not trace to a flow? If so, what should you do
about that?
Were there any flows that were not traced from a feature? If so, what does this mean?
Were there any use cases that had no flows traced from a feature? So, what does this
mean?

60 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Prioritize Scenarios

Get Quote Use Case

Brief Description
Trading Customers get current and historical information about the trading
price of securities.

Flow of Events

Basic Flow
1. Customer logs on.
2. Customer selects “Get Quote” function.
3. Customer selects stock trading symbol .
4. Get desired quote from Quote System.
5. Display quote.
6. Customer logs off.

Alternative Flows
A1 Customer Gets Other Quotes
A2 Unidentified Trading Customer
A3 Quote System Unavailable
A4 Quit
A5 Unknown Trading Symbol

Scenarios
Customer Gets a Quote: Basic Flow
Customer Gets Additional Quotes: Basic Flow, Customer Gets Other
Quotes
Invalid login: Basic Flow, Unidentified Trading Customer
Quote System Unavailable: Basic Flow, Quote System Unavailable
Unknown Trading Symbol: Basic Flow, Unknown Trading Symbol
Quit Before Completion: Basic Flow, Quit

© Copyright IBM Corp. 2003 61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Execute Trade Use Case

Brief Description
Trading Customers buy, sell or transfer securities in their accounts. The
possible trade order types are: Limit Buy Order, Limit Sell Order, Market
Buy Order, Market Sell Order, Transfer Order. Immediately after a trade is
completed, Trading Customers receive a market trading confirmation
containing a transaction id and the results of the trade.

Flow of Events

Basic Flow
1. Customer logs on.
2. Customer selects “Trade” function.
3. Customer selects account.
4. Customer performs trade.
4.1 Select trade order type (market, limit, transfer) and enter trading info.
4.2 Initiate trade with Market Trading System.
4.3 Get trade results from Market Trading System.
5. Customer logs off.

Alternative Flows
A1 Unidentified Trading Customer
A2 Unauthorized Trader
A3 Quit
A4 Trade Is Rejected
A5 Market Trading System Unavailable
A6 Insufficient Funds
A7 No Trading Account
A8 Account Not Operational
A9 Customer Executes More Trades

62 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Prioritize Scenarios

Scenarios
Trading Customer Executes More Trades: Basic Flow, Customer Executes
More Trades.
Invalid login: Basic Flow, Unidentified Trading Customer
Trading Customer is Not Authorized To Execute Trades: Basic Flow,
Unauthorized Trader
Quit before execute: Basic Flow, Quit
Trade is Rejected: Basic Flow, Trade Is Rejected
Market Trading System Unavailable: Basic Flow, Market Trading System
Unavailable
Insufficient Funds in Trading Account: Basic Flow, Verify That Cash Is
Available
Trading Customer Has No Trading Account: Basic Flow, No Trading
Account
Trading Account Not operational: Basic Flow, Account Not Operational

© Copyright IBM Corp. 2003 63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

64 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾

Exercise 8.1


Choose a Style
Look at the styles of writing a flow of events and compare them. Each style has
different benefits.
The way to describe the flow of events depends on factors, such as:
• Who is the reader?
This may differ from project to project. Sometimes you may have a "customer" of
the system, or at other times you need to try to understand what the market
wants without having a “customer.” Depending on who will be reading the flow
of events, there are many different ways to write it. If the readers are unfamiliar
with the system and the Rational Unified Process, you should describe it in one
way. On the other hand, if the systems are well known to all readers, you may
choose to describe it in another way. Regardless of the way you choose to
describe it, be consistent for all use cases in your project.
• Who is the author?
It is not easy to make everyone in a project team write the flow of events in the
same way. The style depends on many factors, including the skills and
background of the authors. For example, if some people have problems
expressing themselves, it may be easier to make a more formal template for the
flow of events. Your use-case modeling guidelines can help ensure that there is a
consistent style.

Objectives
In this exercise, complete the following tasks:
¾ Review different flow of events descriptions.
¾ Compare and contrast the different styles.
¾ Recommend a style for your project team.

© Copyright IBM Corp. 2003 65

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
After you have finished detailing your flow of events, your co-worker Bob mentions
that he has seen use cases written in other styles. He thinks that the team should
decide what style they want to use for their use cases. He proposes some sample
styles to choose from.

Directions
Working by yourself:
Review each of the following samples of a flow of events that are written in
different styles. As you read each style, consider the following:
Consider the following questions when comparing the use cases:
• Is it easy to read and understand?
• Do you think it would be easy to create (write) with a word processor?
• Do you think it would be easy to maintain if you were inserting and
reorganizing the flows?
• In what ways is it better than the others?
• In what ways is it worse than the others?
• Which style do you prefer?
As a whole class:
• Compare the styles of flow of events, using the questions above.
• Recommend a style for your project team.

66 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Style I–Table
1. Use Case Name: Get Quote
1.1 Brief Description
The Trading Customer can get current and historical information about the trading price of securities.

2. Flow of Events
2.1 Basic Flow
Step Trading Customer System Quote System
1 The use case starts when the
Trading Customer logs on.
2 The system validates the customer id
and password. The system presents a
list of available functions.
3 The Trading Customer chooses to
“Get Quote.”
4 The system displays the list of
trading symbols and names of
securities on which it has quotes.
5 The Trading Customer selects
from the list of securities or
enters the trading symbol for a
security.
6 The system sends the trading symbol
to the Quote System
7 The Quote System returns the
most recent quote for the
requested trading symbol.
8 The system presents the
corresponding Quote Display (see the
fields to display in Supplementary
Specifications) to the Trading
Customer.
9 The Trading Customer logs off
the system. The use case ends.

2.2 Alternative Flows

2.2.1 Get Additional Quotes
Step Trading Customer System Quote System
1 At the end of step 8 of the Basic
Flow, if the Trading Customer
wishes to get additional quotes, the
use case resumes at Step 5 in the
Basic Flow.

© Copyright IBM Corp. 2003 67

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
MRMUC Student Workbook

2.2.2 Unidentified Trading Customer

Step Trading Customer System Quote System
1 In Step 1 in the Basic Flow, if the
system determines that the customer
id or password are not valid, an error
message is displayed. The use case
ends.

2.2.3 Quote System Unavailable

Step Trading Customer System Quote System
1 In Step 3 in the Basic Flow, if the
system is unable to communicate
with the Quote System, the system
informs the Trading Customer. The
use case ends.

2.2.4 Quit
The RU e-st System allows the Trading Customer to quit at any time during the use case. The use case ends.
Step Trading Customer System Quote System
1 The RU e-st System allows the
Trading Customer to quit at any
time during the use case. The use
case ends.

2.2.5 Unknown Trading Symbol

Step Trading Customer System Quote System
1 In Step 6 in the Basic Flow, if the
system cannot recognize the trading
symbol, the system notifies the
Trading Customer that the trading
symbol is not recognizable.
The use case continues at the
beginning of Step 5 in the Basic
Flow.

2.2.6 Quote System Cannot Locate Information

Step Trading Customer System Quote System
1 In Step 8 in the Basic Flow, if the
Quote System responds that it does
not have the requested information,
the system notifies the Trading
Customer that the Quote System does
not have information on the
requested security.
The use case continues at the
beginning of Step 5 in the Basic
Flow.

68 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Style II-Bulleted
1. Use Case Name: Get Quote
1.1 Brief Description
The Trading Customer can get current and historical information about the trading price of securities.

2. Flow of Events
2.1 Basic Flow
• Customer Logs On.
o The use case starts when the Trading Customer logs on. The system validates the customer id and
password. The system presents a list of available functions.
• Customer Selects “Get Quote” Function.
o The Trading Customer chooses to “Get Quote.” The system displays the list of trading symbols
and names of securities on which it has quotes.
• Customer Gets Quote.
o The Trading Customer selects from the list of securities or enters the trading symbol for a security.
The system sends the trading symbol to the Quote System and receives the Quote System
Response. The system presents the corresponding Quote Display (see fields to display in
Supplementary Specifications) to the Trading Customer.
• Customer Logs Off.
o The Trading Customer logs off the system. The use case ends.
2.2 Alternative Flows

2.2.1 Get Additional Quotes

At the end of Customer Gets Quote in the Basic Flow, if the Trading Customer wishes to get additional
quotes, the use case resumes at Customer Gets Quote in the Basic Flow.

2.2.2 Unidentified Trading Customer

In Customer Logs On in the Basic Flow, if the system determines that the customer id or password are not
valid, an error message is displayed. The use case ends.

2.2.3 Quote System Unavailable

In Customer Gets Quote in the Basic Flow, if the system is unable to communicate with the Quote System,
the system informs the Trading Customer. The use case ends.

2.2.4 Quit
The RU e-st System allows the Trading Customer to quit at any time during the use case. The use case
ends.

2.2.5 Unknown Trading Symbol

In Customer Gets Quote in the Basic Flow, if the system cannot recognize the trading symbol, the system
notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at the
beginning of Customer Gets Quote in the Basic Flow.

© Copyright IBM Corp. 2003 69

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
MRMUC Student Workbook

2.2.6 Quote System Cannot Locate Information

In Customer Gets Quote, in the Basic Flow, if the Quote System responds that it does not have the
requested information, the system notifies the Trading Customer that the Quote System does not have
information on the requested security. The use case continues at the beginning of Customer Gets Quote in
the Basic Flow.

70 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Style III-RUP
1. Use Case Name: Get Quote
1.1 Brief Description
The Trading Customer can get current and historical information about the trading price of securities.

2. Flow of Events
2.1 Basic Flow
1. Customer Logs On.
The use case starts when the Trading Customer logs on. The system validates the customer id and
password. The system presents a list of available functions.

2. Customer Selects “Get Quote” Function.

The Trading Customer chooses to “Get Quote. “ The system displays the list of trading symbols
and names of securities on which it has quotes.

3. Customer Gets Quote.

The Trading Customer selects from the list of securities or enters the trading symbol for a security.
The system sends the trading symbol to the Quote System and receives the Quote System
Response. The system presents the corresponding Quote Display (see fields to display in
Supplementary Specifications) to the Trading Customer.

5. Customer Logs Off .

The Trading Customer logs off the system. The use case ends.
2.2 Alternative Flows

2.2.1 Get Additional Quotes

At the end of step 3, Customer Gets Quote, if the Trading Customer wishes to get additional quotes, the use
case resumes at step 3 in the Basic Flow.

2.2.2 Unidentified Trading Customer

In Step 1, Customer Logs On, in the Basic Flow, if the system determines that the customer id or password
are not valid, an error message is displayed. The use case ends.

2.2.3 Quote System Unavailable

In Step 3, Customer Gets Quote, in the Basic Flow, if the system is unable to communicate with the Quote
System, the system informs the Trading Customer. The use case ends.

2.2.4 Quit
The RU e-st System allows the Trading Customer to quit at any time during the use case. The use case
ends.

2.2.5 Unknown Trading Symbol

In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the
system notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at
the beginning of Step 3 in the Basic Flow.

© Copyright IBM Corp. 2003 71

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
MRMUC Student Workbook

2.2.6 Quote System Cannot Locate Information

In Step 3, Customer Gets Quote, in the Basic Flow, if the Quote System responds that it does not have the
requested information, the system notifies the Trading Customer that the Quote System does not have
information on the requested security. The use case continues at the beginning of Step 3 in the Basic Flow.

72 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Style IV-Tag
1. Use Case Name: Get Quote
1.1 Brief Description
The Trading Customer can get current and historical information about the trading price of securities.

2. Flow of Events
2.1 Basic Flow
{Trading Customer logs on}
1. The use case starts when the Trading Customer logs on.
2. The system validates the customer id and password. The system presents a list of available functions.
3. The Trading Customer chooses to “Get Quote.”
4. The system displays the list of trading symbols and names of securities on which it has quotes.
{Customer Gets Quote}
5. The Trading Customer selects from the list of securities or enters the trading symbol for a security.
{Request Quote from Quote System}
6. The system sends the trading symbol to the Quote System and receives the Quote System Response.
7. The system presents the corresponding Quote Display (see fields to display in Supplementary
Specifications) to the Trading Customer.
{Log Off}
8. The Trading Customer logs off the system. The use case ends.

2.2 Alternative Flows

2.2.1 Get Additional Quotes

In {Log Off}, if the Trading Customer wishes to get additional quotes, the use case resumes at {Customer
Gets Quote}.

2.2.2 Unidentified Trading Customer

In {Trading Customer logs on} if the system determines that the customer id or password are not valid, an
error message is displayed. The use case ends.

2.2.3 Quote System Unavailable

In {Request Quote from Quote System} if the system is unable to communicate with the Quote System,
the system informs the Trading Customer. The use case ends.

2.2.4 Quit
The RU e-st System allows the Trading Customer to quit at any time during the use case. The use case
ends.

2.2.5 Unknown Trading Symbol

In {Customer Gets Quote} if the system cannot recognize the trading symbol, the system notifies the
Trading Customer that the trading symbol is not recognizable. The use case continues at {Customer Gets
Quote}.

© Copyright IBM Corp. 2003 73

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
MRMUC Student Workbook

2.2.6 Quote System Cannot Locate Information

In {Request Quote from Quote System} if the Quote System responds that it does not have the requested
information, the system notifies the Trading Customer that the Quote System does not have information on
the requested security. The use case continues at {Customer Gets Quote}.

74 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Style V–Pseudo Code

1. Use Case Name: Get Quote
1.1 Brief Description
The Trading Customer can get current and historical information about the trading price of securities.
2. Flow of Events
2.1 Basic Flow
<= 'Show log in menu’
=> ‘Log in’ (User name, Password)
IF the user name or password are incorrect
<= ‘Show log in info incorrect message’
The use case ends
END IF

=> ‘Get Quote’

DO
<= ‘Show list of tickers (trading symbols) and names of securities’
=> ‘Select or enter ticker’
IF the Trading Customer chooses to quit
The use case ends
ENDIF
The system sends the quote request to the Quote System.
IF the Quote System responds
IF the Quote System found the Ticker
<= ‘Show the Quote Details’
ELSE IF the Quote System responds that it does not recognize the Ticker
<= ‘Show Unknown Ticker message’
ELSE IF the Quote System responds that it does not have the information
<= ‘Show Information Currently Unavailable message’
ENDIF
ELSE
<= ‘Show Quote System Unavailable message’
The use case ends
ENDIF
WHILE => 'Get Additional Quotes'
The use case ends.

© Copyright IBM Corp. 2003 75

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
MRMUC Student Workbook

76 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Detail the Flows

¾¾¾
Exercise 8.2
Detail the Flows
The purpose of this exercise is to apply what you have learned about detailing use
cases. In this exercise, you further detail the use cases outlined in Exercise 6.3 and
prioritized in Exercise 7.2.
Use the Get Quote Use Case Report below as an example of a fully detailed use case.
Unlike your use cases for this exercise, every flow in this use case has been detailed.
Notice the level of detail in this example. Remember, you need to describe every
detail that the customer wants the developers to know.

Objectives
In this exercise, complete the following tasks:
¾ Identify the scenarios to be detailed in this iteration (from module 7).
¾ Identify the flows for each scenario to be detailed.
¾ Add detail to the step-by-step outline of the basic flow of events.
¾ Describe clearly what happens in each alternative flow.
¾ Revise the use-case scenario list
¾ Identify preconditions.
¾ Identify postconditions.

© Copyright IBM Corp. 2003 77

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Scenario
Your requirements for the new system are becoming clear. The stakeholders have
accepted your use-case outlines.
Now fill out the step-by-step outline with more detail to the basic and the alternative
flows. As the flows are detailed it is likely that additional alternative flows are
identified. As additional flows are identified the scenario list should be updated to
include them.
As part of detailing use cases you also write a preconditions and postconditions.

Directions
Work together in a small group:
1. Focus on the scenarios you selected to detail in module 7.
• Review your use case outline (developed in Exercise 6.3).
2. Detail the flow of events. (Use the sample on page 79 as a style guide.)
• Give each step in the Basic Flow a title.
• Write one to three sentences that detail each step.
• Write the details of each Alternative Flow.
3. Revise the scenario list.
4. Add a precondition.
5. Add a postcondition.
6. Write the group’s use case report neatly on lined paper.
• If possible, make copies of the use case report(s) for the entire class.
7. If time permits, detail another selected use case.

As a whole class:
1. Present each solution.
2. Compare the solutions from the different groups.
3. Compare the solutions with the sample solution if using the RU e-st project.
• See RUCS6: Use Case Reports.
4. Discuss the “Discussion Topics” at the end of this exercise.

78 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Detail the Flows

Sample Use Case Report

Get Quote Use Case

1. Use Case Name: Get Quote
1.1. Brief Description
The Trading Customer can get current or historical information about the trading
price of securities.
2. Flow of Events
2.1. Basic Flow
1. Log On
The use case starts when the Trading Customer logs on. The system validates the
customer id and password. The system presents a list of available functions.
2. Customer Selects “Get Quote” Function
The Trading Customer chooses to “Get Quote”. The system displays the list of
securities on which it has quotes.
3. Customer Gets Quote
The Trading Customer selects from the list of securities or enters the trading
symbol for a security.
The system sends the trading symbol to the Quote System, and receives the Quote
System Response.
The system presents the corresponding Quote Display (see fields to display in
Supplementary Specifications) to the Trading Customer.
4. End Use Case
The Trading Customer logs off the system. The use case ends.

© Copyright IBM Corp. 2003 79

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

2.2. Alternative Flows

2.2.1. Unidentified Trading Customer
In Step 1, Customer Logs On, in the Basic Flow, if the system determines that
the customer id and/or password are not valid, an error message is displayed.
The use case ends.
2.2.2. Customer Gets Other Quotes
If at the end of Step 3, Customer Gets Quote in the Basic Flow, the customer
wants to get additional quotes, the use case continues at the beginning of step
3.
2.2.3. Quote System Unavailable
In Step 3, Customer Gets Quote, in the Basic Flow, if the system is unable to
communicate with the Quote System, the system informs the Trading
Customer. The use case ends.
2.2.4. Suspect Theft
In Step 1 of the basic flow, if the customer id is on the system’s list of stolen
identification, the system displays an Invalid Login Message.
The system records the date, time, and computer address from which the
person tried to log on, and sends a message to the System Administrator.
The use case ends.
2.2.5. Quit
The RU e-st System allows the Trading Customer to quit at any time during the
use case. The use case ends.
2.2.6. Unknown Trading Symbol
In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot
recognize the trading symbol, the system notifies the Trading Customer that the
trading symbol is not recognizable. The use case continues at the beginning of
Step 3 in the Basic Flow.
2.2.7. Quote System Cannot Locate Information
In Step 3, Customer Gets Quote, in the Basic Flow, if the Quote System
responds that it does not have the requested information, the system notifies the
Trading Customer that the Quote System does not have information on the
requested security. The use case continues at the beginning of Step 3 in the
Basic Flow.

80 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Detail the Flows

3. Special Requirements

3.1. Timely Quote Display

The RU e-st system must present the requested Quote Display within 2
seconds after a Trading Customer finishes requesting it.
4. Preconditions
4.1. RU e-st Has Connection to Quote System
The RU e-st system must have a connection to the Quote System in order to
begin this use case.
5. Postconditions
None.
6. Extension Points
None specified for this use case.
7. Relationships
The Actor starting this Use Case is:
Trading Customer
Actor(s) also involved in this Use Case:
Quote System
8. Use-Case Diagrams
None specified for this use case.
9. Other Diagrams
None specified for this use case.
10. Scenario List
Customer gets a quote: Basic Flow
Customer gets additional quotes: Basic Flow, Customer Gets
Other Quotes
Quit before getting quote: Basic Flow, Quit
Fail due to an invalid login: Basic Flow, Unidentified Trading
Customer
Fail due to stolen id: Basic Flow, Suspect Theft
Fail due to quote system is unavailable: Basic Flow, Quote
System Unavailable
Unknown trading symbol: Basic Flow, Unknown Trading
Symbol
Fail due to quote system is unable to locate information:

© Copyright IBM Corp. 2003 81

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 MRMUC Student Workbook

Basic Flow, Quote System Cannot Locate Information

Discussion Topics
Did you need to reorganize some of the steps in your original outline? Why?
Is it clear how your use case starts? Is it clear how your use case ends?
Are actor interactions and exchanged information clear?
Did you identify any new flows? If so, what was the impact on your scenario list?

82 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 ¾¾¾
Exercise 8.3
Identify Nonfunctional Requirements
Use the class project to identify nonfunctional requirements for your system.
The purpose of this exercise is to practice defining nonfunctional requirements and to
help you determine where nonfunctional specifications should be specified. They can
either be stated in the properties of a particular use case or in the Supplementary
Specifications.

Objectives
In this exercise, you do the following tasks:
¾ Identify nonfunctional requirements.
¾ Determine where nonfunctional requirements should be specified.

© Copyright IBM Corp. 2003 83

Course materials may not be reproduced in whole or in part without the prior written permission of IBM
 MRMUC Student Workbook

Scenario
As project lead, you are responsible for identifying the declarative requirements that
are not readily captured in the use cases of the use-case model. If a nonfunctional
requirement applies to a particular use case, then it is usually specified in the “Special
Requirements” property of the use-case report for the particular use case to which it
applies. Supplementary Specifications contain the declarative requirements that are
not about a particular use case.

Directions
Work in small groups.
1. Review the requirements developed in your project, especially the
stakeholder requests and features.
2. Write at least five nonfunctional software requirements for your project.
• Use language the users can easily understand.
• Make the requirements specific and verifiable.
• Determine the category of each requirement (useability, reliability, and
so on).
3. Determine where to specify the requirements. After each requirement on
your list, tell where you would specify it.
• Does the requirement apply to a specific use case?
- Specify in the use case report under Special Requirements.
• Does the requirement apply to the whole system?
- Specify in the Supplementary Specifications.
4. Write on lined paper. If possible, make copies for the entire class.
As a whole class:
1. Discuss the nonfunctional requirements from the different groups.
2. Compare with the sample solution if using the RU e-st project.
• See RUCS8: Supplementary Specifications.
• See RUCS6: Use Case Reports.
3. Discuss the “Discussion Topics” at the end of this exercise.
Discussion Topics
What types of nonfunctional requirements might be attached to a use case?
To the use-case model, is that the whole system?
How are features related to nonfunctional software requirements?
How are stakeholder requests related to nonfunctional requirements?
What types of nonfunctional requirements are you most likely to encounter
in your own projects?

84 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM
► ► ► Contents

CRA: Course Registration Artifacts

CRA1: Initial Requests .......................................................................1

CRA2: Use-Case Model Survey .........................................................3
CRA3: Use-Case Outlines ..................................................................7
CRA4: Use-Case Reports .................................................................11
Course Registration Version: CRA1
Initial Requests Date: Nov. 15, 2002
Course Registration Artifact 1

Initial System Requests

Wylie College is planning to develop a new online Course Registration System. The new Web-enabled system
replaces its much older system developed around mainframe technology. The new system allows students to register
for courses from any Internet browser. Professors use the system to register to teach courses and to record grades.

Because of a decrease in federal funding, the college cannot afford to replace the entire system at once. The college
will keep the existing course catalog database, where all course information is maintained. This database is an Ingres
relational database running on a DEC VAX. The legacy system performance is poor, so the new system accesses
course information from the legacy database but does not update it. The registrar’s office continues to maintain
course information through another system.

Students can request a printed course catalog containing a list of course offerings for the semester. Students can also
obtain the course information online at any time. Information about each course, such as professor, department,
credit hours, and prerequisites, assists students in making informed decisions.

The new system allows students to select four course offerings for the coming semester. In addition, each student
indicates two alternate choices in case the student cannot be assigned to a primary selection. Course offerings have a
maximum of ten and a minimum of three students.

The registration process closes on the first or second day of classes for the semester. Any course having fewer than
three students enrolled on the day registration closes is cancelled. All courses without an instructor on the day
registration closes are cancelled. Students enrolled in cancelled classes are notified that the course has been
cancelled, and the course is removed from their schedules. The registration system sends information about all
student enrollments to the Billing System so that the students can be billed for the semester.

For the first two weeks of the semester, students are allowed to alter their course schedules. Students may access the
online system during this time to add or drop courses. Changes in schedules are immediately sent to the Billing
System so that an updated bill can be sent to the student.

At the end of the semester, the student can access the system to view an electronic report card. Since student grades
are sensitive information, the system must employ security measures to prevent unauthorized access. All students,
professors, and administrators have their own identification codes and passwords.

Professors must be able to access the online system to indicate which courses they want to teach. They also need to
see which students signed up for their course offerings. In addition, professors can record the grades for the students
in each class.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA1
Initial Requests Date: Nov. 15, 2002
Course Registration Artifact 1

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA2
Use-Case Model Survey Date: Nov. 15, 2002
Course Registration Artifact 2

Use-Case Model Survey

for a Course Registration System

Introduction
This set of suggested solutions on the online course registration problem is derived from knowledge as
college students and general system knowledge. The point of this set of solutions is to show what a
solution may look like and to what level of detail you describe the use cases.

Be aware that this is not a real system.

The point here is not the technical content, but what the descriptions may look like.

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA2
Use-Case Model Survey Date: Nov. 15, 2002
Course Registration Artifact 2

1. Introduction
This is an example of what a solution to the use-case exercises in the MRMUC course may look like. It contains
more information than a normal group might create. It is closer to an example of a use-case model for a regular
project. Keep in mind that this example shows the use-case model in the beginning of a project.

2. Survey Description
The Course Registration System is a Web-enabled system connected to the university computer systems. The
purpose of the system is to allow students to register for courses from any Internet browser. It is also important to
enable professors to register to teach courses and to record grades through this system. An online registration is less
expensive for the college than a campus registration.

3. Actors

3.1 Diagram

Student Registrar

Course Catalog
System

Billing System Professor

Figure 1. Actor Diagram

3.2 Student
A student is a person with a valid student ID who is registered at the college. The student IDs are unique, and they
know the password.

3.3 Registrar
A registrar is a person with a unique ID and password who has authorization to close registration.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA2
Use-Case Model Survey Date: Nov. 15, 2002
Course Registration Artifact 2

3.4 Professor
A professor is a person with a unique ID and password who has authorization to select courses to teach, access class
lists, and submit grades. This person can also interact with the close registration process.

3.5 Course Catalog System

This system maintains a list of course offerings for each semester. In addition, this is where information about each
course, such as professor, department, credit hours, and prerequisites is stored. This system manages production and
printed course catalogs.

3.6 Billing System

From the Course Registration system point of view, the Billing System’s only responsibility is to receive
notification that registration has closed or has been altered.

4 Use Cases

4.1 Primary Cases

4.1.1 Course Registration System Use-Case Diagram

Figure 2. Course Registration System Use-Case Diagram

4.1.2 Register for Courses

The student registers for a course online through an Internet browser, using a valid student ID and password.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA2
Use-Case Model Survey Date: Nov. 15, 2002
Course Registration Artifact 2

4.1.3 Alter Course Selection

The student can add or drop a course online through an Internet browser, using a valid student ID and password,
during the first two weeks of the semester.

4.1.4 Close Registration

The Registrar closes the registration process on the first or second day of classes for the semester. Any course
having fewer than three students enrolled on the day registration closes is canceled. All courses without an instructor
on the day registration closes is canceled. Students enrolled in canceled classes are notified that the course has been
canceled, and the course is removed from their schedules. Professors scheduled to teach canceled courses are also be
notified that the course is canceled. The system sends all information about student enrollments to the Billing
System.

4.1.5 Request Course Catalog

Students can request a printed course catalog containing a list of course offerings for the semester. Students can also
obtain the course information online at any time.

4.1.6 View Grades

Students, professors, and administrators can view grades online through an Internet browser, using a valid ID and
password.

4.1.7 Select Courses to Teach

Professors indicate which courses they want to teach online through an Internet browser, using a valid ID and
password.

4.1.8 Submit Grades

Professors submit grades for each student in their course(s) online through an Internet browser, using a valid ID and
password.

4.1.9 Get Class List

Professors view students enrolled in their courses online through an Internet browser, using a valid ID and password.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA3
Use Case Outlines Date: Nov. 15, 2002
Course Registration Artifact 3

Course Registration Artifact 3

Step-by-Step Outlines

Introduction

This is an example of what a step-by-step outline and a list of alternative flows can look like.
These step-by-step outlines are the first draft of the flow of events in each use case.
This kind of information is usually not in a nice fancy document; the normal format is handwritten.
Later they are used to begin the use-case reports.

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA3
Use Case Outlines Date: Nov. 15, 2002
Course Registration Artifact 3

Register for Courses

Brief Description
This use case allows a student to register for courses in the current semester. The
student can search the list of course offerings for the current semester and obtain course
information prior to making course selections.

Step-by-Step Outline
Basic Flow
1. Log on.
2. Select ‘Create a Schedule’.
3. Obtain course information.
4. Select courses.
5. Submit schedule.
6. Display completed schedule.
Alternative Flows
A1. Unidentified student.
A2. Quit.
A3. Cannot enroll.
A4. Course Catalog System unavailable.
Can we allow students to register if the Course Catalog is unavailable?
A5. Course registration closed.

Should we allow students to pay with credit cards online, or is that outside the scope of
our system? If we allow them to pay, how and what do we tell the billing system?
…

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA3
Use Case Outlines Date: Nov. 15, 2002
Course Registration Artifact 3

Alter Course Selections

Brief Description
This use case allows a student to drop or add registration for courses in the current
semester. The student can search the list of course offerings for the current semester and
obtain course information prior to making revised course selections.

Step-by-Step Outline

Basic Flow
1. Log on.
2. Select ‘Alter a Schedule’.
3. View current schedule.
4. Obtain course information.
5. Add or drop courses.
6. Submit revised schedule.
7. Accept completed schedule.
8. Send changes to billing system.

Alternative Flows
A1. Delete whole schedule.
A2. Unidentified student.
A3. Quit.
A4. Cannot enroll.
A5. Course Catalog System unavailable.
Can we allow students to register if the Course Catalog is unavailable?
A6. Drop/Add period closed.
…

© Copyright IBM Corp. 2003 9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA3
Use Case Outlines Date: Nov. 15, 2002
Course Registration Artifact 3

Close Registration
Brief Description
This use case allows a Registrar to close the regular registration process (usually done in
the first or second day of classes) in the current semester. The registrar can cancel course
offerings of courses that are too small or have no instructor. The enrollment information
is then sent to the Billing System.

Step-by-Step Outline

Basic Flow
1. Log on.
2. Registrar requests registration be closed.
3. Commit or cancel courses.
a. Identify courses to cancel.
b. Drop course from student schedules.
c. Notify students that course was dropped.
d. Remove course from course list.
e. Notify professor that course was canceled.
4. Send billing info to the Billing System.
5. Get acknowledgement from Billing System.
6. Print close-registration report for registrar.
7. Registrar confirms that regular registration process is closed.

Alternative Flows
A1. Quit
A2. Registration Still in Progress
A3. Billing System Unavailable
What are the possible responses the billing system may have? We need to look into
this and figure out what to do for each response.

10 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA4.1
Register for Courses Use Case Report Date: Nov. 15, 2002
Course Registration Artifact 4.1

Register for Courses Use Case

1. Brief Description
This use case allows a student to register for courses in the current semester. The student can search the list
of course offerings for the current semester and obtain course information prior to making course
selections.

2. Flow of Events
2.1 Basic Flow
1. Log On.
This use case starts when a student accesses the Wylie University Web site. The system asks for
identification information. The student enters the student ID and password. The system validates the
ID and password.
2. Select “Create a Schedule.”
The system displays the functions available to the student. The student selects “Create a Schedule.”
3. Obtain Course Information.
The system retrieves a list of available course offerings from the Course Catalog System and displays
the list to the student. The student can search the list by department, professor or topic to obtain the
desired course information.
4. Select Courses.
The student selects four primary course offerings and two alternate course offerings from the list of
available offerings course offerings.
5. Submit Schedule.
The student indicates that the schedule is complete. For each selected course offering on the schedule,
the system verifies that the student has the necessary prerequisites, that the course offering is open, and
that there are no schedule conflicts. The system then enrolls the student in the selected course offering.
6. Accept Completed Schedule.
The system displays the completed schedule containing the selected courses. The confirmation number
for the schedule is displayed. The schedule is saved in the system. The student accepts the schedule.
The use case ends.

2.2 Alternative Flows

2.2.1 Unidentified Student

In Step 1, Log On in the Basic Flow, if the system determines that the student ID or password is not valid,
an error message is displayed. The use case ends.

2.2.2 Quit
The Course Registration System allows the student to quit at any time during the use case. The student may
choose to save a partial schedule before quitting. All courses that are not marked as “enrolled in” are
marked as “selected” in the schedule. The schedule is saved in the system. The use case ends.

© Copyright IBM Corp. 2003 11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA4.1
Register for Courses Use Case Report Date: Nov. 15, 2002
Course Registration Artifact 4.1

2.2.3 Cannot Enroll

In Step 5, Submit Schedule in the Basic Flow, if the system determines that prerequisites for a selected
course are not satisfied, that the course is full, or that there are schedule conflicts, the system will not enroll
the student in the course. A message is displayed that the student can select a different course. The use case
continues at Step 4, Select Courses in the Basic Flow.

2.2.4 Course Catalog System Unavailable

In Step 3, Obtain Course Information in the Basic Flow, if the system is unable to communicate with the
Course Catalog System, the system displays an error message to the student. The student acknowledges the
error message. The use case ends.

2.2.5 Course Registration Closed

When the use case starts, if registration for the current semester has not yet opened or has already been
closed, a message is displayed to the student. The use case ends.

3. Special Requirements
The system must validate or reject a schedule within one minute of the time the student submits the
schedule.

4. Preconditions
The list of course offerings for the semester has been created and is available to the Course Registration
System.

5. Postconditions
At the end of this use case either the student has been enrolled in courses and given a schedule or
registering was unsuccessful and no changes have been made to student schedules or course enrollments.

6. Extension Points
None.

7. Scenarios
Register for courses: Basic Flow
Unidentified Student: Basic Flow, Unidentified Student
Quit before registering: Basic Flow, Quit

12 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA4.2
Alter Course Selections Use-Case Report Date: Nov. 15, 2002
Course Registration Artifact 4.2

Alter Course Selections Use Case

1. Brief Description
This use case allows a student to drop or add registration for courses in the current semester. The student
can search the list of course offerings for the current semester and obtain course information prior to
making revised course selections.

2. Flow of Events
2.1 Basic Flow
1. Log On.
This use case starts when a student accesses the Wylie University Web site. The system asks for
identification information. The student enters the student ID and password. The system validates the
ID and password.
2. Select “Update a Schedule.”
The system displays the functions available to the student. The student selects “Update a Schedule.”
3. View Current Schedule.
The system retrieves and displays the student’s current schedule (for example, the schedule for the
current semester).
4. Obtain Course Information.
The system retrieves a list of available course offerings from the Course Catalog System and displays
the list to the student. The student can search the list by department, professor, or topic to obtain
desired course information.
5. Add or Drop Courses.
The student adds or drops courses from current schedule. The student selects the course offerings to
add from the list of available course offerings. The student also selects any course offerings to drop
from the existing schedule.
6. Submit Revised Schedule.
The student indicates that the schedule is complete. For each newly added course, the system verifies
that the student has the necessary prerequisites, that the course offering is open, and that there are no
schedule conflicts. The system then enrolls the student in the selected course. For each dropped course,
the system cancels the student’s enrollment.
7. Accept Completed Schedule.
The system displays the completed schedule containing the revised courses. The confirmation number
for the revised schedule is displayed. The schedule is saved in the system. The student accepts the
schedule.
8. Send Changes to Billing System.
If the regular course registration has already been closed, the system sends the information about added
or dropped courses to the Billing System. The use case ends.

© Copyright IBM Corp. 2003 13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA4.2
Alter Course Selections Use-Case Report Date: Nov. 15, 2002
Course Registration Artifact 4.2

2.2 Alternative Flows

2.2.1 Delete Whole Schedule

In Step 2, select “Update a Schedule” in the Basic Flow, if the student selects “Delete a Schedule,” the
system retrieves and displays the student’s current schedule (e.g., the schedule for the current semester).
The system prompts the student to confirm the deletion of the schedule. If the student verifies the deletion,
the system deletes the schedule, removes the student from enrollment in all courses, and the use case
continues at Step 8, Send Changes to Billing System. If the student does not verify the deletion, the use
case continues at Step 2, select “Update a Schedule.”

2.2.2 Unidentified Student

In Step 1, Log On in the Basic Flow, if the system determines that the student ID or password is not valid,
an error message is displayed. The use case ends.

2.2.3 Quit
The Course Registration System allows the student to quit at any time during the use case. The student can
choose to save a partial schedule before quitting. All courses that are not marked as “enrolled in” are
marked as “selected” in the schedule. The schedule is saved in the system. The use case ends.

2.2.4 Cannot enroll

In Step 6, Submit Revised Schedule, in the Basic Flow, if the system determines that prerequisites for a
selected course are not satisfied, that the course is full, or that there are schedule conflicts, the system does
not enroll the student in the course. A message is displayed that the student can select a different course.
The use case continues with Step 5, Add or Drop Courses, in the Basic Flow.

2.2.5 Course Catalog System Unavailable

In Step 4, Obtain Course Information, in the Basic Flow, if the system is unable to communicate with the
Course Catalog System, the system displays an error message to the student. The student acknowledges the
error message. The use case ends.

2.2.6 Drop/Add Period Closed

When the use case starts, if drop/add registration for the current semester has already been closed, a
message is displayed to the student. The use case ends.

3. Special Requirements
The system must validate or reject a schedule within one minute of the time the student submits the
schedule.

4. Preconditions
The student has a schedule already completed and on file on the Course Registration System.
The list of course offerings for the semester has been created and is available to the Course Registration
System.

5. Postconditions
At the end of this use case either the student has been enrolled in courses and given a revised schedule or
drop/add was unsuccessful and no changes have been made to student schedules or course enrollments.

6. Extension Points
None.

14 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA4.2
Alter Course Selections Use-Case Report Date: Nov. 15, 2002
Course Registration Artifact 4.2

7. Scenarios
7.1 Success Scenarios
Enroll in courses: Basic Flow
Alter Selections: Basic Flow

7.2 Failure Scenarios

Unidentified Student: Basic Flow, Unidentified Student
Student deletes entire schedule: Basic Flow, Delete Whole Schedule
Student quits before submitting: Basic Flow, Quit
Invalid prerequisites: Basic Flow, Cannot Enroll
Course catalog host link down: Basic Flow, Course Catalog System Unavailable
Course update period expired: Basic Flow, Drop/Add Period Closed

© Copyright IBM Corp. 2003 15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA4.2
Alter Course Selections Use-Case Report Date: Nov. 15, 2002
Course Registration Artifact 4.2

16 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA4.3
Close Registration Use-Case Report Date: Nov. 15, 2002
Course Registration Artifact 4.3

Close Registration Use Case

1. Brief Description
This use case allows a Registrar to close the registration process. Course offerings that do not have enough
students are cancelled. The Billing System is notified for each student in each course offering that is not
cancelled so the student can be billed for the course offering.

2. Flow of Events
2.1 Basic Flow
1. Log On.
This use case starts when a Registrar accesses the Wylie University Web site. The system asks for
identification information. The Registrar enters the identification code and password. The system
validates the ID and password.
2. Select “Close Registration.”
The system displays the functions available to the Registrar. The Registrar requests that the system
close registration.
3. Commit or Cancel Courses.
For each course offering, the system checks to see if a Professor has signed up to teach the course and
at least three students have registered. If so, the system commits the course offering and commits the
course on each student schedule that contains it. If there is no instructor or the course enrollment is too
small (less than three students), the system cancels the course offering.
4. Send Course Cancellations.
For all cancelled courses, the system sends a notice to the Professor (if any) that the course was
cancelled. The system also removes the course offering from each student schedule that contains it and
sends a notice to the student that the course was cancelled.
5. Send Billing Information.
The system sends the schedule for each student for the current semester to the Billing System. The
Billing System acknowledges receiving the schedules.

6. Finalize Close of Registration.

The Course Registration System records the schedules that have been sent for billing. The system
notifies the Registrar that billing information was sent to the Billing System. The system summarizes
actions taken to close the registration for this semester. The Registrar confirms that the registration
process is closed for the semester. The use case ends.

[Note that the steps in Basic Flow of the Use-Case Report are not exactly the same as in the Step-by-
Step Outline. One step (Step 3) in the outline was too big and has been split into two steps. Two
other pairs (Steps 4 and 5, and Steps 6 and 7) were each part of a single round trip. Each pair of
steps in the outline has been combined into one step in the Use-Case Report.]

© Copyright IBM Corp. 2003 17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Course Registration Version: CRA4.3
Close Registration Use-Case Report Date: Nov. 15, 2002
Course Registration Artifact 4.3

2.2 Alternative Flows

2.2.1 Quit
The Course Registration System allows the Registrar to quit at any time during the use case. The courses
are returned to their original status without committing or canceling any courses. If the Billing System has
been sent information, the system sends a new message to the Billing System to undo the billing. The use
case ends.

2.2.2 Registration Still in Progress

In Step 2, select “Close Registration,” in the Basic Flow, if the system determines registration is in
progress, then a message is displayed to the Registrar that the Close Registration processing cannot be
performed if registration is in progress. The use case ends.

2.2.3 Billing System Unavailable

In Step 5, Send Billing Information in the Basic Flow, if the system is unable to communicate with the
Billing System, the system attempts to resend the request after a specified period. The system continues to
re-send until the Billing System becomes available. The use case resumes at Step 5.

3. Special Requirements
The system must be able to handle the closing of registration of up to 10,000 students.

4. Preconditions
None.

5. Postconditions
At the end of this use case, either the registration is closed and all billing information has been transferred
to the Billing System or the closing was unsuccessful and no changes have been made to the system.

6. Extension Points
None.

7. Scenarios
7.1 Success Scenarios
Close registration: Basic Flow

7.2 Failure Scenarios

Quit before closing registration: Basic Flow, Quit
Attempt to close registration too early: Basic Flow, Registration Still In Progress
Billing system host link down: Basic Flow, Billing System Unavailable

18 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM
► ► ► Contents

RUCS: RU e-st Case Study

RUCS1: RU e-st System Specification

RUCS2: Glossary
RUCS3: Vision Document
RUCS4: Use-Case Model Survey
RUCS5: Step-by-Step Outline
RUCS6: Use-Case Reports
RUCS7: Structured Use-Case Reports
RUCS8: Supplementary Specification
RUCS9: Software Development Plan
RUCS10: Requirements Management Plan
RUCS11: Use-Case Modeling Guidelines
 RU E-ST SYSTEM SPECIFICATION

Note: The sample in this handout contains only a few pages of the
specification.

Disclaimer: This is a fictitious system and does not claim to be a model for a good
Software Requirement Specification. It is used for exercise purposes only.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RMUC Student Workbook

INTRODUCTION
RU Financial Services is currently beginning an e-commerce project to develop
software for a Web-based online stock and securities trading system. The new system
has been tentatively named the RU e-st system.

Purpose
The purpose of this SRS is to serve as a statement of understanding between the
Online Trading Business and Engineering Divisions of RU Financial Services. Any
desired departures from the specifications described herein must be negotiated by
the affected parties.
The audience for this SRS includes the engineers who are involved in the
development of the system, the marketers who are involved in its advertisement and
sale, and the testers who validate the system.

Scope
The overall objective of the RU e-st Stock Trading System is to provide our trading
customers with a convenient way to manage their stock portfolios. Managing a stock
portfolio includes such capabilities as buying and selling and researching stock in a
secure environment.

REQUIREMENTS
In this section all of the functions that the RU e-st Stock Trading System Software is to
perform are specified. These specifications are first given from total system
perspective.
The RU e-st system shall provide all of the current functionality of the current stock
trading system, plus any additions specified in this document.

Trading Customer Requirements

The RU e-st system allows its users to trade securities online, using a Web interface
(an existing browser such as Netscape or Internet Explorer). A trading customer can
log on to the Internet anywhere such as a hotel room, airport, and so on. Users can
perform all the basic operations for securities trading: open accounts, trade stocks
and other securities, and transfer assets among RU e-st accounts. Users can also
obtain current and historical information about their accounts, such as the number of
shares held, the current price, and the account total value.
Customers can execute many types of trade orders: market trading (buy and sell at
current market prices), transfers from one mutual fund to another (within one

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Review Customer Requirement Specifications

account), and limit trading (buy and sell at a specific price). The RU e-st system uses
the existing Market Trading System to perform the securities trades. RU e-st also
allows users to transfer cash in an account to or from financial institutions such as
banks or credit card vendors, using the existing Financial Network System. The usual
restrictions apply:
• For online market sales, the securities to sell must be in the customer’s
account.
• For market purchases, cash for the purchase must be in the account by the
settlement date.
• Transfers and purchases from an account are allowed only if, at the time the
transaction occurs, they have enough cash to fund the transaction in the
account.
Trading customers can obtain information about what is happening in the securities
markets. A trading customer can obtain price quotes and news headlines by entering
the trading symbol (for example, “IBM”) for a particular security. The RU e-st system
obtains current and historical quotes from the existing Quote System service and
news items from the existing News System. RU e-st also has a feature to broadcast
news headlines periodically on the trading customer’s screen (without being asked).

Regulatory Requirements
The system must report yearly tax information to the IRS and state tax boards. Tax
forms must be communicated to the IRS and copies mailed to the customer. The
information is also available online for customer viewing.

System Administration Requirements

Updates to the information on the Web pages must be possible without making the
system unavailable.

Development Requirements
The system must be written in one of the company’s approved programming
languages. Refer to document Enterprise Architecture and Development Standards
document EA-12341 for details.

Hardware Requirements
The hardware platform must be one supported by the enterprise hardware
maintenance contract. Supported platforms are specified in the Enterprise

1
This document is not supplied with the course.

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RMUC Student Workbook

Architecture and Development Standards document EA-1234.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

Glossary

Version 1.4

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Sevices Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

Revision History
Date Version Description Author
Jan 8, 2000 1.0 First draft–will continually update J. Carlos Goti
Jan 13, 2000 1.1 Additional entries J. Carlos Goti
Mar 28, 2000 1.2 Relocated Business Rules and Transactions J. Carlos Goti
into the Supplementary Specifications doc
Nov 15, 2000 1.3 Removed categories from terms and added J. Bell
new terms
Oct 30, 2001 1.4 Editorial changes B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

Table of Contents
1. Introduction 5
Purpose 5
Scope 5
References 5
Overview 5

2. Definitions 6
Account 6
Account alias 6
Account funding type 6
Account id 6
Account information 6
Account statusAccount last transaction date 6
Account operation type 6
Account status 6
Account total 7
Account type 7
Asset 7
Asset name 7
Asset total 7
Asset type 7
Bid/ask price 7
Cash asset 7
Customer id 7
Customer password 7
Current price 7
Daily change price 7
Daily high price 7
Daily low price 8
Dividend 8
Earnings per share 8
Executed per unit amount 8
Executed total amount 8
Fifty-two week range 8
IRA 8
IRS 8
Limit trade order 8
Marital status 8
Market trade order 8
Minimum cash asset 8
News list 8
Number of dependents 8
Number of shares owned 8
Number of shares per transaction 8
Opening price 9
Percentage price change 9
Previous close 9
Price/earnings ratio 9
Quote 9

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Sevices Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

RU e-st 9
RU e-st terms and conditions 9
Security 9
Securities list 9
Securities trading 9
Social security number 9
Stock symbol 9
Time stamp executed transaction 9
Total current shares traded 10
Trade order type 10
Trade transaction type 10
Trading customer 10
Trading symbol 10
Transaction fees 10
Transaction id 10
Transfer amount 10
Transfer trade order 10
Volume 10

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

Glossary
1. Introduction

This glossary is part of the set of artifacts for the RU e-st project. This document is used to define
terminology specific to the securities trading problem domain, explaining terms that might be unfamiliar to
the reader of the use-case descriptions or other project documents. This document can also be used as an
informal data dictionary; it captures data definitions so that use-case descriptions and other project
documents can focus on what the system must do with the information.

Purpose

Record the definitions of the principal terms used in the stock/bond trading domain as they relate to the
project.
Analysts and engineers involved in the project are expected to make frequent references to this document
as they complete their activities.
This document is updated frequently (as needed) during the progress of the project when it is necessary to
define new terms in a central place.

Scope

Typical terms that should be included in this glossary are:

• Domain specific
• System’s components
• Systems interacting with RU e-st
• Other

References

Standard stock-trading terminology is used whenever possible.

The RU e-st Supplementary Specification document contains Business Rules referenced in the terms of this
Glossary.
Overview

Definitions are shown next to the corresponding terms.

Terms are kept in ascending alphabetical sequence.

Since the project does not involve multiple domains, all terms are organized in one single list and groups of
terms are not used.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Sevices Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

2. Definitions
Account
A particular account that a trading customer has established. A minimum of $2500 is required to open an
account. A customer can have one or more accounts. Accounts can be non-retirement (Individual or Joint)
or retirement (Individual). Accounts have a number of assets contained in them, depending on their type.
All accounts have a cash asset.
Account alias
An alias that the customer can use to identify his/her account.
Account funding type
Accounts can have the following funding options:
• Wire
• Check
• Transfer
• Stock
• Transfer from an existing RU e-st account
Account id
Unique identifier of a customer account.
Account information
An account description includes:
• Account id
• Primary trading customer name, address, phone number, e-mail address, social security number, date
of birth, marital status, number of dependents, citizenship, employment status
• (If a joint account) Second trading customer name, address, phone number, e-mail address, social
security number, date of birth, marital status, number of dependents, citizenship and employment
status
• Account alias
• Account type
• Account operation type
• Account funding type
Account statusAccount last transaction date
Date of the last transaction executed in a given account.
Account operation type
Accounts can operate with the following characteristics:
• Cash
• Cash and margin
• Cash and margin and option
Account status
The customer account must be in one of the following statuses:
• Probationary: the customer is not allowed to perform buy or sell transactions until the method of
payment has been received and credited to the customer's account or the value of the cash account
complies with the account cash minimum business rule.
• Operational: the customer is allowed to perform any transaction
• Not_in_licensed_US state: the account is in a U.S. state in which RU e-st has no license to operate.
Transactions are not allowed.
• Other

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

Account total
The total current market value of all assets in an account. It is the sum of the asset totals for all assets
included in the account.

Account type
RU e-st supports the following types of accounts:
• Non retirement (stocks, mutual funds, and cash assets):
– Individual: a non-tax-deferred brokerage account has only one owner. Upon the death of the
owner, all property goes to his/her estate.
– Joint: a form of joint ownership exclusively for married couples. Joint accounts can be either Joint
Tenants with Rights of Survivorship, Tenants in Common, Tenants by the Entirety, or Community
Property.
• Retirement (mutual funds and cash assets): an IRA account, always individual. These can be a
single contributory IRA, Roth IRA, Rollover IRA, or a SIMPLE plan.
Asset
The value of a mutual fund, a stock, or cash. Assets are contained in accounts.
Asset name
Full name corresponding to an asset–corresponds uniquely to a stock symbol.
Asset total
The total value of an asset in an account. It is computed as the number of shares owned multiplied by the
current market value of the corresponding security.
Asset type
Assets contained in an account can be:
• Mutual fund
• Stock
• Cash
Bid/ask price
Per-unit value of the last bid and ask prices of a security.
Cash asset
The cash value, in dollars, in an account.
Customer id
Customer id for logging on to RU e-st. A customer has only one customer id, no matter how many accounts
he or she has.
Customer password
Customer password. A customer has only one password, no matter how many accounts he or she has.
Current price
Per-unit price paid for a given security in the most recent trade. The current price changes whenever a new
trade of the given security occurs.
Daily change price
Per-unit difference between the current price and the last closing price of an asset.
Daily high price
Highest per-unit value reached by an asset during the progress of a trading day.

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Sevices Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

Daily low price

Lowest per-unit value reached by an asset during the progress of a trading day.
Dividend
Latest per-share dividend distributed by the company.
Earnings per share
Latest yearly earnings per share reported by the company.
Executed per unit amount
The dollar amount per unit for a security that is bought or sold in a trade transaction. This amount is final
(not an estimate).
Executed total amount
The total dollar amount of a transaction. It is computed as the number of shares times the executed per unit
amount.
Fifty-two week range
A pair of values showing the highest and the lowest closing prices per unit that occurred in the last 52
weeks.
IRA
Individual Retirement Account. A special type of account which must conform with IRS rules in order to
obtain tax reductions.
IRS
Internal Revenue Service, the tax collection agency for the US Government.
Limit trade order
A trade order placed in the securities market to buy or sell stock at a specific price. The order can be
executed only at that price or a better one. It sets the maximum price the customer is willing to pay as a
buyer and the minimum price the customer is willing to accept as a seller.
Marital status
The customer’s marital status: single, married, divorced.
Market trade order
A trade order placed in the securities market to buy or sell stock immediately at the best current price.
Minimum cash asset
The minimum amount of cash that an account is required to have at all times. See Business Rule Account
Cash Minimum for the formula for calculation of the minimum cash asset.
News list
A list of the sixty latest news headlines that relate to a particular stock symbol, obtained from the News
System.
Number of dependents
The customer’s number of dependents: spouse, children, or other legal dependents.
Number of shares owned
The total number of shares of a given security that are owned in an account.
Number of shares per transaction
The number of shares of a given security bought or sold in a transaction.

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

Opening price
Per-unit price of the first trade of an asset during a trading day.
Percentage price change
Percentage of change between the current price and the previous close price, using the previous close price
as the base.
Previous close
Per-unit price of the last trade of an asset on the previous trading day.
Price/earnings ratio
Ratio of the current price to the earnings per share.
Quote
The unit price and other information about a given security, as obtained from the Quote System.
Components are:
• Current price
• Daily high price
• Daily low price
• Opening price
• Previous close
• Bid–ask price
• Fifty-two week range
• Percentage price change
• Volume
• Price/earnings ratio
• Earnings per share
• Dividend
• Yield
• Chart displaying the stock history for the last twelve months
RU e-st
Abbreviation for RationalU e-st, the system under development for online securities trading.
RU e-st terms and conditions
“Fine print” that describes how RU e-st operates from the business point of view.
Security
An asset that is a stock, bond, or mutual fund. Securities are assets that can be traded.
Securities list
A list of all securities that can be traded through RU e-st.
Securities trading
A transaction in which the ownership of a security changes from one person to another.
Social security number
The customer’s social security number.
Stock symbol
Trading symbol used to identify a particular stock.
Time stamp executed transaction
Date and time of the market execution of a transaction.

© Copyright IBM Corp. 2003 9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Sevices Version: RUCS 2
Glossary Date: Oct 30, 2001
RU es-t Case Study 2

Total current shares traded

Total number of shares of a given security traded as the trading day progresses.
Trade order type
Trade orders can be of the following types:
• Market: the order is placed in the market to buy or sell stock immediately at the best current price.
• Limit: allows the customer to buy or sell stock at a specific price. The order can be executed only at
that price or a better one. It sets the maximum price the customer is willing to pay as a buyer and the
minimum price the customer is willing to accept as a seller.
• Transfer: allows the customer to transfer dollars from mutual fund assets in a source account to
mutual fund assets in a target (could be the same) account. The customer cannot transfer funds to an
asset that they do not already own shares in. The customer can only transfer funds between mutual
funds.
Trade transaction type
Trade transactions can be of type:
• Buy
• Sell
Trading customer
A person who has a customer id and password in the RU e-st system.
Trading symbol
A unique identifier for a given stock or other security. The trading symbol identifies the security that is
being bought or sold.
Transaction fees
Total cost charged to the customer for a given transaction. See corresponding Business Rule.
Transaction id
A unique identifier of a customer transaction.
Transfer amount
The dollar amount involved in a transfer between accounts.

Transfer trade order

A trade order which allows the trading customer to transfer dollars from one mutual fund asset in a source
account to mutual fund assets in a target (could be the same) account. The customer cannot transfer funds
to an asset that they do not already own shares in. The customer can only transfer funds between mutual
funds.
Volume
The total number of shares of a given security that have been traded on the current day.

10 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

Vision

Version 1.5

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 4/10/2003 9:14 AM
RU e-st Case Study 3

Revision History
Date Version Description Author
th
19 January, 2000 1.0 First draft J. Carlos Goti
27th January, 2000 1.0 First complete draft J. Carlos Goti
th
17 November, 2000 1.2 Revision for clarification J. Bell
th
16 October, 2001 1.3 Updated for new release B. Baker
30th October 2001 1.4 Editorial changes B. Baker
12th February 2003 1.5 McKinley updates B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 16th October, 2001
RU e-st Case Study 3

Table of Contents
1. Introduction 5
1.1 Purpose 5
1.2 Scope 5
1.3 Definitions, Acronyms, and Abbreviations 5
1.4 References 5
1.5 Overview 5

2. Positioning 5
2.1 Business Opportunity 5
2.2 Problem Statement 6
2.3 Product Position Statement 7

3. Stakeholder and User Descriptions 8

3.1 Stakeholder Summary 8
3.2 User Summary 8
3.3 User environment 9
3.4 Stakeholder Profiles 9
3.4.1 RU e-st Product Manager 9
3.4.2 RU e-st Business Manager 10
3.4.3 RU e-st Development Manager 10
3.4.4 RU e-st Partner Executive 10
3.5 User Profiles 11
3.5.1 RU e-st End User 11
3.5.2 RU e-st System Administrator 11
3.6 Key Stakeholder/User Needs 12
3.7 Alternatives and Competition 12
3.7.1 Stay with the current system. 12
3.7.2 Buy an existing online securities trading service company. 12
3.7.3 Buy an off-the-shelf securities trading system and install it. 13

4. Product Overview 13
4.1 Product Perspective 13
4.2 Summary of Capabilities 14
4.3 Assumptions and Dependencies 14
4.4 Cost and Pricing 14
4.5 Licensing and Installation 14

5. Product Features 15

6. Constraints 15

7. Quality Ranges 15

8. Precedence and Priority 15

9. Other Product Requirements 16

9.1 Applicable Standards 16

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 4/10/2003 9:14 AM
RU e-st Case Study 3

9.2 System Requirements 16

9.3 Performance Requirements 16
9.4 Environmental Requirements 16

10. Documentation Requirements 16

10.1 User Manual 16
10.2 Online Help 16
10.3 Installation Guides, Configuration, Read Me File 16
10.4 Labeling and Packaging 16

11. Appendix 1 - Feature Attributes 16

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 16th October, 2001
RU e-st Case Study 3

RU e-st Project Vision

1. Introduction
The purpose of this document is to collect, analyze, and define high-level needs and features of the RU e-st
system. It focuses on the capabilities needed by the stakeholders, the target users, and why these needs
exist. The details of how RU e-st fulfills these needs are shown in the use case and supplementary
specifications.
This document describes the vision for the proposed RU e-st system. The RU e-st system allows its users to
trade securities online, using a Web interface (an existing browser). It enables its users to perform the basic
operations: open accounts, trade, and obtain information about their accounts and about what is happening
in the securities markets.
1.1 Purpose
The objective of writing a Vision document for the RU e-st system is to enable agreement among
stakeholders, developers, and business representatives. Another purpose of writing a Vision document is to
provide a common platform for agreement between the developers themselves.
1.2 Scope
This document records the vision for the RU e-st system. It is associated with a project to provide Web-
based online trading facilities through financial institutions.
1.3 Definitions, Acronyms, and Abbreviations
Definitions of terms and allowed operations are to match the standard ones in use in the field of securities
trading. See the Glossary document for details.
1.4 References
[1] RU Financial Services RU e-st Requirements Management Plan
[2] RU e-st Project Glossary
1.5 Overview
This document contains product positioning statements, an analysis of the system’s stakeholders, an
analysis of the expected system users, and a list of features that the system should deliver. These features
are derived from the input obtained from stakeholders.
2. Positioning
2.1 Business Opportunity
Currently, RU Financial Services has a number of critical business objectives, which, if not met, threaten
the long-term viability of the organization. The success of this project will enable RU Financial Services to
continue to grow and move into the 21st century from a position of strength.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 4/10/2003 9:14 AM
RU e-st Case Study 3

2.2 Problem Statement

The problem of a stock trading system that:
• Lacks features required by our customers.
• Has intermittent errors in trades.
• Is expensive to operate and maintain due to
labor and infrastructure costs.
• Is difficult to maintain due to:
o Client/server architecture.
o Legacy code that lacks documentation,
structure and architecture.
o Lack of developer knowledge of current
system.
affects RU Financial Services.
The impact of which is We need to replace the current online stock-trading
system.
A successful solution • Provide the feature set demanded by our
would customers.
• Provide a reliable service that has no errors in
trades.
• Reduce the operation and maintenance costs to no
more than 10% of the gross contribution margin
of the online trading business.
• Use a corporate standard architecture and
implementation language.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 16th October, 2001
RU e-st Case Study 3

2.3 Product Position Statement

For RU Financial Services

who needs to replace the current stock trading system
because it is losing profitability, customers, and
market share in the e-stock trading market.
The RU e-st is a Web-based securities trading system
that has the full stock trading functionality demanded by
our customers.
Unlike continuing with the current client-server-based system
that is:
• Running on unsupported hardware.
• Is difficult and expensive to maintain.
• Lacks some of the features required by our
customers.
• Is prone to error.
• Requires our customers to install client software
on their machines.
Our product will make the business profitable again by:
• Providing error free trading that provides all of
the most popular features requested by our
customers.
• Allowing bug fixes and upgrades to be applied
quickly and cheaply due to its Web-based
architecture.
• Reducing operating costs by using supported
hardware and using standard maintenance
contracts.
• Reducing maintenance costs by using corporate
standard programming languages and
architecture.

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 4/10/2003 9:14 AM
RU e-st Case Study 3

3. Stakeholder and User Descriptions

3.1 Stakeholder Summary

There are typically a large number of stakeholders to a project. Here we list the ones that have primary
responsibilities and have the largest influence on the success of the project.

Name Represents Role

RU e-st Product Represents the executive Define a product that satisfies the
Manager management in the company. business requirements. Evaluate
options and scope the different
versions of the system.
RU e-st Business The business entity that makes the Assure that the company has the
Manager funding decisions for development. plans and resources to deliver the
system and that it is a good business
decision for the company to spend
the funds.
RU e-st The team that develops and releases Assure that the development team
Development the system. delivers a system that complies with
Manager the specifications supported by the
RU e-st Product Manager.
RU e-st End User People who trade securities using Validate that the features offered by
the system. the system are adequate and
responsive to the needs of traders.
RU e-st Partner Companies whose systems support Approve business agreements for
Executive the operation of the system. They specialized functions needed to
are: Market Trading, News System, support online securities trading.
and Quote System.

3.2 User Summary

Name Description Stakeholder

End User-Day A very knowledgeable end user, who is RU e-st End User
Trader on the system very frequently and is
aware of and makes use of advanced
features.
End User-Naïve First-time or infrequent end user of the RU e-st End User
system. This person needs guidance and
might need to refer to online help for
definitions and business consequences of
trading actions.

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 16th October, 2001
RU e-st Case Study 3

RU e-st Does customization and setup activities RU e-st Development Manager

Administrator on the system. Maintains up-to-date
information and produces and analyzes
operational reports of system
performance.
RU e-st Support Helps calling customers use the system RU e-st Development Manager
correctly. Reports errors and develops
operational fixes.
RU e-st Developer Part of the team that develops the system RU e-st Development Manager
(software developer, tester, etc.)

3.3 User environment

End users typically work alone. They have logged on to the Internet (hotel room, airport, and so on) and
want to check the status of their investment or perform one or more trades.

Except for the people who share an account, there is no interplay between the different end users. They are
independent of each other.

It is expected that many thousands of end users will be trading at the same time.

End user accesses the system through a standard Internet browser. They do not need to learn new user
interface (UI) techniques of any type. They access the system from many different client platforms
(Windows, McIntosh, Linux, OS/2).

3.4 Stakeholder Profiles

3.4.1 RU e-st Product Manager

Representative The online trading business

Description Defines a product that satisfies the business requirements. Evaluates options and
scope the different versions of the system.
Type Is an expert-level user of the system.
Responsibilities Does the business analysis of the system for justification to the RU e-st Business
Manager. Achieves a definition of the system that can be built and delivered on
time and within cost. Commits the marketing and sales resources to make money
with the product.
Success Criteria The product (system) is accepted and makes money, as evidenced by a continued
trend of reductions in monthly loss of customers with a corresponding increasing
trend in monthly profits.
Involvement Constantly reviews plans and development progress. Assesses how features are
being supported. Validates expenses by system feature.
Deliverables Participates during iteration assessment sessions and when project decisions are
made.
Comments/Issues Needs to keep an eye on the competition to ensure success in the marketplace.

© Copyright IBM Corp. 2003 9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 4/10/2003 9:14 AM
RU e-st Case Study 3

3.4.2 RU e-st Business Manager

Representative The business entity that makes the funding decisions for development.
Description Ensures that the company has the plans and resources to deliver the system and that
it is a good business decision for the company to spend the funds.
Type Probably not a user of the system.
Responsibilities Assures the funds are committed to the project and adjustments are made with
sound business sense. Influences marketing and sales to prioritize the system
according to the company’s vision. Promotes the system with potential customers.
Success Criteria The system makes money for the company and is aligned with the overall strategy.
The company gets good press from the system, and the stock goes up.
Involvement Participates in the system’s phase assessments.
Deliverables Provides the project team with resources and promote the system vision with good
press inside and outside the company.
Comments/Issues The RU e-st Business Manager should be supported with solid marketing and
positioning information about the system.

3.4.3 RU e-st Development Manager

Representative Of the team that develops and releases the system.

Description Ensures that the development team delivers a system that complies with the
specifications supported by the RU e-st Product Manager.
Type Very proficient in the use of the system.
Responsibilities Allocates the resources and provides the technical and business controls to assure
the success of the project.
Success Criteria The project completes a sound delivery that can be sold, as specified by the RU e-st
Product Manager.
Involvement The Development Manager works closely with the Project Manager, the Architect,
and the Analyst to ensure that all is on the right track.
Deliverables Supports the project with controls, imaginative resolution of problems, allocation of
resources, and teams building activities.
Comments/Issues The Development Manager can act as a technical leader in some areas of expertise.

3.4.4 RU e-st Partner Executive

Representative Companies whose systems support the operation of RU e-st. They are: Market
Trading, News System, Quotes System, and the Financial Network System.
Description Approve business agreements for specialized functions needed to support online
securities trading.
Type Might not use the system at all.
Responsibilities Achieves business agreements for cooperation between systems. Agree on business
synergism and mutual charging schemes.
Success Criteria Smoothes business operation (low bureaucracy) during the system’s joint
operations.
Involvement Early agreements during the inception phase of the system. The business
arrangements should be completed early in the development process.
Deliverables Mutual service support during the operation of the systems. Clear arrangements for

10 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 16th October, 2001
RU e-st Case Study 3

production problem resolution.

Comments / Issues Business arrangements are limited in time. Backup arrangements are always good
to have. In some cases, we might want to have two or more partners providing the
same services to minimize full dependencies.

3.5 User Profiles

Users are listed in two categories: end users and RU e-st system administrators. The breakdown shown
above is too detailed for this section.
3.5.1 RU e-st End User

Representative The RU e-st Product Manager is the representative of End Users.

Description Uses the RU e-st system to perform securities trades.
Type The Day Trader is very knowledgeable about the system’s operations and features
because of constant use.
The naïve user is either a first-time user or an infrequent user.
Responsibilities End users give the development team feedback about how the system supports their
trading needs. They should point out lacking features and awkward operational
characteristics of the system.
Success Criteria Users benefit from an improved system access to their needs.
Involvement Users should participate in the description of use cases, the evaluation of partial
implementations, and the assessment of the help features of the system.
Deliverables Users deliver feedback to the team’s analysts and architect either verbally or in
writing.
Comments / Issues It is very important to the project to have good user representatives. They can
improve the system by sharing their domain expertise and operational needs.

3.5.2 RU e-st System Administrator

Representative System administrators are represented by the RU e-st Development Manager.

Description System administrators do set up, customization, support and development of the
system.
Type All system administrators are users at the expert level.
Responsibilities Prepares and executes installation and customization operations.
Tends to production problems (errors, performance, work-around solutions, etc.)
Supports end users who call for help or to report errors.
Develops and test parts of the system.
Success Criteria Customer satisfaction measures.
Involvement Should participate during development in the same way that end users do. They
should concentrate on the support and maintenance use cases.
Deliverables Comments to improve the support and maintenance aspects of the system.
Comments / Issues Often, the system administrator users are not brought on-board in time to improve
the system. A special effort should be made to get their feedback as early as
possible.

© Copyright IBM Corp. 2003 11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 4/10/2003 9:14 AM
RU e-st Case Study 3

3.6 Key Stakeholder/User Needs

Requirements Origin
STRQ1: Want to be able to transfer funds from other accounts (not necessarily held Trading Customer
with this firm) to a trading account.
STRQ2: State and federal regulations require monthly reports of account activity. Regulatory
Refer to specification RUFS-1234 for details of the information required.
STRQ3: The system should allow the use of any browser. Trading Customer
STRQ4: Customers want to manage their retirement funds. Trading Customer
STRQ5: Must be able to upgrade the system without taking it offline. On-line Trading
Business
STRQ6: The system should allow traders to trade in multiple markets across the Trading Customer
world.
STRQ7: Must be able to provide convenient answers to customer’s most common Customer Support
questions.
STRQ8: The system must provide a secure environment that prohibits fraudulent Trading Customer
access.
STRQ9: Need a way to train customers in the use of the system quickly and Customer Support
conveniently.
STRQ10: The system must operate on hardware that falls under the company’s Finance
current maintenance contracts. Department
STRQ11: Need to be able to maintain the system with our current IT hardware and System
skills. Refer to enterprise architecture document EA-1234 for details. Administration
STRQ12: Need account activity statements for tax reporting. Trading Customer
STRQ13: The system must provide all the basic capabilities of a normal stock broking Trading Customer
firm.
STRQ14: Need to be able to perform research on any given stock. Trading Customer
STRQ15: The system must allow traders to obtain up-to-date news and alerts on Trading Customer
nominated stock.
STRQ16: The system must provide current and historical information on Trading Trading Customer
Acounts. Such as number of shares held, current price, total Trading Account value
STRQ17: The system shall provide the following types of trades: Market Trades (buy Trading Customer
and sell), Limit Trades (buy and sell), and transfers between mutual funds.
STRQ18: The system shall use the existing Market Trading System to perform Trading Customer
securities trades.
STRQ19: The system must report yearly tax information to the IRS and state tax Regulatory
boards.
STRQ20: Tax forms will be sent electronically to the IRS and state tax authorities. Regulatory
STRQ21: Tax information can be viewed on-line by the Trading customer and printed Regulatory
if requested.
STRQ22: The system performance must be aceptable to customers that do not have Trading Customer
high-speed data access for their computers.

3.7 Alternatives and Competition

3.7.1 Stay with the current system.

This is not a viable alternative due to the current operating costs and downward trend in customer base.
3.7.2 Buy an existing online securities trading service company.
RU Financial Services could buy an existing online trading company and merge with it. This is surely a
possibility, but there are more institutions wanting to buy than the number of companies in a position to be
bought. Most companies attempting to make this move need a different alternative.

12 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 16th October, 2001
RU e-st Case Study 3

3.7.3 Buy an off-the-shelf securities trading system and install it.

This option is attractive because it eliminates development risks and produces results very quickly.
Sourcing an adequate solution is difficult as there are not many commercially available stock-trading
products available at this stage.

4. Product Overview
RU e-st is planned to interface with other systems in the following fashion:

Trader/ Standard
End User Internet RU e-st
Browsers

Financial Market Trading News Quote

Network System System System
System

All end users access the system’s features through standard Internet browsers. The system provides
facilities for traders to set up accounts, get securities quotes, obtain news headlines about specific
securities, and perform trades. RU e-st keeps information about user’s accounts and the assets in them.

4.1 Product Perspective

RU e-st interacts with other systems for some specific tasks. They are:
• Market-Trading System: to complete trade orders as specified by the trader.
• News System: to retrieve headline news and the corresponding links to full articles for a given
security.
• Quote System: to retrieve current and historical quote information for a given security.
• Financial Network System: to perform money transfers to and from the customers’ financial
institution accounts.

© Copyright IBM Corp. 2003 13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 4/10/2003 9:14 AM
RU e-st Case Study 3

4.2 Summary of Capabilities

RU e-st System
Trader Benefit Supporting Features
Trading online • Online trading
• Online account setup
• Online quotes
• Online news
Securities research online • Online quotes
• Online news
• Online account reports
Portfolio management online • Online account setup
• Online accounts reports
• Online transfers between accounts
• Online transfers with banks
Portfolio record keeping • Historical account reports
• Income tax account reports
• IRS reporting forms

4.3 Assumptions and Dependencies

The basic features of the system are attainable with today’s technologies. No high-risk dependencies are
envisioned.

4.4 Cost and Pricing

Marketing is working on the pricing points.

Development is working on the cost estimates.

4.5 Licensing and Installation

Not applicable.

14 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 16th October, 2001
RU e-st Case Study 3

5. Product Features

Features
FEAT1: The system uses the Financial Services Network to enable transfer of funds between other financial
institutions and the customers Trading Account.
FEAT2: The system provides automatic reporting of tax-related information to the IRS and state tax boards.
FEAT3: The system supports the most common browsers: Microsoft Internet Explorer, (version 4 and higher)
and Netscape Navigator, (versions 4.72 through 4.75 and 6.2).
FEAT4: The system allows funds to be transferred to and from Mutual Fund accounts.
FEAT5: The system allows a customer to operate multiple Trading Accounts with a single login.
FEAT6: The system can be upgraded without taking services off-line.
FEAT7: During upgrades the system will preserve all "in-progress" transactions to ensure an error free
experience for the customer.
FEAT8: The system uses the Market Trading System to allow trading in any market worldwide.
FEAT9: The system provides an FAQ page to answer customer's most frequent questions quickly and simply.
FEAT10: The system provides an "I need help now" capability that will open a "chat window" with the next
available customer support representative. If there is no support personal available the system will inform the
customer where they are in the queue for help.
FEAT11: All Web pages shall be encrypted using 128 Bit SSL Security.
FEAT12: All personal and financial information shall be stored on a separate system with a secure network
connection between the systems.
FEAT13: The system provides comprehensive "how-to" documentation that is structured like a story of using
the system for a particular purpose. For example, "How to perform a Limit Buy."
FEAT14: The system runs on a corporate standard platform.
FEAT15: The system provides electronic and printed statements of account activity, including profit and loss
information, for yearly income tax reporting.
FEAT16: The system provides statements of Trading Account activity including transfers between Trading
Accounts, Trade summaries including: ticket code, number of shares traded and trade price.
FEAT17: Transfer cash from one customer trading account to another.
FEAT18: The system executes transactions in an Internet comfortable speed (less than 3 seconds, not
counting transmission times on a 56K modem).
FEAT19: Charge to a credit card and place funds in a customer's trading account.
FEAT20: Rollover from a retirement account in another institution in to a retirement account managed by the
system.
FEAT21: The system allows Market Buy and Sell transaction types.
FEAT22: The system allows Limit Buy and Sell transaction types.
FEAT23: The system allows mutual fund management.
FEAT24: The system allows stock research and alerts - online quotes, news flashes, and so on.

6. Constraints
All the online features must run on the selected Internet browsers.

Need to perform an additional assessment by the end of the elaboration phase.

7. Quality Ranges
Refer to expected industry standards in this area. Further research is needed.

8. Precedence and Priority

This information is included in the RequisitePro database. Appropriate reports are designed to convey this
information.

© Copyright IBM Corp. 2003 15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 3
Vision Date: 4/10/2003 9:14 AM
RU e-st Case Study 3

9. Other Product Requirements

9.1 Applicable Standards

Refer to standards related to the versions of HTML and Java by the supported Internet browser.
Refer to standards for financial transactions between institutions in the Financial Network.
The application must conform to all the rules of the NASD, SIPC, and other trading institutions involved in
transactions.
9.2 System Requirements
The customer needs a computer (client) with capabilities to access the Internet. Access speed and local hard
drive use depends on the customer’s configuration and practices of use.

9.3 Performance Requirements

Transactions (except for trades, which require a sale or buy operation) must execute in an Internet-
comfortable speed (less than 3 seconds, not counting transmission times).

9.4 Environmental Requirements

No additional requirements other than the ones in common practice for a computer with Internet connection
capability.

10. Documentation Requirements

Basically, all documentation for the RU e-st system is available online and not in print form.

We might need some printed information at the brochure level for mailings and “getting started” help. This
information should describe trading terms and conditions and a basic description of capabilities.

10.1 User Manual

User manuals shall be available in electronic format and can either be downloaded in PDF form or as a
series of HTML pages that can be browsed.

10.2 Online Help

The system offers extensive online help.

The help has two basic objectives:

Assistance in the operation of the system
Assistance with the domain (definitions, descriptions of accounts, transactions, legal issues, etc.)

10.3 Installation Guides, Configuration, Read Me File

No installations are required. No need for this documentation.

10.4 Labeling and Packaging

There is no applicable labeling and packaging activity.

11. Appendix 1 - Feature Attributes

Refer to [1].

16 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Use-Case Model Survey

RU e-st System

Introduction
This set of sample solutions is for the RU e-st system for Web-based stock trading. The point of this set of
solutions is to show what a solution may look like and to what level of detail you describe the use cases.
The stock trading system is based on a real system. However, details of stock trading have been
simplified at many points in order to make a case study suitable for discussion in a relatively short course.
The point here is not the technical content but what the descriptions may look like.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 4
Use Case Model Survey: RU e-st Date: October 30th 2001
RU e-st Case Study 4

1. Introduction
This is an example of what a solution to the use-case exercises in the MRMUC course might look like. It
contains more information than a MRMUC class might create in the limited class time available. It is an
example of a use-case model for a regular project. Keep in mind that this example shows the use-case
model at the beginning of a project.

2. Survey Description
The RU e-st system allows its users to trade securities online, using a Web interface (an existing browser such as
Netscape or Internet Explorer). A trading customer can log on to the Internet anywhere – hotel room, airport, and so
on. Users can perform all the basic operations for securities trading: open accounts, trade stocks and other securities,
and transfer assets among RU e-st accounts. Users can also obtain current and historical information about their
accounts, such as the number of shares held, the current unit price, and the current total value. Trading customers
can obtain information about what is happening in the securities markets, such as current price quotes and news
items. In addition, the system must report yearly tax information to the IRS and state tax boards.

3. Actors

3.1 Diagram

Trading Customer Broker Web Content Provider

Market Trading System

Tech Support Scheduler
Financial Network

Quote System Tax System System Administrator

News System

Figure 1. Actor Diagram

3.2 Trading Customer

A person with a valid customer id and password. The Trading Customer is the primary end-user who trades
securities (stocks and mutual funds) through the RU e-st system.

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 4
Use Case Model Survey: RU e-st Date: October 30th, 2001
RU e-st Case Study 4

3.3 Broker
The Broker has access to accounts assigned to the broker.

3.4 System Administrator

The System Administrator has responsibility for the entire RU e-st system. The System Administrator
authorizes Trading Customers and their trading accounts, authorizes non-standard trades, handles
fraudulent use of the system, and monitors the system’s overall performance and health.

3.5 Customer Service

Customer Service has responsibility for the operation of the RU e-st system. Customer Service answers
questions from Trading customers based on RU e-st account information and accesses and resolves
problems with individual accounts.

3.6 Web Content Provider

The Web Content Provider has responsibility for posting broadcast and other messages on the Web site for
the RU e-st system.

3.7 Market Trading System

The system performs the market trades requested by RU e-st and communicates trade results back.

3.8 Financial Network

A Financial Network provides services to the RU e-st system and is responsible for verifying accounts at
banks, authorizing transactions, and recording completed transactions. The Financial Network makes it
possible for Trading Customers to transfer funds between RU e-st accounts and accounts external to
RU e-st, such as bank accounts or credit card accounts.

3.9 Scheduler
A human or system that initiates a use case based on a calendar event.

3.10 Tax System

This system accepts electronic reports of tax information.

3.11 Quote System

This system provides current and historical market price quotes of securities such as stocks and mutual
funds.

3.12 News System

This system provides news headlines about a particular security (stock or mutual fund).

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 4
Use Case Model Survey: RU e-st Date: October 30th 2001
RU e-st Case Study 4

4 Use Cases

4.1 Primary Cases

4.1.1 Diagram of Use Cases Around the Trading Customer

See Figure 2.

Apply for Execute Trade

Trading Account Market Trading System

Get Quote

Quote System

Manage
Portfolio
Trading
Customer
Financial Network

Distribute
News

News System

Review
Account
Broker
Scheduler

Figure 2. Diagram of Use Cases around the Trading Customer

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 4
Use Case Model Survey: RU e-st Date: October 30th, 2001
RU e-st Case Study 4

4.1.2 Apply for Trading Account

A person can apply for a new trading account. If the person does not already have any trading accounts, the
person is authorized to become a new Trading Customer. A Trading Customer with existing trading
accounts can set up new trading accounts of the same or different account type.

4.1.3 Execute Trade

Trading Customers buy, sell, or transfer securities in their accounts. Immediately after a trade is completed,
Trading Customers receive a market trading confirmation containing a transaction id and the trade results.

4.1.4 Manage Portfolio

Trading Customers can manage their portfolios. Allowable transactions include transferring cash or other
assets between accounts, reviewing accounts, consolidating or splitting accounts, and transferring cash
between their RU e-st accounts and accounts at banks or credit card companies.

4.1.5 Get Quote

Trading Customers get current and historical information about the trading price of securities.

4.1.6 Review Account

Trading Customers get current and historical information about their accounts. Brokers can also use this
use case to review accounts that belong to Trading Customers whose accounts they help manage.

4.1.7 Distribute News

The RU e-st system periodically broadcasts headline news and current stock information and trading tips.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 4
Use Case Model Survey: RU e-st Date: October 30th 2001
RU e-st Case Study 4

4.2 Secondary cases

4.2.1 Diagram of Support and Maintenance Use Cases

Maintain Customer
Accounts

RU e-st Administrator
Report Tax
Information

Tax
System

Maintain
Web Site

Web Content
Provider
Trading
Resolve Account Customer
Problems

Customer Service

Figure 3. Diagram of Support and Maintenance Use Cases

4.2.2 Maintain Customer Accounts

The RU e-st Administrator uses the Maintain Customer Accounts use case to authorize Trading Customers
and accounts, authorize non-standard trades, and oversee the administration of the RU e-st system at a
given financial institution.

4.2.3 Report Tax Information

The RU e-st Administrator uses the Report Tax Information use case to report tax information to the Tax
System. Both state and U.S. taxes can be reported.

4.2.4 Maintain Web Site

The Web Content Provider uses the Maintain Web Site use case to change the Web content: modify
messages for broadcast, modify screen content, and modify links among Web pages.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RationalU e-st Version: RUCS 4
Use Case Model Survey: RU e-st Date: November 15, 20XX
RU e-st Case Study 4

4.2.5 Resolve Account Problems

Customer Service uses the Resolve Account Problems use case to examine and change customer accounts
and transactions. Customer Service representatives communicate with Trading Customers by e-mail and
telephone (outside of the RU e-st system) about problems with accounts or transactions and use RU e-st to
resolve those problems.

Rational Software, 2000 Page 7

RU Financial Services Version: RUCS 4
Use Case Model Survey: RU e-st Date: October 30th 2001
RU e-st Case Study 4

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Get Quote Use Case
1. Brief Description
Trading Customers get current and historical information about the trading price
of securities.

2. Flow of Events
2.1 Basic Flow
1. Customer logs on.

2. Customer selects “Get Quote” function.

3. Customer selects stock trading symbol.

4. Get desired quote from Quote System.

5. Display quote.

6. Customer logs off.

2.2 Alternative Flows

A1 Customer Gets Other Quotes
A2 Unidentified Trading Customer
A3 Quote System Unavailable
A4 Quit
A5 Unknown Trading Symbol
3. Scenarios
3.1 Success Scenarios
Customer gets a quote: Basic Flow
Customer gets additional quotes: Basic Flow, Customer Gets Other Quotes
3.2 Failure Scenarios
Invalid login: Basic Flow, Unidentified Trading Customer
Quote system host link down: Basic Flow, Quote System Unavailable
Trading customer enters an unknown trading symbol: Basic Flow, Unknown
Trading Symbol
Trading customer quits before completion: Basic Flow, Quit

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
© Copyright IBM Corp. 2003 2
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Execute Trade Use Case

1. Brief Description
Trading Customers buy, sell, or transfer securities in their accounts. The possible
trade order types are: Limit Buy Order, Limit Sell Order, Market Buy Order,
Market Sell Order, Transfer Order. Immediately after a trade is completed,
Trading Customers receive a market trading confirmation containing a transaction
id and the results of the trade.

2. Flow of Events
2.1 Basic Flow
1. Customer logs on.

2. Customer selects “Trade” function.

3. Customer selects account.

4. Customer performs trade.

4.1 Select trade order type (market, limit, transfer) and enter trading info.

4.2 Initiate trade with Market Trading System.

4.3 Get trade results from Market Trading System.

5. Customer logs off.

2.2 Alternative Flows

A1 Unidentified Trading Customer
A2 Unauthorized Trader
A3 Quit
A4 Trade Is Rejected
A5 Market Trading System Unavailable
A6 Insufficient Funds
A7 No Trading Account
A8 Account Not Operational
A9 Customer Executes More Trades

3. Scenarios
3.1 Success Scenarios
Customer executes a trade: Basic Flow.
Customer Executes More Trades: Basic Flow, Customer Executes More
Trades.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 3.2 Failure Scenarios
Invalid login: Basic Flow, Unidentified Trading Customer.
Trader is not authorized to use account: Basic Flow, Unauthorized Trader.
Customer quits before executing trade: Basic Flow, Quit.
Trade rejected: Basic Flow, Trade Is Rejected.
Host link down to Market Trading System: Basic Flow, Market Trading
System Unavailable.
Insufficient funds in trading account: Basic Flow, Verify That Cash Is
Available.
Customer doesn’t have a trading account: Basic Flow, No Trading Account.
Trading account is inactive: Basic Flow, Account Not Operational.

© Copyright IBM Corp. 2003 2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

Use-Case Report: Get Quote

Version 1.5

Introduction
This is an example of what a use-case report might look like. There is much more detail in the
use-case report than there was in the step-by-step outline that was the first draft of the use case.
In this example, we show the report as it might appear in the middle of its development process.
There are many styles of writing use cases. We show one style here, based on the template and
guidelines for a use-case report in the Rational Unified Process.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.1
Use Case Report: Get Quote Date: 4/10/2003 9:21 AM
RU e-st Case Study 6

Revision History
Date Version Description Author
Jan 13, 2000 1.0 First draft J. Carlos Goti
Jan 15, 2000 1.0 First complete draft J. Carlos Goti
Nov. 15, 2000 1.2 Revised for clarification J. Bell
Oct 30, 2001 1.3 Editorial changes B. Baker
Jan 30, 2003 1.4 Added scenario list and additional quotes B. Baker
alternative flow
2nd April 2003 1.5 Post McKinley Beta changes B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.1
Use Case Report: Get Quote Date: 4/10/2003 9:21 AM
RU e-st Case Study 6

Table of Contents
1. Use Case Name: Get Quote 4
1.1 Brief Description 4

2. Flow of Events 4
2.1 Basic Flow 4
2.2 Alternative Flows 4

3. Special Requirements 5
3.1 Timely Quote Display 5

4. Preconditions 5

5. Postconditions 5

6. Extension Points 5

7. Relationships 5

8. Use-Case Diagrams 5

9. Other Diagrams 5

10. Scenarios 6
10.1 Success Scenarios 6
10.2 Failure Scenarios 6

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.1
Use Case Report: Get Quote Date: 4/10/2003 9:21 AM
RU e-st Case Study 6

Use-Case Report: Get Quote

1. Use Case Name: Get Quote
1.1 Brief Description
The Trading Customer can get current and historical information about the trading price of securities.

2. Flow of Events
2.1 Basic Flow
1. Customer Logs On.
The use case starts when the Trading Customer logs on.
The system validates the customer id and password.
The system presents a list of available functions.

2. Customer Selects “Get Quote” Function.

The Trading Customer chooses to “Get Quote.”
The system displays the list of trading symbols and names of securities.

3. Customer Selects Security.

The Trading Customer selects from the list of securities or enters the trading symbol for a security.

4. System Gets Quote from Quote System.

The system sends the trading symbol to the Quote System, and receives the Quote System
Response.
The system presents the corresponding Quote Display (see fields to display in Supplementary
Specifications) to the Trading Customer.

5. Customer Logs Off.

The Trading Customer logs off the system.
The use case ends.
2.2 Alternative Flows

2.2.1 Customer Gets Other Quotes

In Step 4, System Gets Quote From Quote System, in the Basic Flow, if the Trading Customer wishes to
get additional quotes, the use case resumes at Step 3, Customer Selects Security, in the Basic Flow.
2.2.2 Unidentified Trading Customer
In Step 1, Customer Logs On, in the Basic Flow, if the system determines that the customer id and/or
password are not valid, the system displays an Invalid Login Message.
The use case ends.

2.2.3 Suspect Theft

In Step 1 of the basic flow, if the customer id is on the system’s list of stolen identification, the system
displays an Invalid Login Message.
The system records the date, time, and computer address from which the person tried to log on and sends a
message to the System Administrator.
The use case ends.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.1
Use Case Report: Get Quote Date: 4/10/2003 9:21 AM
RU e-st Case Study 6

2.2.4 Quote System Unavailable

In Step 4, System Gets Quote From Quote System, in the Basic Flow, if the system is unable to
communicate with the Quote System, the system informs the Trading Customer. The use case ends.

2.2.5 Quit
The RU e-st System allows the Trading Customer to quit at any time during the use case.
The use case ends.

2.2.6 Unknown Trading Symbol

In Step 3, Customer Selects Security, in the Basic Flow, if the system cannot recognize the trading symbol,
the system notifies the Trading Customer that the trading symbol is not recognizable.
The use case continues at the beginning of Step 3 in the Basic Flow.

2.2.7 Quote System Cannot Locate Information

In Step 4, System Gets Quote From Quote System, in the Basic Flow, if the Quote System responds that it
does not have the requested information, the system notifies the Trading Customer that the Quote System
does not have information on the requested security.
The use case continues at the beginning of Step 3, Customer Selects Security, in the Basic Flow.

3. Special Requirements

3.1 Timely Quote Display

The RU e-st system must present the requested Quote Display within two seconds after a Trading Customer
finishes requesting it.

4. Preconditions
None.

5. Postconditions
None.

6. Extension Points
None specified for this use case.

7. Relationships
The Actor starting this Use Case is:
Trading Customer
Actor(s) also involved in this Use Case:
Quote System

8. Use-Case Diagrams
None specified for this use case.

9. Other Diagrams
None specified for this use case.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.1
Use Case Report: Get Quote Date: 4/10/2003 9:21 AM
RU e-st Case Study 6

10. Scenarios
10.1 Success Scenarios
Customer gets a quote: Basic Flow
Customer gets additional quotes: Basic Flow, Customer Gets Other Quotes
10.2 Failure Scenarios
Invalid login: Basic Flow, Unidentified Trading Customer
Fail due to stolen id: Basic Flow, Suspect Theft
Host link down to quote system: Basic Flow, Quote System Unavailable
Customer enters an unknown trading symbol: Basic Flow, Unknown Trading Symbol
Fail due to quote system is unable to locate information: Basic Flow, Quote System Cannot Locate
Information

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

Use-Case Report: Execute Trade

Version 1.5

Introduction
This is an example of what a use-case report might look like. There is much more detail in the
use-case report than there was in the step-by-step outline that was the first draft of the use case.
In this example, we show the report as it might appear in the middle its developing process.
There are some issues noted directly in the use case, as is typical of a use case under
development.
There are many styles of writing use cases. We show one style here, based on the template and
guidelines for a use-case report in the Rational Unified Process.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.2
Use Case Report: Execute Trade Date: 4/10/2003 9:23 AM
RU e-st Case Study 6

Revision History
Date Version Description Author
Jan 13, 2000 1.0 First draft J. Carlos Goti
Jan 15, 2000 1.0 First complete draft J. Carlos Goti
Nov 15, 2000 1.2 Revised for clarification J. Bell
Oct 30, 2001 1.3 Editorial changes B. Baker
Feb 5, 2003 1.4 Added scenario list. Restructured to use B. Baker
sub- flows and alternative flows for
repeating behavior.
Apr 2nd, 2003 1.5 Post McKinley Beta changes B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.2
Use Case Report: Execute Trade Date: 4/10/2003 9:23 AM
RU e-st Case Study 6

Table of Contents
1. Use Case Name: Execute Trade 4
1.1 Brief Description 4

2. Flow of Events 4
2.1 Basic Flow 4
2.2 Sub-Flows 5
2.2.1 Verify That Cash Is Available 5
2.3 Alternative Flows 5
2.3.1 Limit Sell Order (Non-retirement Accounts only) 5
2.3.2 Market Sell Order (Non-retirement or Retirement Accounts) 5
2.3.3 Market Buy Order (Non-retirement or Retirement Accounts) 5
2.3.4 Transfer Order (Retirement Accounts Only) 5
2.3.5 Customer Executes More Trades 5
2.3.6 Account Not Operational 5
2.3.7 Unidentified Trading Customer 6
2.3.8 Unauthorized Trader 6
2.3.9 Quit 6
2.3.10 Trade Is Rejected 6
2.3.11 Market Trading System Unavailable 6
2.3.12 Insufficient Funds 6

3. Special Requirements 6
3.1 Reliable Cash Accounting 6

4. Preconditions 6
4.1 Trading Customer Has a Valid Trading Account 6
4.2 RU e-st Has Connection to Market Trading System 6

5. Postconditions 7
5.1 Accounts Are Adjusted 7

6. Extension Points 7

7. Relationships 7

8. Use-Case Diagrams 7

9. Other Diagrams 7

10. Scenarios 7
10.1 Success Scenarios 7
10.2 Failure Scenarios 7

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.2
Use Case Report: Execute Trade Date: 4/10/2003 9:23 AM
RU e-st Case Study 6

Use-Case Report: Execute Trade

1. Use Case Name: Execute Trade
1.1 Brief Description
Trading Customers buy, sell or transfer securities in their trading accounts. Immediately after a trade is
completed, Trading Customers receive a market trading confirmation containing a transaction id and the
trade results.

2. Flow of Events
2.1 Basic Flow
1. Customer Logs On.
The use case starts when the Trading Customer logs on. The system validates the customer id and
password. The system presents a list of available functions.

2. Customer Selects “Trade” Function.

The Trading Customer chooses to “Trade.” The system displays the customer’s Trading account
List.

3. Customer Selects account.

The Trading Customer selects a trading account. The system presents the Trading Account
Display for the selected trading account. The system displays available types of trade orders, based
on the trading account type.

4. Customer Performs Trade

4.1 Prepare To Trade
The Trading Customer selects a Limit Buy Order (Non-retirement Account) trade
order type.
The Trading Customer enters the Asset Limit Purchase information.
Perform Sub-Flow 2.2.1 – Verify That Cash Is Available.
Note: The Market Trading System must comply with the specified limit. This may result in
a partial purchase because there were no takers for the total order in the market. Also
the Trading System might be able to purchase some or all the requested shares at a price
lower than or equal to the limit.

4.2 Initiate Trade

The system sends the Market Trading Request to the Market Trading System.

4.3 Make Trade

The system presents the transaction reference identifier to the Trading Customer.
The system debits or credits the trading account based on the assumed sale price. The
system receives the Market Trading Confirmation from the Market Trading System. The
system re-debits or re-credits the trading account based on the actual trade price. The
system calculates fees and debits the trading account by subtracting the fees from the
cash in the trading account. The system displays the Market Trading Confirmation to the
Trading Customer.

5. Customer Logs Off .

The Trading Customer logs off the system. The use case ends.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.2
Use Case Report: Execute Trade Date: 4/10/2003 9:23 AM
RU e-st Case Study 6

2.2 Sub-Flows

2.2.1 Verify That Cash Is Available

The system calculates the total cost of the transaction (for Buy: number of shares*price + load +
commission; for Transfer: load + commission) for compliance with the Account Cash Minimum Business
Rule.

If there is sufficient cash in the trading account to comply with the rule, the use case resumes at the point in
the alternative flow from whence it came.

If the system determines that there is not enough cash in the trading account, the system notifies the
Trading Customer that the transaction is not possible.
2.3 Alternative Flows

2.3.1 Limit Sell Order (Non-retirement Accounts only)

In Step 4.1 of the Basic Flow, if the Trading Customer selects Limit Sell Order – Non-retirement
Account, then the Trading Customer enters the Asset Limit Sale information.
The use case resumes at Step 4.2 in the Basic Flow.
Note: The Trading System might be able to partially sell the order because there may be no takers for all
the shares at the limit price. Also, the Trading System might be able to sell some or all the shares at a price
equal to or higher than the limit.
2.3.2 Market Sell Order (Non-retirement or Retirement Accounts)
In Step 4.1 of the Basic Flow, if the Trading Customer selects Market Sell Order – Non-retirement or
Retirement Account, then the Trading Customer enters the Asset Sale information.
Perform Sub-Flow 2.2.1 – Verify That Cash Is Available.
The use case resumes at Step 4.2 in the Basic Flow.
2.3.3 Market Buy Order (Non-retirement or Retirement Accounts)
In Step 4.1 of the Basic Flow, if the Trading Customer selects Market Buy Order – Non-retirement or
Retirement Account, then the Trading Customer enters the Asset Purchase information.
Perform Sub-Flow 2.2.1 – Verify That Cash Is Available.
The use case resumes at Step 4.2 in the Basic Flow.
2.3.4 Transfer Order (Retirement Accounts Only)
In Step 4.1 of the Basic Flow, if the Trading Customer selects Transfer Order – Retirement Accounts
Only, then the Trading Customer enters the Dollar Transfer information.
Perform Sub-Flow 2.2.1 – Verify That Cash Is Available to assess compliance with the minimum cash rule
because load and fee costs are deducted from the cash asset.
The system sends the buy and sell Output Market-Trading Requests to the Market Trading System.
The use case resumes at Step 4.2 in the Basic Flow.
Note: The dollar transfer is done by selling a dollar amount of one mutual fund and buying the same dollar
amount of another mutual fund, both funds already present in the trading account.
2.3.5 Customer Executes More Trades
In Step 5 of the Basic Flow, if the Trading Customer wishes to begin a new transaction, the use case
resumes at Step 3 in the Basic Flow.

2.3.6 Account Not Operational

In Step 3, Customer Selects Account, in the Basic Flow, if the trading account status is not operational, the
system notifies the Trading Customer that no trades are permitted on this trading account. The use case
resumes at Step 2, Customer Selects “Trade” Function, in the Basic Flow.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.2
Use Case Report: Execute Trade Date: 4/10/2003 9:23 AM
RU e-st Case Study 6

How often should you check to see if the status of the trading account has changed from operational to
nonoperational? The status could change without any trade happening because it depends on the value of
stock and other assets versus the amount of cash in the trading account. Right now, I’ve assumed that we
check only when the Trading Customer begins a transaction. Maybe we should check at other times too?
[This is a typical way to employ use cases. You may write your questions right down in the text, and when
you get your answers, you have to correct the text accordingly. Or you may assume one way and let the
reviewers decide; either the reviewers like it or they tell you how it should be changed.]

2.3.7 Unidentified Trading Customer

In Step 1, Customer Logs On, in the Basic Flow, if the system determines that the customer id and/or
password are not valid, an error message is displayed. The use case ends.

2.3.8 Unauthorized Trader

In Step 2, Customer Selects “Trade” Function, in the Basic Flow, if the system determines that the Trading
Customer is not authorized to execute trades, the system notifies the Trading Customer. The use case ends.

2.3.9 Quit
The RU e-st System allows the Trading Customer to quit at any time during the use case. All trades that are
in progress are cancelled. The use case ends.

2.3.10 Trade Is Rejected

In Step 4.3, Make Trade, in the Basic Flow, if the Market Trading System rejects the Market Trading
Request, the system notifies the Trading Customer that the trade is rejected. The use case continues at Step
3, Select Account, in the Basic Flow.

2.3.11 Market Trading System Unavailable

In Step 4.3, Make Trade, in the Basic Flow, if the system is unable to communicate with the Market
Trading System, the system informs the Trading Customer. The use case ends.

2.3.12 Insufficient Funds

If in Step 4.1 of the Basic flow it is determined that there are insufficient funds in the trading account to
perform the trade, the system notifies the Trading Customer that the transaction is not possible.
The use case resumes at Step 4.1, Prepare To Trade, in the Basic Flow.

3. Special Requirements
3.1 Reliable Cash Accounting
The RU e-st system shall round any changes to a trading account to the nearest penny.

4. Preconditions
4.1 Trading Customer Has a Valid Trading Account
The Trading Customer must have a valid trading account in the system in order to begin this use case.

4.2 RU e-st Has Connection to Market Trading System

The RU e-st system must have a connection to the Market Trading System in order to begin this use case.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.2
Use Case Report: Execute Trade Date: 4/10/2003 9:23 AM
RU e-st Case Study 6

5. Postconditions
5.1 Accounts Are Adjusted
At the end of this use case, the system leaves all trading accounts in a sound accounting state (there is no
extra money or lost money to the penny, and all changes can be explained).

6. Extension Points
None specified for this use case.

7. Relationships
The Actor starting this Use Case is:
Trading Customer
Actor(s) also involved in this Use Case:
Market Trading System

8. Use-Case Diagrams
None specified for this use case.

9. Other Diagrams
None specified for this use case.

10. Scenarios
10.1 Success Scenarios
Customer executes a Limit Buy: Basic Flow
Customer executes a Limit Sell: Basic Flow, Limit Sell Order
Customer executes a Market Buy: Basic Flow, Market Buy Order
Customer executes a Market Sell: Basic Flow, Market Sell Order
Customer executes a Transfer between accounts: Basic Flow, Transfer Order
Customer executes more trades: Basic Flow, Customer Executes More Trades
10.2 Failure Scenarios
Fail due to invalid login: Basic Flow, Unidentified Trading Customer
Fail due to Unauthorized trader: Basic Flow, Unauthorized Trader
Quit before execute: Basic Flow, Quit
Fail due to rejected trade: Basic Flow, Trade Is Rejected
Market Trading System Unavailable: Basic Flow, Market Trading System Unavailable
Fail due to insufficient funds in trading account: Basic Flow, Verify That Cash Is Available
Fail due to no active trading accounts: Basic Flow, No Trading Account
Fail due to trading account is not operational: Basic Flow, Account Not Operational

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 6.2
Use Case Report: Execute Trade Date: 4/10/2003 9:23 AM
RU e-st Case Study 6

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services Version: RUCS 7.1
Structured Use Case Model: RU e-st Date: November 15, 2002
RU e-st Case Study 7

RU e-st System

Structured Use-Case Model

Identify
Customer

Get News <<include>>

<<include>>

Execute Trade
<<extend>>

Execute Securities
Get Quote Execute Real Trade
Estate Trade

Trading Customer

[Note: Only the actor who initiates each use case is shown on the diagram. The other actors have been omitted from
this diagram for illustrative reasons. In the individual Use-Case Reports that follow, there are full local diagrams that
include all associations with actors.]

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7
Structured Use Case Model: RU e-st Date: November 15, 2000
RU e-st Case Study 7

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

RU e-st
Use-Case Report: Get Quote

Version 1.5

Introduction
This is an example of what a structured use case report might look like. This example shows the
Get Quote Use-Case Report after the first version has been structured using include and extend
relationships. The new version omits details that are now found in:
• Identify Customer Use-Case Report (included in Get Quote).
• Get News Use-Case Report (extends Get Quote).

In this example, we show the report as it might appear towards the end of its development
process.
There are many styles of writing use cases. We show one style here, based on the template and
guidelines for a use-case report in the Rational Unified Process.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.2
Use Case Report: Get Quote Date: 4/10/2003 9:25 AM
RU e-st Case Study 7

Revision History
Date Version Description Author
Jan 13, 2000 1.0 First draft J. Carlos Goti
Jan 15, 2000 1.0 First complete draft J. Carlos Goti
Nov. 15, 200 1.2 Revised for clarification J. Bell
Nov 17, 2000 1.3 Structured: include and extend J. Bell
Oct 30, 2001 1.4 Editorial changes B. Baker
Feb 4, 2003 1.5 Reformatted for McKinley updates. B. Baker
Added scenario list and additional quotes
alternative flow.
Apr 2, 2003 1.6 McKinley post-Beta changes B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.2
Use Case Report: Get Quote Date: 4/10/2003 9:25 AM
RU e-st Case Study 7

Table of Contents
Introduction 1

1. Use Case Name: Get Quote 4

1.1 Brief Description 4

2. Flow of Events 4
2.1 Basic Flow 4
2.2 Alternative Flows 4
2.2.1 Customer Gets Other Quotes 4
2.2.2 Quote System Unavailable 4
2.2.3 Unknown Trading Symbol 4
2.2.4 Quote System Cannot Locate Information 5
2.2.5 No Reply From User 5
2.2.6 Disconnected Web Session 5

3. Special Requirements 5

4. Preconditions 5
4.1 RU e-st Has Connection to Quote System 5

5. Postconditions 5

6. Extension Points 5
6.1 Optional Services 5

7. Relationships 5
7.1 Actors 5
7.2 Associations To Other Use Cases 6
7.3 Associations FROM other Use Cases 6

8. Use-Case Diagrams 7

9. Other Diagrams 7

10. Scenarios 7
10.1 Success Scenarios 7
10.2 Failure Scenarios 7

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.2
Use Case Report: Get Quote Date: 4/10/2003 9:25 AM
RU e-st Case Study 7

Use Case Report: Get Quote

1. Use Case Name: Get Quote
1.1 Brief Description
The Trading Customer can get current and historical information about the trading price of securities.

2. Flow of Events
2.1 Basic Flow
1. Customer Logs On.
The use case starts when the Trading Customer logs on.
Include Identify Customer use case to verify the Trading Customer’s identity.
The system presents a list of available functions.

2. Customer Selects “Get Quote” Function.

The Trading Customer chooses to “Get Quote.”
The system displays the list of trading symbols and names of securities on which it has quotes.

3. Customer Gets Quote.

The Trading Customer selects from the list of securities or enters the trading symbol for a security.
{Optional Services}

4. System Gets Quote from Quote System.

The system sends the trading symbol to the Quote System and receives the Quote System
Response.
The system presents the corresponding Quote Display (see fields to display in Supplementary
Specifications) to the Trading Customer.

5. Customer Logs Off .

The Trading Customer logs off the system. The use case ends.
2.2 Alternative Flows

2.2.1 Customer Gets Other Quotes

In Step 4, System Gets Quote From Quote System, in the Basic Flow, if the Trading Customer wishes to
get additional quotes, the use case resumes at Step 3, Customer Selects Security, in the Basic Flow.

2.2.2 Quote System Unavailable

In Step 3 of the Basic Flow, if the system is unable to communicate with the Quote System, the system
informs the Trading Customer. The use case ends.

2.2.3 Unknown Trading Symbol

In Step 3 of the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the
Trading Customer that the trading symbol is not recognizable. The use case continues at the beginning of
Step 3 in the Basic Flow.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.2
Use Case Report: Get Quote Date: 4/10/2003 9:25 AM
RU e-st Case Study 7

2.2.4 Quote System Cannot Locate Information

In Step 3 of the Basic Flow, if the Quote System responds that it does not have the requested information,
the system notifies the Trading Customer that the Quote System does not have information on the requested
security. The use case continues at the beginning of Step 3 in the Basic Flow.

2.2.5 No Reply From User

At any time during the use case, if the system asks for input from the Trading Customer and he/she does
not reply within 10 minutes, then a warning sound beeps.
If there still is no reply for fifteen more minutes, this session is closed down and the RU e-st system
terminates any transaction that is waiting for customer input. If a transaction is already in progress with a
Trading System, it is completed; a notation is made that the Transaction Confirmation was not delivered,
and a message is sent to the System Administrator to send a printed confirmation.
The use case ends.

2.2.6 Disconnected Web Session

At any time during the use case, if the Web-based connection is disconnected, then this session is closed
down and the RU e-st system terminates any transaction that is waiting for customer input. If a transaction
is already in progress with a Trading System, it is completed; a notation is made that the Transaction
Confirmation was not delivered, and a message is sent to the System Administrator to send a printed
confirmation.
The use case ends.

3. Special Requirements
None.

4. Preconditions
4.1 RU e-st Has Connection to Quote System
The RU e-st system must have a connection to the Quote System in order to begin this use case.

5. Postconditions
None.

6. Extension Points
6.1 Optional Services
This extension point {Optional Services} occurs in the Basic Flow.

7. Relationships
7.1 Actors
The Actor starting this use case is:
Trading Customer
Actor(s) also involved in this use case:
Quote System

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.2
Use Case Report: Get Quote Date: 4/10/2003 9:25 AM
RU e-st Case Study 7

7.2 Associations To Other Use Cases

Use cases included by this use case (outgoing Include associations)
Identify Customer
Use cases extended by this use case (outgoing Extend associations)
None

7.3 Associations FROM other Use Cases

Use cases including this Use Case (incoming Include associations)
None
Use cases extending this use case (incoming Extend associations)
Get News

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.2
Use Case Report: Get Quote Date: 4/10/2003 9:25 AM
RU e-st Case Study 7

8. Use-Case Diagrams

Identify
Customer

<<include>>

Get Quote
Quote System

Trading Customer

<<extend>>

Get News
News System

Figure 1: Local Use-Case Diagram for Get Quote Use Case

9. Other Diagrams
None specified for this use case.

10. Scenarios
10.1 Success Scenarios
Customer gets a quote: Basic Flow
Customer gets other quotes: Basic Flow, Customer Gets Other Quotes

10.2 Failure Scenarios

Invalid login: Basic Flow, Unidentified Trading Customer (See included use case Identify Customer)
Fraud attempt: Basic Flow, Suspect Theft (See included use case Identify Customer)
Host link down to Quote System: Basic Flow, Quote System Unavailable
Customer enters unknown trading symbol: Basic Flow, Unknown Trading Symbol
Quote system cannot obtain information: Basic Flow, Quote System Cannot Locate Information

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.2
Use Case Report: Get Quote Date: 4/10/2003 9:25 AM
RU e-st Case Study 7

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

RU e-st
Use-Case Report: Identify Customer

Version 1.2

Introduction
This is an example of what a use case report might look like. In this example, we show the report
for an abstract use case.
There are many styles of writing use cases. We show one style here, based on the template and
guidelines for a use-case report in the Rational Unified Process.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.3
Use-Case Report: Identify Customer Date: October 30, 2001
RU e-st Case Study 7

Revision History
Date Version Description Author
Nov. 15, 2000 1.0 New Use Case J. Bell
Oct 30, 2001 1.1 Editorial changes B. Baker
Feb 4, 2003 1.2 Reformatted for McKinley release. Added B. Baker
scenarios section and reworked alternative
flows.

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.3
Use-Case Report: Identify Customer Date: October 30, 2001
RU e-st Case Study 7

Table of Contents
Introduction 1

1. Use Case Name: Identify Customer 4

1.1 Brief Description 4

2. Flow of Events 4
2.1 Basic Flow 4
2.2 Alternative Flows 4
2.2.1 Unidentified Trading Customer 4
2.2.2 Suspect Theft 4

3. Special Requirements 4
3.1 Time to process customer id 4

4. Preconditions 4

5. Postconditions 4

6. Extension Points 4

7. Relationships 5
7.1 Actors 5
7.2 Associations TO other Use Cases 5
7.3 Associations FROM other Use Cases 5

8. Use-Case Diagrams 5

Figure 1: Local Use-Case Diagram 6

9. Other Diagrams 6

10. Scenarios 6

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.3
Use-Case Report: Identify Customer Date: October 30, 2001
RU e-st Case Study 7

Use-Case Report: Identify Customer

1. Use Case Name: Identify Customer
1.1 Brief Description
This use case describes how the RU e-st system verifies the identity of a Trading Customer.

2. Flow of Events
2.1 Basic Flow
1. Enter Customer Id.
The system prompts the Trading Customer to log into the system.
The Trading Customer enters their customer id.
2. Enter Password.
The system asks for the customer password.
The Trading Customer enters the password.
3. Validate Customer Id and Password.
The system validates the customer id and password.

2.2 Alternative Flows

2.2.1 Unidentified Trading Customer
In Step 3 of the Basic Flow, if the system determines that either the customer id or password is not valid,
the system displays an Invalid Login Message.
The use case ends.

2.2.2 Suspect Theft

In Step 3 of the basic flow, if the customer id is on the system’s list of stolen identification, the system
displays an Invalid Login Message.
The system records the date, time, and computer address from which the person tried to log on and sends a
message to the System Administrator.
The use case ends.

3. Special Requirements
3.1 Time to process customer id
The system shall respond within .5 seconds after the Trading Customer enters his/her customer id.

4. Preconditions
None specified for this use case.

5. Postconditions
None specified for this use case.

6. Extension Points
None specified for this use case.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.3
Use-Case Report: Identify Customer Date: October 30, 2001
RU e-st Case Study 7

7. Relationships
7.1 Actors
The Actor starting this use case is:
None.
Actor(s) also involved in this use case:
Trading Customer
System Administrator

7.2 Associations TO other Use Cases

Use Cases included by this use case (outgoing Include associations)
None
Use Cases extended by this use case (outgoing Extend associations)
None

7.3 Associations FROM other Use Cases

Use cases including this use case (incoming Include associations)
Execute Trade
Get Quote
Review Account
Use cases extending this use case (incoming Extend associations)
None

8. Use-Case Diagrams
[In most cases this would not show the base use cases since the included use case does not know which use cases
include it and it would take too much effort to maintain. They are included here to show its completed form for this
example.]

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.3
Use-Case Report: Identify Customer Date: October 30, 2001
RU e-st Case Study 7

Trading Customer

System Administrator

Identify Customer

<<include> <<include> <<include>

Get Quote Review Account

Execute Trade

Figure 1: Local Use-Case Diagram

9. Other Diagrams
None specified for this use case.

10. Scenarios
Refer to including use case.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

RU e-st
Use-Case Report: Get News

Version 1.2

Introduction
This is an example of what a structured use case report might look like. This example shows an abstract
use case, Get News, which extends Get Quote.
In this example, we show the report as it might appear towards the end of developing it.
There are many styles of writing use cases. We show one style here, based on the template and
guidelines for a use-case report in the Rational Unified Process.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.4
Use Case Report: Get News Date: October 30, 2001
RU e-st Case Study 7

Revision History
Date Version Description Author
Nov 15, 2000 1.0 New use case J. Bell
Oct 30, 2001 1.1 Editorial changes B. Baker
Feb 4, 2003 1.2 Reformatted for McKinley release. B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.4
Use Case Report: Get News Date: October 30, 2001
RU e-st Case Study 7

Table of Contents
Introduction 1

1. Use Case Name: Get News 4

1.1 Brief Description 4

2. Flow of Events 4
2.1 Basic Flow 4
2.2 Alternative Flows 4
2.2.1 News System Unavailable 4
2.2.2 News System Cannot Locate Information 4

3. Special Requirements 4
3.1 Timely Headline News Display 4

4. Preconditions 4
4.1 RU e-st Has Connection to News System 4

5. Postconditions 5

6. Extension Points 5

7. Relationships 5
7.1 Actors 5
7.2 Associations TO other Use Cases 5
7.3 Associations FROM other Use Cases 5

8. Use-Case Diagrams 6

9. Other Diagrams 6

10. Scenarios 6

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.4
Use Case Report: Get News Date: October 30, 2001
RU e-st Case Study 7

Use-Case Report: Get News

1. Use Case Name: Get News
1.1 Brief Description
The Trading Customer can get news headlines about a given security (stock or mutual fund).

2. Flow of Events
2.1 Basic Flow

This is an extension of the Get Quote Use Case. At extension point {Optional Services} of the basic flow,
the Trading Customer can also select "Get News."
1. Customer Selects “Get News” Function.
If the Trading Customer chooses to “Get News,” the system asks the Trading Customer to enter
the time period for which news is desired and the number of news items to get.
The Trading Customer enters the time period and number of news items.

2. Get Latest News for Trading Symbol.

The system sends the trading symbol to the News System and receives the News System
Response. The system displays Headline News Display (see fields to display in Supplementary
Specifications) to the Trading Customer.

The extended use case continues after the extension point {Optional Services}.

2.2 Alternative Flows

2.2.1 News System Unavailable

In Step 2, Get Latest News for Trading Symbol, in the Basic Flow, if the system is unable to communicate
with the News System, the system informs the Trading Customer.
The use case ends.

2.2.2 News System Cannot Locate Information

In Step 2 of the Basic Flow, if the News System responds that it does not have the requested information,
the system notifies the Trading Customer that the News System does not have information on the requested
security.
The use case ends.

3. Special Requirements

3.1 Timely Headline News Display

The RU e-st system must present the requested Headline News Display within two seconds after a Trading
Customer finishes requesting it.

4. Preconditions
4.1 RU e-st Has Connection to News System
The RU e-st system must have a connection to the News System in order to begin this use case.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.4
Use Case Report: Get News Date: October 30, 2001
RU e-st Case Study 7

5. Postconditions
None.

6. Extension Points
None.

7. Relationships
7.1 Actors
The Actor starting this use case is:
Trading Customer
Actor(s) also involved in this use case:
News System

7.2 Associations TO other Use Cases

Use cases included by this use case (outgoing Include associations)
None
Use cases extended by this use case (outgoing Extend associations)
Get Quote

7.3 Associations FROM other Use Cases

Use cases including this use case (incoming Include associations)
None
Use cases extending this use case (incoming Extend associations)
None

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.4
Use Case Report: Get News Date: October 30, 2001
RU e-st Case Study 7

8. Use-Case Diagrams

Trading Customer
News System
Get Quote

<<extend>>

Get News

Figure 1: Local Use-Case Diagram for Get News Use Case

9. Other Diagrams
None specified for this use case.

10. Scenarios
Customer gets News: Basic Flow (Get Quote), Basic Flow
News System Unavailable: Basic Flow (Get Quote), Basic Flow, News System Unavailable
Information Unavailable: Basic Flow (Get Quote), Basic Flow, News System Cannot Locate Information

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

Use-Case Report: Execute Trade

Version 1.4

Introduction
This is an example of what a use-case report might look like. There is much more detail in the
use-case report than there was in the step-by-step outline that was the first draft of the use case.
In this example, we show the report as it might appear in the middle its developing process.
There are some issues noted directly in the use case, as is typical of a use case under
development.
There are many styles of writing use cases. We show one style here, based on the template and
guidelines for a use-case report in the Rational Unified Process.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.5
Use Case Report: Execute Trade Date: February 5, 2003
RU e-st Case Study 7

Revision History
Date Version Description Author
Jan 13, 2000 1.0 First draft J. Carlos Goti
Jan 15, 2000 1.0 First complete draft J. Carlos Goti
Nov 15, 2000 1.2 Revised for clarification J. Bell
Oct 30, 2001 1.3 Editorial changes B. Baker
Feb 5, 2003 1.4 Reformatted for McKinley release B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.5
Use Case Report: Execute Trade Date: February 5, 2003
RU e-st Case Study 7

Table of Contents
1. Use Case Name: Execute Trade 4
1.1 Brief Description 4

2. Flow of Events 4
2.1 Basic Flow 4
2.2 Sub-Flows 4
2.3 Alternative Flows 4
2.3.1 Customer Executes More Trades 4
2.3.2 Account Not Operational 4
2.3.3 Unauthorized Trader 5
2.3.4 Quit 5

3. Special Requirements 5
3.1 Reliable Cash Accounting 5

4. Preconditions 5

5. Postconditions 5
5.1 Accounts Are Adjusted 5

6. Extension Points 5

7. Relationships 5
7.1 Actors 5
7.2 Associations TO other Use Cases 5
7.3 Associations FROM other Use Cases 6
7.4 Generalizations 6

8. Use-Case Diagrams 6

9. Other Diagrams 6

10. Scenarios 6

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.5
Use Case Report: Execute Trade Date: February 5, 2003
RU e-st Case Study 7

Use-Case Report: Execute Trade

1. Use Case Name: Execute Trade
1.1 Brief Description
This abstract use case describes how a Trading Customers can buy, sell or transfer ay type of asset in their
trading accounts. Immediately after a trade is completed, Trading Customers receive a confirmation of the
trade result for the transaction. Trading customers also receive a transaction summary for the session.

2. Flow of Events
2.1 Basic Flow
1. Customer Logs On.
The use case starts when the Trading Customer logs on.
Include Identify Customer use case to verify the Trading Customer’s identity.
The system presents a list of available functions.

2. Customer Selects “Trade” Function.

The Trading Customer chooses to “Trade.”
The system displays the customer’s Trading account List.

3. Customer Selects account.

The Trading Customer selects a trading account.
The system presents the Trading Account Display for the selected trading account.
The system displays available types of trade orders, based on the trading account type.

4. {Customer Performs Trade}1

5. Display Summary
The System Displays a Summary of all trade orders.
Trading Customer logs off the system.
The use case ends.
2.2 Sub-Flows
None.
2.3 Alternative Flows

2.3.1 Customer Executes More Trades

In Step 5 of the Basic Flow, if the Trading Customer wishes to begin a new transaction, the use case
resumes at Step 3 in the Basic Flow.

2.3.2 Account Not Operational

In Step 3, Customer Selects Account, in the Basic Flow, if the trading account status is not operational, the
system notifies the Trading Customer that no trades are permitted on this trading account. The use case
resumes at Step 2, Customer Selects “Trade” Function, in the Basic Flow.

1
This is a pure-abstract step – as indicated by the italics.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.5
Use Case Report: Execute Trade Date: February 5, 2003
RU e-st Case Study 7

How often should you check to see if the status of the trading account has changed from operational to
nonoperational? The status could change without any trade happening, because it depends on the value of
stock and other assets versus the amount of cash in the trading account. Right now, I’ve assumed that we
check only when the Trading Customer begins a transaction. Maybe we should check at other times too?
[This is a typical way to employ use cases. You may write your questions right down in the text, and when
you get your answers you have to correct the text accordingly. Or you may assume one way and let the
reviewers decide; either the reviewers like it or they tell you how it should be changed.]

2.3.3 Unauthorized Trader

In Step 2, Customer Selects “Trade” Function, in the Basic Flow, if the system determines that the Trading
Customer is not authorized to execute trades, the system notifies the Trading Customer. The use case ends.

2.3.4 Quit
The RU e-st System allows the Trading Customer to quit at any time during the use case. All trades that are
in progress are cancelled. The use case ends.

3. Special Requirements
3.1 Reliable Cash Accounting
The RU e-st system shall round any changes to a trading account to the nearest penny.

4. Preconditions
None.

5. Postconditions
5.1 Accounts Are Adjusted
At the end of this use case, the system leaves all trading accounts in a sound accounting state (there is no
extra money or lost money to the penny, and all changes can be explained).

6. Extension Points
None specified for this use case.

7. Relationships
7.1 Actors
The Actor starting this use case is:
None
Actor(s) also involved in this use case:
Trading Customer

7.2 Associations TO other Use Cases

Use cases included by this use case (outgoing Include associations)
Identify Customer
Use cases extended by this use case (outgoing Extend associations)
None

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.5
Use Case Report: Execute Trade Date: February 5, 2003
RU e-st Case Study 7

7.3 Associations FROM other Use Cases

Use cases including this use case (incoming Include associations)
None
Use cases extending this use case (incoming Extend associations)
None

7.4 Generalizations
Use cases that are children of this use case (incoming generalization associations)
Execute Securities Trade, Execute Real Estate Trade
Use cases that are parents of this use case (outgoing generalization associations)
None

8. Use-Case Diagrams

Identify
Customer

<<include>>

Real Estate
Trading System Execute
Trade Market
Trading System

Execute Real
Estate Trade Execute Securities
Trade

Trading Customer

Figure 1: Local Use-Case Diagram for Execute Trade Use Case

9. Other Diagrams
None specified for this use case.

10. Scenarios
See concrete (child) use cases.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

Use-Case Report: Execute Securities Trade

Version 1.4

Introduction
This is an example of what a use case report might look like. There is much more detail in the
use-case report than there was in the step-by-step outline that was the first draft of the use case.
In this example, we show the report as it might appear in the middle its developing process.
There are some issues noted directly in the use case, as is typical of a use case under
development.
There are many styles of writing use cases. We show one style here, based on the template and
guidelines for a use-case report in the Rational Unified Process.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.6
Use-Case Report: Execute Securities Trade Date: November 15, 2003
RU e-st Case Study 7

Revision History
Date Version Description Author
Jan 13, 2000 1.0 First draft J. Carlos Goti
Jan 15, 2000 1.0 First complete draft J. Carlos Goti
Nov 15, 2000 1.2 Revised for clarification J. Bell
Oct 30, 2001 1.3 Editorial changes B. Baker
Feb 5, 2003 1.4 Added scenario list. Restructured to use sub B. Baker
flows; and alternative flows for repeating
behavior.

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.6
Use-Case Report: Execute Securities Trade Date: November 15, 2003
RU e-st Case Study 7

Table of Contents
1. Use Case Name: Execute Trade 4
1.1 Brief Description 4

2. Flow of Events 4
2.1 Basic Flow 4
2.2 Sub-Flows 5
2.2.1 Verify That Cash Is Available 5
2.3 Alternative Flows 5
2.3.1 Limit Sell Order (Non-retirement Accounts only) 5
2.3.2 Market Sell Order (Non-retirement or Retirement Accounts) 5
2.3.3 Market Buy Order (Non-retirement or Retirement Accounts) 5
2.3.4 Transfer Order (Retirement Accounts Only) 5
2.3.5 Unidentified Trading Customer 5
2.3.6 Trade Is Rejected 5
2.3.7 Market Trading System Unavailable 6
2.3.8 Insufficient Funds 6

3. Special Requirements 6

4. Preconditions 6
4.1 Trading Customer has a valid trading account 6
4.2 RU e-st Has Connection to Market Trading System 6

5. Postconditions 6

6. Extension Points 6

7. Relationships 6
7.1 Actors 6
7.2 Associations TO other Use Cases 6
7.3 Associations FROM other Use Cases 6
7.4 Generalizations 7

8. Use-Case Diagrams 7

9. Other Diagrams 7

10. Scenarios 7

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.6
Use-Case Report: Execute Securities Trade Date: November 15, 2003
RU e-st Case Study 7

Use-Case Report: Execute Securities Trade

1. Use Case Name: Execute Trade
1.1 Brief Description
Trading Customers buy, sell, or transfer securities in their trading accounts. Immediately after a trade is
completed, Trading Customers receive a market trading confirmation containing a transaction id and the
trade results.
The Trading Customer also receives a transaction summary for the session.

2. Flow of Events
2.1 Basic Flow
1. Customer Logs On.

2. Customer Selects “Trade” Function.

3. Customer Selects account.

4. {Customer Performs Trade}

4.1 Prepare To Trade
The Trading Customer selects a Limit Buy Order (Non-retirement Account) trade
order type.
The Trading Customer enters the Asset Limit Purchase information.
Perform Sub-Flow 2.2.1 – Verify That Cash Is Available.
Note The Market Trading System must comply with the specified limit. This may result in
a partial purchase because there were no takers for the total order in the market. Also
the Trading System might be able to purchase some or all the requested shares at a price
lower than or equal to the limit.

4.2 Initiate Trade

The system sends the Market Trading Request to the Market Trading System.

4.3 Make Trade

The system presents the transaction reference identifier to the Trading Customer.
The system debits or credits the trading account based on the assumed sale price. The
system receives the Market Trading Confirmation from the Market Trading System. The
system re-debits or re-credits the trading account based on the actual trade price. The
system calculates fees and debits the trading account by subtracting the fees from the
cash in the trading account. The system displays the Market Trading Confirmation to the
Trading Customer.

5. Display Summary.
In addition to the steps described in the parent, the system offers the option to e-mail the summary
to the Trading Customer’s email account that is on file.
The Trading Customer selects to have the summary emailed.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.6
Use-Case Report: Execute Securities Trade Date: November 15, 2003
RU e-st Case Study 7

2.2 Sub-Flows

2.2.1 Verify That Cash Is Available

If the type of trade order is Market Buy, Limit Buy, or Transfer, then the system calculates the total cost
of the transaction (for Buy: number of shares*price + load + commission; for Transfer: load + commission)
for compliance with the Account Cash Minimum Business Rule.

If there is sufficient cash in the trading account to comply with the rule, the use case resumes at the point in
the alternative flow from whence it came.

If the system determines that there is not enough cash in the trading account, the system notifies the
Trading Customer that the transaction is not possible.
2.3 Alternative Flows

2.3.1 Limit Sell Order (Non-retirement Accounts only)

In Step 4.1 of the Basic Flow, if the Trading Customer selects Limit Sell Order – Non-retirement
Account, then the Trading Customer enters the Asset Limit Sale information.
The use case resumes at Step 4.2 in the Basic Flow.
Note: The Trading System may be able to partially sell the order because there might be no takers for all
the shares at the limit price. Also, the Trading System might be able to sell some or all the shares at a price
equal to or higher than the limit.
2.3.2 Market Sell Order (Non-retirement or Retirement Accounts)
In Step 4.1 of the Basic Flow, if the Trading Customer selects Market Sell Order – Non-retirement or
Retirement Account, then the Trading Customer enters the Asset Sale information.
Perform Sub-Flow 2.2.1 – Verify That Cash Is Available.
The use case resumes at Step 4.2 in the Basic Flow.
2.3.3 Market Buy Order (Non-retirement or Retirement Accounts)
In Step 4.1 of the Basic Flow, if the Trading Customer selects Market Buy Order – Non-retirement or
Retirement Account, then the Trading Customer enters the Asset Purchase information.
Perform Sub-Flow 2.2.1 – Verify That Cash Is Available.
The use case resumes at Step 4.2 in the Basic Flow.
2.3.4 Transfer Order (Retirement Accounts Only)
In Step 4.1 of the Basic Flow, if the Trading Customer selects Transfer Order – Retirement Accounts
Only, then the Trading Customer enters the Dollar Transfer information.
Perform Sub-Flow 2.2.1 – Verify That Cash Is Available to assess compliance with the minimum cash rule
because load and fee costs will be deducted from the cash asset.
The system sends the buy and sell Output Market-Trading Requests to the Market Trading System.
The use case resumes at Step 4.2 in the Basic Flow.
Note: The dollar transfer is done by selling a dollar amount of one mutual fund and buying the same dollar
amount of another mutual fund, both funds already present in the trading account.
2.3.5 Unidentified Trading Customer
In Step 1, Customer Logs On, in the Basic Flow, if the system determines that the customer id or password
is not valid, an error message is displayed. The use case ends.

2.3.6 Trade Is Rejected

In Step 4.3, Make Trade, in the Basic Flow, if the Market Trading System rejects the Market Trading
Request, the system notifies the Trading Customer that the trade is rejected. The use case continues at Step
3, Select Account, in the Basic Flow.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.6
Use-Case Report: Execute Securities Trade Date: November 15, 2003
RU e-st Case Study 7

2.3.7 Market Trading System Unavailable

In Step 4.3, Make Trade, in the Basic Flow, if the system is unable to communicate with the Market
Trading System, the system informs the Trading Customer. The use case ends.

2.3.8 Insufficient Funds

If in Step 4.1 of the Basic flow it is determined that there are insufficient funds in the trading account to
perform the trade, the system notifies the Trading Customer that the transaction is not possible.
The use case resumes at Step 4.1 Prepare To Trade, in the Basic Flow.

3. Special Requirements
No additional special requirements

4. Preconditions
4.1 Trading Customer has a valid trading account
The Trading Customer must have a valid trading account in the system in order to begin this use case.

4.2 RU e-st Has Connection to Market Trading System

The RU e-st system must have a connection to the Market Trading System in order to begin this use case.

5. Postconditions
No additional special requirements.

6. Extension Points
None specified for this use case.

7. Relationships
7.1 Actors
The Actor starting this use case is:
Trading Customer
Actor(s) also involved in this use case:
Market Trading System

7.2 Associations TO other Use Cases

Use cases included by this use case (outgoing Include associations)
None
Use cases extended by this use case (outgoing Extend associations)
None

7.3 Associations FROM other Use Cases

Use cases including this use case (incoming Include associations)
None

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.6
Use-Case Report: Execute Securities Trade Date: November 15, 2003
RU e-st Case Study 7

Use cases extending this use case (incoming Extend associations)

None

7.4 Generalizations
Use cases that are children of this use case (incoming generalization associations)
None
Use cases that are parents of this use case (outgoing generalization associations)
Execute Trade
8. Use-Case Diagrams

Identify Customer

<<include>>

Real Estate Market

Trading System Trading System
Execute Trade

Execute Real Estate Trade Execute Securities Trade

Trading Customer

Figure 1: Local Use-Case Diagram for Execute Securities Trade Use Case

9. Other Diagrams
None specified for this use case.

10. Scenarios
Limit Buy: Basic Flow
Limit Sell: Basic Flow, Limit Sell Order
Market Buy: Basic Flow, Market Buy Order
Market Sell: Basic Flow, Market Sell Order
Transfer: Basic Flow, Transfer Order
Invalid login: Basic Flow, Unidentified Trading Customer
Unauthorized trader: Basic Flow, Unauthorized Trader
Quit before execute: Basic Flow, Quit

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.6
Use-Case Report: Execute Securities Trade Date: November 15, 2003
RU e-st Case Study 7

Trade rejected: Basic Flow, Trade Is Rejected

Market Trading System Unavailable: Basic Flow, Market Trading System Unavailable
Insufficient funds: Basic Flow, Insufficient Funds
No trading accounts: Basic Flow, No Trading Account
Account not operational: Basic Flow, Account Not Operational
Customer Executes More Trades: Basic Flow, Customer Executes More Trades

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

Use-Case Report: Execute Real Estate Trade

Version 1.2

Introduction
This is an example of what a use case report might look like. There is much more detail in the
use-case report than there was in the step-by-step outline that was the first draft of the use case.
In this example, we show the report as it might appear in the middle its developing process.
There are some issues noted directly in the use case, as is typical of a use case under
development.
There are many styles of writing use cases. We show one style here, based on the template and
guidelines for a use-case report in the Rational Unified Process.

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.7
Use-Case Report: Execute Real Estate Trade Date: November 15, 2003
RU e-st Case Study 7

Revision History
Date Version Description Author
Nov 17, 2001 1.0 First draft J. Carlos Goti
Oct 30, 2002 1.1 Editorial changes B. Baker
Feb 5, 2003 1.2 Added scenario list. Restructured to use sub B. Baker
flows; and alternative flows for repeating
behavior.

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.7
Use-Case Report: Execute Real Estate Trade Date: November 15, 2003
RU e-st Case Study 7

Table of Contents
1. Use Case Name: Execute Trade 4
1.1 Brief Description 4

2. Flow of Events 4
2.1 Basic Flow 4
2.2 Sub-Flows 4
2.3 Alternative Flows 5
2.3.1 Real Estate Buy Order 5
2.3.2 Real Estate Accept Sale Order 5
2.3.3 Real Estate Accept Buy Order 5
2.3.4 Real Estate Cancel Order 5
2.3.5 Real Estate Trading Request Is Rejected 5
2.3.6 Real Estate Exchange System Unavailable 5

3. Special Requirements 5

4. Preconditions 5
4.1 RU e-st Has Connection to Real Estate Exchange System 5

5. Postconditions 6

6. Extension Points 6

7. Relationships 6
7.1 Actors 6
7.2 Associations TO other Use Cases 6
7.3 Associations FROM other Use Cases 6
7.4 Generalizations 6

8. Use-Case Diagrams 7

9. Other Diagrams 7

10. Scenarios 7

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.7
Use-Case Report: Execute Real Estate Trade Date: November 15, 2003
RU e-st Case Study 7

Use-Case Report: Execute Securities Trade

1. Use Case Name: Execute Trade
1.1 Brief Description
Trading Customers buy, sell or transfer real estate property in their accounts. Trading Customers place an
order to buy or sell a specific piece of property and the transaction is submitted to the Real Estate Exchange
System. The trade is probably not completed in a single trading because buying or selling real estate may
take weeks or months. The offer to buy or sell remains in effect until the Trading Customer accepts a trade
or cancels the offer. Trading Customers receive a trading confirmation containing a transaction detail and
the trade results (if any). The Trading Customer also receives a transaction summary for the session.

2. Flow of Events
2.1 Basic Flow
1. Customer Logs On

2. Customer Selects “Trade” Function

3. Customer Selects account

4. {Customer Performs Trade}

4.1 Prepare To Trade
The Trading Customer selects Real Estate Sell Order.
The system prompts the Trading Customer to enter the Real Estate Sale Information,
Trading Customer enters Real Estate Sale Information.
The system prepares a Real Estate Trading Request for the Sell Order.
[What information is needed for a Real Estate Sell Order? What information is needed
for any of these Real Estate Orders? We are new in the Real Estate business so we need
to find domain experts who will help us with the details for this use case.]

4.2 Initiate Trade Order

The system sends the Real Estate Trading Request to the Real Estate Exchange System,
and receives a Trading Confirmation from the Real Estate Exchange.

4.3 Adjust Account

If the trade order type was Real Estate Accept Sale Order or Real Estate Accept Buy
Order, the system debits or credits the account based on the actual trade price.
The system subtracts commissions and fees from the cash in the account.

4.4 Confirm Trade Order

The system presents the transaction reference identifier and the Trading Confirmation to
the Trading Customer.
5. Display Summary

2.2 Sub-Flows
None.

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.7
Use-Case Report: Execute Real Estate Trade Date: November 15, 2003
RU e-st Case Study 7

2.3 Alternative Flows

2.3.1 Real Estate Buy Order

In Step 4.1 of the Basic Flow, if the Trading Customer selects Real Estate Buy Order, then the Trading
Customer enters Real Estate Purchase Information. The system prepares a Real Estate Trading Request for
the Buy Order. The use case resumes at Step 4.2 of the Basic Flow.
2.3.2 Real Estate Accept Sale Order
In Step 4.1 of the Basic Flow, if the Trading Customer selects Real Estate Accept Sale Order, the Trading
Customer enters Real Estate Accept Sale Information. The system prepares a Real Estate Trading Request
for the Accept Sale Order. The use case resumes at Step 4.2 of the Basic Flow.
2.3.3 Real Estate Accept Buy Order
In Step 4.1 of the Basic Flow, if the Trading Customer selects Real Estate Accept Buy Order, the Trading
Customer enters Real Estate Accept Purchase Information. The system calculates the total cost of the
transaction (property price + commission) for compliance with the Account Cash Minimum Business Rule.
If there is sufficient cash or approved loan value in the account to comply with the rule, the system prepares
a Real Estate Trading Request for the Accept Buy Order. The use case resumes at Step 4.2 of the Basic
Flow.

If the system determines that there is not enough cash or approved loan value in the account, the system
notifies the Trading Customer that the transaction is not possible. The use case resumes at Step 4.1 of the
Basic Flow.

2.3.4 Real Estate Cancel Order

In Step 4.1 of the Basic Flow, if the Trading Customer selects Real Estate Cancel Order, then the system
prompts the Trading Customer to confirm the desire to cancel the transaction. If the Trading Customer
confirms, the system prepares a Real Estate Trading Request for canceling the indicated real estate order.
The use case resumes at Step 4.2 of the Basic Flow.

If the Trading Customer reconsiders and declines to cancel the Real Estate Order, then the use case resumes
at Step 4.1 of the Basic Flow.

2.3.5 Real Estate Trading Request Is Rejected

In Step 4.2 of the Basic Flow, if the Real Estate Exchange System rejects the Real Estate Trading Request,
the system notifies the Trading Customer that the trade is rejected. The use case continues at Step 5,
Customer Begins New Transaction, in the Basic Flow.

2.3.6 Real Estate Exchange System Unavailable

In Step 4.2 of the Basic Flow, if the system is unable to communicate with the Real Estate Exchange
System, the system informs the Trading Customer. The use case ends.

3. Special Requirements
No additional special requirements

4. Preconditions
4.1 RU e-st Has Connection to Real Estate Exchange System
The RU e-st system must have a connection to the Real Estate Exchange System in order to begin this use
case.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.7
Use-Case Report: Execute Real Estate Trade Date: November 15, 2003
RU e-st Case Study 7

5. Postconditions
No additional special requirements

6. Extension Points
None specified for this use case.

7. Relationships
7.1 Actors
The Actor starting this Use Case is:
Trading Customer
Actor(s) also involved in this Use Case:
Real Estate Exchange System

7.2 Associations TO other Use Cases

Use Cases included by this Use Case (outgoing Include associations)
None
Use Cases extended by this Use Case (outgoing Extend associations)
None

7.3 Associations FROM other Use Cases

Use Cases including this Use Case (incoming Include associations)
None
Use Cases extending this Use Case (incoming Extend associations)
None

7.4 Generalizations
Use Cases that are children of this Use Case (incoming generalization associations)
None
Use Cases that are parents of this Use Case (outgoing generalization associations)
Execute Trade

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.7
Use-Case Report: Execute Real Estate Trade Date: November 15, 2003
RU e-st Case Study 7

8. Use-Case Diagrams

Identify Customer

<<include>>

Real Estate Market

Trading System Trading System
Execute Trade

Execute Real Estate Trade Execute Securities Trade

Trading Customer

Figure 1: Local Use-Case Diagram for Execute Real Estate Trade Use Case

9. Other Diagrams
None specified for this use case.

10. Scenarios
Sell Real Estate: Basic Flow
Buy Real Estate: Basic Flow, Real Estate Buy Order
Accept Sale: Basic Flow, Real Estate Accept Sale Order
Accept Buy: Basic Flow, Real Estate Accept Buy Order
Cancel Order: Basic Flow, Real Estate Cancel Order
Trade Rejected: Basic Flow, Real Estate Trading Request is Rejected
Real Estate System Unavailable: Basic Flow, Real Estate System Unavailable
Invalid login: Basic Flow, Unidentified Trading Customer
Unauthorized trader: Basic Flow, Unauthorized Trader
Quit before execute: Basic Flow, Quit
Account not operational: Basic Flow, Account Not Operational
Customer Executes More Trades: Basic Flow, Customer Executes More Trades

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 7.7
Use-Case Report: Execute Real Estate Trade Date: November 15, 2003
RU e-st Case Study 7

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

Supplementary Specification

Version 1.3

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

Revision History
Date Version Description Author
Mar 28, 2001 1.0 Added Business Rules and Inputs/Outputs J. Carlos Goti
November 17, 2001 1.2 Additions and reorganization J. Bell
October 30, 2002 1.3 Editorial changes B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

Table of Contents
1. Introduction 5
1.1 Purpose 5
1.2 Scope 5
1.3 Definitions, Acronyms and Abbreviations 5
1.4 References 5
1.5 Overview 5

2. Functionality 5
2.1 Localization 5
2.2 Business Rules 6
2.2.1 Account Cash Minimum 6
2.2.2 Limit Order Allowable Accounts 6
2.2.3 Market Order Allowable Accounts 6
2.2.4 RU e-st terms and conditions 6
2.2.5 Transaction Fees 6

3. Usability 6
3.1 Browser compatibility 6
3.2 Access to information 6
3.3 Online tutorial 6

4. Reliability 6
4.1 Availability 6
4.2 Timeliness and Accuracy 7

5. Performance 7
5.1 Response Time 7

6. Supportability 7
6.1 Installability 7

7. Design Constraints 7

8. Online User Documentation and Help System Requirements 7

9. Purchased Components 7

10. Interfaces 7
10.1 Inputs 7
10.1.1 Asset Limit Purchase Information 7
10.1.2 Asset Limit Sale Information 8
10.1.3 Asset Purchase Information 8
10.1.4 Asset Sale Information 8
10.1.5 Dollar Transfer Information 8
10.1.6 New Account Information 8
10.1.7 News System Response 8
10.1.8 Quote System Response 9

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

10.2 Outputs 9
10.2.1 Account List 9
10.2.2 Headline News Display 9
10.2.3 Market Trading Confirmation 9
10.2.4 Market Trading Request 9
10.2.5 Account Display 10
10.2.6 Quote Display 10
10.2.7 Stock Yearly History Chart 10
10.3 Systems with Which to Interface 10
10.3.1 Quote System 10
10.3.2 Market Trading System 10
10.3.3 News System 10
10.3.4 Financial Network System 10
10.3.5 IRS Reporting System 11

11. Licensing Requirements 11

12. Legal, Copyright and Other Notices 11

13. Applicable Standards 11

13.1 NASD, SIPC rules 11

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

Supplementary Specification
1. Introduction

The purpose of this document is to collect, analyze and define the supplementary specifications for the RU
e-st system.

1.1 Purpose

This document records specifications that have general applicability to the RU e-st product with the
objective of achieving agreement of what the system does between stakeholders and developers.

1.2 Scope

This document is a record of specifications that affect the RU e-st product as a whole or large parts of it.

1.3 Definitions, Acronyms, and Abbreviations

See Glossary.

1.4 References

Vision document
Glossary
Use cases

1.5 Overview

This document contains the supplementary specifications, organized by type of requirement: Functionality,
Usability, Reliability, Performance, Supportability, Design Constraints, Documentation Requirements,
Purchased Components, Interfaces, Licensing Requirements, Legal Requirements, and Applicable
Standards.

2. Functionality

Functionality at a high level is documented in the Vision document. Detailed functional requirements are
primarily documented in the Use Case Reports for individual uses cases of the RU e-st system. Here we
record a localization requirement that pertains to all use cases and business rules for the RU e-st system.
2.1 Localization
The application allows the user to select a language preference of English, Spanish, French, German, or
Swedish. The application displays all information to the customer in their selected language.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

2.2 Business Rules

2.2.1 Account Cash Minimum

For each account that a customer has and independently of other accounts (with different asset values and a
cash asset), the cash asset in the account must be maintained at 10% of the total account value for the status
of the account to be “operational,” meaning that trade transactions are allowed.

RU e-st forecasts the cash value percentage of the account after a transaction proposed by the customer and
prevents the transaction from being executed if it would break this rule.

An account may break this rule without a customer transaction because of market value fluctuations. RU e-
st performs periodic checks and notifies customers of their accounts switched to probationary status
because of this reason, but in no case is a transaction allowed if the account is in probationary state or if the
transaction is estimated to place the account in probationary state.

If it is considered that a transaction will not cause the account to violate this rule, the transaction is allowed.
Once the Trading System returns the final results of the transaction, RU e-st recalculates the cash value
percent and places the account in probationary status if the rule is broken.
2.2.2 Limit Order Allowable Accounts
Limit orders for stock are only allowed on non-retirement accounts.
2.2.3 Market Order Allowable Accounts
Market orders for stock are only allowed on non-retirement accounts.
2.2.4 RU e-st Terms and Conditions
An account cannot be in operational state if the customer has not indicated that he/she agrees with the terms
and conditions.
2.2.5 Transaction Fees
When a transaction is confirmed by the Trading System, the fees are calculated and deducted from the cash
in the account. These monies are transferred to the RU e-st holdings.

3. Usability
3.1 Browser Compatibility
The application can run under either MS Internet Explorer or Netscape Navigator.

3.2 Access to Information

The user can gather all information related to their accounts on one screen.

3.3 Online Tutorial

The application provides an online tutorial for the customer.

4. Reliability
4.1 Availability
The application will be up and available 100 percent of the time during NYSE market hours. The
application should not be down for more than 15 minutes at any other time.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

4.2 Timeliness and Accuracy

The application must provide accurate market data that is no more than fifteen minutes old.

5. Performance

5.1 Response Time

A customer must receive status on their transaction within five seconds of placing the order. Even though
the transaction may not execute immediately, the customer should receive notification that the order has
been successfully accepted and is ready to be executed.

6. Supportability
6.1 Installability
The user does not have to install any additional software to use the application.

7. Design Constraints

TBD

8. Online User Documentation and Help System Requirements

TBD

9. Purchased Components

N/A

10. Interfaces

In this section the interfaces that must be supported by the application are specified. The first two
subsections record the contents of all inputs and outputs that RU e-st has to support/provide. Also, the list
of systems that RU e-st interfaces with is shown.

10.1 Inputs
Each of the following sections specifies the content for a particular kind of input to the RU e-st system.

10.1.1 Asset Limit Purchase Information

Components are (for the asset the customer wishes to acquire):
• Trading symbol
• Number of shares
• Limit price

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

10.1.2 Asset Limit Sale Information

Components are (for the asset the customer wishes to sell):
• Trading symbol
• Number of shares
• Limit price
10.1.3 Asset Purchase Information
Components are (for the asset the customer wishes to acquire):
• Trading symbol
• Number of shares

10.1.4 Asset Sale Information

Components are (for the asset the customer wishes to sell):
• Trading symbol
• Number of shares

10.1.5 Dollar Transfer Information

Components are:
• For the source account:
o Account id
o Trading symbol
o Dollar amount that they would like to transfer
• For the target account:
o Account id
o Trading symbol of the asset to which they are going to transfer the funds
10.1.6 New Account Information
Components are:
• Name
• Address
• Phone number
• E-mail address
• Social security number
• Date of birth
• Marital status
• Number of dependents
• Citizenship status
• Employment status
• Account operation type
• Account funding type
• The customer must also indicate that he/she agrees with RU e-st terms and conditions

10.1.7 News System Response

Components are:
• List of headlines for the news stories for the last six months that relate to a given security

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

10.1.8 Quote System Response

Components are:
• Current price
• Daily high price
• Daily low price
• Opening price
• Previous close
• Bid–ask price
• Fifty-two week range
• Percentage price change
• Volume
• Price/earnings ratio
• Earnings per share
• Dividend
• Yield
• Chart displaying the stock history for the last twelve months
10.2 Outputs
Each of the following sections specifies the content for a particular kind of output from the RU e-st
system. The name of each output gives the type of content of the output and (if not a display to the
end-user) the system to which the output is sent.
10.2.1 Account List
Components are:
• All accounts the customer has opened with RU e-st and for each:
o Account id
o Account type
o Account total
o Account alias
10.2.2 Headline News Display
• List of headlines for the news stories for the last six months that relate to a given security.

10.2.3 Market Trading Confirmation

Components are:
• Trading symbol
• Trade transaction type (buy or sell)
• Number of shares traded
• Executed price
• Date and time of the transaction
• Transaction id

10.2.4 Market Trading Request

Components are:
• Trading symbol
• Trade transaction type (buy or sell)
• Number of shares for requested trade
• Limit trade order price (a special code indicates “market” trade)
• Date and time of the transaction
• Transaction id

© Copyright IBM Corp. 2003 9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

10.2.5 Account Display

Components are:
• All securities the customer has in the non-retirement account showing for each one:
o Trading symbol
o Asset name
o Number of shares owned
o Asset total value
o Asset last transaction date
• Cash asset value
• Account total value
• Account status (operational or not)

10.2.6 Quote Display

Components are:
• Current price
• Daily high price
• Daily low price
• Opening price
• Previous close
• Bid – ask price
• Fifty-two week range
• Percentage price change
• Volume
• Price/earnings ratio
• Earnings per share
• Dividend
• Yield
• Chart displaying the stock history for the last twelve months

10.2.7 Stock Yearly History Chart

This chart shows the stock’s closing prices for the last fifty-two weeks.

10.3 Systems with Which to Interface

10.3.1 Quote System

This system provides market quotes based on trading symbols.
10.3.2 Market Trading System
The system performs the trade orders requested by RU e-st and communicates trade transaction results back
to RU e-st.
10.3.3 News System
The system provides news headlines linked to a particular trading symbol.

10.3.4 Financial Network System

The system provides the ability to transfer funds between RU e-st accounts and accounts external to
RU e-st, such as bank accounts or credit card accounts.

10 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

10.3.5 IRS Reporting System

The system accepts electronic reports of tax information.

11. Licensing Requirements

12. Legal, Copyright and Other Notices

TBD – Contracts and Legal Department

13. Applicable Standards

13.1 NASD, SIPC rules

The application must conform to all the rules of the NASD, SIPC, and any other securities trading
institutions that interface with the RU e-st system.
The application must conform to the rules of the Federal Trade Commission (FTC) and the Securities and
Exchange Commission (SEC).

© Copyright IBM Corp. 2003 11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services Version: RUCS 8
Supplementary Specification Date: October 30, 2002
RU e-st Case Study 8

12 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU e-st
Software Development Plan

Version 1.0

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Revision History
Date Version Description Author
6th Jan 2003 1.0 Initial version Bryon Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services Version: RUCS 9
Software Development Plan Date: 4/10/2003 9:32 AM
RU e-st Case Study 9

Table of Contents
1. Introduction..................................................................................................................................... 5
1.1 Purpose ................................................................................................................................... 5
1.2 Scope ...................................................................................................................................... 5
1.3 Definitions, Acronyms and Abbreviations ............................................................................. 5
1.4 References .............................................................................................................................. 5
1.5 Overview ................................................................................................................................ 5

2. Project Overview ............................................................................................................................ 6

2.1 Project Purpose, Scope, and Objectives ................................................................................. 6
2.2 Assumptions and Constraints ................................................................................................. 6
2.3 Project Deliverables................................................................................................................ 6
2.4 Evolution of the Software Development Plan ........................................................................ 6

3. Project Organization ....................................................................................................................... 7

3.1 Organizational Structure......................................................................................................... 7
3.2 External Interfaces.................................................................................................................. 7
3.3 Roles and Responsibilities...................................................................................................... 7

4. Management Process ...................................................................................................................... 8

4.1 Project Estimates .................................................................................................................... 8
4.2 Project Plan............................................................................................................................. 8
4.2.1 Phase Plan ...................................................................................................................... 8
4.2.2 Iteration Objectives ........................................................................................................ 9
4.2.3 Releases........................................................................................................................ 11
4.2.4 Project Schedule ........................................................................................................... 12
4.2.5 Project Resourcing ....................................................................................................... 13
4.2.5.1 Staffing Plan....................................................................................................................... 13
4.2.5.2 Resource Acquisition Plan ................................................................................................. 13
4.2.5.3 Training Plan...................................................................................................................... 13
4.2.6 Budget .......................................................................................................................... 14
4.3 Iteration Plans....................................................................................................................... 14
4.4 Project Monitoring and control............................................................................................. 14
4.4.1 Requirements Management Plan .................................................................................. 14
4.4.2 Schedule Control Plan .................................................................................................. 14
4.4.3 Budget Control Plan ..................................................................................................... 15
4.4.4 Quality Control Plan..................................................................................................... 15
4.4.5 Reporting Plan.............................................................................................................. 15
4.4.6 Measurement Plan ........................................................................................................ 15
4.5 Risk Management plan ......................................................................................................... 15
4.6 Close-out Plan ...................................................................................................................... 15

5. Technical Process Plans ................................................................................................................ 15

5.1 Development Case................................................................................................................ 15
5.2 Methods, tools and techniques.............................................................................................. 15
5.3 Infrastructure Plan ................................................................................................................ 15
5.4 Product Acceptance Plan ...................................................................................................... 15

6. Supporting Process Plans .............................................................................................................. 15

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 7. Additional plans ............................................................................................................................ 15

8. Annexes ........................................................................................................................................ 15

9. Index ............................................................................................................................................. 16

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services Version: RUCS 9
Software Development Plan Date: 4/10/2003 9:32 AM
RU e-st Case Study 9

Software Development Plan

1. Introduction
1.1 Purpose
The objective of this Software Development Plan is to define the development activities in terms
of the phases and iterations required for implementing a computerized stock trading system for
RU Financial Services.
1.2 Scope
This Software Development Plan describes the overall plan to be used by RU Financial Services
Information Systems for developing the RU e-st Stock Trading System for RU Financial Services.
The details of the individual iterations are described in the Iteration Plans.
The plans as outlined in this document are based upon the product requirements as defined in the
Vision Document [1].
1.3 Definitions, Acronyms and Abbreviations
See Glossary [4].
1.4 References

Applicable references are:

1. Vision for the RU e-st Stock Trading System, RUIT387, V1.0, RU Financial Services IT.
2. System Business Case for the RU e-st Stock Trading System, RUIT388, DRAFT, 1998,
RU Financial Services IT.
3. Stakeholder Requests Document for the RU e-st Stock Trading System, RUT389, V1.0,
1998, RU Financial Services IT.
4. Glossary for the RU e-st Stock Trading System, RUT406, V1.0, 1998, RU Financial
Services IT.
5. RU e-st Stock Trading System High Level Project Schedule, V1.0, 1999, RU Financial
Services IT.
6. Rational Unified Process, 1999, Rational Software Corp.
7. RU e-st Stock Trading System Cost Model and Analysis Report, RUIT390, V1.0 RU
Financial Services IT.
8. RU e-st Stock Trading System Risk List, RUT389, V1.0, RU Financial Services IT.
9. RU e-st Stock Trading System Development Case, RUT390, V1.0, RU Financial
Services IT.
10. RU Financial Services Software Process Website
11. RU e-st Stock Trading System E1 Iteration Plan, RUT391, V1.0, RU Financial Services
IT.
1.5 Overview
This Software Development Plan contains the following information:
Project Overview: provides a description of the project's purpose, scope, and objectives. It also
defines the deliverables that the project is expected to deliver.
Project Organization: describes the organizational structure of the project team.
Management Process: explains the estimated cost and schedule, defines the major phases and
milestones for the project, and describes how the project is monitored.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Technical Process Plans: provides an overview of the software development process, including
methods, tools and techniques to be followed.
Supporting Process Plans: this includes the configuration management plan.
2. Project Overview
2.1 Project Purpose, Scope, and Objectives
This Software Development Plan describes the overall plan to be used by RU Financial Services
Information Systems for developing the RU e-st Stock Trading System for RU Financial Services.
The details of the individual iterations are described in the Iteration Plans.
The plans as outlined in this document are based upon the product requirements as defined in the
Vision [1].
2.2 Assumptions and Constraints
The system is intended to replace the current system that runs on legacy hardware. The hardware
is scheduled to be decommissioned upon expiration of the maintenance contract expires in
December 2003. The system must be fully available by this date.
2.3 Project Deliverables

The following deliverables will be produced during the project:

• Software Development Plan

• Vision
• Use Cases
• Glossary
• Supplementary Specification
• Software Architecture Document
• Design Model
• Implementation Subsystem
• Build
• Test Package
• Change Requests
• Test Summary
• Release Notes
2.4 Evolution of the Software Development Plan
The Software Development Plan will be revised prior to the start of each Iteration phase.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services Version: RUCS 9
Software Development Plan Date: 4/10/2003 9:32 AM
RU e-st Case Study 9

3. Project Organization
3.1 Organizational Structure

3.2 External Interfaces

The Project Manager provides Status Assessment, as scheduled in this plan, to the IT Executive
stakeholder (see Vision [1]).
The project team also interacts with other stakeholders to solicit inputs and review of relevant
artifacts.
3.3 Roles and Responsibilities
The following table identifies the organizational units that are responsible for each of the
disciplines, workflow details, and supporting processes.

Role Responsibility

Project Manager As described in the Rational Unified Process [6]. Responsible for
managing the overall Project Management discipline. Leads the
extended Project Management Team.

Process Engineer Responsible for the project environment and providing process
related support for the teams in the project as defined in the
Environment discipline in Rational Unified Process. Participates
in an extended Project Management Team.

Configuration Manager/ Responsible for Configuration Control on the project and for
Change Control Manager exercising the RU Financial Services Change Request Process in
the project. Participates in an extended Project Management
Team.

Systems Engineering Team Leads the team primarily responsible for managing the Business
Lead Modeling and Requirements disciplines. Participates in an
extended Project Management Team.

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 Software Engineering Team Primarily responsible for the analysis and design and the
Lead Implementation disciplines. Participates in an extended Project
Management Team.

Test Team Lead Leading the team responsible for managing the Test discipline.
Participates in an extended Project Management Team.

Deployment Team Lead Leads the team responsible for installation activities and
infrastructure in the end-user environment. Participates in an
extended Project Management Team.

4. Management Process
4.1 Project Estimates
Project estimates are based on the RU e-st Stock Trading System Cost Model and Analysis Report
[7].
The RU e-st Stock Trading System is similar in complexity and architecture to the Commercial
Banking System, built by RU Financial Services in 2002. The RU e-st Stock Trading System
database is roughly 25% more complex, and the number and complexity of use cases suggests that
the system roughly 20% more complex overall. The time frame and effort estimates from this
report are the basis of the project budget and schedule.
4.2 Project Plan
4.2.1 Phase Plan
A Work Breakdown Structure is being prepared and will be provided in the next version of this
document.

The development of the RU e-st Stock Trading System is conducted using a phased
approach where multiple iterations occur within a phase. The phases and the relative
timeline is shown in the table below:

Phase No. of Start End

Iterations

Inception Phase 1 Week 1 Week 8

Elaboration Phase 1 Week 8 Week 15

Construction Phase 3 Week 15 Week 31

Transition Phase 2 Week 25 Week 32

Table 4.2.1 describes each phase and the major milestone that marks the completion of
the phase.

Phase Description Milestone

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services Version: RUCS 9
Software Development Plan Date: 4/10/2003 9:32 AM
RU e-st Case Study 9

Inception Phase The Inception Phase develops the product Business Case Review
requirements and establishes the business case for Milestone at the end of
the RU e-st Stock Trading System. The major use the phase marks the
cases are developed as well as the high level Go/No Go decision for
Software Development Plan. At the end of the the project.
Inception Phase, RU Financial Services will decide
whether to fund and proceed with the project based
upon the business case.

Elaboration Phase The Elaboration Phase analyzes the requirements The Architectural
and develops the architectural prototype. At the Prototype Milestone
completion of the Elaboration Phase, all use cases marks the end of the
selected for Release 1.0 will have completed Elaboration Phase. This
analysis and design. In addition, the high-risk use prototype signifies
cases for Release 2.0 will have been analyzed and verification of the major
designed. The architectural prototype tests the architectural components
feasibility and performance of the architecture that that comprise the R1.0
is required for Release 1.0. Release.

Construction Phase During the Construction Phase, remaining use cases The R2.0 Operational
are analyzed and designed. The Beta version for Capability Milestone
Release 1.0 is developed and distributed for marks the end of the
evaluation. The implementation and test activities Construction Phase.
to support the R1.0 and R2.0 releases are Release 2.0 software is
completed. ready for packaging.

Transition Phase The Transition Phase prepares the R1.0 and R2.0 The R2.0 Release
releases for distribution. It provides the required Milestone marks the end
support to ensure a smooth installation including of the Transition Phase.
user training. At this point all
capabilities, as defined in
the Vision Document [1],
are installed and available
for the users.

Table 4.2.1 Project Phases and Major Milestones

Each phase is split into development iterations as described in Section 4.3.

Section 4.2.4 illustrates the high-level project schedule showing phases, iterations, and major milestones.
The project duration is expected to be 7-8 months.

4.2.2 Iteration Objectives

Each phase consists of development iterations in which a subset of the system is

developed. In general, these iterations:

o Reduce technical risk.

o Provide early versions of a working system.
o Allow maximum flexibility in planning features for each release.
o Enable scope changes to be handled effectively within an iteration cycle.

© Copyright IBM Corp. 2003 9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 The following table describes the iterations along with associated milestones and
addressed risks.

Phase Iteration Description Associated Risks Addressed

Milestones

Inception Preliminary Defines business model, Business Case Clarifies user

Phase Iteration product requirements, Review requirements up front.
Software Development
Plan, and business case. Develops realistic
Software Development
Plans and scope.

Determines feasibility of
project from a business
point of view.

Elaboration E1 Iteration: Completes analysis and Architectural Architectural issues

Phase Develop design for all R1 use Prototype clarified.
Architectural cases. Develops the
Prototype architectural prototype for Technical risks
R1. mitigated.

Complete analysis and Early prototype for user

design for all high-risk R2 review.
use cases.

Construction C1 Iteration: Implement and test R1 R1 Beta All key features from a
Phase Develop R1 use cases to provide the user and architectural
Beta R1 Beta Version. prospective implemented
in the Beta.

User feedback prior to

release of R1.

C2 Iteration: Implement and test R1 Software R1 fully reviewed by

Develop R1 remaining R1 use cases, user community.
Release fix defects from Beta, and Product quality should
incorporate feedback be high.
from Beta. Develops the Defects minimized.
R1 system. Cost of quality reduced.

C3 Iteration: Design, implement, and R2 Software Quick release of R2

Develop R2 test R2 use cases. addresses customer
Release satisfaction.
Incorporate enhancements
and defects from R1. All key functionality
provided in System by
Develops the R2 system. R2 Release.

Phase Iteration Description Associated Risks Addressed

Milestones

10 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services Version: RUCS 9
Software Development Plan Date: 4/10/2003 9:32 AM
RU e-st Case Study 9

Transition T1 Iteration: Package, distribute, and R1 Released Two-stage release

phase R1 Release install R1 Release. minimizes defects.

Two-stage release
provides easier transition
for users.

T2 Iteration: Package, distribute, and R2 Released Two-stage release

R2 Release install R2 Release. minimizes defects.

Two-stage release
provides easier transition
for users.

4.2.3 Releases

This Software Development Plan addresses the first two releases of the RU e-st Stock
Trading System. Key features as defined in the Vision Document [1] are targeted for the
first two releases. All features critical to online stock trading are planned for the first
release (R1.0).

The planned content of the releases is expected to change as the project progresses. This
may be due to a number of business and technical factors. To accommodate the changes,
Rational RequisitePro is used to manage the product requirements and to keep track of
release content. In particular, benefit, effort, and risk attributes are used to determine
priority of product requirements and thus the target release.

It is anticipated that the RU e-st Stock Trading System will be released for general use
through two to four main releases.

Release 1 must contain as a minimum the basic functionality as listed below:

o Logon
o Get a Quote
o Execute a trade
o Interface to the Market Trading System and Quote System
o Administer customer accounts
o Report tax information to the customer and IRS

Release 2 should include:

o News updates to customer

o Manage investment portfolio

The functionality for Release 3 has not yet been determined. It is

anticipated that this release will contain enhancements to the existing
functionality.

© Copyright IBM Corp. 2003 11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 In addition, a Beta Release will precede the R1.0 Product Release.

4.2.4 Project Schedule

The high-level schedule showing project phases, iterations, and milestones is contained in the RU
e-st Stock Trading System High Level Project Schedule [5] as shown below.

Task Name Start Finish

Milestones Tue 12/1/02 Thu 6/24/03
Start Tue 12/1/02 Tue 12/1/02
Business Case Review Milestone (end Inception Phase) Tue 1/19/03 Tue 1/19/03
Architectural Prototype Milestone (end Elaboration Phase) Tue 3/2/03 Tue 3/2/03
Beta Milestone (Beta Version Ready) Fri 4/2/03 Fri 4/2/03
Initial Operational Capability Milestone (Release 1.0) Mon 5/10/03 Mon 5/10/03
Product Release R1.0 Milestone Wed 5/19/03 Wed 5/19/03
Second Operational Capability Milestone (Release 2.0) Tue 6/15/03 Tue 6/15/03
Product Release R2.0 Milestone Thu 6/24/03 Thu 6/24/03

Inception Phase Tue 12/1/02 Tue 1/19/03

Preliminary Iteration Tue 12/1/02 Tue 1/19/03
Business Modeling Tue 12/1/02 Mon 12/21/02
Requirements Tue 12/1/02 Tue 1/19/03
Configuration Management Tue 12/1/02 Mon 1/11/03
Management Tue 12/1/02 Tue 1/19/03

Elaboration Phase Wed 1/20/03 Tue 3/2/03

Iteration E1 - Develop Architectural Prototype Wed 1/20/03 Tue 3/2/03
Business Modeling Wed 1/20/03 Fri 1/22/03
Requirements Mon 1/25/03 Fri 1/29/03
Use Cases/Scenarios:
Execute Trade Use Case: Customer executes a market buy. Mon 1/25/03 Wed 1/27/03
Execute Trade Use Case: Fail due to rejected trade Thu 1/28/03 Fri 1/29/03
Get Quote Use Case: Customer gets a quote Mon 1/25/03 Wed 1/27/03
Get Quote Use Case: Fail due to quote system is unavailable Thu 1/28/03 Fri 1/29/03
Analysis and Design (Architecture and Major Risks) Mon 2/1/03 Fri 2/12/03
Implementation (Architecture and Major Risks) Mon 2/15/03 Fri 2/19/03
Test (Architecture and Major Risks) Mon 2/22/03 Tue 3/2/03
Management Wed 1/20/03 Tue 3/2/03

Construction Phase Wed 3/3/03 Tue 6/15/03

Iteration C1: Develop Release 1 Beta Wed 3/3/03 Fri 4/2/03
Requirements Mon 1/25/03 Fri 1/29/03
Use Cases/Scenarios:
T.B.D.

Implementation (Beta) Wed 3/3/03 Wed 3/24/03

Test (Interfaces and Integrated Function) Thu 3/25/03 Fri 4/2/03
Management Wed 3/3/03 Fri 4/2/03
Iteration C2: Develop Release 1 Mon 4/5/03 Mon 5/10/03
Requirements Mon 1/25/03 Fri 1/29/03
Use Cases/Scenarios:

12 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services Version: RUCS 9
Software Development Plan Date: 4/10/2003 9:32 AM
RU e-st Case Study 9

T.B.D.

Analysis & Design (Refine) Mon 4/5/03 Mon 4/12/03

Implementation (Effective Production) Tue 4/13/03 Mon 4/26/03
Test (Interfaces and Integrated Function) Tue 4/27/03 Mon 5/10/03
Management Mon 4/5/03 Mon 5/10/03
Iteration C3: Develop Release 2.0 Tue 5/11/03 Tue 6/15/03
Requirements Mon 1/25/03 Fri 1/29/03
Use Cases/Scenarios:
T.B.D.

Analysis & Design (Refine) Tue 5/11/03 Tue 5/18/03

Implementation (Effective Production) Wed 5/19/03 Wed 6/2/03
Test (Interfaces and Integrated Function) Thu 6/3/03 Tue 6/15/03
Management Tue 5/11/03 Tue 6/15/03

Transition Phase Tue 5/11/03 Thu 6/24/03

Iteration T1: Release 1 Tue 5/11/03 Wed 5/19/03
Deployment Tue 5/11/03 Wed 5/19/03
Iteration T2: Release 2 Wed 6/16/03 Thu 6/24/03
Deployment Wed 6/16/03 Thu 6/24/03

Environment Tue 12/1/02 Fri 6/25/03

4.2.5 Project Resourcing
4.2.5.1 Staffing Plan

The IT employees identified in the Organizational Chart in Section 8.1 are allocated to
the project. Additional resources will not staffed until the business case is reviewed at the
end of the Inception Phase and a Go/No Go decision is made on the project.

The test organization relies on support from the software engineering organization, as
shown by the dotted line in the organization chart.

4.2.5.2 Resource Acquisition Plan

The RU Financial Services IT department has insufficient developers and designers to

meet the project needs. The RU Financial Services Recruiting office is prepared to recruit
a Senior Developer with several years J2EE experience, an experienced System
Integrator, and two Implementer/Testers (Junior Grade), with at least one year of J2EE
experience.

4.2.5.3 Training Plan

Training on the following skills will be conducted for the project team prior to the
commencement of design activities:

o Mastering Requirements Management with Use Cases

o Object Oriented Analysis and Design
o Introduction to the Rational Unified Process
o Advanced J2EE Architectures

© Copyright IBM Corp. 2003 13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 4.2.6 Budget

The project’s budget as based upon the initial estimates.

4.3 Iteration Plans

See the RU e-st Stock Trading System E1 Iteration Plan [11].
4.4 Project Monitoring and Control
4.4.1 Requirements Management Plan
The requirements for this system are captured in the Vision [1] and Stakeholder Requests [3]
documents.
4.4.2 Schedule Control Plan
The project manager maintains a summary schedule showing the expected date of each milestone,
and is part of the Status Assessment Report, as described in the reporting plan. The Status
Assessment Report is provided to the IT Executive, who may use this to set new priorities or to
recommend corrective action.
The summary schedule is derived from a detailed schedule maintained by the team managers. The
line items in the detailed schedule are work packages assigned to individuals. Each individual
who is assigned a work package provides % completion information to his/her team manager on a
weekly basis.

14 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services Version: RUCS 9
Software Development Plan Date: 4/10/2003 9:32 AM
RU e-st Case Study 9

4.4.3 Budget Control Plan

Expenses are monitored by the project manager and reported and assessed via the Status
Assessment Report.
4.4.4 Quality Control Plan
All deliverables are required to go through the appropriate review process. The review is required
to ensure that each deliverable is of acceptable quality, using guidelines described in the Rational
Unified Process [6] review guidelines and checklists.
In addition, defects are recorded and tracked and defect metrics gathered as described on the
Wylie Software Process Website [10].
4.4.5 Reporting Plan
The Status Assessment report is prepared by the Project Manager at least once per month. This
includes:
• Updated cost and schedule estimates
• Summary of metrics
4.4.6 Measurement Plan
Standard project metrics, as described in The RU Financial Services Software Process Website
[10], are gathered and included in the Status Assessment Report.
4.5 Risk Management Plan
See RU e-st Stock Trading System Risk List [8].
4.6 Close-Out Plan
The schedule shows a gradual roll-off of staff onto other projects. At least one developer is
retained part-time by the IT Department after delivery to provide maintenance of the system.
A Post-Mortem Report is submitted to the IT Executive summarizing lessons learned, including an
assessment of actual cost and schedule vs. predicted.
5. Technical Process Plans
5.1 Development Case
See RU e-st Stock Trading System Development Case [9].
5.2 Methods, Tools, and Techniques
See RU Financial Services Software Process Website [10].
5.3 Infrastructure Plan
N/A
5.4 Product Acceptance Plan
N/A
6. Supporting Process Plans
See RU Financial Services Process Website [10].
7. Additional plans
N/A.
8. Annexes
N/A.

© Copyright IBM Corp. 2003 15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 9. Index
N/A.

16 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

RU e-st
Requirements Management Plan

Version 1.3

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Revision History
Date Version Description Author
21-Feb-2000 0.1 Initial Session Feedback Applied Stephen Hunt(slh)
26-Feb-2000 0.2 Follow-up interview feedback applied slh
7-Mar-2000 0.3 Revised requirement attributes slh
24-Mar-2000 0.7 First Draft Proof slh
26-Mar-2000 0.9 Revisions from internal reviews slh
29-Nov-2000 1.2 New UC strategy and new RM template J. Bell
30 October 2001 1.3 Editorial changes B. Baker

2 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Table of Contents
1. Introduction 5
1.1 Purpose 5
1.2 Scope 5
1.3 Definitions, Acronyms, and Abbreviations 5
1.3.1 Baseline 5
1.3.2 Business Rule 5
1.3.3 Business Unit Manager 5
1.3.4 Customer 5
1.3.5 Engineering Time 6
1.3.6 NCSS 6
1.3.7 Pareto Chart 6
1.3.8 Product Feature 6
1.3.9 Rational RequisitePro® 6
1.3.10 Rational Rose 6
1.3.11 Rational SoDA 6
1.3.12 Rational TestManager 6
1.3.13 Stakeholder 6
1.3.14 Stakeholder Request 7
1.3.15 Vision Document 7
1.4 References 7
1.5 Overview 8

2. Requirements Management 8
2.1 Organization, Responsibilities, and Interfaces 8
2.2 Tools, Environment, and Infrastructure 9

3. The Requirements Management Program 10

3.1 Requirements Identification 10
3.2 Traceability 10
3.2.1 Criteria for Stakeholder Requests 11
3.2.2 Criteria for Product Feature Requirements 11
3.2.3 Criteria for Use-Case Requirements 12
3.2.4 Criteria for Supplementary Requirements 12
3.2.5 Criteria for Glossary Requirements 12
3.2.6 Criteria for Supporting Document Requirements 12
3.3 Attributes 12
3.3.1 Requirement Attributes for Feature (FEAT) 12
3.3.2 Requirement Attributes for Requirements Management Plan Requirements (RM) 15
3.3.3 Requirement Attributes for Software Requirements (SR) 16
3.3.4 Requirement Attributes for Stakeholder Requests (STRQ) 17
3.3.5 Requirement Attributes for Supplementary Requirements (SUPL) 18
3.3.6 Requirement Attributes for Use Case (UC) 19
3.4 Reports and Measures 21
3.5 Requirements Change Management 21
3.5.1 Change Request Processing and Approval 21
3.5.2 Change Control Board (CCB) 21
3.5.3 Project Baselines 21
3.6 Workflows and Activities 21

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

4. Milestones 21

5. Training and Resources 21

Appendix 1: Technology Risk Assessment 22

4 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Requirements Management Plan

1. Introduction
1.1 Purpose
This document describes the guidelines used by the RU e-st project within RU Financial Services for
establishing the requirements documents, requirement types, requirements attributes, and traceability in
order to manage their software project requirements. It also serves as the configuration document for
Rational RequisitePro®.

1.2 Scope
This Requirements Management Plan documents the approach followed to record, structure, and evolve
requirements for the RU e-st project. This Requirements Management Plan is based on guidelines for all
software projects performed by the RU Financial Services IT department.
The Requirements Management Plan described in this document is almost identical to the Composite
Template defined in Rational RequisitePro®. This template combines the best qualities of both use-case
modeling and traditional requirements specification techniques by providing an outline for a modern
software requirements specification package applying both document based techniques and use-case
modeling.
Document types in the Requirements Management Plan include: Vision Document, Glossary, Modern
Software Requirements Specification, Use-Case Specification, Requirements Management Plan,
Stakeholder Request Document, Supplementary Specification, Test Case Specification, and Test Plan.
Requirement types included are: Stakeholder Request, Feature, Glossary Term, Software Requirement, Use
Case, Requirements Management Plan Requirement, Supplementary Specification, and Test Case.

1.3 Definitions, Acronyms, and Abbreviations

1.3.1 Baseline
A reviewed and approved release of artifacts that constitutes an agreed basis for further evolution or
development and that can be changed only through a formal procedure, such as change management and
configuration control.

1.3.2 Business Rule

A formal regulation or bylaw imposed by an organization or simply the standard practices of users
governing the way the organization conducts its business. Business rules may be classified as definitions,
facts (relationships, connections), constraints ('must have' versus 'must not have') and derivation rules
(inferring new facts from existing ones).

1.3.3 Business Unit Manager

A member of an RU Financial Services business unit. Responsible and accountable for communicating
requirements for systems to IT and for accepting delivery of systems.
1.3.4 Customer
The economic buyer of a project developed by IT.

© Copyright IBM Corp. 2003 5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

1.3.5 Engineering Time

A measurement unit describing engineering effort. Usually expressed in units of weeks or months. The
move away from terms like man-months, or person-months is deliberate. Men and months are
interchangeable commodities only when a task can be partitioned among many workers with no
communication among them. In most uses, engineering time is used to understand the relative size of
something, not as an advertised elapsed time to complete a task.

1.3.6 NCSS
Non-Commented Source Statements. A metric used to estimate project risk, estimate schedules, and most
importantly, a component of software release decision when used in defect density calculation.

1.3.7 Pareto Chart

A useful tool for graphically depicting where allocating time, human, and financial resources will yield the
best results. Dr. Joseph Juran (of total quality management fame) formulated the Pareto Principle after
expanding on the work of Wilfredo Pareto, a nineteenth century economist and sociologist. The Pareto
Principle states that a small number of causes is responsible for a large percentage of the effect–usually a
20 percent to 80 percent ratio.

1.3.8 Product Feature

A capability or characteristic of a system that directly fulfills a Stakeholder Need. Often thought of as the
"advertised benefits" of the system.

1.3.9 Rational RequisitePro®

The Rational RequisitePro® product helps teams organize, prioritize, track and control changing
requirements of a system or application.
Rational Requisite®Web helps teams organize, prioritize, track and control changing requirements of a
system or application via a Web browser interface.

1.3.10 Rational Rose

Rational Rose® is a graphical component modeling and development tool, using the industry-standard
Unified Modeling Language (UML).

1.3.11 Rational SoDA

Rational SoDA® provides automatic generation of software documentation.

1.3.12 Rational TestManager

Designed to help you track software testing information through all phases of the software development,
test, and revision cycles. You can use TestManager to plan testing strategies, and to track information
related to test execution.

1.3.13 Stakeholder
A stakeholder is defined as anyone who is materially affected by the outcome of the project. Effectively
solving any complex problem involves satisfying the needs of a diverse group of stakeholders.
Stakeholders will typically have different perspectives on the problem, and different needs that must be
addressed by the solution.

6 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

1.3.14 Stakeholder Request

Requests a stakeholder makes for the system to be developed. It may also contain references to external
sources to which the system must comply.

1.3.15 Vision Document

A general vision of the core project requirements. It provides the contractual basis for the more detailed
technical requirements. This is a project management document owned by the IT project manager. A
system analyst authors it with primary input elicited from the stakeholders.

1.4 References
Applicable references are:
1. Rational Unified Process v2003.06.00, Copyright  1987–2003 Rational Software Corporation
2. Grady R., Practical Software Metrics For Project Management And Process Improvement,
Englewood Cliffs, NJ: Prentice-Hall, Inc., 1992, pp. 14, 42, 172-174
3. Grady, R. and D. Caswell, Software Metrics: Establishing a Company-Wide Program, Englewood
Cliffs, NJ: Prentice-Hall, Inc., 1987, pp. 34, 65, 111, 112, 113
4. Card, D., V. Church, and W. Agresti, “An Empirical Study of Software Design Practices,” IEEE
Transactions of Software Engineering, Vol. SE-12, no. 2, (Feb. 1986), pp. 264-271
5. Cash, J., F. McFarlan, J. McKenny, and L. Applegate, Corporate Information Systems Management:
Text and Cases, Boston, MA: Richard D. Irwin, Inc., 1992, pp. 418-426
6. Spence, I. and L. Probasco, Tracability Strategies for Managing Requirements with Use-Cases,
Cupertino, CA: Rational Software Corporation, 1998
7. Brooks, F., The Mythical Man-Month, Reading, MA: Addison Wesley Longman, Inc., 1998, pp. 16-26
8. Mc McCabe, T. and A. Watson, "Software Complexity," Crosstalk, Journal of Defense Software
Engineering 7, 12 (December 1994): pp. 5-9.
9. Vision Document Template, V 0.1, Draft, 2000
10. Supplementary Specification Template, V 0.1, Draft, 2000
11. Use-Case Specification Template V 0.1, Draft, 2000
12. Test Plan Template, V 0.1, Draft, 2000
13. Glossary Template, V 0.1, Draft, 2000
14. Assumptions Template, V 0.1, Draft, 2000
15. Issues Template, V 0.1, Draft, 2000
16. Business Rules Template, V 0.1, Draft, 2000
17. Use-Case Model Survey Template, V 0.1, Draft, 2000

© Copyright IBM Corp. 2003 7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

1.5 Overview
This Requirements Management Plan is being created to address identified problems in the requirements
management process experienced previously in software projects delivered by RU Financial Services IT.
Problems include:
Poor communication of changes to requirements, including the use of e-mail to communicate
changes.
Data changes out of sync with code changes.
Lack of formal handoffs between team members for software artifacts.
Minimal contact with stakeholders.
Users not knowing what they want until they see it.
Fast pace of requirements change.
Geographically disbursed team, a problem that has been remedied.
Lack of clear understanding of roles within the requirements process.
Separation of the subject matter experts and developers may result in decreased customer
satisfaction.
Inconsistent documentation.
Inability to easily find requirement documents.
What follows is the response to these problems. A standard set of documents used to express requirements
of all levels will be defined. An established set of requirement types to capture stakeholder problems,
needed features of the system, software requirements, test requirements, standard terms, and business rules
will be described. For each requirement type a collection of requirements attributes, used to manage
delivery of the needed system and manage changes to the requirements over the lifecycle of the project,
will be identified along with values and ranges appropriate for each.
A model of traces between requirements will be established to help communicate requirements change to
all members of the project team. An initial list of predefined views of requirements information will be
defined. This list must evolve with use. A set of tool extensions to provide needed functionality specifically
for the RU e-st project will be created. Finally, a list of roles within the requirements management process
will be identified.
The premise of this endeavor from the start was that an initial process and tool configuration for
requirements management be defined, and that these would evolve through use. This being the case, this
document should be considered a “living” document and changes to it over time and experience are
expected. Changes to this document should be made in a controlled manner and only after review by
stakeholders.
The project management strategy taken by RU Financial Services IT is one that places an emphasis on
customer satisfaction. This plan embraces that strategy.

2. Requirements Management
2.1 Organization, Responsibilities, and Interfaces
TBD

8 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

2.2 Tools, Environment, and Infrastructure

TBD

© Copyright IBM Corp. 2003 9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

3. The Requirements Management Program

3.1 Requirements Identification
ARTIFACT REQT. TYPE DESCRIPTION
Vision (VIS) Product The Vision document defines the stakeholder’s view of the product to be
Feature developed, specified in terms of the stakeholder’s key needs and features.
(FEAT) Owned and authored by the System Analyst.
Stakeholder Stakeholder Requests a stakeholder makes for the system to be developed. It may also
Requests (STR) Requests contain references to external sources to which the system must comply.
(STRQ) Provided by Stakeholders.
Glossary (GLS) Term (TERM) The Glossary defines important terms used in the project. Owned and
authored by the System Analyst. Content provided by Stakeholders and RU
Financial Services IT.
Requirements Requirements Describes the documents, requirement types, and attributes; and information
Management Management and control mechanisms for measuring, reporting, and controlling changes to
Plan (RMP) Plan (RMP) the product requirements. Owned and authored by the System Analyst.
Modern Software Package capturing the complete software requirements for the system. For
Software Requirements the system being developed, this artifact consists of a package containing
Requirements (SR) Use-Case Specifications and Supplementary Specification.
(MSRS)
Use-Case Model Generated SoDA report providing a high-level view of all use cases and
Survey actors for this release documented in Rational Rose.
Use-Case Use Case (UC) Use cases are defined for each use-case name at the top of a hierarchy with
Specification dependents representing sections of the use-case description. Individual
(UCS) detailed requirements as specified in the use-case specification. These are
also known as software requirements. Owned and authored by the System
Analyst. Content provided by Stakeholders.
Supplementary Supplementary The Supplementary Specifications capture system requirements not readily
Specification Requirement captured in use cases. Such requirements include: legal and regulatory
(SUPL) (SUPL) requirements; quality requirements such as usability, reliability, performance
and supportability; and design constraints. Owned and authored by the
System Analyst. Content provided by Stakeholders.

3.2 Traceability

10 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Requirements Traceability

Stakeholder Request
(STRQ)

Feature (FEAT)

Use Case (UC) Supplementary Requirement

(SUPL)

Figure 3-1 Requirements Traceability Diagram

3.2.1 Criteria for Stakeholder Requests

The Stakeholder Request requirements defined in the Stakeholder Requests Document are traced from
product feature requirements. A request requirement may trace from zero or more feature requirements.

3.2.2 Criteria for Product Feature Requirements

The product feature requirements defined in the Vision document will be traced from the corresponding
use-case requirements and/or supplementary requirements in the Use-Case Specifications and the
Supplementary Specification documents.
Each feature requirement with a status of incorporated and a target release identified must trace from one
or more use-case requirement and/or supplementary requirement.

© Copyright IBM Corp. 2003 11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

A feature requirement may also trace to other product feature requirements where the traced-to requirement
represents a feature to which the origin requirement is dependent.

3.2.3 Criteria for Use-Case Requirements

The use-case requirements defined in a RequisitePro database will be traced from the associated actor
requirements defined in a RequisitePro database.
The detailed requirements defined in a use-case specification document will be hierarchically related.
Every use-case requirement must trace from one or more test case requirements. The use-case requirements
will be traced from test case requirements defined in test case specifications.
A use-case requirement may also trace to other use-case requirements where the traced-to requirement
represents a system behavior expressed by that requirement to which the origin requirement is dependent.

3.2.4 Criteria for Supplementary Requirements

The supplementary requirements defined in a supplementary specification document are traced from test
case requirements defined in test case specification. Every supplementary requirement must trace from one
or more test case requirements.
A supplementary requirement may also trace to other supplementary requirements where the traced-to
requirement represents a requirement to which the origin requirement is dependent.

3.2.5 Criteria for Glossary Requirements

This is a trace between Glossary terms and their definitions. You may choose to trace to the Glossary
requirement from any document. However, usually the trace is established between a Glossary term within
another Glossary definition to the source of the Glossary term.

3.2.6 Criteria for Supporting Document Requirements

This traceability type allows you to add any documents that you like into the traceability hierarchy. This is
particularly useful for including pre-existing examples or documentation that clarifies the meaning or
purpose of another traceability item. The flexible traceability mechanisms of RequisitePro allow you to
associate supporting documentation with any traceability item of any type. An example of using the
Supporting document type is to include the detailed EDI message specifications as supporting information
for the Glossary, or as appendixes to the use cases that will use the message.

3.3 Attributes

3.3.1 Requirement Attributes for Feature (FEAT)

Requirement Text is the feature description.

Priority
Set by the Business System Manager. Ranking requirements by their relative benefit to the business opens
a dialogue with customers, analysts and members of the development team. Used in managing scope and
determining development priority.

12 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

High Essential requirements. Failure to implement means the system will not meet
customer needs. All critical requirements must be implemented in the release.
Medium Requirements important to the effectiveness and efficiency of the system for most
applications. The functionality cannot be easily provided in some other way. Lack
of inclusion of an important requirement may affect customer or user satisfaction,
or even revenue, but release will not be delayed due to lack of any important
requirement.
Low Requirements that are useful in less typical applications will be used less
frequently, or for which reasonably efficient workarounds can be achieved. No
significant revenue or customer satisfaction impact can be expected if such an
item is not included in a release.

Table 3-1 Priority attribute values for FEAT Requirement Type.

Difficulty
Set by the Development Team, it indicates the estimated effort required for implementing and validating
the requirement. Because some requirements require more time and resources than others, estimating the
engineering time is the best way to gauge complexity and set expectations of what can and cannot be
accomplished in a given time frame. Used in managing scope and determining development priority.

High Above average effort to implement.

Medium Average effort to implement.
Low Below average effort to implement.

Table 3-2 Difficulty attribute values for FEAT Requirement Type.

Difficulty estimate is based on estimates of many factors, including effort, size, and coordination
complexity.
When estimating effort keep in mind all of the activities associated with the production of a software
product. Rule of thumb: Projects created primarily from reused software take about 23 percent of the time
and resources of those that are new. Measurement will be integer value, unit of engineering weeks.
Size refers to the estimated number of non-commented source statements needed to implement the
requirement. The greater the number of lines of code the greater the complexity of the project. Reused
software lines of code should be counted at a quarter of their number. Measurement will be an integer
value, number of non-commented source statements/1000(KNCSS).
Coordination complexity is estimated by analyst and development teams based on the reliance on
organizations outside their control needed to implement the requirement. Measurement will be qualitative:
high, medium or low.

Risk
Set by the development team based on technology risk, development risk, and other risk factors. Normally
performed at the project level, the Technology Risk Assessment (TRA), Appendix 1, for the requirement,
allows the development team to understand the slope they must climb to deliver the goods. Used to help
establish development risk. Measurement will be an integer value between zero and 150. A value of zero
indicates no assessment has been performed.

© Copyright IBM Corp. 2003 13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Risk can be measured and calculated in a variety of ways. For example, effort, size, coordination
complexity, technology risk, architectural impact is evaluated for its value in the matrix and the resulting
value is multiplied by the weight and totaled. The result is an integer valued between 0 – 100. This
measures the probability the project will experience undesirable events, such as cost overruns, schedule
delays or even cancellation. The result is then recorded as a qualitative category: high, medium, or low.

High It is very likely that implementing this requirement will result in undesirable
events, such as cost overruns, schedule delays or cancellation. The
development team is very concerned about completing this requirement, with
the given constraints. Reasons for the concern are documented in a separate
document.
Medium No indicator exists to predict the likelihood of undesirable events. The
development team feels comfortable implementing this requirement under the
constraints. But, there are some unknown elements that need to be considered.
Reasons for these concerns are documented in a separate document. Default
value.
Low It is very unlikely that implementing this requirement will result in undesirable
events. The development team is fully confident of being able to implement the
requirement within the project’s constraints. The team has done similar work
before with success.

Table 3-3 Stability attribute values for FEAT Requirement Type.

Stability
Set by the Business System Manager and development. Used to help establish development priorities and
determine the items for which additional exploration and discovery is the appropriate next action.

High It is very unlikely that this requirement will change, or that the development team’s
understanding of the requirement will change.
Medium No indicator exists to predict the likelihood of change for the requirement.
DEFAULT
Low It is very likely that this requirement will change, or that the development team’s
understanding of the requirement will change.

Table 3-4 Stability attribute values for FEAT Requirement Type.

Status
Set after negotiation and review by the project management team and Business Unit Managers. Tracks
progress during definition of the project baseline. Used to control scope.

Proposed Requirement is under discussion but has not yet been reviewed and accepted by
the "official channel," such as a working group consisting of representatives from
the project team, product management and user or customer community.
Approved Requirement is deemed useful and feasible and has been approved for
implementation by the official approval channel.
Incorporated Requirement is incorporated into the product baseline at a specific point in time.
Validated Requirement has been implemented and validated.

Table 3-5 Status attribute values for FEAT Requirement Type.

14 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Planned Iteration
The iteration when this requirement is planned to begin to be implemented. Integer value.

Actual Iteration
The iteration when this requirement actually began to be implemented. Integer value.

Assigned to
Set by the System Analyst. Text giving the analyst’s name who has been assigned to fully describe this
item. The name is given in the format: first-name last-name – Example: Sue Collins.

Origin
Set by the System Analyst. List value giving the source of the requirement: hotline, partners, competitors,
or large customers.

Rationale
Set by the System Analyst. Text giving the rationale for the requirement.

Cost
Set by Development Team based on the estimated cost to fully develop this requirement. Used in managing
scope and determining development priority.

3.3.2 Requirement Attributes for Requirements Management Plan Requirements (RM)

Requirement text consists of one or more phrases that describe planning requirements that are part of the
Requirements Management Plan.
See 3.3.2, Requirement Attributes for Feature Requirements, for a full description of attribute values for
priority, status, difficulty, and stability.

Priority
Set by the Business System Manager. Ranking requirements by their relative benefit to the business opens
a dialogue with customers, analysts and members of the development team. Used in managing scope and
determining development priority. Values: High, Medium, and Low.

Status
Set after negotiation and review by the project management team and Business Unit Managers. Tracks
progress during definition of the project baseline. Used to control scope. Values: Proposed, Approved,
Incorporated, or Validated.

Difficulty
Set by the development team, it indicates the estimated effort required for implementing and validating the
requirement. Used in determining development priority. Values: High, Medium, and Low.

© Copyright IBM Corp. 2003 15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Stability
Set by the Business System Manager and development team. Used to help establish development priorities
and determine the items for which additional exploration and discovery is the appropriate next action.
Values: High, Medium, and Low.

Cost
Set by development team based on the estimated cost to fully develop this requirement. Used in
determining development priority. Real value.

Assigned to
Text giving the analyst’s name who has been assigned to fully describe this item. Set by the System
Analyst. The name is given in the format: first-name last-name – Example: Sue Collins.

3.3.3 Requirement Attributes for Software Requirements (SR)

Requirement text consists of one or more phrases that describes detailed software requirement for the
system to be developed.
See 3.3.2, Requirement Attributes for Feature Requirements, for a full description of attribute values for
priority, status, difficulty, and stability.

Priority
Set by the Business System Manager. Ranking requirements by their relative benefit to the business opens
a dialogue with customers, analysts and members of the development team. Used in managing scope and
determining development priority. Values: High, Medium, and Low.

Status
Set after negotiation and review by the project management team and Business Unit Managers. Tracks
progress during definition of the project baseline. Used to control scope. Values: Proposed, Approved,
Incorporated, or Validated.

Difficulty
Set by the development team, it indicates the estimated effort required implementing and validating the
requirement. Used in determining development priority. Values: High, Medium, and Low.

Stability
Set by the Business System Manager and development. Used to help establish development priorities and
determine the items for which additional exploration and discovery is the appropriate next action. Values:
High, Medium, and Low.

Cost
Set by development team based on the estimated cost to fully develop this use case. Used in managing
scope and determining development priority. Real value.

16 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Assigned to
Set by the System Analyst. Text giving the analyst’s name that has been assigned to fully describe this
item. The name is given in the format: first-name last-name – Example: Sue Collins.

3.3.4 Requirement Attributes for Stakeholder Requests (STRQ)

Requirement text consists of one or more phrases that describe the request a stakeholder makes for the
system to be developed. It may also contain references to external sources to which the system must
comply.
See 3.3.2, Requirement Attributes for Feature Requirements, for a full description of attribute values for
priority, status, difficulty, stability, and origin.

Priority
Set by the Business System Manager. Ranking requirements by their relative benefit to the business opens
a dialogue with customers, analysts and members of the development team. Used in managing scope and
determining development priority. Values: High, Medium, and Low.

Status
Set after negotiation and review by the project management team and Business Unit Managers. Tracks
progress during definition of the project baseline. Used to control scope. Values: Proposed, Approved,
Incorporated, or Validated.

Difficulty
Set by the development team, it indicates the estimated effort required for implementing and validating the
requirement. Used in determining development priority. Values: High, Medium, and Low.

Stability
Set by the Business System Manager and development team. Used to help establish development priorities
and determine the items for which additional exploration and discovery is the appropriate next action.
Values: High, Medium, and Low.

Cost
Set by development team based on the estimated cost to fully develop this requirement. Used in managing
scope and determining development priority. Real value.

Assigned to
Set by the System Analyst. Text giving the analyst’s name that has been assigned to fully describe this
item. The name is given in the format: first-name last-name – Example: Sue Collins.

Origin
Set by the System Analyst. List value giving the source of the requirement: hotline, partners, competitors,
or large customers.

© Copyright IBM Corp. 2003 17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Rationale
Text giving the rationale for the Requirement. Set by the System Analyst

Synchlinks
Text value used for synchronizing information. Set after information has been synchronized.

3.3.5 Requirement Attributes for Supplementary Requirements (SUPL)

Requirement text describes what the system should do.
See 3.3.2, Requirement Attributes for Feature Requirements, for a full description of attribute values for
priority, status, difficulty, and stability.

Priority
Set by the Business System Manager. Ranking requirements by their relative benefit to the business opens
a dialogue with customers, analysts and members of the development team. Used in managing scope and
determining development priority. Values: High, Medium, and Low.

Status
Set after negotiation and review by the project management team and Business Unit Managers. Tracks
progress during definition of the project baseline. Used to control scope. Values: Proposed, Approved,
Incorporated, or Validated.

Difficulty
Set by the development team, it indicates the estimated effort required implementing and validating the
requirement. Used in determining development priority. Values: High, Medium, and Low.

Stability
Set by the Business System Manager and development. Used to help establish development priorities and
determine the items for which additional exploration and discovery is the appropriate next action. Values:
High, Medium, and Low.

Cost
Set by Development Team based on the estimated cost to fully develop this Requirement. Used in
managing scope and determining development priority. Real value.

Assigned to
Text giving the analyst’s name that has been assigned to fully describe this item. Set by the System
Analyst. The name is given in the format first-name last-name – Example: Sue Collins.

18 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

3.3.6 Requirement Attributes for Use Case (UC)

Requirement text describes what the system should do.
See 3.3.2, Requirement Attributes for Features, for full descriptions of attribute values for priority,
difficulty, status, and stability.

Brief Description
Brief textual description of the use case, focusing on the goals and intent of the use case.

© Copyright IBM Corp. 2003 19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Property
Set by the System Analyst. Indicates the location within a Use-Case Report where the requirement lives.

Name The requirement is found in the name of the Use-Case.

Brief The requirement is found in the brief description of the Use-Case.
Description
Basic Flow The requirement is found in the basic flow of the Use-Case.
Alternate Flow The requirement is found in an alternate flow of the Use-Case.
Special The requirement is found in the Special Requirements section of the Use-
Requirements Case.
Precondition The requirement is found in the Precondition section of the Use-Case.
Postcondition The requirement is found in the Postcondition section of the Use-Case.
Relationships The requirement is found in the Relationships section of the Use-Case.
Extension Points The requirement is found in the Extension Points section of the Use-Case.

Table 3-14 Property attribute values for UC Requirement Type.

Affects Architecture
Set by the Software Architect, this indicates the requirement has an influence on the software architecture.
Values: True or False.

Planned Iteration
The iteration when this use case or use case section is planned to begin to be implemented. Integer value.

Actual Iteration
The iteration when this use case or use case section actually began to be implemented. Integer value.

Assigned to
Text giving the analyst’s name that has been assigned to fully describe this item. Set by the System
Analyst. The name is given in the format: first-name last-name – Example: Sue Collins.

Rank
Set by the development team based on impact on the architecture or its importance for a release. Ranking
requirements opens a dialogue with customers, analysts and members of the development team. Used in
determining development priority. Integer.

Test
Set by the Test Designer, it indicates if the use case has been tested. Values: True or False.

Priority
Set by the Business System Manager. Ranking requirements by their relative benefit to the business opens
a dialogue with customers, analysts and members of the development team. Used in managing scope and
determining development priority. Values: High, Medium, and Low.

20 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Status
Set after negotiation and review by the project management team and Business Unit Managers. Tracks
progress during definition of the project baseline. Used to control scope. Values: Proposed, Approved,
Incorporated, or Validated.

Difficulty
Set by the development team, it indicates the estimated effort required for implementing and validating the
requirement. Used in determining development priority. Values: High, Medium, and Low.

Stability
Set by the Business System Manager and development. Used to help establish development priorities and
determine the items for which additional exploration and discovery is the appropriate next action. Values:
High, Medium, and Low.

Cost
Set by development team based on the estimated cost to fully develop this use case. Used in managing
scope and determining development priority. Real value.

Synchlinks
Text value used for synchronizing information. Set after information has been synchronized.

3.4 Reports and Measures

TBD

3.5 Requirements Change Management

3.5.1 Change Request Processing and Approval

TBD

3.5.2 Change Control Board (CCB)

TBD

3.5.3 Project Baselines

TBD

3.6 Workflows and Activities

TBD

4. Milestones
TBD

5. Training and Resources

TBD

© Copyright IBM Corp. 2003 21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services RUCS10
Requirements Management Plan Date: October 30, 2001
RU e-st Case Study Artifact 10

Appendix 1: Technology Risk Assessment

Risk Factor Weight

1. Which hardware, needed for the feature, is new to the company? X5
None 0
CPU High 3
Peripheral and/or additional storage High 3
Terminals High 3
Mini/Micro/CU High 3
2. Is the system software (non-operating system) new to the IT project team? X5
No 0
Programming Language High 3
Database High 3
Data communications High 3
Other High 3
3. How knowledgeable is the primary Stakeholder(s) in the proposed application area? X5
Limited High 3
Understands concept but has no experience Medium 2
Has been involved in prior implementation efforts Low 1
4. How knowledgeable is IT team in proposed application area? X5
Limited High 3
Understands concept but has no experience Medium 2
Has been involved in prior implementation efforts Low 1
Total 10-
150

Table A-1 Technology Risk Assessment. [5]

Answer the questions for each feature, multiply the weight by the weight factor in table A-1 the weight factor for all
questions is five. Then total the weighted answers for the technical risk. Range 10-150. The Solution Center may
want to revise this assessment with experience.

22 © Copyright IBM Corp. 2003

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
 RU Financial Services

RU e-st
Use-Case-Modeling Guidelines

Version 0.2

© Copyright IBM Corp. 2003 1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

Revision History
Date Version Description Author
th
12 February 2003 0.1 Initial version Bryon Baker
5th March 2003 0.2 Incorporated review feedback Bryon Baker

© Copyright IBM Corp. 2003 2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms, and Abbreviations 4
1.4 References 4
1.5 Overview 4

2. Use-Case-Modeling Guidelines 5
2.1 Evolution of a Use Case 5
2.1.1 Discovered 5
2.1.2 Briefly Described 5
2.1.3 Outlined 5
2.1.4 Fully Described 5
2.2 Use-Case Model Structure 6
2.3 Communicates Association 6

3. How to Describe a Use Case 7

3.1 Use Case Flows of Events Style 7
3.2 Subflows 8
3.3 Conditional Behavior 9

4. UML Stereotypes 9
4.1 «initiates» stereotype 9

5. Model Structuring 10
5.1 «include» relationship 10
5.2 «extend» relationship 10
5.3 Use-Case Generalization 10
5.4 Actor Generalization 11

© Copyright IBM Corp. 2003 3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

Use-Case-Modeling Guidelines
1. Introduction
1.1 Purpose
This document describes the use-case modeling guidelines used by the RU e-st project within RU Financial
Services. It provides guidelines to ensure a consistent look and feel of all use-case related artifacts.

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

Refer to [2] and [3].

1.4 References
[1] Rational Unified Process, Rational Software Corporation
[2] RU e-st project glossary RUCS2
[3] RU Financial Services Corporate Glossary
[4] OMG Unified Modeling Language Specification, Version 1.4. (http://www.omg.org)

1.5 Overview
This use-case modeling guideline is being created to provide project standards for the development and
maintenance of requirements with use cases. This set of guidelines is organized into the following sections.
• Section 1 - Introduction provides an overview of this document.
• Section 2 – Use-Case-Modeling Guidelines describes how a use case evolves, packaging
guidelines and communicates association conventions.
• Section 3 - How to Describe a Use Case describes flow-structuring guidelines.
• Section 4 - UML Stereotypes describes any project specific UML stereotypes that are used in the
use-case model.
• Section 5 - Model Structuring provides guidance on model structuring with «include», «extend»,
use-case generalization and actor generalization.

© Copyright IBM Corp. 2003 4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

2. Use-Case-Modeling Guidelines
2.1 Evolution of a Use Case
In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process,
a use case evolves from the spark of an idea to a fully described description of how your system behaves.
The following diagram shows the lifecycle of a use case.

Figure 1: Evolution of a use case

2.1.1 Discovered
Initially you “discover” a use case. This is done when you identify and name the goal that the actor is trying
to achieve. A use case is discovered once you have named it.

2.1.2 Briefly Described

Immediately after discovering a use case (usually while you are discussing the name) you create a brief
description of the use case. A brief description describes the goal in two or three sentences. For example,
the Close Registration Use Case for a course registration system would be: This use case allows a Registrar
to close the registration process. Course offerings that do not have enough students are cancelled. The
Billing System is notified for each student in each course offering that is not cancelled, so the student can
be billed for the course offering.

2.1.3 Outlined
The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You
may also choose to identify (not outline) possible alternate flows. This enables you to identify scenarios
and also gain an understanding of the possible size and complexity of the use case.

2.1.4 Fully Described

Finally you fully describe the use case. This in itself is done iteratively. You identify particular flows for
development in an iteration and then fully describe (and implement) just those flows. You then identify
© Copyright IBM Corp. 2003 5
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

flows for subsequent iterations and fully describe (and implement) those during that iteration. At the end of
the project you will have all of your use cases fully described.

2.2 Use-Case Model Structure

2.3 Communicates Association

Relationships between actors and use cases are called communicates-associations. A communicates-
association between an actor and a use-case indicates that they interact: the actor participates in and
communicates with the system containing the use case. Communicates associations do not describe data
flow. Interactions could be mechanical, electrical, data, audible, visual, or any combination of the five. For
example, an actor may press a button on the system (mechanical stimulus) and the system could turn a light
on (visual response).
A communicates-association is represented on UML diagrams as a solid line. The line may be adorned with
an arrowhead. The line and arrow represent a two-way dialog between the actor and the system.
Arrowheads do not describe the direction of data flow.
The arrowhead is used to represent which actor is allowed to initiate each communication. If an arrowhead
is present, then only the "thing" at the tail of the association can initiate each communication with the
"thing" at the head of the association. No arrowhead means that both ends initiate each communication with
each other.

Figure 2: Communicates association

For example, in the Figure 2: Communicates association, Actor 1 always initiates communication with the
system. The system may respond to messages from Actor 1, but can never send an unsolicited message to
Actor 1. For the second association the system always initiates communication with Actor 2. Actor 2 may
respond to messages from the system, but can never send an unsolicited message to the system. For the
third association Actor 3 or the system may initiate the each communication.

© Copyright IBM Corp. 2003 6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

Figure 3: Example communicates association

Figure 3: Example communicates association shows an example of a use case in a fire alarm monitoring
system. The Supervisor is the person who administers the system and starts the monitoring.
A passive sensor is a smoke detector that requires the system to ask for its status. An active sensor is a
smoke detector that will automatically send its status to the system every 60 seconds. A hybrid sensor is a
smoke detector that will send its status every 60 seconds, but it can also receive status requests from the
system. In this system, if the system does not hear from it in 75 seconds then the system will ask the sensor
for its status.
Note: It is the exception to see two navigation arrows pointing towards a use case. Most of the time you
will have only one arrow pointing in and the rest pointing out. The top example is present to reinforce that
the navigation arrow is about indicating who initiates each interaction, not who obtains the goal or who
initiates the use case. If you do encounter this situation, refer to section 4.1 – «initiates» stereotype.
For further details, refer to the UML 1.3 Spec. Part 2 – Foundation, 2.5 – Core.

3. How to Describe a Use Case

3.1 Use Case Flows of Events Style
The RU e-st project shall follow the style described in the RUP [1].
The use-case flows shall make use of headings to describe the steps at a high-level, followed by a
description of what the actor does and what the system does under the heading. For example:

Figure 4: Example flow structure

Each flow should be a round-trip of events that describes what the actor does and what the system does in
response.
© Copyright IBM Corp. 2003 7
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

3.2 Subflows

3.2.1 Definition
When a particular flow becomes overly complex, a common practice is to factor out the complex flow and
place it in an included use case. While the author had the best intentions of reducing the complexity of the
flow, he/she functionally decomposed the system and made it harder to understand the requirements of the
system. The reader now has to look in two documents to understand the requirements.
An alternative approach is to use subflows. A subflow can be thought of as an “internal include”.
Benefits to this approach
•The flow is still contained in the same use-case specification.
•The flow can be used to increase clarity by factoring out complex flows.
• The flow allows the reuse of flows within the same use case. This is because subflows can be
called from multiple places.
The difference between an alternative flow and a subflow is that alternative flows insert themselves into
another flow. The flow it inserts itself into has no knowledge of the alternative flow. An alternative flow
may also resume at any place within the use case.
Subflows are not described as part of a scenario. By definition, if the calling flow is in the scenario, the
subflow is also in the scenario.
As with any other flow, a subflow may have alternative flows.

3.2.2 Using Subflows

A subflow is explicitly called from a flow. When a subflow complete it always returns to the line after it
was called from. It is similar in concept to a subroutine call in some programming languages.
Subflows are described in their own section of the use case.

Figure 5: Calling a subflow

© Copyright IBM Corp. 2003 8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

Figure 6: Example subflow

3.3 Conditional Behavior

The use of statements like: IF, WHILE, REPEAT, UNTIL in the flows of events make identifying
scenarios difficult and are therefore prohibited. All conditional and repetitive behavior must be expressed in
alternative flows.
The following statements are permitted in alternative flows:
• IF – used to express the condition the alternative flow is executed
• RESUME – used to express where the alternative flow resumes in the use case.

Figure 7: Example alternative flow to describe repetitive behavior

4. UML Stereotypes
4.1 «initiates» stereotype
Being able to visually identify which actor initiates the use case is a useful feature of the use-case diagram.
If there is only one inward pointing navigation arrow you can safely assume that the actor at the tail of the
association initiates the use case. If, however, you do encounter the situation where there are two
navigation arrows pointing towards a use case, you should attach an «initiates» stereotype to the
communicates-association from the actor that starts the use case. Refer to Figure 8: «initiates» stereotype
example for an example.
The semantics of an «initiates» stereotype on a communicates-association are identical to the UML
semantics for a communicates-association, plus, it indicates which actor starts the use case.

© Copyright IBM Corp. 2003 9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

Figure 8: «initiates» stereotype example

5. Model Structuring
5.1 «include» relationship
The «include» relationship is only to be used when there are flows that are common to multiple use cases.
Overuse of the «include» relationship increases the complexity for the testers, designers and documentation
authors because each «include» introduces another artifact that must be read in order to understand the
complete requirements. Care must also be taken when using the «include» relationship that the use-case
model does not become functionally decomposed.

5.2 «extend» relationship

If there is a part of a base use case that is optional, or not necessary to understand the primary purpose of
the use case, you can factor that part out to an addition use case in order to simplify the structure of the base
use case. The addition is implicitly inserted in the base use case, using the extend relationship.
The extension is conditional, which means its execution is dependent on what has happened while
executing the base use case. (Similar to an alternative flow.) The base use case does not control the
conditions for the execution of the extension. Those conditions are described within the extend relationship.
The extension use case may access and modify properties of the base use case. The base use case, however,
cannot see the extensions and may not access their properties.
The base use case is implicitly modified by the extensions. You can also say that the base use case defines a
framework into which extensions can be added, but the base does not have any visibility of the specific
extensions.
The base use case should be complete in and of itself, meaning that it should be understandable and
meaningful without any references to the extensions. However, the base use case is not independent of the
extensions, because it cannot be executed without the possibility of following the extensions.
The base use case has no knowledge of the use case that extends it and therefore cannot see the properties
of the extending use case. The extending use case knows which use case it extends and can see all the
properties of the base use case.
The base use case must identify extension points in a separate section of the use-case specification. The
extending use case then indicates where it extends the base use case by referencing these named extension
points in the base use case.

5.3 Use-Case Generalization

This relationship is prohibited from use on the RU e-st project.

© Copyright IBM Corp. 2003 10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

5.4 Actor Generalization

Actor generalization is used to simplify the use-case diagram and avoid the “chopstick effect” of
communicates associations when multiple actors all execute the use case for the same purpose. In the
following example, the three actors: doctor, nurse, and aide; all perform the use case Read Chart. Rather
than have all three actors, each with a communicates association to the Read Chart use case, you can
identify an abstract actor and use actor generalization between the actors. The following example shows an
abstract actor Medical Worker (no one is employed as a medical worker) that represents the role that the
three concrete actors play when reading the medical chart. This has reduced the complexity of the use case
diagram.

Figure 9: Actor generalization

© Copyright IBM Corp. 2003 11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
RU Financial Services, RU e-st Project RUCS11
Use-Case-Modeling Guidelines Date: 4/10/2003 12:35 PM
RUCS11

© Copyright IBM Corp. 2003 12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
► ► ► Contents

WP: White Papers

WP1: The Five Levels of Requirements Management Maturity

WP2: Features, Use cases, Requirements, Oh My!
WP3: Using the RUP to Evolve a Legacy System
WP4: Generating Test Cases From Use Cases
WP5: Structuring the Use-Case Model
WP6: ACRE: Selecting Methods For Requirements Acquisition
Copyright Rational Software 2003 http://www.therationaledge.com/content/feb_03/f_managementMaturity_jh.jsp

The Five Levels of Requirements Management

Maturity

by Jim Heumann
Requirements Evangelist
Rational Software

Maturity: the quality of sound

judgment associated with adult
humans.
-- The Wordsmyth English
Dictionary/Thesaurus

Being mature means being able to see

the big picture and make good choices.
In a business context, that means
basing decisions on a clear
understanding of the full range of both
the costs and benefits of doing one
thing over another.

This article looks at the decisions organizations make and what they do as
they move up the scale in requirements management maturity (RMM).
Just as hiking up a mountain has a cost (in energy and time), so does this
climb upward. Therefore, as we look at the benefits of reaching higher
levels of maturity, we will not ignore the investment required in terms of
time, effort, and money. In addition, we will analyze how automated
requirements management (RM) tools can help support organizations
striving for greater RM maturity.

Those familiar with the CMM (Capability Maturity Model) from the Software
Engineering Institute (SEI) will note some similarities to our parallel
model, which has no direct relationship to the CMM save one: Achieving
Level Five of the RMM will assuredly help an organization get to at least
Level Three of the CMM. Of course, it's important to keep in mind that
attaining a high level of maturity in a single area, such as requirements
management, is easier than attaining overall organizational process
maturity.

The five levels of maturity for our RMM are: 1) written 2) organized 3)
structured 4) traced, and 5) integrated. We will use these categories to
partition requirements management practices, starting at the lowest level
(One) and moving up through Level Five.

Chaos: No Requirements
Actually, there is one other level on the requirements maturity scale: Level
Zero -- no requirements. At Level Zero, organizations fly by the seat of
their pants; they make broad assumptions that they know what to build;
they gamble that the time they save by not gathering requirements will
not be squandered later because they deliver either too much or too little.
Sometimes this gamble works, but more often than not, a product is
released that is missing functionality, has functions that are not needed,
or is of poor quality. These problems will have varying degrees of impact,
depending on the customer and the criticality of the software, but if the
consequences are severe enough, they may prompt the organization to
start "doing requirements" (and to create an RM process along the way).

Level One --Written Requirements

The first step up from the chaos of no requirements is simply to write the
requirements. White boards and sticky notes don't count. Any medium
that cannot be backed-up and restored is so fraught with risk that we will
not consider it here.

Once you write requirements, several benefits become obvious.

First, you have a real basis for a contract with your customer. If you write
them well, the requirements can clearly state your understanding of what
the customer wants you to build, and they can read the requirements and
agree (or disagree).

Second, everyone on your development team has a basis for doing his or
her work. This obviously includes the architects and designers, who can
start thinking about how to architect the system to meet customer
expectations, but it also includes the testers, who can get a very early
start writing test cases, upon which they can later base test procedures
and scripts.

Third, as you staff up the project, new members, too, will have a source
for figuring out what the application or system is supposed to do. And
because written requirements can be backed up and restored if necessary,
you will have taken a big step toward reducing risk.

How about the cost? Someone -- or perhaps a team of people -- must take
the time to do the writing. And unless the team is making up the
requirements, there is effort involved in talking to the customer to find out
what they want. Maintenance is also a time/cost factor; unless they are
kept up-to-date, the requirements will become useless. And whoever is
responsible for maintenance must learn and implement some "tool" to do
the writing, even if it is simply Word or Notepad.

Is it worth the time and effort? To answer this question, you have to
compare the cost to the potential consequences of not expending the
effort to record the requirements. What will happen if you don't build and
deliver what your customer wants? What will happen if you build too
much? If the answer is "not much," then it's not a problem. But if
delivering the wrong system would mean a major drop in your stock price
or an unhappy customer, well, then you might want to make the
investment.

Level Two -- Organized

At this level an organization deals with things like the quality of the
requirements, their format, their security, where they are stored, and how
to keep track of different versions.

The goal of a requirement is to clearly communicate the proposed

behavior of the software to a diverse set of constituents: users,
customers, and other stakeholders, as well as the development team. This
is a tall order and not easily accomplished. A good set of requirements
does this job well; a bad one does not. Good requirements are
understandable by stakeholders who specify them; they are also usable by
the architect, developers, and testers. To achieve this, they must be not
only readable, but also unambiguous and testable.

Formatting

Requirements must also be formatted effectively. Consistent numbering

schemes, headers, fonts, and a good table of contents make your
documents easier to read, understand, and use. Even a well-written
requirement can be rendered useless if it's poorly formatted. Formatting is
a simple thing, but it's often overlooked in the rush to get the
requirements "done." Document templates can help, as can simple
formatting standards for requirements documents.

Accessibility, Security, and Version Control

Have you ever become frustrated because you couldn't find a

requirements document? At Level Two, you need a central, well known
location for the requirements, one that is accessible by all users. Think
about security, too. Whether you use simple file system security or a more
sophisticated technique, limiting the ability to modify requirements to
authorized persons only can help ensure the requirements' integrity.

Instituting version control for your requirements can also save time and
prevent frustration by ensuring that you always know whether or not you
are working on the most current versions of the specifications. In addition,
you will always know who has made a change and why they made it.

These are not the only benefits of getting to Level Two, because you will
automatically enhance the advantages of Level One. When your
requirements are more readable and easier to understand (and more
trustworthy), you will have a better basis for a contract with the customer,
the development team will find the requirements easier to use, and new
staff will be able to come up to speed more quickly.
Costs associated with getting to Level Two relate mostly to training and
review. Writing quality requirements is not a simple task. Unless you are
lucky enough to have skilled analysts already on staff, you will have to
train your team. Getting to, and staying at, a given maturity level will
require consistent review of requirements documents and some level of
"process enforcement." These are additional tasks that take time.

Of course, these costs are counterbalanced by the obvious advantages in

ensuring that the requirements are right: less rework and better customer
acceptance, to name two. If you have to get it right the first time, the
costs are probably worth it.

Level Three -- Structured

Getting to Level Three involves being more specific about the "types" of
requirements you gather. Are they functional or nonfunctional? Business
or system? Features or software requirements? How about customer,
marketing, and user requirements? Making these distinctions helps you
get a better understanding of the requirements and manage them better.
Getting to Level Three also means adding information about the
requirements, beyond the basic text. You can provide this additional
information in the form of "attributes," which will help you take a big step
up in managing and reporting on the requirements.

Getting Your Types Straight

As you think about the many possible types of requirements, you should
consider two particular issues.

The first issue arises if you do not distinguish among different types of
requirements. If your current requirements specification simply contains a
big list of requirements with no indication of their type, it is likely that the
list contains a mix of different types. For example, one requirement might
be "The supplier's help desk shall respond to 90 percent of all trouble
tickets within four hours," and another might be "The system shall support
automatic checking of prerequisites."

Although these are both valid requirements, they are clearly directed at
different concerns. The first is a requirement for the support organization
of the company supplying the software; the second is a specification for
what the software must do. Without indications of type, a long list of
requirements can cause confusion and waste readers' time. Those looking
for software requirements will get distracted by the support requirements,
and vice versa. It is also difficult to run a report, for example, to show all
of the software requirements.

The second issue relates to having requirement types but no agreement

on what they mean. An interesting exercise in such a case is to ask team
members who must use the requirements to write definitions for the
various requirement types. You might be surprised at the variety of
interpretations. Clearly, if one person defines a "user requirement" as "a
business need the end user thinks the future system must perform so that
he can do his job" and another defines it as "a requirement for the user
experience," then there is a problem.

Attributes

Let's turn now to the concept of requirements attributes, another Level

Three capability. All requirements are not created equal: Some are more
important than others; some are more stable than others; some may be
intended for one release, some for another release. These are important
things to keep track of, and adding attributes for requirements can help
you do so. Attributes include information that supplements the
requirement text and helps you better understand and manage your
requirements.

But how do you know what attribute information is needed? It depends on

the needs of those who will use the requirements information. One
common mistake is to blindly use a predefined set of attributes from
another project or requirements tool (like the one that comes with
Rational® RequisitePro,® for example). Project templates are a great
start, but you will likely have to modify the template to your needs.
Otherwise, it may saddle you with attributes that you don't need and omit
many you do need. For a large project that assigns requirements to
different analysts, an "owner" attribute would be very useful; but such an
attribute may not make sense for a small project on which one person
"owns" all the requirements. You need to understand how the
requirements will be used in order to understand what attributes are
necessary. What reports and queries will you need to support? What
metrics must you keep? Getting answers to these questions up front will
help you start on the right foot.

Benefits of getting to Level Three revolve around better understanding and

easier management. Well-structured requirements clearly identify different
requirement types, and attributes provide the ability to query and filter
groups of requirements; this means that team members have to do far
less detective work and guesswork to identify their responsibilities and
tasks. Better typing of requirements also provides greater assurance that
the team has identified all important requirements. The main cost of
getting to Level Three is in planning and maintenance. Determining
appropriate requirement types and attributes is not a trivial task. A mini-
project in itself, it involves talking to the requirements users to determine
what they need. Usually this information is captured in a Requirements
Management Plan (RMP). Then, requirements attributes are of little use if
they are not kept up-to-date, so there is a maintenance burden that goes
beyond the one for Level Two. There is an increased cost too, because
determining the correct attribute values takes time. Often, when
organizations get to Level Three, they institute the use of a requirements
management tool (like Rational RequisitePro). This has large benefits that
often outweigh the cost of purchasing, updating, and administering the
software.

Level Four -- Traced

Implementing the previous three levels will get you to the point where you
can determine and track requirements relationships. Most systems of any
significant complexity will have a hierarchy of requirements. In a systems
engineering environment, this hierarchy starts with system requirements
and moves down to subsystem requirements, program requirements, and
element requirements. In the Rational Unified Process, the hierarchy starts
with user needs, proceeds to features, and then goes on to use cases. The
ability to keep track of these relationships is commonly called traceability,
and it entails identifying and documenting the derivation path (upward)
and allocation/flowdown path (downward) of requirements in the
hierarchy. Traceability provides the ability to understand how changes to
one requirement might affect others (impact analysis) and can also help
determine if your requirements are complete (coverage analysis).

Usually, an organization at Level Four will develop an explicit traceability

strategy prior to starting a project and then document it in the
requirements management plan. The strategy will define the requirements
levels and how they fit in the hierarchy. In addition, it will lay down some
"rules" for requirements relationships. For example, one rule might be that
for every "user need" there must at least be one "feature," and for each
feature there must be at least one use case. Implementing a requirements
management process like this sets up capability for sophisticated
reporting, as we described earlier.

Coverage analysis reports show whether each high-level requirement has

a lower level requirement associated with it. This helps you determine
whether you have coverage holes. For example, if you have a feature that
does not have a use case associated with it, the resulting software may be
missing functionality. Or if you have a use case with no associated feature,
you may be implementing functionality with no business value.

Impact analysis reports are primarily intended for managing change. They
clearly show how a change to one requirement may impact others, which
makes it much easier to either justify or resist changes. For example, if
someone desires to change a feature, and an impact report shows that
doing so will cause changes to several use cases (and slow down the
project schedule), it is easier to see how to weigh costs against benefits
for the feature change.

These benefits of tracing requirements are significant, but again, they are
not without cost. The effort involved in entering and maintaining the trace
relationships is not trivial. Defining, running, and analyzing the coverage
and impact reports takes time and effort. Requirements tracing can be
done manually via simple tables in Word or Excel in very small projects,
but complex projects often need a requirements management tool like
Rational RequisitePro. The benefits of using such a tool are significant, but
as we noted earlier, there is a cost associated with purchasing,
maintaining, and providing training for the tool.

Level Five -- Integrated

It is often the case that requirements are used up front to get agreement
from the customer on what the software is supposed to do, but then those
requirements are not really tied in to the way the software is developed.
This results in stale requirements and software that doesn't meet its
objectives. Reaching Level Five means integrating the requirements
management process with the rest of your software development
environment. It means using requirements directly in software design,
change management, testing, and project management.

Software that does what the customer expects is built to comply with the
requirements -- that is, the team's software development process uses the
requirements as a key input. The system's architects and designers follow
a process to ensure that all of the requirements are implemented in the
design; the Rational Unified Process does this by treating use cases as the
input artifact for the analysis and design discipline.

Integrating requirements into your change management process helps

ensure that no changes are made to requirements without review and
approval. And relating each change request to an existing or new
requirement helps to limit feature creep.

Requirements-based testing is also an important part of verifying that the

software meets its objectives. Just as designers must use requirements to
design the system, testers must use them to create test cases and other
testing artifacts.

Since requirements are the basis for the whole development process,
project managers should have direct access to a project's status in relation
to the requirements. This includes metrics about new requirements,
requirements implemented, requirements tested, and requirement change
requests.

A comprehensive, requirements-based software development process as

described here takes significant planning, training, and process
enforcement. Software development tools are also an important part of
implementing such a process. Visual modeling tools such as Rational
Roseý or Rationalý XDE,ý change management tools such as Rationalý
ClearQuest,ý requirements management tools such as Rational
RequisitePro, and project status reporting tools such as Rationalý
ProjectConsole, can all significantly enhance your organization's ability to
get to the highest level of RM maturity. Again, although these tools have
clear benefits, they also have associated costs for purchase, maintenance,
and training.

Requirements Management Tool Support

Until Level Five, it is theoretically possible to do everything that we have
talked about either "manually" or with general-purpose tools like a word
processor and spreadsheet. However, starting at Level Two, an RM tool
can help you be far more efficient and consistent. Table 1 shows how the
important features of Rational RequisitePro support key characteristics of
the five RM maturity levels.

Table 1: How Rational RequisitePro Supports RMM Levels

 Rational RequisitePro Feature Maturity Level
Dynamic integration between Microsoft Word ® and One -- Written
requirements database Two --Organized
Secure central requirements repository Two -- Organized
User security Two -- Organized
Requirements revision history Two -- Organized
Web interface Two -- Organized
Requirements project templates Three -- Structured
User-defined requirement types, requirements
Three -- Structured
attributes, and document types
Requirements attributes and query capability Three -- Structured
Requirements traceability and coverage analysis Four -- Traced
Impact of requirement change Four -- Traced
Integrations with other software development tools Five -- Integrated

RUP Support
The five levels we have been talking about encompass a requirements
management process. A process determines and documents who does
what, when they do it, and what things they produce. It takes time and
effort to decide what the process should be and then to document it. An
organization can save resources by not reinventing the wheel, and by
adapting a standard process to suit their own needs. The Rational Unified
Process (RUP), for example, is divided into disciplines, one of which is the
Requirements Management Discipline. If you look at that discipline, you
will notice that it contains a workflow detailing many of the concepts we
have talked about here. Starting with RUP can give an organization a
valuable head start on improving RM maturity.

Evaluate and Move Up

The goal of this article has been to describe the best practices
organizations adopt as their requirements management efforts mature,
and they move to new levels of sophistication. The five levels we described
should provide a framework for you to evaluate your own organization and
understand where you stand and what needs improvement. It should also
provide a way for you to understand the benefits and costs involved in
moving up to higher levels of requirements management maturity.

For more information on the products or services discussed in this

article, please click here and follow the instructions provided.
Thank you!

Copyright Rational Software 2003 | Privacy/Legal Information

Copyright Rational Software 2001 http://www.therationaledge.com/content/dec_00/t_usecase.html

Features, Use Cases, Requirements, Oh My!

by Dean Leffingwell
Senior Vice President of Process and Project Management
Rational Software

As a follower and proponent of object-oriented (OO) technology in the

BU (Before UML) days, I must admit to a certain fascination with the
various methods and notations spread by the industry thought leaders
at the time. At about two to four years BU, if we had walked into a
room full of OO advocates and asked the following question:

I think this OO technology shows great promise; but tell me,

since the object shares behavior and data, what do you call
this thing an object does to fulfill its behavioral obligations?

We might have gotten the following answers:

"It's a responsibility!" (Wirfs-Brock)

"It's an operation!" (Booch)

"It's a service!" (Coad/Yourdon)

"It's a (virtual) function!" (Stroustrup)

"It's a method!" (many others)

And if this array of answers seems confusing, don't even think about
the range of responses we would have elicited by asking how you would
graphically represent that thing we call an object and a class (e.g., "It's
a rectangle," "It's a cloud," "It's a. . . whatever."). While these
differences might seem inconsequential, the reality is that some of the
most significant shared concepts among our software engineering
leaders -- inheritance, relationships, encapsulation -- were obscured by
minor differences in terminology and notation. In other words, neither
the science of OO engineering nor the benefits to be gained could
advance further because the language to describe the science had not
yet been invented. Of course, gaining agreement among these authors,
methodologists1, and independent thinkers was not a trivial matter, but
eventually, along came the UML, and the science of software
engineering marched forward again.

While it's perhaps not as bad as the Tower of Babel wrought by the pre-
UML competing OO methodologies, the methodology of requirements
management suffers from some of the same issues -- specifically, the
prevalence of ambiguous, inconsistent, and overloaded usage of
common terms. These terms, including such seminal constructs as "Use
Cases," "Features," and "Requirements," we assume are common,
everyday terms that "everyone understands." In truth, however, each
individual attaches his or her own meaning to these terms within a
given context. The result is often ineffective communication. And this
occurs in a domain wherein success is defined simply by having
achieved a common understanding.

Booch [Booch 1994] points out that Stepp observed:

. . .an omnipresent problem in science is to construct

meaningful classifications of observed objects and situations.
Such classifications facilitate human comprehension of the
observations and subsequent development of a scientific
theory.

In order to advance the "scientific theory" of requirements, we have to

come to terms with terms!

The purpose of this article is to take a small step forward in the

discipline of software engineering by defining and describing some of
the most common terms and concepts used in describing requirements
for systems that contain software. In doing so, we hope to provide a
basis for common understanding among the many stakeholders
involved: users, managers, developers, and others. Certainly if we
communicate more effectively and establish a common view, it will be
possible to more quickly develop and deliver higher quality systems.

This article is not an overview of the requirements management

discipline -- for that we refer you to a number of books on the topic
listed under the heading "Suggested Reading." The goal of this article is
simply to help practitioners in the field improve their ability to answer
the following, fundamental question:

"What, exactly, is this system supposed to do?"

The Problem Domain vs. the Solution Domain

Before we start describing specific terms, however, it's important to
recognize that we will need to define terms from two quite different
worlds -- the world of the problem and the world of the solution. We'll
call these the problem domain and solution domain, respectively.

The Problem Domain

If we were to fly over the problem domain at a fairly low level, we

would see things that look very much like the world around us. If we
flew over the HR department, we might see employees, payroll clerks,
and paychecks. If we flew over a heavy equipment fabricator, we might
see welders, welding controllers, welding robots, and electrodes. If we
flew over the World Wide Web, we'd see routers and server farms, and
users with browsers, telephones, and modems. In other words, in any
particular problem domain we can most readily identify the things
(entities) that we can see and touch. Occasionally, we can even see
relationships among those things; for example, there seems to be a one-
to-one relationship between Web users and browsers. We might even
see messages being passed from thing to thing -- e.g., "That welder
appears to be programming a sequence into a welding robot's 'brain.'"

If we were really observant, we might see things that look like problems
just waiting to be resolved: "The welder seems really frustrated with his
inability to get the sequence right," or "Notice that nasty time delay
between the time that employee enters her payroll data and the day
she receives her check!"

Some of the problems seem to just beg for a solution. So we say:

"Perhaps we can build a system (a better programmable controller, a
more efficient payroll processing) to help those poor users down there
fix those problems."

On User and Stakeholder Needs

Before we build that new system, however, we need to make sure that
we understand the real needs of the users in that problem domain. If
we don't, then we may discover that the welder was grimacing only
because he was suffering from a painful corn on his toe, so neither he
nor his manager is interested in purchasing our brand new "SmartBot"
automated welding control unit. We might also notice that when we try
to sell the SmartBot, the manager seems
to emerge as a key stakeholder in the
purchasing decision. We don't remember
seeing her in our fly-over. (Perhaps she
was in the smoking lounge; our cameras
don't work as well in there.) In other
words, not all stakeholders are users, and
we have to understand the needs of both
communities (stakeholders and users) if we hope to have a chance to
sell the SmartBot. To keep things simple, we call all of these needs
stakeholder needs, but we'll constantly remind ourselves that the
potential users of the system appear to represent a very important
class of stakeholders indeed.

We'll define a stakeholder need as:

. . .a reflection of the business, personal, or operational

problem (or opportunity) that must be addressed to justify
consideration, purchase, or use of a new system.

Stakeholder needs, then, are an expression of the issues associated

with the problem domain. They don't define a solution, but they provide
our first perspective on what any viable solution would need to
accomplish. For example, if we interview the plant manager for a heavy
equipment fabricator, we may discover that welding large, repetitive
weldments consumes a significant amount of manufacturing time and
cost. In addition, welders don't seem to like these particular jobs, and
they are constantly in danger of burnout. Worse still, the physical
aspects of the job -- repetition, awkward manual positions, danger to
eyesight, and so on -- present personal safety issues and long-term
healthcare concerns.

With these insights, we could start defining some stakeholder needs:

We need an automated way to fabricate large, repetitive

weldments without the welder having to manually control the
electrode.

We are happy to have a welder present, but we need to

remove him to a safety zone outside of the welding area and
away from any moving machinery.

We need an easy-to-use "training mode" so that average

welders can "train" the machine to do the majority of the
welding for them.

We need to allow more flexibility in the training mode and

recognize that this may contradict some aspects of the need
for user-friendliness.

As we understand these various aspects of the system, we'll mentally

"stack" these discoveries in a little pile called "stakeholder needs."

The Solution Domain

Fortunately, our fly-over of the problem domain doesn't take very long,
and (usually) what we find there is not too complicated. We start to
appreciate the problem when we leave the airplane, and set off to build
a solution to the problems and needs we have observed. Yes, we've
reached the beginning of the hard part: forming a solution to the
problem. We consider the set of activities (system definition, design,
and so on), the "things" we find and build to solve the problem
(computers, robot arms, and the like), and the artifacts we create in the
process (such as source code, use cases, and tests) part of the
solution domain.

In the solution domain, there are many steps and activities we must
successfully execute to define, build, and eventually deploy a successful
solution to the problem. They include:

1. Understand the user's needs

2. Define the system
3. Manage the scope and manage change
4. Refine the system definition
5. Build the right system
In a nutshell, the steps above define a simplified process for
requirements management. This paper won't discuss these steps in
much detail; for this we refer you to the Bibliography and Suggested
Reading, including the text, Managing Software Requirements
[Leffingwell, 1999]. The ideas in this paper are consistent with those in
that text, and most of the definitions provided here are taken from it.

The text defines requirements management as:

. . .a systematic approach to eliciting, organizing, and

documenting the requirements of the system, and a process
that establishes and maintains agreement between the
customer and the project team on the changing requirements
of the system.

But let's move on to discovering and defining more of the requirements

management terms we'll need to describe the system we are about to
build.

Common Requirements Terms in the Solution

Domain

Features of a Product or System

As we start thinking about solutions to the problems we've identified,

it's very natural to start jotting down the features of a system. Features
occupy an interesting place in the development of a system. They fit
somewhere between an expression of the user's real needs and a
detailed description of exactly how the system fulfills those needs. As
such, they provide a handy construct -- a "shorthand", if you will -- for
describing the system in an abstract way. Since there are many
possible solutions for the problem that needs to be solved, in a sense
features provide the initial bounds of a particular system solution; they
describe what the system is going to do and, by omission, what it will
not do.

We'll define a feature as:

. . .a service that the system provides to fulfill one or more

stakeholder needs.

Features are easily represented in natural language, using terms

familiar to the user. For example:

The system runs off standard North American power.

The tree browser provides a means to organize the defect

information.

The home lighting control system has interfaces to standard

home automation systems.
 Since features are derived from
stakeholder needs, we position them at the
next layer of the pyramid, below needs.
Note that we've also moved from the
problem domain (needs) to the first level
of the solution domain (features).

It's important to notice that features are

NOT just a refinement (with increasing
detail) of the stakeholder needs. Instead,
they are a direct response to the problem
offered by the user, and they provide us
with a top-level solution to the problem.

Typically, we should be able to describe a system by defining 25-50

features that characterize the behavior of that system. If we find
ourselves with more than 50 features on our hands, it's likely that
we've insufficiently abstracted the true features of the system. Or the
system may be too large to understand, and we may need to consider
dividing it into smaller pieces.

Features are described in natural language so that any stakeholder who

reads the list can immediately gain a basic understanding of what the
system is going to do. A features list usually lacks fine-grained detail.
That's all right. Its purpose is simply to communicate the intent and,
since many stakeholders are likely to be non-technical, too much detail
can be confusing and may even interfere with understanding. For
example, a partial list of features for our SmartBot automated welding
robot might include:

A "lead through path" training mode that allows the welder to

teach the robot what paths will be welded.

A "step-and-repeat" feature that supports repetitive welding

sequences.

Use Cases

As we think further about the way in which the system needs to do its
job for the user, we might find it beneficial to employ the Use Case
Technique for further describing system behavior. This technique has
been well developed in a number of books [Jacobson 1992] and is also
an integral technique in the industry-standard Unified Modeling
Language (UML) [Booch 1999].

Technically, a use case:

. . .describes a sequence of actions, performed by a system,

that yields a result of value to the user.

In other words, the use case describes a series of user and system
interactions that help users accomplish something they wanted to
accomplish. Stated differently, the use case describes HOW users and
the system work together to realize the identified feature.

Use cases also introduce the construct of an actor, which is simply a

label for someone who is using the system at a given time. In UML, a
use case is represented by a simple oval; an actor is represented by a
stick figure with a name. So we can illustrate both with a simple
diagram like the one below.

The use case technique prescribes a simple, step-by-step procedure for

how the actor accomplishes the use case. For example, a use case for
Step and Repeat might start out as follows:

Step 1: The welder presses the "Step and Repeat"

button to initiate the sequence.

Step 2: The welding system releases power to the

drive motors so that the robot's arms can be moved
manually.

Step 3: The welder grabs the trigger, moves the arm

to the weldment, and holds down the "Weld Here"
button for each path to be welded.

The use case technique provides a number of other useful constructs,

such as pre and post descriptions, alternate flows, and so on. We'll talk
about these later as we examine the use case in more detail. For now,
we simply need to know that use cases provide an excellent way to
describe how the features of the system are achieved.

For planning purposes, it's likely that more than use cases will be
necessary to describe how a particular feature is implemented. A small
number of use cases (perhaps 3-10) may well be necessary for each
feature. In describing the use cases, we are elaborating on the behavior
of the system. Detail increases as we achieve additional specificity.

Vision Document
 Many development projects use a Vision document that
defines the problem, identifies key stakeholders and user
needs, lists system features, and perhaps includes example
use cases. This document may be called by a variety of other
names: Project Charter, Product Requirements Document,
Marketing Requirements Document, and so forth. No matter what it's
called, the Vision document highlights the overall intent and purpose of
the system being built. It captures the "gestalt" of the system, using
stakeholder needs, features, and use cases to communicate the intent.

We cannot, however, simply dump features and initial use cases into
the hands of the development team and expect them to rush off and
develop a system that really satisfies stakeholder needs. We need to be
a lot more definitive about what we want the system to do, and we'll
probably have to add a lot of new stakeholders, including developers,
testers, and the like. That's what happens in the next layer of the
system definition -- the software requirements.

Software Requirements

Software requirements provide the next

level of specificity in the requirements
definition process. At this level, we specify
requirements and use cases sufficiently for
developers to write code and testers to see
whether the code meets the requirements.
In our graphical representation, software
requirements are at the base of our
pyramid.

What is a software requirement? Although

many definitions have been used
throughout the years, we find the
definition provided by requirements
engineering authors Dorfmann and Thayer
[Dorfmann 1990] to be quite workable.
They say that a software requirement is:

. . .a software capability needed by the user to solve a

problem that will achieve an objective

OR

a software capability that must be met or possessed by a

system or system component to satisfy a contract, standard,
specification or other formally imposed documentation.

Applying this definition, the team can develop a more specific set of
requirements to refine, or elaborate, the features list discussed earlier.
Each requirement serves some feature and vice versa. Notice the
simplicity of this approach. We have a list of features, and we then
elaborate those features by writing a set of requirements that serve
those features. We don't write any other requirements. We avoid the
temptation to sit down, stare at the ceiling, and "think up some
requirements for this system."

The process is straightforward but not necessarily easy. Each feature is

reviewed, and then requirements are written to support it. Inevitably,
writing the requirements for one feature will spur ideas for new
requirements or revised requirements for a feature that has already
been examined.

Of course, as we know, it's not easy to write down requirements -- and

there may be a large number of them. It's helpful to think about three
types or categories of software requirements: functional requirements,
nonfunctional requirements, and design constraints.

We find these three categories helpful in

thinking about the requirement and what
role we expect it to fill. Let's look at these
different types of requirements and see
how we can use them to define different
aspects of the proposed system.

Functional Requirements
Functional requirements express what the
system does. More specifically, they
describe the inputs and outputs, and how it
is that specific inputs are converted to
specific outputs at various times. Most
business software applications are rich with functional requirements.
When specifying these requirements, it's important to strike a balance
between being too vague ("When you push the 'On' button, the system
turns on") and being too specific about the functionality. It's important
to give designers and implementers as wide a range of design and
implementation choices as possible. If we're too wishy-washy, the team
won't know what the system is supposed to achieve; if we're too
specific, we may impose too many constraints on them.

There isn't one right way to specify requirements. One technique is

simply to take a declarative approach and write down each detailed
thing the system needs to do. For example:

During the time in which the "Weld Here" input is active, the
system digitizes the position of the electrode tip by reading
the optical encoders every 100 msec.

Elaborating the Use Case

In many systems, it's helpful to organize the specification activity by
refining the use cases defined earlier and developing additional use
cases to fully elaborate the system. Using this technique, we refine the
steps of the use case into more and more detailed system interactions.
We'll also need to define pre-conditions and post-conditions (states the
system assumes before and after the use case), alternative actions due
to exception conditions, and so on.

Since use cases are semantically well defined, they provide a structure
into which we can organize and capture the system behavior. Here is a
representative use case for the Smartbot.

Use Case Name Teach Weld Path

Actor Welder
This use case prescribes the way in
Brief Description which the welder teaches the robot a
single weldment path operation.
Basic flow for the use case begins
when the welder presses the "Teach"
button on the control console.

The system turns off the power to the

robot arms.

The welder grabs the teaching

electrode and positions the teaching
tip at the start of the first weld.
Flow of Events
The welder presses the "Weld Here"
trigger and simultaneously moves the
teaching tip across the exact path to
be welded.

At the end of the path, the welder

releases the "Weld Here" trigger and
then returns the robot's arm to the
rest position.
At any time during the motion, the
welder can press the "Pause" button;
then the robot will turn on power to
Alternative Flow of Events
the motors and hold the arms and
teaching tip in the last known
position.
The robot must have performed a
Pre-conditions
successful auto-calibrate procedure.
The traverse path and weld paths are
Post-conditions
remembered by the system.
The welder cannot move the tip at a
rate faster than 10cm/second. If
faster motion is detected, the system
Special Requirements
will add resistance to the arms until
the welder returns to the acceptable
lead-through speed.

Nonfunctional Requirements
In addition to functional requirements such as inputs translating to
outputs, most systems also require the definition of a set of
nonfunctional requirements that focus on specifying additional system
"attributes," such as performance requirements, throughput, usability,
reliability, and supportability. These requirements are just as important
as the input-output oriented functional requirements. Typically,
nonfunctional requirements are stated declaratively, using expressions
such as "The system should have a mean time between failure of 2,000
hours;" "The system shall have a mean time to repair of 0.5 hours;"
and "The Smartbot shall be able to store and retrieve a maximum of
100 weld paths."

Design Constraints
As opposed to defining the behaviors of the system, this third class of
requirements typically imposes limitations on the design of the system
or process we use to build the system. We'll define a design constraint
as:

. . .a restriction upon the design of a system, or the process

by which a system is developed, that does not affect the
external behavior of the system, but must be fulfilled to meet
technical, business, or contractual obligations.

A typical design constraint might be expressed as "Program the welder

control unit in Java." In general, we should treat any reasonable design
constraints just like any other requirements, although testing
compliance to such constraints may require different techniques. Just
like functional and nonfunctional requirements, these constraints can
play an integral role in designing and testing the system.

Hierarchical Requirements
Many projects benefit from expressing requirements in a hierarchical or
parent-child structure. A parent-child requirement amplifies the
specificity expressed in a parent requirement. Parent-child requirements
give us both a flexible way to enhance and augment a specification, and
a means to organize levels of detail. The parent, or top-level
specification, is easily understandable to all users; implementers can
inspect the more detailed "child" specification to make sure that they
understand all of the implementation details. Note that hierarchical
requirements consist of the standard three types of requirements:
functional, non-functional, and design constraints. The hierarchical
approach simply defines the elaboration relationship among
requirements.

Traceability

In addition to defining the terms we use for things that describe system
requirements, we should now turn to a key relationship, traceability,
which may exist among these things.

A significant factor in quality software is the ability to understand, or

trace, requirements through the stages of specification, architecture,
design, implementation, and test. Historical data shows that the impact
of change is often missed, and small changes to a system can create
significant reliability problems. Therefore, the ability to track
relationships, and relate these relationships when change occurs, is key
in software quality assurance processes. This is particularly the case for
mission critical activities, including safety-critical systems (medical and
transportation products), systems with high economic costs of failure
(online trading), and so on. Here's how we define requirements
traceability:

A traceability relationship is a dependency in which the entity

(feature, use case, requirement) "traced to" is in some way
dependent on the entity it is "traced from."

For example, we've described how one or more Software Requirements

are created to support a given feature or use case specified in the
Vision document. Therefore, we can say that these Software
Requirements have a traceability relationship with one or more
Features.

Impact Analysis and Suspectness

A traceability relationship goes beyond a simple dependency
relationship because it provides the ability to do impact analysis using a
concept that we call "suspectness." A traceability relationship goes
"suspect" whenever a change occurs in the "traced from" (independent)
requirement, and therefore the "traced to" (dependent requirement)
must be checked to ensure that it remains consistent with the
requirement from which it is traced.

For example, if we use traceability to relate requirements to specific

tests, and if a requirement such as "The Smartbot shall be able to store
and retrieve a maximum of 100 weld paths" becomes "The Smartbot
shall be able to store and retrieve a maximum of 200 weld paths," then
the test traced from this requirement is suspect. It is unlikely any test
devised for the first requirement will be adequate to test the second
one.

Change Requests and the Change Management

System

Finally, change is inevitable. For a project to have any hope of

succeeding, a process for managing all changes -- including requests
that affect features and requirements -- in an orderly manner is
essential. The key element of any change management system is the
Change Request itself. We'll define a Change Request as:

. . .an official request to make a revision or addition to the

features and/or requirements of a system.

Change Requests need to enter the system as structured, formalized

statements of proposed changes and any particulars surrounding those
changes. In order to manage these changes, it's important that each
one have its own identity in the system. A simple Change Request form
might look something like this:
Change Request

Change Request Item Value

Change Request ID CR001

Change Request Name Safety Feature on "Power On" Button

Add hold time to "Power On" button

that requires user to hold button
Brief Description of Change
for xx seconds before system turns
on.

Requested by... Safety Supervisor

A change management system should be used to capture all inputs and

transmit them to the authority of a Change Control Board (CCB) for
resolution. The CCB should consist of no more than three to five people
who represent the key stakeholders for the project (customers,
marketing, and project management). They administer and control
changes to the system, and thereby play a key role in helping the
project succeed.

Summary
At the beginning, we noted that a goal of this article was to help
practitioners in the field improve their ability to answer the fundamental
question:

"What, exactly, is this system supposed to do?"

As a step toward this goal, we defined and described some of the

common terms -- such as stakeholder needs, features, use cases,
software requirements, and more -- used by analysts and others who
have responsibility for describing issues in the problem domain, and for
expressing the requirements to be imposed upon any prospective
solution. In so doing, we also illustrated some of the key concepts of
effective requirements management. By using the terms and
approaches outlined in this article, you can better understand your
user's needs and communicate requirements for proposed solutions to
developers, testers, and other technical team members.

The Unified Modeling Language (UML) is an important technique for

further defining and communicating additional key aspects of software
solutions. A language for visualizing, specifying, and documenting the
artifacts of a software-intensive system, it provides a means for
expressing these technical constructs in a more semantically precise
manner. The User Guide and Reference Manual for UML listed below
provide practical advice on its use.

Suggested Reading
Leffingwell, Dean, and Don Widrig. Managing Software Requirements:
A Unified Approach. Reading, MA: Addison Wesley Longman, 1999.
Weigers, Karl. Software Requirements. Redmond, WA: Microsoft Press,
1999.

Bibliography

Booch, Grady. Object-Oriented Analysis and Design with Applications,

2nd ed. Redwood City, CA: Benjamin Cummings, 1994.
Booch, Grady, James Rumbaugh, and Ivar Jacobson. The Unified
Modeling Language User Guide. Reading, MA: Addison Wesley
Longman, 1999.
Dorfmann, Merlin, and Richard H. Thayer. Standards, Guidelines, and
Examples of System and Software Requirements Engineering. Los
Alamitos, CA: IEEE Computer Society Press, 1990.
Jacobson, Ivar, Magnus Christerson, Patrik Jonsson, and Gunnar Över-
gaard. Object-Oriented Software Engineering: A Use Case Driven
Approach. Harlow, Essex, England: Addison Wesley Longman, 1992.
Rumbaugh, James, Ivar Jacobson, and Grady Booch. The Unified
Modeling Language Reference Manual. Reading, MA: Addison Wesley
Longman, 1999.

1At Rational Software, it has been my privilege to work with some of

the industry's leading methodologists -- Grady Booch, Ivar Jacobson,
Jim Rumbaugh, Philippe Kruchten, Bran Selic, and others. While this
has been a rewarding and fascinating part of my career, it's not
something I could recommend for everybody. In other words, please do
NOT try this at home.

For more information on the products or services discussed in

this article, please click here and follow the instructions
provided. Thank you!

Copyright Rational Software 2000 | Privacy/Legal Information

Copyright Rational Software 2001 http://www.therationaledge.com/content/may_01/t_legacy_pk.html

Using the RUP to Evolve a Legacy System

by Philippe Kruchten
Rational Fellow
Rational Software Canada

Some people claim that the Rational Unified

Process™ (RUP) is only useful for "green
field" development, that is, the development
of a brand new system, from the ground up,
in an empty green field. They contend that
it cannot be used for further development or
evolution of a "legacy" system. I strongly
disagree: I know that large portions of the
RUP can be used to evolve an existing
system. Actually, about 80 percent of the
sites where the RUP is used today include some form of legacy.

Assessing Your Legacy System

To determine whether a legacy evolution project is suitable for the RUP, I
would pose three preliminary questions to the development organization:

1. What characterizes your legacy system?

2. How do you want to evolve your legacy system?
3. Is your plan a sound business decision?

We'll discuss these in detail below.

What Characterizes Your Legacy System?

A legacy system has been defined as a system that "…significantly resists

modification and evolution to meet new and constantly changing business
requirements."1 It is usually implied that the system is large and old. And
in this context, the person asking this question also means "a system
whose original development was not done with the RUP."

If the original development was done with the Rational Unified Process,
then most of the artifacts you need would exist already in some form or
another. In this case, evolving the system could mean just adding one
more complete development cycle (inception, elaboration, construction,
and transition); inception and elaboration might be relatively small,
depending on the complexity of the proposed evolution. This is the case,
for example, if there are no significant architectural impacts. I would
classify this as a maintenance cycle, which I will discuss in a separate
article.

So let us assume that your legacy system was not developed with the
RUP. This means that the development artifacts, when they exist, do not
carry the usual RUP names, or are not in the form we expect them in the
RUP. Very often, they are just missing or obsolete, or so old that nobody
can trust them to still be relevant to the system. We can assume that
other techniques were used: the design was not done using object-
oriented technology, the requirements did not employ use cases, and so
on.

We also assume that the legacy system represents a significant asset (a

"legacy") that is really worth reusing in some form or another, as opposed
to scrapping it altogether. So the value of the current asset must be
assessed: Is its value in the code? The design? The requirements? Some
of the algorithms or data? Or just the market share that the product
commands? Unfortunately, the older the system, the harder it is to grasp
and use the existing assets. The software documentation is very often
obsolete, and the design must be reverse engineered (i.e., it requires
"design recovery"), sometimes from the code itself.

Having to deal with a legacy system is usually considered a negative, but

the existence of a "precedent" system to establish a point of comparison
and use as a source of information is, in fact, very valuable.
Unprecedented systems are much harder to define and develop.

In particular, your legacy system will enable you to easily identify:

● Requirements and business rules

● What is architecturally significant
● Primary use cases
● Users' priorities, wishes, and behaviors

The only danger is that the legacy system can be an anchor, stifling the
examination and consideration of fresher approaches.

How Do You Want To Evolve Your Legacy System?

There is a broad range of evolutionary changes that we might want to

undertake, from simple functionality extension, to a radical architectural
change, to complete redesign and reimplementation. And for each,
different technical solutions and levels of process formality will apply. Here
are examples of legacy system evolutions:

● Extension
● Cosmetic makeover
● Migration
● Redevelopment
● "All of the above"

Extension. In simple cases, you just need to add some functionality or

feature. Drivers such as regulation changes, emerging business needs, or
new features made available by the competition all require a
corresponding evolution of the existing system. With many legacy
systems, the older they are, the more difficult even simple additions
become. The cumulative effect of years of extension leads to a
degradation of the system's architectural integrity, thus increasing the
difficulty of extending that system.

Cosmetic makeover. Often you do not need to scrap the whole system,
but only to give it a new look, or perhaps take advantage of a new GUI
technology or interface. A solution based on wrapping certain components
of your system to give them a new interface or allow their re-
implementation can lead to an acceptable result with minimal
development. This is the case for many applications that need to be
rapidly "Web-enabled," for example.

Migration. Often the system has exceeded the useful life of its underlying
hardware, operating system, or middleware. It relies on technologies that
are either no longer maintained or very costly to keep alive. The solution
is to migrate the legacy system to a new platform (hardware or software),
preserving much of the existing software. For example, an application
developed for a DEC VAX VMS environment must rapidly be deployed on a
wide range of Unix- and Linux-based platforms. This was the case when
we migrated the Rational Environment (a product with two million lines of
code) from our own proprietary platform to a range of Unix-based
platforms, which led to the product known today as Rational Apex.
Whereas extension means adding new domain-specific behavior, migration
means adapting the legacy system to a different technology platform.
Migration has less tangible domain-specific value, but failing to do it in a
timely and efficient way can bring the whole show to a halt.

Redevelopment. If the legacy system is a mission-critical system that

has become extremely hard to evolve, that cannot scale up, and that
relies on obsolete hardware or software technologies, then you may have
to redevelop it. Usually you have to do this gradually, as you cannot afford
to lose your existing customer base. This was the case for the Canadian
Automated Air Traffic System, which was running on very old hardware
and an operating system more than twenty years old. You may object that
this option does not belong here; but even if you plan to rebuild a system
from scratch, you should exploit your legacy system to understand key
aspects of the new system. It contains a wealth of both positive and
negative experience and knowledge.

"All of the above." Finally, there are circumstances under which a

company may need to do a migration, cosmetic makeover, and
redevelopment in succession. They may need to rapidly move a legacy
system to a new platform and give the system a brand new look to satisfy
market demands, then redesign the system and gradually replace the old
code base, chunk-by-chunk, using new technology -- software
components, new language, and middleware -- in order to be able to
move forward. This is the most challenging and risky approach, but it can
be done. I recall a customer with a large MIS application containing
several million lines of RPG (Report Program Generator) code developed
on an IBM AS/400 platform that had to be converted to Java and capable
of running on the Web and a wide range of Windows and Unix systems.
They successfully redesigned and implemented the application in Java over
a period of two to three years, without too much disruption for the
installed based.

Is Your Plan a Sound Business Decision?

You do not evolve a legacy system just because it is there. You have to
ask whether changing the system makes sense. In general, it really is
reasonable to keep legacy systems around: their development or
acquisition is typically a sunk cost, and most likely there is no business
justification for scrapping them. There is also an opportunity cost,
however: given limited resources and infinite demand to build new things,
to maintain a legacy system is a decision not to spend those scarce
resources on new things. If you find that you are simply engaging in
preservation -- injecting resources into a system for emotional or historical
reasons rather than for meaningful business reasons, or because you have
not examined any alternatives -- then it is probably unreasonable to
continue maintaining the system.

Using the Rational Unified Process

If you do decide to pursue any of the legacy system evolutions we
described above, then the first things you can apply from the RUP are its
fundamental principles:

● Early risk mitigation

● Iterative development
● Progress assessment based on concrete, measurable evidence
● Organization around small, empowered teams
● Verifying quality continuously
● Scope management
● Producing only the artifacts that are needed

These principles are not specific to "green field" development; they apply
to any type of software development. This already makes the basic RUP
lifecycle template, with its four phases of Inception, Elaboration,
Construction, and Transition fully applicable to a legacy system project.
This in turn makes most of the Project Management activities of the RUP
fully applicable as well. Just because it is a legacy system, there is no
reason not to have a Vision Document, describing what it is you want to
achieve; a Project Plan, showing major milestones and what you want to
accomplish; maybe iterations and their specific objectives; and a Risk List.
You also need a Business Case, to be able to discuss the benefits of doing
the project and the approach you will take. This Business Case will be
based on an estimate of costs: staffing and other requirements (tools,
middleware, training), which, in turn, will depend on the extent of the
work to be accomplished. As you progress toward the Transition phase,
you will need a Deployment Plan, showing how the new system will be
deployed, replacing the old one.

Establishing a RUP-Friendly Baseline

To go beyond simply applying the RUP lifecycle and use other disciplines of
the RUP going forward, you need to establish a starting point. You must
identify a minimal set of essential artifacts describing the legacy system.
Depending on the scope of the evolution, you may need more or less of:

● Requirements
● Architecture and design
● Tests
● User documentation

Once you have established this baseline of RUP artifacts, you can proceed
with the legacy project as if it were a RUP Evolution cycle.

Establishing a minimal set of artifacts that will allow your project to

proceed as per the RUP requires some reverse engineering on your legacy
system. By reverse engineering, I mean trying to identify, extract, or
recreate enough information to enable you to proceed almost as if the
project had been originally developed using the RUP. This is the point at
which many project managers are ready to scrap the RUP for their legacy
project, as they perceive this reverse engineering effort to be a huge
waste of time. It does not need to be such an immense effort, though, as
the intent is not to recreate every single artifact, but to understand the
key attributes of the current system, and determine what should be
conserved and what should be replaced or upgraded.

Requirements. The most important value of the legacy system is to

provide a minimum specification for the new system. For example, when
we started Rational Apex, the first draft of our Vision Document stated
"…it has first to do everything that the Rational Environment (version
Delta) does, and do it no slower." Then we specified deviations from the
Rational Environment: features added, features dropped. A smart team
never retrospectively documents the requirements of a legacy system, so
you do not have to restart the requirements effort from scratch; you only
need to identify your key use cases. You probably have them already,
described in the current User's Manual. Just having an inventory of the use
cases (a Use Case Survey) may be enough. You will only need to detail the
use cases that need to change. Many of the nonfunctional requirements
can be derived from your marketing or installation documentation:
capabilities, size and performance characteristics, operating systems,
memory, peripherals, other software, general constraints, and most of the
"ilities." If you are not using a requirements management tool, then
maybe now is the right time to start doing this inventory.

Architecture and Design. Your legacy system does not need to be

completely redesigned using object-oriented (OO) techniques. You will,
however, need a minimal amount of architectural information. You can
create a minimal Software Architecture Document, starting from the
Implementation View: What are the various subsystems or main bodies of
code? And what are the critical interfaces? From this information you can
identify your Deployment View and your Process View, if the legacy
system is distributed. You will need a precise inventory of the existing
software, clearly identifying each element and the relationships among
them. If the software is not yet under configuration management, now is
the right time to start controlling it.

Describing the interfaces and the scenarios of how these interfaces are
exercised is crucial. Later on, you will identify the subsystems that are not
affected by the evolution: the stable, core, reusable chunks of the legacy
system. Do you need a detailed software design documentation as well as
these interface descriptions? If you have it and can trust it, that is nice,
but do not embark on a huge effort to produce it before you know what
pieces need to be changed. And even then, proceed on a case-by-case
basis. Tools can help you do this reverse engineering, which does not need
to exceed a few days of work.

Tests. Whatever tests, test scripts, test cases, and test harnesses were
developed for the legacy system will still be largely applicable for the new
system.

User Documentation. Unless there is an incentive to completely revamp

it, the user documentation for the legacy system can constitute a good
baseline for the new system. The RUP templates for these artifacts can be
used, as well as some of the associated guidelines and checkpoints. But
you probably want to tailor the templates first, to avoid falling into the
trap of documenting elements you do not need. In many cases, you can
"fill in" the templates (in your first pass) by cross-referencing; that is,
indicating in which existing document the corresponding information can
be found. If the existing documentation is online in HTML, then use a URL.

Finally, a good additional artifact to create while doing this reverse

engineering is a Glossary of terms used in the legacy system, collecting
terms as you encounter them. It will prove invaluable when going forward.

Note that this step of establishing a baseline is not RUP specific. Whatever
process or method you will use to go forward, you will need to do some
reverse engineering of the existing system. The Web site for
"Renaissance," an Esprit project on software reengineering, is a good
source of information on reverse engineering.1
Evolution: Going Forward with the RUP

Once you have established your minimal RUP artifact baseline, much of it
by reference to existing information, you can now proceed. Most of the
activities of the RUP apply, just as they do in Construction and Transition
iterations for a brand new development project. Yet, as always, try to
keep things as light as possible as you choose what to adopt from RUP; do
not execute activities or create artifacts that are unnecessary.

Requirements Management. Express new requirements using use

cases. You may have to recreate a use case for existing functionality to
better articulate what is being changed. If several use cases need to be
added or changed, you may find it useful to derive a small Domain Model
from your Glossary.

Architecture and Design. You might want to use object-oriented

techniques and the UML (Unified Modeling Language) for your new
development. A handy technique is to consider some of the least affected
subsystems as big composite classes, especially when you are doing
sequence diagrams. As you may have done for your use cases, you can
create a Design Model, but only go into details for the classes that are
architecturally important or that need to evolve. Proxies can be created for
these classes, mapping their functionality to the existing code.

If your long-term goal is ambitious and aims at a complete, gradual

replacement of the legacy system, you will have to do an architectural
design for the new system, and then map it to the existing subsystems.
You can create wrappers around some of the existing body of code to
make it look like it was designed using OO techniques. Reassembling the
complete system with the various wrappers can be an internal milestone in
your elaboration phase. As you go into use-case design, your use-case
realizations will show you the impact on various existing subsystems. Then
you can decide which of these "wrapped subsystems" need be converted,
ported, or rewritten.

In some limited cases, you might be able to use tools such as Rational
Rose to reverse engineer elements of your existing code into the UML. But
do not rely on using the results blindly; they will always require some
enlightened human interpretation.

Deployment. Depending on the scope of the evolution, deployment of the

new system may be more challenging than a green field development. If
you migrated the system to a new architecture or redeveloped significant
portions of it, you will have to choose a strategy: either to cut over "cold
turkey" from the old system to the new one, or use a phased strategy and
do the transition in small incremental steps. Or, you can even have both
systems working in parallel until the new one can be fully trusted. In
practice, deployment is often much more delicate with a legacy system
than a new application, as you need to tackle issues of data conversion,
continuity of operations, retraining of personnel, and so on.

Other Disciplines. Other software development disciplines, with all their

activities, guidelines, techniques, and tools, also apply: test and
implementation, for example. Configuration management may be more
relevant and required earlier in the project than for a new development, as
you start from day one with many existing artifacts, sometimes with
complex dependencies between them. In a legacy system upgrade,
change management becomes a dominant activity.

Often, the decision to redevelop a legacy system also represents an

opportunity to reengineer business processes, using business modeling,
which could lead to a different set of requirements for the new system.

Completing the RUP. When creating the development case for a legacy
system evolution project, you will notice that the RUP does not contain
activities or guidelines for reverse engineering, design recovery, database
conversion, or the technique of using "wrappers." These techniques are
very dependent on the state of the legacy system and the technologies it
uses, and it is hard to generalize them. See References 1, 2, and 4 below
for pointers to various approaches and techniques.

A RUP-Based Evolution Cycle

The RUP's Inception phase specifies that you produce a Vision Document
and Business Case, as well as an Initial Development Case specifying
which artifacts you need to recreate. In this phase you will also start the
process of reverse engineering for some of the artifacts: requirements and
architecture, mainly, in order to be able to choose the appropriate
evolution strategy and estimate its cost.

In the Elaboration phase, you will complete your RUP baseline, the
minimal set of artifacts that you need to go forward, including the
conversion of some older artifacts to the new tool set. For simple
extensions, this can be done in one short iteration. But if there are a large
number of architectural changes to go through, as in a migration strategy
or redevelopment, then you will have several iterations in this elaboration
phase to implement a new architectural baseline. It may even be that this
Elaboration phase is the dominant phase, and that there will be little to do
in Construction and Transition. Testing is put in place in the new
environment, and regression testing can start early. Unlike Elaboration for
a green-field development, there is from the beginning a large number of
artifacts -- code in particular -- to manage, and activities from the Change
and Configuration Management discipline have to be stressed earlier.

The Construction phase is not significantly different from any other RUP
project. Additional elements are reverse-engineered, redesigned, and
documented as necessary. Or they are just ported or translated into
another language.

The Transition phase may be more delicate, depending on the

deployment strategy to go from the old system to the new one; see the
section on Deployment above.

Clearly, the RUP is helpful in staging legacy evolutions, with very concrete
and measurable objectives for each iteration. Joe Marasco, the manager
for the Rational Apex project wrote:
 We decided which bits of functionality needed to be moved first,
which parts will be moved without touching them at all, which
will be moved in later iterations. The version on Sun OS was
postponed to a later iteration, once the version on AIX was
stable. Instead of seeing the butterfly emerge in one day from
the cocoon, you plan its metamorphosis and track its evolution
iteration by iteration. I cannot imagine managing the evolution
of a complex legacy system by any other means.

Limit the Changes

How do you apply the RUP to a legacy system?

● First, by understanding what you are trying to do.

● Second, by intelligently exploiting what you already have.
● Third, by focusing on the principles, and not necessarily the details,
of the RUP.

Large portions of the RUP can be used for the evolution of a legacy
system, with more or less tailoring and formality, depending on the type of
evolution you envisage and how much information on the legacy system is
at hand. How many of the RUP artifacts you need to actually develop by
extracting from, or reverse engineering, the existing system depends on
the complexity of the evolution and the degree of risk you can tolerate.

One caution: We have seen projects fail when too many changes were
attempted at the same time: A major evolution of a legacy system (e.g., a
migration to a new platform), at the same time as a change of process
(e.g., going to the RUP), and a change of tool set (e.g., going to Rational
Suites). It is preferable to introduce a new process and new tools during
an earlier project, before you undertake a major legacy evolution, so that
developers can become familiar with the RUP, its philosophy, and its
contents, as well as the tools that support it. Avoid multiplying risk for the
project by introducing too many unknowns and changes simultaneously.

Acknowledgments
Many thanks to my friends and colleagues for their help in assembling the
information this article, which is based on their own blood-and-sweat
experiences: Dean Leffingwell, Bruce MacIsaac, Joe Marasco, Walker
Royce, John Smith, Grady Booch, Craig Larman, as well as the many
participants in Rational's internal process discussion forum. They posed
the question, again and again, whether RUP can be used effectively for
legacy evolutions and provided valuable elements of the answer in this
article. Thanks also to Catherine Southwood for ironing out my Frenglish.

References
1. Jesús Bisbal et al, "Legacy Information Systems: Issues and
Directions." IEEE Software 16 (5), Sept. 1999, 103-111.
2. Michael Brodie and Michael Stonebraker, Migrating Legacy Systems.
San Francisco: Morgan Kaufmann Publishers, 1995.

3. Rational Unified Process 2001. Cupertino, California: Rational Software

Corporation, 2001.

4. The RenaissanceWeb: www.comp.lancs.ac.uk/projects/renaissance.

1Michael Brodie and Michael Stonebraker, Migrating Legacy Systems. San Francisco: Morgan
Kaufmann Publishing, 1995.

2 See The Renaissance Web: http://www.comp.lancs.ac.uk/projects/renaissance.

For more information on the products or services discussed in this

article, please click here and follow the instructions provided.
Thank you!

Copyright Rational Software 2001 | Privacy/Legal Information

Copyright Rational Software 2001 http://www.therationaledge.com/content/jun_01/m_cases_jh.html

Generating Test Cases From Use Cases

by Jim Heumann
Requirements Management Evangelist
Rational Software

In many organizations, software testing

accounts for 30 to 50 percent of software
development costs. Yet most people believe
that software is not well tested before it is
delivered. That contradiction is rooted in two
clear facts: First, testing software is a very
difficult proposition; and second, testing is
typically done without a clear methodology.

A widely-accepted tenet in the industry -- and

an integral assumption in the Rational Unified
Process® (RUP®) -- is that it is better to start
testing as early in the software development
process as possible. Delaying the start of testing activities until all
development is done is a high-risk way to proceed. If significant bugs are
found at that stage (and they usually are), then schedules often slip.

Haphazard methods of designing, organizing, and implementing testing

activities and artifacts also frequently lead to less-than-adequate test
coverage. Having a straightforward plan for how testing is done can help
increase coverage, efficiency, and ultimately software quality.

In this article, we will discuss how using use cases to generate test cases
can help launch the testing process early in the development lifecycle and
also help with testing methodology.

In a software development project, use cases define system software

requirements. Use case development begins early on, so real use cases for
key product functionality are available in early iterations. According to the
RUP, a use case "…fully describes a sequence of actions performed by a
system to provide an observable result of value to a person or another
system using the product under development." Use cases tell the
customer what to expect, the developer what to code, the technical writer
what to document, and the tester what to test.

For software testing -- which consists of many interrelated tasks, each

with its own artifacts and deliverables -- creation of test cases is the first
fundamental step. Then test procedures are designed for these test cases,
and finally, test scripts are created to implement the procedures. Test
cases are key to the process because they identify and communicate the
conditions that will be implemented in test and are necessary to verify
successful and acceptable implementation of the product requirements.
They are all about making sure that the product fulfills the requirements of
the system.

Although few actually do it, developers can begin creating test cases as
soon as use cases are available, well before any code is written. We will
discuss how to do this, and the advantages you can reap from it, below.

An Introduction to Use Cases

Use cases are based on the Unified Modeling Language (UML) and can be
visually represented in use-case diagrams. Figure 1 shows a use-case
diagram depicting requirements for a university course registration
system.

Figure 1: Use Case Diagram for a University Course Registration System

The ovals represent use cases, and the stick figures represent "actors,"
which can be either humans or other systems. The lines represent
communication between an actor and a use case. As you can see, this use-
case diagram provides the big picture: Each use case represents a big
chunk of functionality that will be implemented, and each actor represents
someone or something outside our system that interacts with it.

It is a significant step to identify use cases and actors, but now there is
more to be done. Each use case also requires a significant amount of text
to describe it. This text is usually formatted in sections, as shown in Table
1.

Table 1: Format for a Use-Case Textual Description

Use Case Section Description

Name An appropriate name for the use case

(see Leslee Probasco’s article in the
March issue of The Rational Edge).

Brief Description A brief description of the use case’s role

and purpose.

Flow of Events A textual description of what the system

does with regard to the use case (not
how specific problems are solved by the
system). The description should be
understandable to the customer.

Special Requirements A textual description that collects all

requirements, such as non-functional
requirements, on the use case, that are
not considered in the use-case model,
but that need to be taken care of during
design or implementation.

Preconditions A textual description that defines any

constraints on the system at the time the
use case may start.

Post conditions A textual description that defines any

constraints on the system at the time the
use case will terminate.

The most important part of a use case for generating test cases is the flow
of events. The two main parts of the flow of events are the basic flow of
events and the alternate flows of events. The basic flow of events
should cover what "normally" happens when the use case is performed.
The alternate flows of events covers behavior of an optional or exceptional
character relative to normal behavior, and also variations of the normal
behavior. You can think of the alternate flows of events as "detours" from
the basic flow of events.
 Figure 2: Basic Flow of Events and Alternate Flows of Events for a Use Case

Figure 2 represents the typical structure of these flows of events. The

straight arrow represents the basic flow of events, and the curves
represent alternate flows. Note that some alternate flows return to the
basic flow of events, while others end the use case. Both the basic flow of
events and the alternative flows should be further structured into steps or
subflows

Register For Courses

Basic Flow

1. Logon
This use case starts when a Student accesses the Wylie
University Web site.
The system asks for, and the Student enters, the student ID
and password.

2. Select 'Create a Schedule'

The system displays the functions available to the student. The
student selects "Create a Schedule."

3. Obtain Course Information

The system retrieves a list of available course offerings from the
Course Catalog System and displays the list to the Student.

4. Select Courses
The Student selects four primary course offerings and two
alternate course offerings from the list of available course
offerings.
 5. Submit Schedule
The student indicates that the schedule is complete. For each
selected course offering on the schedule, the system verifies
that the Student has the necessary prerequisites.

6. Display Completed Schedule

The system displays the schedule containing the selected course
offerings for the Student and the confirmation number for the
schedule.

Figure 3: Textual Description for the University Course Registration Use-Case Basic
Flow of Events

Figure 4 shows a few alternate flows.

Register For Courses

Alternate Flows

1. Unidentified Student
In Step 1 of the Basic Flow, Logon, if the system determines
that the student ID and/or password is not valid, an error
message is displayed.

2. Quit
The Course Registration System allows the student to quit at
any time during the use case. The Student may choose to save
a partial schedule before quitting. All courses that are not
marked as "enrolled in" are marked as "selected" in the
schedule. The schedule is saved in the system. The use case
ends.

3. Unfulfilled Prerequisites, Course Full, or Schedule

Conflicts
In Step 5 of the Basic Flow, Submit Schedule, if the system
determines that prerequisites for a selected course are not
satisfied, that the course is full, or that there are schedule
conflicts, the system will not enroll the student in the course. A
message is displayed that the student can select a different
course. The use case continues at Step 4, Select Courses, in the
basic flow.

4. Course Catalog System Unavailable

 In Step 3 of the Basic Flow, Obtain Course Information, if the
system is down, a message is displayed and the use case ends.

5. Course Registration Closed

If, when the use case starts, it is determined that registration
has been closed, a message is displayed, and the use case
ends.

Figure 4: Textual Description for University Course Registration Use-Case Alternate

Flows

As you can see, a significant amount of detail goes into fully specifying a
use case. Ideally, the flows should be written as "dialogs" between the
system and the actors. Each step should explain what the actor does and
what the system does in response; it should also be numbered and have a
title. Alternate flows always specify where they start in the basic flow and
where they go when they end.

Use-Case Scenarios
There is one more thing to describe before we concentrate on how use
cases can be used to generate test cases: a use-case scenario. A use-case
scenario is an instance of a use case, or a complete "path" through the
use case. End users of the completed system can go down many paths as
they execute the functionality specified in the use case. Following the
basic flow would be one scenario. Following the basic flow plus alternate
flow 1A would be another. The basic flow plus alternate flow 2A would be a
third, and so on.

Table 2 lists all possible scenarios for the diagram shown in Figure 2,
beginning with the basic flow and then combining the basic flow with
alternate flows.

Table 2: Scenarios for the Use Case Shown in Figure 2

Scenario 1 Basic
Flow

Scenario 2 Basic Alternate Flow

Flow 1

Scenario 3 Basic Alternate Flow Alternate Flow

Flow 1 2

Scenario 4 Basic Alternate Flow

Flow 3
Scenario 5 Basic Alternate Flow Alternate Flow
Flow 3 1

Scenario 6 Basic Alternate Flow Alternate Flow Alternate Flow

Flow 3 1 2

Scenario 7 Basic Alternate Flow

Flow 4

Scenario 8 Basic Alternate Flow Alternate Flow

Flow 3 4

These scenarios will be used as the basis for creating test cases.

Generating Test Cases

A test case is a set of test inputs, execution conditions, and expected
results developed for a particular objective: to exercise a particular
program path or verify compliance with a specific requirement, for
example.

The purpose of a test case is to identify and communicate conditions that

will be implemented in test. Test cases are necessary to verify successful
and acceptable implementation of the product requirements (use cases).

We will describe a three-step process for generating test cases from a fully-
detailed use case:

1. For each use case, generate a full set of use-case scenarios.

2. For each scenario, identify at least one test case and the conditions
that will make it "execute."
3. For each test case, identify the data values with which to test.

Step One: Generate Scenarios

Read the use-case textual description and identify each combination of
main and alternate flows -- the scenarios -- and create a scenario matrix.
Table 3 shows a partial scenario matrix for the Register for Courses use
case. This is a simple example with no nested alternate flows.

Table 3: Partial Scenario Matrix for the Register for Courses Use Case

Scenario Name Starting Flow Alternate

Scenario 1 - Successful registration Basic Flow

Scenario 2 - Unidentified student Basic Flow A1

Scenario 3 - User quits Basic Flow A2

Scenario 4 - Course catalog system Basic Flow A4

unavailable

Scenario 5 - Registration closed Basic Flow A5

Scenario 6 – Cannot enroll Basic Flow A3

Step Two: Identify Test Cases

Once the full set of scenarios has been identified, the next step is to
identify the test cases. We can do this by analyzing the scenarios and
reviewing the use case textual description as well. There should be at least
one test case for each scenario, but there will probably be more. For
example, if the textual description for an alternate flow is written in a very
cursory way, like the description below,

3A. Unfulfilled Prerequisites, Course Full, or Schedule Conflicts

then additional test cases may be required to test all the possibilities. In
addition, we may wish to add test cases to test boundary conditions.

The next step in fleshing out the test cases is to reread the use-case
textual description and find the conditions or data elements required to
execute the various scenarios. For the Register for Course use case,
conditions would be student ID, password, courses selected, etc.

To clearly document the test cases, once again, a matrix format is useful,
like the one in Table 4. Notice the top row. The first column contains the
test case ID, the second column has a brief description of the test case,
including the scenario being tested, and all other columns except the last
one contain data elements that will be used in implementing the tests. The
last column contains a description of the test case's expected output.

Table 4: Test Case Matrix for the Register for Courses Use Case

Test Scenario/ Student Password Courses Prerequisites Course Schedule Expected

Case Condition ID selected fulfilled Open Open Result
ID
 RC 1 Scenario 1- V V V V V V Schedule
successful and
registration confirmation
number
displayed

RC 2 Scenario 2- I N/A N/A N/A N/A N/A Error

unidentified message;
student back to
login screen

RC 3 Scenario 3- V V N/A N/A N/A N/A Login screen

valid user appears
quits

RC 4 Scenario 4- V V N/A N/A N/A N/A Error

course message;
registration back to step
system 2
unavailable

RC 5 Scenario 5- V V N/A N/A N/A N/A Error

registration message;
closed back to step
2

RC 6 Scenario 6- V V V V I V Error
cannot message;
enroll -- back to step
course full 3

RC 7 Scenario 6- V V V I V V Error
cannot message;
enroll -- back to step
prerequisite 4
not fulfilled

RC 8 Scenario 6- V V V V V I Error
cannot message;
enroll -- back to step
schedule 4
conflict

Notice that in this matrix no data values have actually been entered. The
cells of the table contain a V, I, or n/a. V indicates valid, I is for invalid,
and n/a means that it is not necessary to supply a data value in this case.
This specific matrix is a good intermediate step; it clearly shows what
conditions are being tested for each test case. It is also very easy to
determine by looking at the Vs and Is whether you have identified a
sufficient number of test cases. In addition to the "happy day" scenarios in
which everything works fine, each row in the matrix should have at least
one I indicating an invalid condition being tested. In the test case matrix
in Table 4, some conditions are obviously missing -- e.g., Registration
Closed -- because RC3, RC4, and RC5 each has the same combination of
Is and Vs.

Step Three: Identify Data Values to Test

Once all of the test cases have been identified, they should be reviewed
and validated to ensure accuracy and to identify redundant or missing test
cases. Then, once they are approved, the final step is to substitute actual
data values for the Is and Vs. Without test data, test cases (or test
procedures) can't be implemented or executed; they are just descriptions
of conditions, scenarios, and paths. Therefore, it is necessary to identify
actual values to be used in implementing the final tests. Table 5 shows a
test case matrix with values substituted for the Is and Vs in the previous
matrix. A number of techniques can be used for identifying data values,
but these are beyond the scope of this article.

Table 5: Test Case Matrix with Data Values

Test Scenario/ Student Password Courses Prerequisites Course Schedule Expected

Case Condition ID selected fulfilled Open Open Result
ID

RC 1 Scenario 1- jheumann abc123 M101> Yes Yes Yes Schedule

successful and
registration confirmation
E201 number
displayed
S101

RC 2 Scenario 2- Jheuman1 N/A N/A N/A N/A N/A Error

unidentified message;
student back to
login screen

RC 3 Scenario 3- jheumann abc123 N/A N/A N/A N/A Login

valid user screen
quits appears

RC 4 Scenario 4- jheumann abc123 N/A N/A N/A N/A Error

course message;
registration back to step
system 2
unavailable

RC 5 Scenario 5- jheumann abc123 N/A N/A N/A N/A Error

registration message;
closed back to step
2

RC 6 Scenario 6- jheumann abc123 M101 Yes M101 Yes Error

cannot full message;
enroll -- back to step
E201
course full 3

S101

RC 7 Scenario 6- jheumann abc123 M101 No for E201 Yes Yes Error

cannot message;
enroll -- back to step
prerequisite E201 4
not fulfilled
S101
 RC 8 Scenario 6- jheumann abc123 M101 Yes Yes E202 and Error
cannot S101 message;
enroll -- conflict back to step
schedule E201 4
conflict
S101

Putting It All Together

In current practice, use cases are associated with the front end of the
software development lifecycle and test cases are typically associated with
the latter part of the lifecycle. By leveraging use cases to generate test
cases, however, testing teams can get started much earlier in the lifecycle,
allowing them to identify and repair defects that would be very costly to
fix later, ship on time, and ensure that the system will work reliably.

Using the clearly-defined methodology I've outlined above for generating

test cases, developers can simplify the testing process, increase efficiency,
and help ensure complete test coverage.

For more information on the products or services discussed in this

article, please click here and follow the instructions provided.
Thank you!

Copyright Rational Software 2001 | Privacy/Legal Information

 Structuring the Use-Case Model

Structuring the Use-Case

Model
Maria Ericsson
Email: [email protected]

Introduction
The purpose of this white paper is to summarize and exemplify how use-case relationships
will be defined in the UML 1.3. It is an excerpt of what will be in the Rational Unified
Process 5.0. It is assumed that the reader is familiar with the basics of use cases.

Why Structure the Use-Case Model?

There are three main reasons for structuring the use-case model:

• To make the use cases easier to understand.

• To reuse behavior that is shared among many use cases.

• To make the use-case model easier to maintain.

Structuring is, however, not the first you do. There is no point in structuring the use cases
until you know a bit more about their behavior, beyond a one sentence brief description. You
should at least have established a step-by-step outline to the flow of events of the use case, to
make sure that you decisions are based on an accurate enough understanding of the behavior.

To structure the use cases, we have three kinds of relationships. You will use these
relationships to factor out pieces of use cases that can be reused in other use cases, or that are
specializations or options to the use case. The use case that represents the modification we
call the addition use case. The use case that is modified we call the base use case.

• If there is a part of a base use case that represents a function of which the use case only
depends on the result, not the method used to produce the result, you can factor that part
out to an addition use case. The addition is explicitly included in the base use case, using
the include-relationship.

• If there is a part of a base use case that is optional, or not necessary to understand the
primary purpose of the use case, you can factor that part out to an addition use case in
order to simplify the structure of the base use case. The addition is implicitly included in
the base use case, using the extend-relationship.

• If there are use cases that have commonalties in behavior and structure and that have
similarities in purpose, their common parts can be factored out to a base use case (parent)
that is inherited by addition use cases (children). The child use cases can insert new
 Structuring the Use-Case Model

behavior and modify existing behavior in the structure they inherit from the parent use
case.

You can also use actor-generalization to show how actors are specializations of one another.

In factoring out behavior to new use cases you may create use cases that never are instantiated
on their own, only as part of some other use case. Such non-instantiable use cases are referred
to as abstract use cases. Use cases that are directly initiated by actors and instantiated on their
own are called concrete use cases.

Example:
Consider part of the use-case model for an Order Management System.

It is useful to separate ordinary Customer from Internet Customer, since they have
slightly different properties. However, since Internet Customer does exhibit all properties
of a Customer, you can say that Internet Customer is a specialization of Customer,
indicated with an actor-generalization.

The concrete use cases in this diagram are Phone Order (initiated by the Customer actor)
and Internet Order (initiated by Internet Customer). These use cases are both variations of
the more general Place Order use case, which in this example is abstract. The Request
Catalog use case represents an optional segment of behavior that is not part of the
primary purpose of Place Order. It has been factored out to an abstract use case to
simplify the Place Order use case. The Supply Customer Data use case represents a
segment of behavior that was factored out since it is a separate function of which only the
result is affecting the Place Order use case and it can also be reused in other use cases.
Both Request Catalog and Supply Customer Data are abstract in this example.
 Structuring the Use-Case Model

Customer Internet Customer

Phone Order Internet Order

<<extend>> Request Catalog

Place Order <<include>>

Supply Customer Data

A use-case diagram showing part of the use-case model for an Order Management System.

The following table shows a more detailed comparison between the three different use-case
relationships:

Question Extend Include Generalization

What is the direction of The addition use case The base use case The addition use case
the relationship? references the base use references the addition (child) references the
case. use case. base use case (parent).

Does the relationship Yes, on the addition No. If you want to No.
have multiplicity? side. include the same
segment of behavior
more than once, that
needs to be stated in the
base use case.

Does the relationship Yes. No. If you want to No.

have a condition? express a condition on
the inclusion you need
to say it explicitly in the
base use case.
 Structuring the Use-Case Model

Is the addition use case Often yes, but not Yes. Often no, but it can be.
abstract? necessarily.

Is the base use case The extension implicitly The inclusion explicitly If the base use case
modified by the modifies the behavior of modifies the effect of (parent) is instantiated,
addition? the base use case. the base use case. it is unaffected by the
child. To obtain the
effects of the addition,
the addition use case
(child) must be
instantiated.

Does the base use case Yes. Together with the If it is abstract, no.
have to be complete and additions, yes.
meaningful?

Does the addition use No. No. Together with the base
case have to be use case (parent), yes.
complete and
meaningful?

Can the addition use Yes. No. The inclusion is Yes, by the normal
case access attributes of encapsulated, and only mechanisms of
the base use case? "sees" itself. inheritance.

Can the base use case No. The base use case No. The base use case No. The base use case
access attributes of the must be well-formed in only knows about the (parent) must in this
addition use case? the absence of the effect of the addition. sense be well-formed in
addition. The addition is the absence of the
encapsulated. addition (child).

Another aspect of organizing the use-case model for easier understanding is to group the use
cases into packages. The use-case model can be organized as a hierarchy of use-case
packages, with "leaves" that are actors or use cases.
 Structuring the Use-Case Model

The use-case model hierarchy. Arrows show possible ownership.

Include-Relationship
An include-relationship is a relationship from a base use case to an inclusion use case,
specifying how the behavior defined for the inclusion use case is explicitly inserted into the
behavior defined for the base use case.

Notation: a dashed arrow with the text «include».

The inclusion use case is always abstract. The base use case has control of the relationship to
the inclusion and can depend on the result of performing the inclusion, but neither the base
nor the inclusion may access each other's attributes. The inclusion is in this sense
encapsulated, and represents behavior that can be reused in different base use cases.

You can use the include-relationship to:

• Factor out behavior from the base use case that is not necessary for the understanding of
the primary purpose of the use case, only the result of it is important.

• Factor out behavior that is in common for two or more use cases.

Example:
In an ATM system, the use cases Withdraw Cash, Deposit Cash, and Transfer Funds all
need to include how the customer is identified to the system. This behavior can be
extracted to a new inclusion use case called Identify Customer, which the three base use
cases include. The base use cases are independent of the method used for identification,
and it is therefore encapsulated in the inclusion use case. From the perspective of the base
use cases, it does not matter whether the method for identification is to read a magnetic
bank card, or to do a retinal scan. They only depend on the result of Identify Customer,
which is the identity of the customer. And vice versa, from the perspective of the Identify
Customer use case, it does not matter how the base use cases use the customer identity or
what has happened in them before the inclusion is executed, the method for identification
is still exactly the same.
 Structuring the Use-Case Model

Identify Customer

<<include>> <<include>> <<include>>

Withdraw Cash Deposit Cash Transfer Funds

In the ATM system, the use cases Withdraw Cash, Deposit Cash, and Transfer Funds all
include the use case Identify Customer.

The behavior of the inclusion is inserted in one location in the base use case. When a use-case
instance following the description of a base use case reaches a location in the base use case
from which include-relationship is defined, it will follow the description of the inclusion use
case instead. Once the inclusion is performed, the use-case instance will resume where it left
off in the base use case.

Use-Case Instance
Base Use Case

Inclusion Use Case

A use-case instance following the description of a base use case including its inclusion.

The include-relationship is not conditional, if the use-case instance reaches the location in the
base use case it is defined for, it is always executed. If you want to express a condition, you
need to do that as part of the base use case. If the use-case instance never reaches the location
the include-relationship is defined for, it will not be executed.
 Structuring the Use-Case Model

Use-Case Instance #1
Base Use Case
Use-Case Instance #2

Inclusion Use Case

Use-case instance #1 follows the base use case and its inclusion. Use-case instance #2 never
reaches the point the inclusion is defined for, and follows only the base use case.

The inclusion use case is one continuous segment of behavior, all of which is included at one
location in the base use case. If you have separate segments of behavior that need to be
inserted at different locations, you should consider an extend-relationship or use-case-
generalization instead.

Extend-Relationship
An extend-relationship is a relationship from an extension use case to a base use case,
specifying how the behavior defined for the extension use case can be inserted into the
behavior defined for the base use case. It is implicitly inserted in the sense that the extension
is not shown in the base use case.

Notation: a dashed arrow with the text «extend».

You define where in the base to insert the extension by referring to extension points in the
base use case. The extension use case is often abstract, but does not have to be. The extension
is conditional. The base use case does not control the conditions for the execution of the
extension, those conditions are described within the extend-relationship.

An extension point opens up a base use case to the possibility of an extension. It has a name,
and a list of references to one or more locations within the flow of events of the use case. An
extension point may reference a single location between two behavior steps within the base
use case. It may also reference a set of discrete locations.

You can use the extensions for several purposes:

• To show that a part of a base use case is optional, or potentially optional, system
behavior. In this way, you separate optional behavior from mandatory behavior in your
model.

• To show that a subflow is executed only under certain (sometimes exceptional)

conditions, such as triggering an alarm.
 Structuring the Use-Case Model

• To show that there may be a set of behavior segments of which one or several may be
inserted at an extension point in a base use case. It will depend on the interaction with the
actors during the execution of the base use case which of the behavior segments are
inserted and in what order.

The base use case is implicitly modified by the extensions. You can also say that the base use
case defines a modular framework into which extensions can be added, but the base does not
have any visibility of the specific extensions.

The base use case should be complete in and of itself, meaning that it should be
understandable and meaningful without any references to the extensions.

Example:

Place Call
Caller Callee
<<extend>>

<<extend>>

Show Caller Identity

Place Conf erence Call

Callee

The use cases Place Conference Call and Show Caller Identity are both extensions to the base
use case Place Call.

In a phone system, the primary service provided to the users is represented by the use
case Place Call. Examples of optional services are to be able to add a third party to a call
(Place Conference Call) and to allow the callee to see the identity of the caller (Show
Caller Identity). We can represent the behaviors needed for these optional services as
extension use cases to the base use case Place Call. This is a correct use of the extend-
relationship, since Place Call is meaningful in itself, you do not need to read the
descriptions of the extension use cases to understand the primary purpose of the base use
case, and the extensions use cases have optional character.

If both the base use case and the "base plus extension" use case must be explicitly
instantiable, or if you want the addition to modify behavior in the base use case, you should
use use-case-generalization instead.

When a use-case instance performing the base use case reaches a location in the base use case
that has an extension point defined for it, the condition on the corresponding extend-
relationship is evaluated. If the condition is true or if it is absent, the use-case instance will
follow the extension. If the condition of the extend-relationship is false, the extension is not
executed. Once the use-case instance has performed the extension, the use-case instance
resumes executing the base use case at the point where it left off.
 Structuring the Use-Case Model

Use-Case Instance
Base Use Case

Extension Point

Extension Use Case

A use-case instance following a base use case and its extension.

An extension use case can have more than one insertion segment, each related to its own
extension point in the base use case. If this is the case, the use-case instance will resume the
base use case and continue to the next extension point specified in the extend-relationship. At
that point it will execute the next insertion segment of the extension use case. This is repeated
until the last insertion segment has been executed. Note that the condition for the extend-
relationship is checked at the first extension point only, once started all insertion segments
must be performed.
 Structuring the Use-Case Model

Use-Case Instance
Base Use Case

Extension Point 2
Extension Point 1

Extension Use Case

A use-case instance following a base use case and an extension use case, the latter with two
insertion segments.

Use-Case-Generalization
A use-case-generalization is a relationship from a child use case to a parent use case,
specifying how a child can specialize all behavior and characteristics described for the parent.

Notation: a generalization arrow.

Neither parent nor child is necessarily abstract, although the parent in most cases is abstract.
A child inherits all structure, behavior, and relationships of the parent. This is generalization
as applicable to use cases.

Generalization is used when you find two or more use cases that have commonalities in
behavior, structure, and purpose. In such case you can describe the shared parts in a new use
case, that then is specialized by child use cases.
 Structuring the Use-Case Model

Example:

Place Order

Phone Order Internet Order

Customer Internet Customer

The use cases Phone Order and Internet Order are specializations of the abstract use case
Place Order.

In an Order Management system, the use cases Phone Order and Internet Order share a
lot in structure and behavior. A general use case Place Order is defined where that
structure and common behavior is defined. The abstract use case Place Order need not be
complete in itself, but provides a general behavioral framework which the child use cases
can make complete.

The parent use case is not always abstract.

Example:
Consider the Order Management system in the previous example. Say that we want to
add an Order Registry Clerk actor, who can enter orders into the system on behalf of a
customer. This actor would initiate the general Place Order use case, which now must
have a complete flow of events described for it. The child use cases can add behavior to
the structure the parent use case provides, and also modify behavior in the parent.
 Structuring the Use-Case Model

Place Order
Order Registry
Clerk

Phone Order Internet Order

Customer Internet Customer

The actor Order Registry Clerk can instantiate the general use case Place Order. Place Order
can also be specialized by the use cases Phone Order or Internet Order.

If two child use cases are specializing the same parent (or base), the specializations are
independent of one another, meaning they are executed in separate use-case instances. This is
unlike the extend- or include-relationships, where several additions implicitly or explicitly
modify one use-case instance executing the same base use case.

Both use-case-generalization and include can be used to reuse behavior among use cases in
the model. The difference is that with use-case generalization, the execution of the children
are dependent on the structure and behavior of the parent (the reused part), while in an
include-relationship the execution of the base use case only depends on the result of the
function the inclusion use case (the reused part) performs. Another difference is that in a
generalization the children share similarities in purpose and structure, while in the include-
relationship the base use cases reusing the same inclusion can have completely different
purposes, they just need the same function to be performed.

A use-case instance executing a child use case will follow the flow of events described for the
parent use case, inserting additional behavior and modifying behavior as defined in the flow
of events of the child use case.
 Structuring the Use-Case Model

Parent Use Case

Use-Case Instance

Child Use Case

The use-case instance follows the parent use case, with behavior inserted or modified as
described in the child use case.
Structuring the Use-Case Model

[This page intentionally left blank]