RATIONALE-BASED USE CASE SPECIFICATION

Jochem van Kats, Group II

Introduction

Rationale-Based Use Case Specification: capturing requirements and their rationale (the ‘why’).

Proposed in 2002 by: Allen H. Dutoit: Research Scientist TU

München Barbara Paech: chair Software Engineering

University of Heidelberg

Dutoit, A. H., & Paech, B. (2002). Rationale-based use case specification. Requirements engineering, 7(1), 3–19. Springer.

Related literature

Inquire Circle by Potts, Takahashi and Anton (1994): Short-term rationale to improve quality of requirements for evolving systems

SCRAM by Sutcliffe (1995): Improve stakeholder participation by exposing them with rationale info

FOOM by Nguyen and Swatman (1999): RE by refinement steps, document rationale per step.

Rationale-Based Use Case Specification by Dutoit and Paech (2002)

Rationale-based Analysis tool by Wolf and Dutoit (2004): Tool that support Rationale-Based Use Case Specification. Tested in students project, encouraging results.

Rationale-Based Use Case Specification

Why?: Documenting design rationale makes it

possible to involve more people to critically reflect the decision process

Rationale is essential when the design gets altered (adding, fixing or modifying features)

How?: Integrated Use Case specification with

rationale capture

Capture requirements: User Tasks Use cases

Capture rationale: Questions Options Non-Functional Requirements

Rationale-Based Use Case Specification

System services Glossary

Assessments Arguments Decision

Example: (part of a) Use Case

Review specification

Reviewer asks QUESTION:How to handle drivers of whom the system cannot check their availability because the driver did not enter it? Requirement engineers propose OPTIONs:

Send e-mail reminder Send text-message reminder Call to remind

Assess OPTIONs according to NFRs and make DECISION

Example: Rationale

Example: Rationale

Example: Rationale

Are there any..

QUESTIONs?