requirements management with use cases module 9: requirements across the product lifecycle...

Requirements Management with Use Cases

Module 9: Requirements Across The Product Lifecycle

Requirements Management with Use Cases

Module 9: Requirements Across The Product Lifecycle

Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 2

0 - About This Course1 - Best Practices of Software Engineering2 - Introduction to RMUC3 - Analyze the Problem4 - Understand Stakeholder Needs5 - Define the System6 - Manage the Scope of the System7 - Refine the System Definition8 - Manage Changing Requirements9 - Requirements Across the Product Lifecycle

RMUC: Course Outline


Requirements Across the Product Lifecycle

Problem

Solution Space

Problem Space

Needs

Features

SoftwareRequirements

Test Procedures Design User

Docs

The The Product Product To Be To Be BuiltBuilt

Traceability


Requirements Across the Product Lifecycle

Requirements


Each Iteration Makes a Pass Through Requirements


Inception Iterations: Typical Requirements Results

Collect information to develop the business case: A draft of a survey of the use-case model An initial terminology A few use-case flow of events (requirements capture) Sketches of user interfaces A prototype (optional)


L P

I DU

Elaboration Iterations: Typical Requirement Results Refine requirements to build/validate architecture

Update terminology Capture most software requirements

• Use cases and supplementary specifications Refine use cases developed in previous iterations Decide on use-case view of the architecture


Construction Iterations: Typical Requirement Results Build the complete system. At this point,

requirements should be relatively stable. Change requests on use-case’s flow of events Updated use-case flow of events Emphasis on analysis&design, implementation and test


Transition Iterations: Typical Requirements Results

Normally, requirements should not change at this late stage of the project.

However, if decisions are made to add new features to the system, an iteration (and produced results) would be similar to a typical construction-phase iteration.


Iteration Assessment Assess requirements capture results relative to the

evaluation criteria established during iteration planning: Functionality Performance Capacity Quality measures

Consider external changes that have occurred during this iteration Examples: changes to requirements, user needs,

competitor’s plans Determine what rework, if any, is required and

assign it to the remaining iterations


Reviewing Requirements

Informal reviews To find errors Whenever needed Small team, possibly including QA

Formal reviews To decide whether to proceed to

next phase At milestones and tollgates Large reviewing team, including

customers


Types of Reviews

Walkthrough

Inspection

Formal Review

Less Formal

More Formal

IEEE, 1994


Reviewing Requirements: Walkthrough Purpose

Find errors in an early stage Find deviations from approved style, technique, standards Informing

Participants A few project members, need not be prepared

Procedure Analyst gives an overview of the results Analyst walks through reviewed chapters, other

participants comment Analyst makes notes on errors found


Reviewing Requirements: Formal Review Purpose

To ensure that results are complete and consistent To decide on continuation of project

Participants Top management, project leaders, process owners,

analysts Procedure

Check status of documents (evaluation results) Review outcome of the project Authorize start of next phase


Reviewing Requirements: Inspection Purpose

To get views from different parts of the organization To become aware of each other’s views To find errors and problems early

• Problems surfacing at the end may kill the project! To decide whether the reviewed document should be

• Approved, approved with corrections, or rejected Participants

Moderator Recorder Author Inspectors


Who Should be Inspectors?

Users of the system Members of departments using the new system

Representatives of all departments using new system Not just those that are involved in this use case

Process owners Managers of the users Domain experts Designers of the system


How to Organize an Inspection Before the meeting - At least 1 week in advance

Invite Inspectors (Hint: < 8) Distribute materials to review (Hint: < 50 pages) Distribute instructions and questions Have inspectors read materials and write comments

At the meeting Moderator leads and keeps meeting focused

• Keep the meeting short and fast (Hint: < 2 hours)

Recorder records all issues Inspectors look for and discuss errors

• Objective is to find problems - not to solve them• Handle spelling/typographical errors outside the meeting


Results of an Inspection Major Problems

Severe problem: a section has to be reworked Use case can’t be approved: a new inspection is required

Minor Problems Things that can be fixed Approval of use case may be delegated to moderator

Recommendations Give concrete, constructive suggestions for improvements Avoid too general comments like “bad” or “unclear” Do not focus only on the negative, note positives too


Review Questions For The Use-Case Model

Is the use-case model understandable? By studying the use-case model, do you

understand the system's functions and how they are related?

Have all functional requirements been met? Does the use-case model contain any

superfluous behavior? Is the division of the model into use-case

packages appropriate? Is it worth the money to build the system?


Review Questions For Actors

Have all the actors been identified? Is each actor involved with at least one use

case? Is each actor really a role? Should any be

merged or split? Do two actors play the same role in relation

to a use case? Do the actors have intuitive and descriptive

names? Can both users and customers understand the names?


Review Questions For Use Cases Name and brief description

Is it clear which actor wishes to do the use case? Is the purpose of the use case also clear? Does the use case have a unique and intuitive name so

that it cannot be mixed up with others? Flows of events

Are the flows (basic and alternative) accurate? Is it clear how and when each flow of events starts and

ends? Are actor interactions and exchanged information clear? Does the communication sequence between actor and

use-case conform to the user's expectations?


Review Questions For Use Cases (Continued)

Does the use case deliver a result of value? Do you understand how the result of value is

achieved? Is this a good way to do it? Is there a better way to do it? Is anything missing? Is the use case overly complex? Is the use case independent of the others? Do any use cases have very similar behaviors

or flows of events?


Exercise: Review the Use-Case Model

Review the current state of the use-case model of one of the groups in the class What type of review would be appropriate at

this point in time?


Review: Requirements Across the Product Lifecycle

1. What is the typical state of a use-case model at end of The Inception phase? The Elaboration phase? The Construction phase? The Transition phase?

2. Under what circumstances would you change anything in the use-case model during the Transition phase?

3. What is the purpose and contents of an iteration assessment?

4. What are the different types of reviews? When might each be used?


How Do Requirements Drive Development?

Verified byRealized by Implemented by

Implementation Model Test ModelDesign Model

Use-Case Model


Requirements Drive Design and Implementation

Analysisand DesignAdd detail and

design decisions

Developer’s Perspective

Use CasesDevelop model of requirements

User’s Perspective


• The system displays a list of transaction offerings.

• The system retrieves and displays a list of current transaction offerings from the ATM database.

Analysis/Design Adds Information To Use Cases


Bank ConsortiumWithdraw CashBank Customer

<<boundary>>Card Reader

<<boundary>>Bank Interface

Analysis/Design Defines Classes


Use-Case RealizationUse Case

Sequence DiagramsCollaboration Diagrams

Analysis/Design Defines Interactions Among Classes

For each use-case flow of events, show interactions in interaction diagrams

UC7: UC Collaboration Diagram


Example: Withdraw Cash UC Sequence Diagram

: Card Reader : Card Trans : PIN request : Menu : Money in ATM : Withdraw Trans

: Money dispenser : Select amount : Bank interface : log : Receipt Printer

New card, card idrequest PIN code

Check available money, kind of bills

Display possible selectionsWithdraw selected

Start withdrawCheck bills

Ask for amount

Ask for account

Send

Log Start of trans

OK to dispense

Log

Dispense Money

Eject card

Money ejected

Print receipt


Example: Withdraw Cash UC Collaboration Diagram

: Card Reader

: Card Trans

: PIN request : Menu

The Customer inserts thei card in the card reader

: Money in ATM

: Withdraw Trans

: Money dispenser

: Select amount : Bank interface

: log : Receipt Printer

Knows the amountof each kind of bill

The bank withdraws immediately the money from the account

1: New card, card id

2: request PIN code

3: Check available money, kind of bills

4: Display possible selections

5: Withdraw selected

6: Start withdraw

8: Ask for amount

9: Ask for account

15: Dispense Money

11: Send

12: OK to dispense

7: Check bills

10: Log Start of trans

13: Log OK

14: Eject card

17: Print receipt

16: Money ejected


Requirements Drive Test

TestAdd detail and

test case decisions

Tester’s Perspective

Use CasesDevelop model of requirements

User’s Perspective


Scenario 1: Normal Flow

Insert card Read card Enter PIN Select transaction type Enter account Enter withdraw amount Check cash in ATM Ask bank for authorization Give money and receipt Take money, receipt,

and cardBank CustomerBank Customer

WithdrawWithdraw


TC#

executioncondition

Card / Reader

PIN Acct. # $entered

$ inacct.

$ inATM

Expectedresult

min. $ V / V V V V V V successmax. $ V / V V V V V V success

Use Case: Cash WithdrawalTest Type - Business Function

Test Cases For Scenario 1

Test ParametersTest ParametersTest ParametersTest Parameters


WithdrawWithdraw

Bank CustomerBank Customer

Scenario 2: Alternative Flow

Insufficient Cash in ATM

Insert card Read card Enter PIN Select transaction type Enter account Enter withdraw amount Verify cash amount in ATM Warning message given Press cancel ATM returns to select

transaction type prompt


Use Case: Cash WithdrawalTest Type - Business Function

TC#

Desc. Card /Reader

PIN Acct. # $entered

$ inacct.

$ inATM

Expectedresult

min. $ V / V V V V V V successmax. $ V / V V V V V V successATM outof funds

V / V V V V V I warningmsg.

Test Cases For Scenario 2: Alternative Flow

UC 6: Withdraw Cash Tests CasesTP8:Test Plan Template


RMUC: Summary Build the right system right by following a process to define

and manage requirements to meet the customer’s real needs

Effective problem analysis will help avoid the “Yes, but…” Elicitation helps you understand your stakeholders’ needs Use features and a use-case model to come to an

agreement with the customer on the definition of the system

Increase your chances to deliver on time and on budget by managing scope throughout the lifecycle of the project

A use-case model of the software requirements helps refine the system definition to drive design, test, and user documentation

Requirement attributes and traceability help you manage change and avoid “scope creep”


Applying RMUC Concepts: Handouts

Summary: Key Skills for Requirements Management White Paper: Applying Requirements Management

with Use Cases

WP3WP4


Why Are We Here?

The GOAL is to deliver quality products

on time and on budgetwhich meet the customer’s

real needs.

requirements management with use cases module 9: requirements across the product lifecycle...

Documents