Eva Trosborg Slide no.: 1Requirement Specification

Requirement SpecificationFall 2005

Agenda• Requirement definition through use cases

by

Eva Trosborg

Eva Trosborg Slide no.: 2Requirement Specification

After this lesson you should :

• Be able to analyze a given situation and write a simple requirement specification for a smaller software system using object oriented techniques such as use case diagrams

Eva Trosborg Slide no.: 3Requirement Specification

Sources to this lesson

• Graig Larman; Applying UML and Patterns Chapter 4 - 7

Eva Trosborg Slide no.: 4Requirement Specification

Fig. 5.1Poor user input

13%

Changing requirements12%

Poor technical skills7%

Poor staffing6%

Other50%

Incomplete requirements12%

Poor user input

Eva Trosborg Slide no.: 5Requirement Specification

Fig. 6.1

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

Scenarie = use case instance = one specific path through the use case

Requirements

Use Case cover all possible scenario’s

p63

Eva Trosborg Slide no.: 6Requirement Specification

Fig. 6.2 Primary actors and goals at different system boundaries p86

Goal: Process sales

Cashier

Customer

POS System

Checkout Service

Goal: Buy items

Enterprise Selling Things

Sales TaxAgency

Goal: Collect taxes on sales Sales Activity

System

Goal: Analyze sales and performance data

Eva Trosborg Slide no.: 7Requirement Specification

Fig. 6.3 Partial use case context diagram p90

NextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation for a computer system actor

«actor»HR System

Cash In

«actor»Sales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

Eva Trosborg Slide no.: 8Requirement Specification

Fig. 6.4 Notation suggestions p91

NextGen

Process Sale

. . .Cashier

Show computer system actors with an alternate notation to human actors.

primary actors on the left

supporting actors on the right

For a use case context diagram, limit the use cases to user-goal level use cases.

«actor»Payment

AuthorizationService

Eva Trosborg Slide no.: 9Requirement Specification

Fig. 6.5 Alternate actor notation p91

NextGen

Process Sale

«system»Payment

AuthorizationService

...

«actor»Payment

AuthorizationService

Some UML alternatives to illustrate external actors that are other computer systems.

The class box style can be used for any actor, computer or human. Using it for computer actors provides visual distinction.

PaymentAuthorization

Service

Eva Trosborg Slide no.: 10Requirement Specification

Fig. 6.6 Use case diagram (“context diagram”) for Monopoly system p94

Table 6.1 Sample requirements effort across the early iterations; not a recipe p96

Your project??

Eva Trosborg Slide no.: 11Requirement Specification

Fig. 6.7 process and setting context for writing use cases p97

January February

Use Case: Capture a Sale. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

Use Case: Handle Returns. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

WhenOnce during inception. Short; do not try to define or polish all requirements.

Several times during elaboration iterations.

WhereAt a requirements workshop.

WhoMany, including end users and developers, will play the role of requirements specifier, helping to write use cases.

Led by system analyst who is responsible for requirements definition.

How: ToolsSoftware: For use case text, use a web-enabled requirements tool

that integrates with a popular word processor.For use case diagrams, a UML CASE tool.Hyperlink the use cases; present them on the project website.

Hardware: Use two projectors attached to dual video cards and set the display width double to improve the spaciousness of the drawing area or display 2 adjacent word processor windows .

Developer

CustomerSystemAnalyst

End User

Two adjacent projections.

SoftwareArchitect

Eva Trosborg Slide no.: 12Requirement Specification

Fig. 7.1

NextGen POS

Cashier

System Administrator

Store Manager

Calls upon services

Calls upon services

«actor»Payment

AuthorizationService

«actor»Tax Calculator

«actor»Accounting

System

«actor»Human

Resources System

«actor»Inventory System

«actor»Sales Activity

System

Eva Trosborg Slide no.: 13Requirement Specification

Assignment for the 13. September

• Project establishment. Preparing the presentation of the different project roles, Dream group “agreement”.

• Slides to be sent to trosborg@itu.dk