TK2023 Object-Oriented Software Engineering

TK2023 Object-Oriented Software Engineering CHAPTER 4 REQUIREMENTS AND USE CASES

REQUIREMENTS • Requirements are capabilities and conditions to which the system must conform. • A prime challenge of requirements work is to find, communicate, and remember (record) what is really needed, in a form that can be understood by the client and development team members. • UP promotes a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.

THE REQUIREMENTS DISCIPLINE IN UP Sample UP Disciplines Business Modeling Requirements Requirements Design Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations

TYPES OF REQUIREMENTS • UP categorizes requirements according to the FURPS+ model: • Functional - features, capabilities, securities • Usability - human factors, help, documentation • Reliability - frequency of failure, recoverability, predictability • Performance - response times, throughput, accuracy, availability, resource usage • Supportability - adaptability, maintainability, internationalization, configurability

Ancillary and sub-factors, such as • Implementation - resource limitations, languages and tools, hardware, … • Interface - constraints imposed by interfacing with external systems • Operations - system management in its operational setting • Packaging • Legal - licensing, etc • Requirements are sometimes broadly categorized as functional (behavioural) and non-functional (everything else).

INTRODUCTION TO USE CASES • Customers and end users have goals and want computer systems to help meet them. • Informally, use cases are stories of using a system to meet goals. • Example (brief format): Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The cashier enters payment information, which the system validates and records. The system updates inventory. The system produces a receipt. The customer receives the receipt from the cashier and then leaves with the items.

The essence of use cases is the discovering and recording of functional requirements through writing stories of using a system to help fulfill various stakeholder goals. • The idea of use cases to describe functional requirements was introduced by Ivar Jacobson in 1986.

ACTOR • An actor is an external entity which interacts with the SuD (System under Discussion) to achieve a desired goal. It can be a person (identified by its role), computer system or organization. • Actors are basically users of the SuD. For example, cashier.

SCENARIO • A scenario is a specific sequence of actions and interactions between actors and the SuD. It is also called a user story or a use case instance. • Example, Use case: Process Sale Possible scenarios: • Successfully purchasing items with cash • Failure to purchase items because credit card is rejected by the system.

In other words, a use case is a collection of related success and failure scenarios that describe actors using a system to support a goal.

ANOTHER EXAMPLE (CASUAL FORMAT) Handle Returns Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item … Alternate Scenarios: • If the credit authorization is rejected, inform the customer and ask for an alternate payment method.

If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code. • If the system detects failure to communicate with the external tax calculator system, … • …

ANOTHER FORMAT (TWO-COLUMN FORMAT) Process Sale Main Success Scenario:

BLACK-BOX USE CASES • Black-box use cases are use cases that do not describe the internal workings of the SuD, its components or design. • They specify what the SuD must do (the functional requirements) without deciding how it will do it (the design). • Black-box use cases should be written during requirements analysis.

USE CASE FORMATS • The format used for writing a use case depends on the current need. • brief Terse one-paragraph summary, usually of the main success scenario. • casual Informal paragraph format. Multiple paragraphs that cover various scenarios. • fully dressed The most elaborate format. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees. EXAMPLE

GOAL LEVELS • Use cases can be expressed at different levels, depending on the system boundary, actors and goals. • Generally, there are 3 goal levels: • Summary Level • User Level • Subfunction Level

SUMMARY GOAL LEVEL • Example (Handle a Claim): 1. Customer reports a claim (paper, phone or fax) to Clerk. 2. Clerk finds the policy, registers loss in System, and assigns an Adjuster. 3. Adjuster investigates the claim and updates the claim with additional information. 4. Adjuster enters progress notes over time. 5. Adjuster corrects entries and sets monies aside over time. …

USER GOAL LEVEL • Example: The manager requests for a hardcopy of a certain report from his personal assistant. The personal assistant turns to his computer to accomplish a goal i.e. to print the document. He works with the computer for a while and finally accomplishes the goal. He then passes the hardcopy to the manager.

SUBFUNCTION LEVEL • Subfunction-level goals are normally referred to by user-level goals. • Examples: • Open a file • Find a product • Find a customer • Log into system

USER GOAL-LEVEL USE CASES • Actors have goals (or needs) and use computer applications to help satisfy them. • A user goal-level use case is one that serves to fulfill a goal of a user of the SuD. • When identifying such use cases, one should first ask Example: Goal: capture or process a sale Use case: process sale What are the goals of the primary actors?

Some guidelines in identifying user goal-level use cases: • A use case should yield an observable result of value to a particular actor (refer Boss Test). • Is “Log In” a use case at the user goal level? • The use case should not be just a single small step. The main success scenario is probably 5 to 10 steps. • The use case can be executed in a single session (probably between a few minutes to an hour). It should not take days and multiple sessions.

USE CASE EXAMPLE: ATM • Some user goal-level use cases: • Start Up ATM • Shut Down ATM • Deposit Fund • Withdraw Fund • Transfer Fund • Check Account Balance

PROCEDURE FOR DEFINING USE CASES • The basic procedure: • Choose the system boundary • Identify the primary actors • Identify user goals • Define the use cases

STEP 1: CHOOSE SYSTEM BOUNDARY • Can be done by determining what is outside the boundary of the SuD i.e what are the primary and supporting actors? • Primary actors have user goals fulfilled through using the SuD. • Supporting actors provide services to the SuD. • For the case study, the POS system itself is the SuD. Cashiers, payment authorization service, inventory control system, etc are outside the system boundary.

STEPS 2 & 3: IDENTIFY PRIMARY ACTORS AND GOALS • There are three types of actors: • Primary actor • has user goals fulfilled through services of the SuD • Example: cashier • Supporting actor • provides a service to the SuD • Example: printer subsystem • Offstage actor • has an interest in the behaviour of the use case but is not primary or supporting • Example: customer

Note that the SuD itself is an actor (when it calls upon the services of other systems). • Recall that primary actors can be other than persons.

Record the primary actors and their user goals in an actor-goal list. For example,

Questions that can help in brainstorming actors and goals: • Who starts and stops the system? • Who does user and security management? • Who does system administration? • Is there a monitoring process that restarts the system if it fails? • Who evaluates system activity or performance? • … (refer textbook p 83)

Enterprise Selling Things Checkout Service Sales Tax Agency POS System Goal: Collect Sales Activity taxes on sales System Cashier Customer Goal: Buy items Goal: Analyze sales Goal: Process sales and performance data • The identification of primary actors and user goals depends on the system boundary. • Why is Customer not the primary actor in the use case Process Sale?

STEP 4: DEFINE USE CASES • In general, define one use case for each user goal. A common exception is to combine CRUD (Create, Retrieve, Update, Delete) separate goals into one CRUD use case (Manage <X>). Example: Define “Manage Users” use case to satisfy the goals “create user”, “delete user”, “edit user”, etc.

Name the use case similar to the user goal. Make sure use case names start with a verb. Examples: Process Sale, Handle Returns, Start System

USE CASE LEVEL FOR REQUIREMENTS ANALYSIS • What is a useful level to express use cases for application requirements analysis? For requirements analysis for a computer application, focus on use cases at the user goal level.

WRITING USE CASES • Use cases written at the start of development are always imperfect and incomplete. • Writing use cases is not a “waterfall” process. There needs to be an ongoing personal communication between the developers and those who understand the domain (domain experts) and can make requirement decisions.

Use cases are said to be written in an essential style if the narrative is expressed at the level of user's intentions and system's responsibilities rather than their concrete actions. Compare the following actor's action 2. Cashier enters ID and password with 2. Cashier identifies self

Use cases written in an essential style are free of technology and mechanism details, especially those related to the UI (User Interface). They focus on the real user intent. • If user interface decisions are embedded in the text of a use case then that use case is said to be written in a concrete style.

Example (Concrete form/Not in essential form): … 1. Administrator enters ID and password in dialog box (see Picture 3). 2. System authenticates Administrator 3. System displays the “edit users” window (see Picture 4). …

Example (Written in essential/abstract form): … 1. Administrator identifies self 2. System authenticates identity …

Use cases should be written in an essential style during early requirements work. • Why? • Use cases written in a concrete style are useful later in design work.

system boundary communication NextGen POS Process Sale alternate notation for a computer Customer Payment system actor Authorization Service Handle Returns «actor» actor Tax Calculator Cashier «actor» Cash In Accounting System Manager «actor» «actor» Analyze Activity HR System Sales Activity System Manage Security System Manage Users Administrator use case . . . USE CASE DIAGRAMS • The UML provides a notation called the use case diagram to illustrate use cases, actors and the relationships between them.

REMEMBER THIS… • A use case diagram makes a good context diagram. It is a communication tool that summarizes the behaviour of a system and its actors. Use case diagrams and use case relationships are secondary in use case work. Focus on writing use cases.

stereotype • Actors can be represented using the following notation or as below

Actors are associated with use cases by solid lines. • It is optional to put an arrowhead at the end of the line to indicate the direction of the initial invocation or to indicate the primary actor in the use case.

USE CASES ARE NOT OBJECT-ORIENTED • It needs to be understood that there is nothing object-oriented about use cases. • They are a requirements analysis tool that can also be applied to non-object-oriented projects.

USE CASES WITHIN THE UP • Use cases are very important in the UP. In fact, UP encourages use-case driven development. • Requirements are primarily recorded in use cases; other requirement techniques are secondary. • Use cases play an important role in iterative planning. • Use-case realizations drive the design. • Use cases often influence the organization of user manuals.

USE CASES IN THE INCEPTION PHASE • User goal-level use cases are identified in this phase. Most of the interesting, complex or risky use cases are written in brief format. Through this exercise, the team should have a high-level picture of the system's functionalities. • 10% to 20% of the use cases that represent core complex functions or risky ones are rewritten in fully dressed format. This is done to better comprehend the magnitude and complexities of the project. inc. elaboration construction transition

USE CASES IN THE ELABORATION PHASE • In the elaboration phase, risky, high-value, and architecturally significant parts of the system are incrementally built. Also, majority of the requirements are identified and clarified in this phase. • Use cases are prioritized and each iteration focuses on a subset of the most important ones. inc. elaboration construction transition

The team's understanding of the requirements increases after each iteration through feedback from previous iterations. Requirements are iteratively and adaptively refined and becomes stable gradually. • More and more use cases are written, and rewritten, in fully dressed format. By the end of the elaboration phase, 80% - 90% of the use cases should have been written in detail.

USE CASES IN THE CONSTRUCTION PHASE • The construction phase focuses on completing the system, once the risky and core unstable issues have settled down in elaboration. • There will be some minor use case writing but much less so than in the elaboration phase. • Majority of core functional and non-functional requirements should have iteratively and adaptively stabilized. inc. elaboration construction transition

YOUR FIRST ASSIGNMENT • Suppose you are involved in a project to develop an online cinema reservation system. • Identify three user goal-level use cases. Draw a use case diagram showing those use cases and the actors involved. • Determine which of those use cases you think is the most complex one and do the following tasks: • Write the use case in the casual format with at least two alternate paths. • Write a happy path for that use case in the two-column format. • Write one success scenario and one failure scenario for that use case. • The use cases you write must be black-box use cases and written in essential style. • Your handwritten assignment must be submitted by 10:00 am, 1 February 2010 (Monday).

TK2023 Object-Oriented Software Engineering