Lecture 7: Requirements Engineering and Use Cases

Lecture 7:Requirements Engineering

and Use Cases

Software System Design and ImplementationITCS/ITIS 6112/8112 001Fall 2008

Dr. Jamie PaytonDepartment of Computer ScienceUniversity of North Carolina at Charlotte

Sept. 16, 2008

2

Announcements

Homework 1 is available Due Tuesday, Sept. 23 at 5:00 pm

• No late submissions accepted for credit

Submit by email to payton@uncc.edu• Electronic copy only, preferably in PDF

3

Lecture Overview

Requirements engineering activities Requirements change management Requirements and use cases

4

Requirements Engineering Activities

Inception Elicitation Elaboration/Analysis

Negotiation

Specification Validation

5

Requirements Engineering Activities

Inception Elicitation Elaboration/Analysis

Negotiation

Specification Validation

6

Requirements Validation Techniques

Requirements reviews Systematic manual analysis of the requirements

Prototyping Using an executable model of the system to check

requirements• Covered in Chapter 17

Test-case generation Developing tests for requirements to check testability

• If difficult to design tests, requirement will be difficult to Implement Validate

7

Reviewing Requirements

Individual Requirements Verifiability

• Is the requirement realistically testable?

Comprehensibility• Is the requirement properly understood?

Traceability• Is the origin of the requirement clearly stated?

Adaptability• Can the requirement be changed without a large impact on

other requirements?

8

Reviewing Requirements

Collection of requirements (SRS) Consistency

• Are there any requirements conflicts?

Completeness• Are all functions required by the customer included?

Realism• Can the requirements be implemented given available budget

and team?

9

Requirements Management

Requirements change during a project Need to understand, control, and track changes

• Policies Requirements identification Change management process Traceability policy CASE tool support

10

Requirements Change Management

Should apply to all proposed changes to therequirements

Principal stages Problem analysis

• Discuss requirements problem and propose change Change analysis and costing

• Assess effects of change on other requirements Change implementation

• Modify documentation to reflect change

11

Traceability

Traceability is concerned with the relationships betweenrequirements, their sources and the system design

Requirements should be uniquely identified to aid in traceability Naming convention should reflect traceability relationships

Traceability relationships Source traceability

• Links from requirements to stakeholders who proposed theserequirements

Requirements traceability• Links between dependent requirements

Design traceability• Links from the requirements to the design

12

Traceability Matrix

Relates requirements to Stakeholders Other requirements System features Design modules

• Subsystems• Interfaces

Req.

id

1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

1.1 D R

1.2 D D D

1.3 R R

2.1 R D D

2.2 D

2.3 R D

3.1 R

3.2 R

Creation Manual for small projects Generated from database in

large projects

Traceability and requirement relationships

13

CASE Tools forRequirements Change Management

Basic productivity tools Word processors, spreadsheets, databases

Workbenches CASE Spec

• www.analysttool.com• Free demo

Borland Caliber Analyst• http://www.borland.com/us/products/caliber/index.html• Free trial

DOORS (by IBM)• http://www.telelogic.com/corp/products/doors/• Free trial

14

The Software RequirementsSpecification Document

The official statement of what is required of thesystem developers

Should include: a definition of user requirements a specification of the system requirements

15

Requirements Document Structure

Preface Intended audience Version Change summary

Introduction Project overview

Glossary Requirements

User requirements definition System requirements specification

Appendices Hardware, software related requirements

16

Lecture Overview

Requirements engineering activities Requirements change management Requirements and use cases

17

Developing Use Cases

Use Case Scenario-based approach to capturing functional

requirements Model behavior as a sequence of actions

Describes how an actor interacts with the system Actor (UML terminology)

• Represents role people or device play when using the system• External to system (system is not an actor)

Provides an observable result of value to the actor• Related to some tangible amount of work

18

Use Cases in UML

Use Case Diagram Represents a product’s use cases and actors involved in each

use case Models a static view of a system Catalogs all use cases

Graphical Notation

19

Use Case Diagram Example

University Library System Who are the actors? What do they want to do with the system?

Automated Carwash Who are the actors? What do they want to do with the system?

20

Use Case Specification Guidelines (1)

Never make the product an actor Name actors with noun phrases Name use cases with verb phrases Each use case must be associated with at least one

actor Each actor must be associated with at least one use

case Associations only link actors to use cases

21

Use Case Specification Guidelines (2)

Draw use case diagrams on a single page Organize by actor, problem domain, or solution categories

Make uses cases of similar size/complexity Use cases should achieve something useful (a goal)

for an actor If it isn’t useful, you’re specifying use cases at a level that is

too detailed!

22

Use Case Model

Use Case Diagrams Static model Capture user-level requirements Names product use cases and actors

Use Case Descriptions Specifies actors’ interactions with product Model operational-level requirements in greater detail Dynamic model

• Textual descriptions of activities Will use a standard template

• Supplemented by activity, statechart diagrams Order of interactions Possible courses of interaction

23

Writing Use Case Descriptions

Finding the actors Stakeholders are a superset of human use case actors

Preconditions Only state conditions that are necessary and important E.g., user must be logged in to system

Postconditions Must be true, no matter which flow is executed E.g., Account balance is greater than or equal to $0.00

Trigger Sometimes the first step in the use case

24

Writing Use Case Descriptions(2)

Basic Flow Choose a simple and common activity flow Start at the beginning and write the flow to successful

completion• Number each step• Write each step in simple, declarative sentence

Basic Flow Example Fingerprint Access System

• Enter Secure Facility Use Case

25

Organizing the Use Case Model

May have overlap in use case model Use cases may be specified at different levels of granularity Use cases may have variant

Want to reduce redundancy to promote consistency Can extract common and related behavior among use cases Can specify relationships between use cases

Use Case Relationships in UML Generalization

• One use case is a specialization of another Include

• One use case is a part of another Extend

• One use case extends the behavior of a core use case

26

Generalization

A specific (child) use case inherits behavior and meaning of a more general (parent)

use case May add to behavior or override behavior or more general

(parent) use case

Customer

Perform Transaction

Withdraw Money Deposit Money

27

Include

One use case explicitly incorporates another An included use case is always instantiated by larger containing use

case• Not based on meeting conditions• Never stands alone!• Executes exactly as stated

Used to extract common behaviors from multiple use cases into asingle description

Customer

Withdraw Money

Validate UserCheck Balance<<include>>

28

Extend

A use case implicitly incorporates the behavior ofanother Extension is not a stand alone use case Captures conditional behavior

• Instantiated only if triggering condition is met

CustomerPay Overdraft feePay Invoice

<<extend>>

29

Writing Use Cases with Extensions

Extensions Find the branch points Think of alternatives to finish the activity/task How might the use case end in success? How might the use case end in failure?

Treat extensions as a separate use case Condition is the trigger Extension steps are basic flow Completing use case or returning to branch point are goals

Extension Example Fingerprint Access System

• Enter Secure Facility Use Case

30

A bank wishes to design a billing and payment system. Thesystem will use the Internet to send orders, invoices, andpayments between buyers and sellers. The bank’s motivation fordeveloping the system is to attract new customers by offering alow payment-processing fee. The bank will also be able to reduceits wage costs by processing payment requests automaticallythrough the Internet instead of manually through cashiers.

The motivations for buyers and sellers are to reduce costs,paperwork, and processing time. The payment of invoices will behandled, for instance, between the buyer’s computer and theseller’s computer. Buyers and sellers will also have a betteroverview of the status of their invoices and payments.

Example