Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements

Requirements Management with Use Cases

Module 10: Requirements Across the Product Lifecycle

Requirements Management with Use Cases

Module 10: Requirements Across the Product Lifecycle

Requirements Management with Use CasesCopyright © 1998-2001 Rational Software, all rights reserved 2

Objectives: Requirements Across the Lifecycle

Describe the state of a use-case model at the end of each phase of the lifecycle

Explain an iteration assessment Identify the types of requirements reviews Describe how requirements drive analysis

and design Describe how requirements drive test


Requirements Across the Product Lifecycle


Inception Iterations: Typical Requirements ResultsCollect information to develop the business case:

A draft of a survey of the use-case model An initial vocabulary A few use-case flows of events (requirements capture) Sketches of user interfaces A prototype (optional) Approximately 10% of schedule time Approximately <5% of person hours


L P

I DU

Elaboration Iterations: Typical Requirement ResultsRefine 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 Approximately 30% of schedule time Approximately 20% of person hours


Construction Iterations: Typical Requirement ResultsBuild the complete system

Change requests on use-case’s flow of events Updated use-case flow of events Emphasis on analysis, design, implementation and test Approximately 50% of schedule time Approximately 65% of person hours


Transition Iterations: Typical Requirements Results

Requirements should not change Similar to typical construction-phase iteration if

new features are added Approximately 10% of schedule time Approximately 10% of person hours


Iteration Assessment Apply evaluation criteria

Functionality Performance Capacity Quality measures

Consider external changes Examples: changes to requirements, user

needs, competitor’s plans Determine what rework, if any, is required Assign rework to 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


Review 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


Review Requirements: Inspection

Purpose To share views from different parts of the organization To find errors and problems early To make approval, revision, or rejection decisions

Participants Moderator, recorder, author, and inspectors

Procedure Organize before the meeting Keep meeting focused (moderator) Record all issues (recorder) Look for and discuss errors (Inspectors)


Review 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


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 Perspective

Use CasesDevelop model of requirements

User Perspective


Use-Case Realization

Use Case

Sequence Diagrams

Collaboration Diagrams

Analysis/Design Defines Classes and Interactions

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


Requirements Drive Test

TestAdd detail and

test case decisions

Tester Perspective

Use CasesDevelop model of requirements

User Perspective


Scenario 1: Happy Day Flow

Customer logs on Customer selects ‘Trade’ Customer selects account Customer performs trade

Select ‘Market Buy Order’ Enter Asset Purchase Information System sends Market Buy Order to Marketing

Trading System and receives confirmation Display Confirmation of Trade

Customer logs off

Execute TradeTrading

Customer


Scenario 2: Alternative Flow, Insufficient Cash

Customer logs on Customer selects ‘Trade’ Customer selects account Customer performs trade

Select ‘Market Buy Order’ Enter Asset Purchase Information System determines not enough cash in account Notify customer that account has insufficient

funds Customer logs off

TP8:Test Plan Template

Execute TradeTrading

Customer


Review: Requirements Across the Product Lifecycle

1. What is the typical state of a use-case model at the end of each phase of the lifecycle?

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?

5. How do requirements drive design?6. How do requirements drive test?


Summary (1 of 2)

Build the right system right by using a process to define and manage requirements to meet the customer’s needs

Effective problem analysis helps avoid the “Yes, but…”

Elicitation helps you understand your stakeholders’ needs

Use features and a use-case model to gain agreement with the customer on the definition of the system


Summary (2 of 2)

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

A use-case model of 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

WP4WP5

Documents

Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements