Req480 Mastering Requirements Management With Use Cases: Student Workbook



®

1

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 EX4: Analyze the Problem Exercise 4.1: The Problem Behind the Problem Exercise 4.2: Describe the Problem EX5: Understand Stakeholder Needs Exercise 5.1: Review Customer Requirements Specifications Exercise 5.2: Brainstorming EX6: Define the System Exercise 6.1: Identify the System Features Exercise 6.2: Identify the Use Cases Exercise 6.3: Outline them Use Cases EX7: Manage Scope Exercise 7.1: Prioritize Requirements Using Attributes Exercise 7.2: Prioritize Scenarios EX8: Refine the System Definition Exercise 8.1: Choose A Style Exercise 8.2: Detail the Flows Exercise 8.3: Identify Nonfunctional Requirements CRA: Course Registration Artifacts CRA1: Initial Requests CRA2: Use-Case Model Survey CRA3: Use-Case Outlines CRA4: Use-Case Reports 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

1 7 15 25 33 35 43 49 55 59 65 77 83 1 3 7 11

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

3

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

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: realtime 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

9

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.

10

•

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.)

© 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

11

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

13

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

15

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

17

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

19

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)

20

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 would

provide real-time access to a trouble-shooting database by support representatives and facilitate dispatch of service technicians, in a timely manner, only to those locations that genuinely need their assistance.

© 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

21

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)

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 would

• • • •

Provide the feature set demanded by our 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.

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

23

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

25

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

27

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

29

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

31

MRMUC Student Workbook

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

32

Origin Trading Customer Regulatory Trading Customer Trading Customer On-line Trading Business Trading Customer Customer Support Trading Customer Customer Support Finance Department System Administration Trading Customer Trading Customer Trading Customer Trading Customer Trading Customer Trading Customer Trading Customer Regulatory Regulatory Regulatory Trading Customer

© 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

33

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

35

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

37

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

38

For

Rational Software's existing and prospective customers

Who

need to get timely solutions to their technical problems while using our products

The TSXWEB

is a Technical Support External Web Site

That

brings the latest technologies to the Web and allows for 24X7 technical support, from finding solutions to participating in case activity, in a selfhelp 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.

© 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

39

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

41

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 estock 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. 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.

Our product

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

43

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

45

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

47

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

48

This document is not supplied with the course.

© 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

49

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 usecase 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

51

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

53

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

55

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.

Medium Low Medium Medium High High Medium Low High Low High Low Low Medium Medium Medium High Medium High High Medium Medium High

Mandatory Mandatory Desired Desired Desired Mandatory Mandatory Desired Optional Mandatory Mandatory Desired Mandatory Mandatory Mandatory Optional Desired Desired Desired Mandatory Mandatory Desired Desired

57

Medium

Medium

High High Medium Medium Medium Medium

Low High

Low

Low Low

Low

Medium High

High Low Medium

Low Low High Medium

Medium Low

Risk

Difficulty

Customer Priority Desired

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

© Copyright IBM Corp. 2003

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.

Requirements

Using Attributes in Managing Scope

High Low High High High Low

High Medium

Medium

High Medium

Medium

High Low

Medium Low Medium

High Medium Medium High

High High

High

Stability

Prioritize Requirements Using Attributes

Rank

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

58

¾¾¾

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

59

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

61

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

63

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

65

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 1 The use case starts when the Trading Customer logs on. 2

3 The Trading Customer chooses to “Get Quote.” 4

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

System

Quote System

The system validates the customer id and password. The system presents a list of available functions.

The system displays the list of trading symbols and names of securities on which it has quotes.

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 1

System 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.

Quote System

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

67

MRMUC Student Workbook 2.2.2 Unidentified Trading Customer Step 1

Trading Customer

System 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.

Quote System

System 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.

Quote System

2.2.3 Quote System Unavailable Step 1

Trading Customer

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 1

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

System

Quote System

System 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.

Quote System

2.2.5 Unknown Trading Symbol Step 1

Trading Customer

2.2.6 Quote System Cannot Locate Information Step 1

68

Trading Customer

System 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.

Quote System

© 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

69

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

71

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

73

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

75

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

77

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

79

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

81

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM

83

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 Initial Requests Course Registration Artifact 1

Version: CRA1 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

Course Registration Initial Requests Course Registration Artifact 1

2

Version: CRA1 Date: Nov. 15, 2002

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

Course Registration Use-Case Model Survey Course Registration Artifact 2

Version: CRA2 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

3

Course Registration Use-Case Model Survey Course Registration Artifact 2

Version: CRA2 Date: Nov. 15, 2002

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

Registrar

Student

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 Use-Case Model Survey Course Registration Artifact 2

Version: CRA2 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

Course Registration Use-Case Model Survey Course Registration Artifact 2

4.1.3

Version: CRA2 Date: Nov. 15, 2002

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 Use Case Outlines Course Registration Artifact 3

Version: CRA3 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

Course Registration Use Case Outlines Course Registration Artifact 3

Version: CRA3 Date: Nov. 15, 2002

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 Use Case Outlines Course Registration Artifact 3

Version: CRA3 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

9

Course Registration Use Case Outlines Course Registration Artifact 3

Version: CRA3 Date: Nov. 15, 2002

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 Register for Courses Use Case Report Course Registration Artifact 4.1

Version: CRA4.1 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

11

Course Registration Register for Courses Use Case Report Course Registration Artifact 4.1

Version: CRA4.1 Date: Nov. 15, 2002

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 Alter Course Selections Use-Case Report Course Registration Artifact 4.2

Version: CRA4.2 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

13

Course Registration Alter Course Selections Use-Case Report Course Registration Artifact 4.2

Version: CRA4.2 Date: Nov. 15, 2002

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 Alter Course Selections Use-Case Report Course Registration Artifact 4.2

Version: CRA4.2 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

15

Course Registration Alter Course Selections Use-Case Report Course Registration Artifact 4.2

16

Version: CRA4.2 Date: Nov. 15, 2002

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

Course Registration Close Registration Use-Case Report Course Registration Artifact 4.3

Version: CRA4.3 Date: Nov. 15, 2002

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-byStep 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

17

Course Registration Close Registration Use-Case Report Course Registration Artifact 4.3

Version: CRA4.3 Date: Nov. 15, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

3

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Sevices Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

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 into the Supplementary Specifications doc

J. Carlos Goti

Nov 15, 2000

1.3

Removed categories from terms and added new terms

J. Bell

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 Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

Table of Contents 1.

Introduction Purpose Scope References Overview

5 5 5 5 5

2.

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

6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9

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

3

RU Financial Sevices Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

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

4

9 9 9 9 9 9 9 9 10 10 10 10 10 10 10 10 10 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 Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Sevices Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

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 Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

RU Financial Sevices Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

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 Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

9

RU Financial Sevices Glossary RU es-t Case Study 2

Version: RUCS 2 Date: Oct 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services Vision RU e-st Case Study 3

Version: RUCS 3 Date: 4/10/2003 9:14 AM

Revision History Date th

Version

Description

Author

19 January, 2000

1.0

First draft

J. Carlos Goti

27th January, 2000

1.0

First complete draft

J. Carlos Goti

th

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

17 November, 2000

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 Vision RU e-st Case Study 3

Version: RUCS 3 Date: 16th October, 2001

Table of Contents 1.

Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview

5 5 5 5 5 5

2.

Positioning 2.1 Business Opportunity 2.2 Problem Statement 2.3 Product Position Statement

5 5 6 7

3.

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

8 8 8 9 9 9 10 10 10 11 11 11 12 12 12 12 13

4.

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

13 13 14 14 14 14

5.

Product Features

15

6.

Constraints

15

7.

Quality Ranges

15

8.

Precedence and Priority

15

9.

Other Product Requirements 9.1 Applicable Standards

16 16

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

3

RU Financial Services Vision RU e-st Case Study 3 9.2 9.3 9.4 10. 10.1 10.2 10.3 10.4 11.

4

Version: RUCS 3 Date: 4/10/2003 9:14 AM

System Requirements Performance Requirements Environmental Requirements

16 16 16

Documentation Requirements User Manual Online Help Installation Guides, Configuration, Read Me File Labeling and Packaging

16 16 16 16 16

Appendix 1 - Feature Attributes

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 Vision RU e-st Case Study 3

Version: RUCS 3 Date: 16th October, 2001

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 Webbased 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services Vision RU e-st Case Study 3

Version: RUCS 3 Date: 4/10/2003 9:14 AM

2.2 Problem Statement The problem of

affects

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. RU Financial Services.

The impact of which is

We need to replace the current online stock-trading system.

A successful solution would

• • • •

6

Provide the feature set demanded by our 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.

© 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 RU e-st Case Study 3

Version: RUCS 3 Date: 16th October, 2001

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. 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.

Our product

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

7

RU Financial Services Vision RU e-st Case Study 3

Version: RUCS 3 Date: 4/10/2003 9:14 AM

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 Manager

Represents the executive management in the company.

Define a product that satisfies the business requirements. Evaluate options and scope the different versions of the system.

RU e-st Business Manager

The business entity that makes the funding decisions for development.

Assure 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.

RU e-st Development Manager

The team that develops and releases the system.

Assure that the development team delivers a system that complies with the specifications supported by the RU e-st Product Manager.

RU e-st End User

People who trade securities using the system.

Validate that the features offered by the system are adequate and responsive to the needs of traders.

RU e-st Partner Executive

Companies whose systems support the operation of the system. They are: Market Trading, News System, and Quote System.

Approve business agreements for specialized functions needed to support online securities trading.

3.2 User Summary

8

Name

Description

Stakeholder

End User-Day Trader

A very knowledgeable end user, who is on the system very frequently and is aware of and makes use of advanced features.

RU e-st End User

End User-Naïve

First-time or infrequent end user of the system. This person needs guidance and might need to refer to online help for definitions and business consequences of trading actions.

RU e-st End User

© 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 RU e-st Case Study 3

Version: RUCS 3 Date: 16th October, 2001

RU e-st Administrator

Does customization and setup activities on the system. Maintains up-to-date information and produces and analyzes operational reports of system performance.

RU e-st Development Manager

RU e-st Support

Helps calling customers use the system correctly. Reports errors and develops operational fixes.

RU e-st Development Manager

RU e-st Developer

Part of the team that develops the system (software developer, tester, etc.)

RU e-st Development Manager

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 Description Type Responsibilities

Success Criteria

Involvement Deliverables Comments/Issues

The online trading business Defines a product that satisfies the business requirements. Evaluates options and scope the different versions of the system. Is an expert-level user of the system. 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. 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. Constantly reviews plans and development progress. Assesses how features are being supported. Validates expenses by system feature. Participates during iteration assessment sessions and when project decisions are made. Needs to keep an eye on the competition to ensure success in the marketplace.

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

9

RU Financial Services Vision RU e-st Case Study 3

Version: RUCS 3 Date: 4/10/2003 9:14 AM

3.4.2 RU e-st Business Manager Representative Description Type Responsibilities

Success Criteria Involvement Deliverables Comments/Issues

The business entity that makes the funding decisions for development. 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. Probably not a user of the system. 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. 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. Participates in the system’s phase assessments. Provides the project team with resources and promote the system vision with good press inside and outside the company. 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 Description Type Responsibilities Success Criteria Involvement Deliverables Comments/Issues

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

3.4.4 RU e-st Partner Executive Representative Description Type Responsibilities Success Criteria Involvement Deliverables 10

Companies whose systems support the operation of RU e-st. They are: Market Trading, News System, Quotes System, and the Financial Network System. Approve business agreements for specialized functions needed to support online securities trading. Might not use the system at all. Achieves business agreements for cooperation between systems. Agree on business synergism and mutual charging schemes. Smoothes business operation (low bureaucracy) during the system’s joint operations. Early agreements during the inception phase of the system. The business arrangements should be completed early in the development process. Mutual service support during the operation of the systems. Clear arrangements for © 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 RU e-st Case Study 3

Comments / Issues

Version: RUCS 3 Date: 16th October, 2001

production problem resolution. 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 Description Type

Responsibilities

Success Criteria Involvement Deliverables Comments / Issues

The RU e-st Product Manager is the representative of End Users. Uses the RU e-st system to perform securities trades. 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. 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. Users benefit from an improved system access to their needs. Users should participate in the description of use cases, the evaluation of partial implementations, and the assessment of the help features of the system. Users deliver feedback to the team’s analysts and architect either verbally or in writing. 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 Description Type Responsibilities

Success Criteria Involvement Deliverables Comments / Issues

System administrators are represented by the RU e-st Development Manager. System administrators do set up, customization, support and development of the system. All system administrators are users at the expert level. 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. Customer satisfaction measures. Should participate during development in the same way that end users do. They should concentrate on the support and maintenance use cases. Comments to improve the support and maintenance aspects of the system. 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

11

RU Financial Services Vision RU e-st Case Study 3

Version: RUCS 3 Date: 4/10/2003 9:14 AM

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

Origin Trading Customer Regulatory Trading Customer Trading Customer On-line Trading Business Trading Customer Customer Support Trading Customer Customer Support Finance Department System Administration Trading Customer Trading Customer Trading Customer Trading Customer Trading Customer Trading Customer Trading Customer Regulatory Regulatory Regulatory Trading Customer

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 Vision RU e-st Case Study 3

Version: RUCS 3 Date: 16th October, 2001

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/ End User

Standard Internet Browsers

Financial Network System

RU e-st

Market Trading System

News System

Quote 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

13

RU Financial Services Vision RU e-st Case Study 3

Version: RUCS 3 Date: 4/10/2003 9:14 AM

4.2 Summary of Capabilities

RU e-st System Trader Benefit Trading online

Securities research online

Portfolio management online

Portfolio record keeping

Supporting Features • Online trading • Online account setup • Online quotes • Online news • Online quotes • Online news • Online account reports • Online account setup • Online accounts reports • Online transfers between accounts • Online transfers with banks • 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 Vision RU e-st Case Study 3

Version: RUCS 3 Date: 16th October, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

15

RU Financial Services Vision RU e-st Case Study 3

Version: RUCS 3 Date: 4/10/2003 9:14 AM

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 Internetcomfortable 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 4

Use Case Model Survey: RU e-st RU e-st Case Study 4

Date: October 30th 2001

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

Market Trading System

Quote System

Broker

Tech Support

News System

Web Content Provider

Financial Network

Tax System

Scheduler

System Administrator

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 RU e-st Case Study 4

Date: October 30th, 2001

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 RU e-st Case Study 4

Date: October 30th 2001

4 Use Cases 4.1 Primary Cases 4.1.1

Diagram of Use Cases Around the Trading Customer

See Figure 2.

Apply for Trading Account

Execute Trade Market Trading System

Get Quote Quote System

Trading Customer

Manage Portfolio Financial Network

Distribute News News System

Broker

Review Account

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 RU e-st Case Study 4

Date: October 30th, 2001

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 RU e-st Case Study 4

Date: October 30th 2001

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 Resolve Account Problems

Trading Customer

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 RU e-st Case Study 4

Date: November 15, 20XX

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 RU e-st Case Study 4

Date: October 30th 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

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

2

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

2

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 6.1

Use Case Report: Get Quote RU e-st Case Study 6

Date: 4/10/2003 9:21 AM

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 alternative flow

B. Baker

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 RU e-st Case Study 6

Date: 4/10/2003 9:21 AM

Table of Contents 1.

Use Case Name: Get Quote 1.1 Brief Description

4 4

2.

Flow of Events 2.1 Basic Flow 2.2 Alternative Flows

4 4 4

3.

Special Requirements 3.1 Timely Quote Display

5 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 10.1 Success Scenarios 10.2 Failure Scenarios

6 6 6

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

3

RU Financial Services

Version: RUCS 6.1

Use Case Report: Get Quote RU e-st Case Study 6

Date: 4/10/2003 9:21 AM

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 RU e-st Case Study 6

Date: 4/10/2003 9:21 AM

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services

Version: RUCS 6.1

Use Case Report: Get Quote RU e-st Case Study 6

Date: 4/10/2003 9:21 AM

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 6.2

Use Case Report: Execute Trade RU e-st Case Study 6

Date: 4/10/2003 9:23 AM

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- flows and alternative flows for repeating behavior.

B. Baker

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 RU e-st Case Study 6

Date: 4/10/2003 9:23 AM

Table of Contents 1.

Use Case Name: Execute Trade 1.1 Brief Description

4 4

2.

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

4 4 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6

3.

Special Requirements 3.1 Reliable Cash Accounting

6 6

4.

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

6 6 6

5.

Postconditions 5.1 Accounts Are Adjusted

7 7

6.

Extension Points

7

7.

Relationships

7

8.

Use-Case Diagrams

7

9.

Other Diagrams

7

10.

Scenarios 10.1 Success Scenarios 10.2 Failure Scenarios

7 7 7

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

3

RU Financial Services

Version: RUCS 6.2

Use Case Report: Execute Trade RU e-st Case Study 6

Date: 4/10/2003 9:23 AM

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 RU e-st Case Study 6

Date: 4/10/2003 9:23 AM

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services

Version: RUCS 6.2

Use Case Report: Execute Trade RU e-st Case Study 6

Date: 4/10/2003 9:23 AM

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 RU e-st Case Study 6

Date: 4/10/2003 9:23 AM

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

RU Financial Services

Version: RUCS 6.2

Use Case Report: Execute Trade RU e-st Case Study 6

Date: 4/10/2003 9:23 AM

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 RU e-st Case Study 7

Date: November 15, 2002

RU e-st System Structured Use-Case Model

Identify Customer

<>

Get News <>

Execute Trade

<<extend>>

Get Quote

Execute Real Estate Trade

Execute Securities 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 7

Structured Use Case Model: RU e-st RU e-st Case Study 7

Date: November 15, 2000

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 7.2

Use Case Report: Get Quote RU e-st Case Study 7

Date: 4/10/2003 9:25 AM

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

B. Baker

Apr 2, 2003

1.6

Reformatted for McKinley updates. Added scenario list and additional quotes alternative flow. McKinley post-Beta changes

2

B. Baker

© 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 RU e-st Case Study 7

Date: 4/10/2003 9:25 AM

Table of Contents Introduction

1

1.

Use Case Name: Get Quote 1.1 Brief Description

4 4

2.

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

4 4 4 4 4 4 5 5 5

3.

Special Requirements

5

4.

Preconditions 4.1 RU e-st Has Connection to Quote System

5 5

5.

Postconditions

5

6.

Extension Points 6.1 Optional Services

5 5

7.

Relationships 7.1 Actors 7.2 Associations To Other Use Cases 7.3 Associations FROM other Use Cases

5 5 6 6

8.

Use-Case Diagrams

7

9.

Other Diagrams

7

10. 10.1 10.2

Scenarios Success Scenarios Failure Scenarios

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

7 7 7

3

RU Financial Services

Version: RUCS 7.2

Use Case Report: Get Quote RU e-st Case Study 7

Date: 4/10/2003 9:25 AM

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 RU e-st Case Study 7

Date: 4/10/2003 9:25 AM

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services

Version: RUCS 7.2

Use Case Report: Get Quote RU e-st Case Study 7

Date: 4/10/2003 9:25 AM

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 RU e-st Case Study 7

Date: 4/10/2003 9:25 AM

8. Use-Case Diagrams

Identify Customer <>

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

RU Financial Services

Version: RUCS 7.2

Use Case Report: Get Quote RU e-st Case Study 7

Date: 4/10/2003 9:25 AM

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services Use-Case Report: Identify Customer RU e-st Case Study 7

Version: RUCS 7.3 Date: October 30, 2001

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 scenarios section and reworked alternative flows.

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 Use-Case Report: Identify Customer RU e-st Case Study 7

Version: RUCS 7.3 Date: October 30, 2001

Table of Contents Introduction

1

1.

Use Case Name: Identify Customer 1.1 Brief Description

4 4

2.

Flow of Events 2.1 Basic Flow

4 4 4 4 4

2.2

Alternative Flows 2.2.1 Unidentified Trading Customer 2.2.2 Suspect Theft

3.

Special Requirements 3.1 Time to process customer id

4 4

4.

Preconditions

4

5.

Postconditions

4

6.

Extension Points

4

7.

Relationships 7.1 Actors 7.2 Associations TO other Use Cases 7.3 Associations FROM other Use Cases

5 5 5 5

8.

Use-Case Diagrams

5

Figure 1: Local Use-Case Diagram

6

9.

6

Other Diagrams

10.

Scenarios

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

6

3

RU Financial Services Use-Case Report: Identify Customer RU e-st Case Study 7

Version: RUCS 7.3 Date: October 30, 2001

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 Use-Case Report: Identify Customer RU e-st Case Study 7

Version: RUCS 7.3 Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services Use-Case Report: Identify Customer RU e-st Case Study 7

Version: RUCS 7.3 Date: October 30, 2001

Trading Customer System Administrator

Identify Customer

<

Execute Trade

<

Get Quote

<

Review Account

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 7.4

Use Case Report: Get News RU e-st Case Study 7

Date: October 30, 2001

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 RU e-st Case Study 7

Date: October 30, 2001

Table of Contents Introduction

1

1.

Use Case Name: Get News 1.1 Brief Description

4 4

2.

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

4 4 4 4 4

3.

Special Requirements 3.1 Timely Headline News Display

4 4

4.

Preconditions 4.1 RU e-st Has Connection to News System

4 4

5.

Postconditions

5

6.

Extension Points

5

7.

Relationships 7.1 Actors 7.2 Associations TO other Use Cases 7.3 Associations FROM other Use Cases

5 5 5 5

8.

Use-Case Diagrams

6

9.

Other Diagrams

6

10.

Scenarios

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

6

3

RU Financial Services

Version: RUCS 7.4

Use Case Report: Get News RU e-st Case Study 7

Date: October 30, 2001

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 RU e-st Case Study 7

Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services

Version: RUCS 7.4

Use Case Report: Get News RU e-st Case Study 7

Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 7.5

Use Case Report: Execute Trade RU e-st Case Study 7

Date: February 5, 2003

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 RU e-st Case Study 7

Date: February 5, 2003

Table of Contents 1.

Use Case Name: Execute Trade 1.1 Brief Description

4 4

2.

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

4 4 4 4 4 4 5 5

3.

Special Requirements 3.1 Reliable Cash Accounting

5 5

4.

Preconditions

5

5.

Postconditions 5.1 Accounts Are Adjusted

5 5

6.

Extension Points

5

7.

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

5 5 5 6 6

8.

Use-Case Diagrams

6

9.

Other Diagrams

6

10.

Scenarios

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

6

3

RU Financial Services

Version: RUCS 7.5

Use Case Report: Execute Trade RU e-st Case Study 7

Date: February 5, 2003

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 RU e-st Case Study 7

Date: February 5, 2003

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services

Version: RUCS 7.5

Use Case Report: Execute Trade RU e-st Case Study 7

Date: February 5, 2003

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

<> Real Estate Trading System

Execute Trade

Execute Real Estate Trade

Market Trading System

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 7.6

Use-Case Report: Execute Securities Trade RU e-st Case Study 7

Date: November 15, 2003

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 flows; and alternative flows for repeating behavior.

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.6

Use-Case Report: Execute Securities Trade RU e-st Case Study 7

Date: November 15, 2003

Table of Contents 1.

Use Case Name: Execute Trade 1.1 Brief Description

4 4

2.

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

4 4 5 5 5 5 5 5 5 5 5 6 6

3.

Special Requirements

6

4.

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

6 6 6

5.

Postconditions

6

6.

Extension Points

6

7.

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

6 6 6 6 7

8.

Use-Case Diagrams

7

9.

Other Diagrams

7

10.

Scenarios

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

7

3

RU Financial Services

Version: RUCS 7.6

Use-Case Report: Execute Securities Trade RU e-st Case Study 7

Date: November 15, 2003

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 RU e-st Case Study 7

Date: November 15, 2003

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services

Version: RUCS 7.6

Use-Case Report: Execute Securities Trade RU e-st Case Study 7

Date: November 15, 2003

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 RU e-st Case Study 7

Date: November 15, 2003

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

<>

Real Estate Trading System

Market 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

RU Financial Services

Version: RUCS 7.6

Use-Case Report: Execute Securities Trade RU e-st Case Study 7

Date: November 15, 2003

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services

Version: RUCS 7.7

Use-Case Report: Execute Real Estate Trade RU e-st Case Study 7

Date: November 15, 2003

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 flows; and alternative flows for repeating behavior.

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.7

Use-Case Report: Execute Real Estate Trade RU e-st Case Study 7

Date: November 15, 2003

Table of Contents 1.

Use Case Name: Execute Trade 1.1 Brief Description

4 4

2.

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

4 4 4 5 5 5 5 5 5 5

3.

Special Requirements

5

4.

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

5 5

5.

Postconditions

6

6.

Extension Points

6

7.

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

6 6 6 6 6

8.

Use-Case Diagrams

7

9.

Other Diagrams

7

10.

Scenarios

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

7

3

RU Financial Services

Version: RUCS 7.7

Use-Case Report: Execute Real Estate Trade RU e-st Case Study 7

Date: November 15, 2003

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 RU e-st Case Study 7

Date: November 15, 2003

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services

Version: RUCS 7.7

Use-Case Report: Execute Real Estate Trade RU e-st Case Study 7

Date: November 15, 2003

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 RU e-st Case Study 7

Date: November 15, 2003

8. Use-Case Diagrams

Identify Customer

<>

Real Estate Trading System

Market 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

RU Financial Services

Version: RUCS 7.7

Use-Case Report: Execute Real Estate Trade RU e-st Case Study 7

Date: November 15, 2003

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

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 Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

Table of Contents 1.

Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 1.5 Overview

5 5 5 5 5 5

2.

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

5 5 6 6 6 6 6 6

3.

Usability 3.1 Browser compatibility 3.2 Access to information 3.3 Online tutorial

6 6 6 6

4.

Reliability 4.1 Availability 4.2 Timeliness and Accuracy

6 6 7

5.

Performance 5.1 Response Time

7 7

6.

Supportability 6.1 Installability

7 7

7.

Design Constraints

7

8.

Online User Documentation and Help System Requirements

7

9.

Purchased Components

7

10.

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

7 7 7 8 8 8 8 8 8 9

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

3

RU Financial Services Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

10.2

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

9 9 9 9 9 10 10 10 10 10 10 10 10 11

11.

Licensing Requirements

11

12.

Legal, Copyright and Other Notices

11

Applicable Standards NASD, SIPC rules

11 11

13. 13.1

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 Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services Supplementary Specification RU e-st Case Study 8 2.2

Version: RUCS 8 Date: October 30, 2002

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 est 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 Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

RU Financial Services Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

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 Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

9

RU Financial Services Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

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 Supplementary Specification RU e-st Case Study 8

Version: RUCS 8 Date: October 30, 2002

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

11

RU Financial Services Supplementary Specification RU e-st Case Study 8

12

Version: RUCS 8 Date: October 30, 2002

© 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

Revision History Date 6th Jan 2003

2

Version 1.0

Description Initial version

Author Bryon Baker

© 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 Software Development Plan RU e-st Case Study 9

Version: RUCS 9 Date: 4/10/2003 9:32 AM

Table of Contents 1. 1.1 1.2 1.3 1.4 1.5

Introduction..................................................................................................................................... 5 Purpose ................................................................................................................................... 5 Scope ...................................................................................................................................... 5 Definitions, Acronyms and Abbreviations ............................................................................. 5 References .............................................................................................................................. 5 Overview ................................................................................................................................ 5

2.1 2.2 2.3 2.4

Project Overview ............................................................................................................................ 6 Project Purpose, Scope, and Objectives ................................................................................. 6 Assumptions and Constraints ................................................................................................. 6 Project Deliverables................................................................................................................ 6 Evolution of the Software Development Plan ........................................................................ 6

2.

3.

4.

Project Organization ....................................................................................................................... 7 3.1 Organizational Structure......................................................................................................... 7 3.2 External Interfaces.................................................................................................................. 7 3.3 Roles and Responsibilities...................................................................................................... 7 Management Process ...................................................................................................................... 8 Project Estimates .................................................................................................................... 8 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 4.1 4.2

5. 5.1 5.2 5.3 5.4 6.

Technical Process Plans ................................................................................................................ 15 Development Case................................................................................................................ 15 Methods, tools and techniques.............................................................................................. 15 Infrastructure Plan ................................................................................................................ 15 Product Acceptance Plan ...................................................................................................... 15 Supporting Process Plans .............................................................................................................. 15

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

3

4

7.

Additional plans ............................................................................................................................ 15

8.

Annexes ........................................................................................................................................ 15

9.

Index ............................................................................................................................................. 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 Software Development Plan RU e-st Case Study 9

Version: RUCS 9 Date: 4/10/2003 9:32 AM

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. 2.

Vision for the RU e-st Stock Trading System, RUIT387, V1.0, RU Financial Services IT. 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

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: • • • • • • • • • • • • •

2.4

6

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

Evolution of the Software Development Plan The Software Development Plan will be revised prior to the start of each Iteration phase.

© 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 Software Development Plan RU e-st Case Study 9

Version: RUCS 9 Date: 4/10/2003 9:32 AM

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/ Change Control Manager

Responsible for Configuration Control on the project and for exercising the RU Financial Services Change Request Process in the project. Participates in an extended Project Management Team.

Systems Engineering Team Lead

Leads the team primarily responsible for managing the Business Modeling and Requirements disciplines. Participates in an extended Project Management Team.

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

7

Software Engineering Team Lead

Primarily responsible for the analysis and design and the 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. 4.1

Management Process 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 4.2.1

Project Plan 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 Iterations

Start

End

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

8

Description

Milestone

© 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 Software Development Plan RU e-st Case Study 9

Version: RUCS 9 Date: 4/10/2003 9:32 AM

Inception Phase

The Inception Phase develops the product requirements and establishes the business case for the RU e-st Stock Trading System. The major use cases are developed as well as the high level Software Development Plan. At the end of the Inception Phase, RU Financial Services will decide whether to fund and proceed with the project based upon the business case.

Business Case Review Milestone at the end of the phase marks the Go/No Go decision for the project.

Elaboration Phase

The Elaboration Phase analyzes the requirements and develops the architectural prototype. At the completion of the Elaboration Phase, all use cases selected for Release 1.0 will have completed analysis and design. In addition, the high-risk use cases for Release 2.0 will have been analyzed and designed. The architectural prototype tests the feasibility and performance of the architecture that is required for Release 1.0.

The Architectural Prototype Milestone marks the end of the Elaboration Phase. This prototype signifies verification of the major architectural components that comprise the R1.0 Release.

Construction Phase

During the Construction Phase, remaining use cases are analyzed and designed. The Beta version for Release 1.0 is developed and distributed for evaluation. The implementation and test activities to support the R1.0 and R2.0 releases are completed.

The R2.0 Operational Capability Milestone marks the end of the Construction Phase. Release 2.0 software is ready for packaging.

Transition Phase

The Transition Phase prepares the R1.0 and R2.0 releases for distribution. It provides the required support to ensure a smooth installation including user training.

The R2.0 Release Milestone marks the end of the Transition Phase. 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 o o o

Reduce technical risk. Provide early versions of a working system. Allow maximum flexibility in planning features for each release. Enable scope changes to be handled effectively within an iteration cycle.

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

9

The following table describes the iterations along with associated milestones and addressed risks. Phase

Iteration

Description

Associated Milestones

Risks Addressed

Inception Phase

Preliminary Iteration

Defines business model, product requirements, Software Development Plan, and business case.

Business Case Review

Clarifies user requirements up front. Develops realistic Software Development Plans and scope. Determines feasibility of project from a business point of view.

Elaboration Phase

E1 Iteration: Develop Architectural Prototype

Completes analysis and design for all R1 use cases. Develops the architectural prototype for R1.

Architectural Prototype

Technical risks mitigated.

Complete analysis and design for all high-risk R2 use cases. Construction Phase

C1 Iteration: Develop R1 Beta

Implement and test R1 use cases to provide the R1 Beta Version.

Architectural issues clarified.

Early prototype for user review. R1 Beta

All key features from a user and architectural prospective implemented in the Beta. User feedback prior to release of R1.

C2 Iteration: Develop R1 Release

Implement and test remaining R1 use cases, fix defects from Beta, and incorporate feedback from Beta. Develops the R1 system.

R1 Software

R1 fully reviewed by user community. Product quality should be high. Defects minimized. Cost of quality reduced.

C3 Iteration: Develop R2 Release

Design, implement, and test R2 use cases.

R2 Software

Quick release of R2 addresses customer satisfaction.

Incorporate enhancements and defects from R1.

All key functionality provided in System by R2 Release.

Develops the R2 system. Phase

10

Iteration

Description

Associated Milestones

Risks Addressed

© 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 Software Development Plan RU e-st Case Study 9 Transition phase

T1 Iteration: R1 Release

Version: RUCS 9 Date: 4/10/2003 9:32 AM

Package, distribute, and install R1 Release.

R1 Released

Two-stage release minimizes defects. Two-stage release provides easier transition for users.

T2 Iteration: R2 Release

Package, distribute, and install R2 Release.

R2 Released

Two-stage 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 o o o o o

Logon Get a Quote Execute a trade Interface to the Market Trading System and Quote System Administer customer accounts Report tax information to the customer and IRS

Release 2 should include: o o

News updates to customer 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

11

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

12

Start

Finish

Start Business Case Review Milestone (end Inception Phase) Architectural Prototype Milestone (end Elaboration Phase) Beta Milestone (Beta Version Ready) Initial Operational Capability Milestone (Release 1.0) Product Release R1.0 Milestone Second Operational Capability Milestone (Release 2.0) Product Release R2.0 Milestone

Tue 12/1/02 Tue 12/1/02 Tue 1/19/03 Tue 3/2/03 Fri 4/2/03 Mon 5/10/03 Wed 5/19/03 Tue 6/15/03 Thu 6/24/03

Thu 6/24/03 Tue 12/1/02 Tue 1/19/03 Tue 3/2/03 Fri 4/2/03 Mon 5/10/03 Wed 5/19/03 Tue 6/15/03 Thu 6/24/03

Inception Phase Preliminary Iteration Business Modeling Requirements Configuration Management Management

Tue 12/1/02 Tue 12/1/02 Tue 12/1/02 Tue 12/1/02 Tue 12/1/02 Tue 12/1/02

Tue 1/19/03 Tue 1/19/03 Mon 12/21/02 Tue 1/19/03 Mon 1/11/03 Tue 1/19/03

Elaboration Phase Iteration E1 - Develop Architectural Prototype Business Modeling Requirements Use Cases/Scenarios: Execute Trade Use Case: Customer executes a market buy. Execute Trade Use Case: Fail due to rejected trade Get Quote Use Case: Customer gets a quote Get Quote Use Case: Fail due to quote system is unavailable Analysis and Design (Architecture and Major Risks) Implementation (Architecture and Major Risks) Test (Architecture and Major Risks) Management

Wed 1/20/03 Wed 1/20/03 Wed 1/20/03 Mon 1/25/03

Tue 3/2/03 Tue 3/2/03 Fri 1/22/03 Fri 1/29/03

Mon 1/25/03 Thu 1/28/03 Mon 1/25/03 Thu 1/28/03 Mon 2/1/03 Mon 2/15/03 Mon 2/22/03 Wed 1/20/03

Wed 1/27/03 Fri 1/29/03 Wed 1/27/03 Fri 1/29/03 Fri 2/12/03 Fri 2/19/03 Tue 3/2/03 Tue 3/2/03

Construction Phase Iteration C1: Develop Release 1 Beta Requirements Use Cases/Scenarios: T.B.D.

Wed 3/3/03 Wed 3/3/03 Mon 1/25/03

Tue 6/15/03 Fri 4/2/03 Fri 1/29/03

Implementation (Beta) Test (Interfaces and Integrated Function) Management Iteration C2: Develop Release 1 Requirements Use Cases/Scenarios:

Wed 3/3/03 Thu 3/25/03 Wed 3/3/03 Mon 4/5/03 Mon 1/25/03

Wed 3/24/03 Fri 4/2/03 Fri 4/2/03 Mon 5/10/03 Fri 1/29/03

Milestones

© 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 Software Development Plan RU e-st Case Study 9

Version: RUCS 9 Date: 4/10/2003 9:32 AM

T.B.D. Analysis & Design (Refine) Implementation (Effective Production) Test (Interfaces and Integrated Function) Management Iteration C3: Develop Release 2.0 Requirements Use Cases/Scenarios: T.B.D.

Mon 4/5/03 Tue 4/13/03 Tue 4/27/03 Mon 4/5/03 Tue 5/11/03 Mon 1/25/03

Mon 4/12/03 Mon 4/26/03 Mon 5/10/03 Mon 5/10/03 Tue 6/15/03 Fri 1/29/03

Analysis & Design (Refine) Implementation (Effective Production) Test (Interfaces and Integrated Function) Management

Tue 5/11/03 Wed 5/19/03 Thu 6/3/03 Tue 5/11/03

Tue 5/18/03 Wed 6/2/03 Tue 6/15/03 Tue 6/15/03

Transition Phase Iteration T1: Release 1 Deployment Iteration T2: Release 2 Deployment

Tue 5/11/03 Tue 5/11/03 Tue 5/11/03 Wed 6/16/03 Wed 6/16/03

Thu 6/24/03 Wed 5/19/03 Wed 5/19/03 Thu 6/24/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 o o o

Mastering Requirements Management with Use Cases Object Oriented Analysis and Design Introduction to the Rational Unified Process Advanced J2EE Architectures

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

13

4.2.6

Budget

The project’s budget as based upon the initial estimates. 4.3 4.4

Iteration Plans See the RU e-st Stock Trading System E1 Iteration Plan [11]. 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 Software Development Plan RU e-st Case Study 9

Version: RUCS 9 Date: 4/10/2003 9:32 AM

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

15

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

Table of Contents 1.

Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.3.1 Baseline 1.3.2 Business Rule 1.3.3 Business Unit Manager 1.3.4 Customer 1.3.5 Engineering Time 1.3.6 NCSS 1.3.7 Pareto Chart 1.3.8 Product Feature 1.3.9 Rational RequisitePro® 1.3.10 Rational Rose 1.3.11 Rational SoDA 1.3.12 Rational TestManager 1.3.13 Stakeholder 1.3.14 Stakeholder Request 1.3.15 Vision Document 1.4 References 1.5 Overview

5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 7 7 7 8

2.

Requirements Management 2.1 Organization, Responsibilities, and Interfaces 2.2 Tools, Environment, and Infrastructure

8 8 9

3.

The Requirements Management Program 3.1 Requirements Identification 3.2 Traceability 3.2.1 Criteria for Stakeholder Requests 3.2.2 Criteria for Product Feature Requirements 3.2.3 Criteria for Use-Case Requirements 3.2.4 Criteria for Supplementary Requirements 3.2.5 Criteria for Glossary Requirements 3.2.6 Criteria for Supporting Document Requirements 3.3 Attributes 3.3.1 Requirement Attributes for Feature (FEAT) 3.3.2 Requirement Attributes for Requirements Management Plan Requirements (RM) 3.3.3 Requirement Attributes for Software Requirements (SR) 3.3.4 Requirement Attributes for Stakeholder Requests (STRQ) 3.3.5 Requirement Attributes for Supplementary Requirements (SUPL) 3.3.6 Requirement Attributes for Use Case (UC) 3.4 Reports and Measures 3.5 Requirements Change Management 3.5.1 Change Request Processing and Approval 3.5.2 Change Control Board (CCB) 3.5.3 Project Baselines 3.6 Workflows and Activities © Copyright IBM Corp. 2003 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

10 10 10 11 11 12 12 12 12 12 12 15 16 17 18 19 21 21 21 21 21 21 3

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

4.

Milestones

21

5.

Training and Resources

21

Appendix 1: Technology Risk Assessment

4

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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

5

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

7

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

2.2 Tools, Environment, and Infrastructure TBD

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

9

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

3. The Requirements Management Program 3.1 Requirements Identification ARTIFACT

REQT. TYPE

DESCRIPTION

Vision (VIS)

Product Feature (FEAT)

The Vision document defines the stakeholder’s view of the product to be developed, specified in terms of the stakeholder’s key needs and features. Owned and authored by the System Analyst.

Stakeholder Requests (STR)

Stakeholder Requests (STRQ)

Requests a stakeholder makes for the system to be developed. It may also contain references to external sources to which the system must comply. Provided by Stakeholders.

Glossary (GLS)

Term (TERM)

Requirements Management Plan (RMP)

Requirements Management Plan (RMP)

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. Describes the documents, requirement types, and attributes; and information and control mechanisms for measuring, reporting, and controlling changes to the product requirements. Owned and authored by the System Analyst.

Modern Software Requirements (MSRS)

Software Requirements (SR)

Package capturing the complete software requirements for the system. For the system being developed, this artifact consists of a package containing Use-Case Specifications and Supplementary Specification. Generated SoDA report providing a high-level view of all use cases and actors for this release documented in Rational Rose.

Use-Case Model Survey Use-Case Specification (UCS)

Use Case (UC)

Use cases are defined for each use-case name at the top of a hierarchy with dependents representing sections of the use-case description. Individual 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 Specification (SUPL)

Supplementary Requirement (SUPL)

The Supplementary Specifications capture system requirements not readily captured in use cases. Such requirements include: legal and regulatory 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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

11

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Requirements Management Plan RU e-st Case Study Artifact 10

High Medium

Low

RUCS10 Date: October 30, 2001

Essential requirements. Failure to implement means the system will not meet customer needs. All critical requirements must be implemented in the release. 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. 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 Medium Low

Above average effort to implement. Average effort to implement. 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

13

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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

Medium

Low

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. 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. 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 Medium Low

It is very unlikely that this requirement will change, or that the development team’s understanding of the requirement will change. No indicator exists to predict the likelihood of change for the requirement. DEFAULT 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

Approved Incorporated Validated

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. Requirement is deemed useful and feasible and has been approved for implementation by the official approval channel. Requirement is incorporated into the product baseline at a specific point in time. 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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

15

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

17

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

19

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

Property Set by the System Analyst. Indicates the location within a Use-Case Report where the requirement lives. Name Brief Description Basic Flow Alternate Flow Special Requirements Precondition Postcondition Relationships Extension Points

The requirement is found in the name of the Use-Case. The requirement is found in the brief description of the Use-Case. The requirement is found in the basic flow of the Use-Case. The requirement is found in an alternate flow of the Use-Case. The requirement is found in the Special Requirements section of the UseCase. The requirement is found in the Precondition section of the Use-Case. The requirement is found in the Postcondition section of the Use-Case. The requirement is found in the Relationships section of the Use-Case. 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 Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

21

RU Financial Services Requirements Management Plan RU e-st Case Study Artifact 10

RUCS10 Date: October 30, 2001

Appendix 1: Technology Risk Assessment Risk Factor 1. Which hardware, needed for the feature, is new to the company? None CPU Peripheral and/or additional storage Terminals Mini/Micro/CU

High High High High

2. Is the system software (non-operating system) new to the IT project team? No Programming Language Database Data communications Other 3. How knowledgeable is the primary Stakeholder(s) in the proposed application area? Limited Understands concept but has no experience Has been involved in prior implementation efforts 4. How knowledgeable is IT team in proposed application area? Limited Understands concept but has no experience Has been involved in prior implementation efforts Total

Weight X5 0 3 3 3 3 X5

High High High High

0 3 3 3 3

X5 High 3 Medium 2 Low 1 X5 High 3 Medium 2 Low 1 10150

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

1

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

12 February 2003

0.1

Initial version

Bryon Baker

5th March 2003

0.2

Incorporated review feedback

Bryon Baker

th

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

2

RU Financial Services, RU e-st Project

RUCS11

Use-Case-Modeling Guidelines

Date: 4/10/2003 12:35 PM

RUCS11

Table of Contents 1. 1.1

Introduction Purpose

4 4

1.2

Scope

4

1.3

Definitions, Acronyms, and Abbreviations

4

1.4

References

4

1.5

Overview

4

Use-Case-Modeling Guidelines Evolution of a Use Case

5 5

2. 2.1

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.1

How to Describe a Use Case Use Case Flows of Events Style

7 7

3.2

Subflows

8

3.3

Conditional Behavior

9

4.

UML Stereotypes «initiates» stereotype

9 9

5. 5.1

Model Structuring «include» relationship

10 10

5.2

«extend» relationship

10

5.3

Use-Case Generalization

10

5.4

Actor Generalization

11

3.

4.1

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

3

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

4

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 communicatesassociation 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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

6

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

8

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

9

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

10

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 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

11

RU Financial Services, RU e-st Project

RUCS11

Use-Case-Modeling Guidelines

Date: 4/10/2003 12:35 PM

RUCS11

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

12

►

►

►

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 miniproject 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 attributes, and document types

Three -- Structured

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 preUML 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 oneto-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

Brief Description

This use case prescribes the way in 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.

Flow of Events

The welder grabs the teaching electrode and positions the teaching tip at the start of the first weld. 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. Pre-conditions

The robot must have performed a successful auto-calibrate procedure.

Post-conditions

The traverse path and weld paths are remembered by the system.

Special Requirements

The welder cannot move the tip at a rate faster than 10cm/second. If faster motion is detected, the system 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 Övergaard. 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

http://www.therationaledge.com/content/may_01/t_legacy_pk.html

Copyright Rational Software 2001

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 objectoriented 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 reimplementation 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.

1

Michael 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 usecase 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 Flow

Alternate Flow 1

Scenario 3 Basic Flow

Alternate Flow 1

Scenario 4 Basic Flow

Alternate Flow 3

Alternate Flow 2

Scenario 5 Basic Flow

Alternate Flow 3

Alternate Flow 1

Scenario 6 Basic Flow

Alternate Flow 3

Alternate Flow 1

Scenario 7 Basic Flow

Alternate Flow 4

Scenario 8 Basic Flow

Alternate Flow 3

Alternate Flow 2

Alternate Flow 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 fullydetailed 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 unavailable

Basic Flow

A4

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 Case ID

Scenario/ Condition

Student Password Courses Prerequisites Course Schedule ID selected fulfilled Open Open

Expected Result

RC 1

Scenario 1successful registration

RC 2

V

V

V

V

V

V

Schedule and confirmation number displayed

Scenario 2- I unidentified student

N/A

N/A

N/A

N/A

N/A

Error message; back to login screen

RC 3

Scenario 3valid user quits

V

V

N/A

N/A

N/A

N/A

Login screen appears

RC 4

Scenario 4course registration system unavailable

V

V

N/A

N/A

N/A

N/A

Error message; back to step 2

RC 5

Scenario 5registration closed

V

V

N/A

N/A

N/A

N/A

Error message; back to step 2

RC 6

Scenario 6cannot enroll -course full

V

V

V

V

I

V

Error message; back to step 3

RC 7

Scenario 6- V cannot enroll -prerequisite not fulfilled

V

V

I

V

V

Error message; back to step 4

RC 8

Scenario 6cannot enroll -schedule conflict

V

V

V

V

I

Error message; back to step 4

V

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/ Case Condition ID

Student ID

RC 1

jheumann abc123

Scenario 1successful registration

Password Courses Prerequisites Course Schedule Expected selected fulfilled Open Open Result

M101>

Yes

Yes

Yes

Schedule and confirmation number displayed

E201 S101

RC 2

Scenario 2- Jheuman1 N/A unidentified student

N/A

N/A

N/A

N/A

Error message; back to login screen

RC 3

Scenario 3valid user quits

jheumann abc123

N/A

N/A

N/A

N/A

Login screen appears

RC 4

Scenario 4course registration system unavailable

jheumann abc123

N/A

N/A

N/A

N/A

Error message; back to step 2

RC 5

Scenario 5registration closed

jheumann abc123

N/A

N/A

N/A

N/A

Error message; back to step 2

RC 6

Scenario 6cannot enroll -course full

jheumann abc123

M101

Yes

M101 full

Yes

Error message; back to step 3

No for E201

Yes

Yes

Error message; back to step 4

E201 S101

RC 7

Scenario 6- jheumann abc123 cannot enroll -prerequisite not fulfilled

M101 E201 S101

RC 8

Scenario 6cannot enroll -schedule conflict

jheumann abc123

M101 E201

Yes

Yes

E202 and S101 conflict

Error message; back to step 4

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

Request Catalog

<<extend>>

Place Order

<>

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 relationship?

The addition use case references the base use case.

The base use case references the addition use case.

The addition use case (child) references the base use case (parent).

Does the relationship have multiplicity?

Yes, on the addition side.

No. If you want to include the same segment of behavior more than once, that needs to be stated in the base use case.

No.

Does the relationship have a condition?

Yes.

No. If you want to express a condition on the inclusion you need to say it explicitly in the base use case.

No.

Structuring the Use-Case Model

Is the addition use case abstract?

Often yes, but not necessarily.

Yes.

Often no, but it can be.

Is the base use case modified by the addition?

The extension implicitly modifies the behavior of the base use case.

The inclusion explicitly modifies the effect of the base use case.

If the base use case (parent) is instantiated, 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 have to be complete and meaningful?

Yes.

Together with the additions, yes.

If it is abstract, no.

Does the addition use case have to be complete and meaningful?

No.

No.

Together with the base use case (parent), yes.

Can the addition use case access attributes of the base use case?

Yes.

No. The inclusion is encapsulated, and only "sees" itself.

Yes, by the normal mechanisms of inheritance.

Can the base use case access attributes of the addition use case?

No. The base use case must be well-formed in the absence of the addition.

No. The base use case only knows about the effect of the addition. The addition is encapsulated.

No. The base use case (parent) must in this sense be well-formed in the absence of the 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 <>

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-casegeneralization 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:

Caller

Place Call

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 extendrelationship, 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 extendrelationship 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 extendrelationship is checked at the first extension point only, once started all insertion segments must be performed.

Structuring the Use-Case Model

Use-Case Instance

Extension Point 1

Base Use Case

Extension Point 2

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 includerelationship 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]