requirements, use cases & user...

1

Requirements

1

Requirements, Use Cases

& User Stories

How to write good code

COSC 425/6 2

http://xkcd.com/844/



2

Agile development at 30k ft.

COSC 425/6 3

Implement

one piece

Refactor Break into

pieces

Good

Code?

Yes

Any

More?

No

Yes

Start project

No

COSC 425/6 4

3

COSC 425/6 5

Primary project killers

Requirements mistakes

Wrong requirements

Ever-changing requirements

Improper schedule

COSC 425/6 6

Cost of Change Curve

Requirements

Design

Construction

Test

Deployment

Cost of fixing a bug

4

COSC 425/6 7

Requirements Analysis

Database Network

Computer

Context

COSC 425/6 8

Requirements include:

Behavior of system

Data formats

Reports to be generated

User Interface

5

COSC 425/6 9

Correct Requirements are

Critical to Success

Getting the right requirements is crucial and hard. Requirements are a key part of software engineering.

Must communicate with users

Models are helpful in analyzing and communicating requirements

COSC 425/6 10

Learning about Requirements

How do you learn

what the problem is?

what you can change?

what the computer should do?

whether you were correct?

6

COSC 425/6 11

Discovery Techniques

Reading

Interviews

Teams

Creating requirements document

Building models

Building prototypes

Requirements -

There are more than one kind

COSC 425/6 12

Functional requirements

inputs, outputs, and the relations between them

Non-functional requirements (includes –ilities)

7

Requirements -

There are more than one kind

COSC 425/6 13


inputs, outputs, and the relations between them

Non-functional requirements (includes –ilities)

Wait! What’s are –ilities?

COSC 425/6 14

Specifying Requirements

Requirements should be specific, so you can determine whether or not you met them.

Requirements should be as precise as necessary, but no more

Functional requirements - in theory, these can be specified completely

Non-functional requirements – can be hard to specify, often can’t specify completely

8

COSC 425/6 15


Inputs, outputs, and the relationship between them

Use Cases (or User Stories)

Formats, standard interfaces

Business rules and complex formula

COSC 425/6 16


Command languages

The “get” command will transfer ...

Web pages

Input forms, dynamic pages

Connections to other systems

Files, sockets, XML, …

Reports, displays…

9

COSC 425/6 17

Non-functional requirements

Performance

Must answer a query in 3 seconds

Usability

New user must be able to finish buying a book in 15 minutes

90% of users must say they like interface

Maintainability

New programmers should be able to fix first bug in two weeks on the job

COSC 425/6 18

Non-functional requirements

Technology

Must be developed using Java

Business

Must complete project in 1 year, spending less than $1,000,00

And other –ilities

• Security, reliability, efficiency, scalability, portability

10

COSC 425/6 19

Requirements must be

managed

Everyone must agree to changes in requirements

Usually increases price

Must be reviewed

Make sure each part of design is due to a requirement

Analyze problems: what was the root cause of this bug?

COSC 425/6 20

Traceability

Traceability - the ability to trace the effect of a requirement and determine who/what caused it

Why do we have this requirement? Who wrote it?

How is this requirement met?

What requirement caused this design?

11

COSC 425/6 21

Traditional Requirements

Document

List requirements

Name requirements

Categorize requirements by

source

feature

subsystem

type

COSC 425/6 22

System Description

A typical description has two parts

data

operations on that data

Three increasing levels of detail

requirements

specification

design

12

COSC 425/6 23

Descriptions often have

many purposes

Used to communicate to

Users

Developers

Management (technical and functional)

Complete - lots of detail

Easy to read - less detail

Depends on audience!

COSC 425/6 24

Many notations

UML Use cases

Class diagrams

State diagrams

Finite state machines

Data flow diagrams

Programming languages

Pseudocode

13

COSC 425/6 25

Let’s Consider Use Cases…

COSC 425/6 26

Use Cases

Invented by Ivar Jacobsen

Popularized by Alistair Cockburn

http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases

Use Case Fundamentals

Use Cases, Ten Years Later

Sample systems requirement document

Part of UML

14

COSC 425/6 27

Use Cases

Use Case: Something that the “System” does, or that happens to the “System”. Always involves an “Actor”.

Actor: Role of something or someone that interacts with the “System”

System: The thing you are studying or building

COSC 425/6 28

Use Case Diagrams

Shows actors and use cases and the relationships between them

Shows context - what is in and out of the system, i.e., the system scope and boundaries

Is not a description of use cases

Similar to System Context Diagram (SCD)

15

Provider Fax to claim

Electronic claim

Automatic Claim Processing

Knowledge

Worker

Paper claim

Claims Processing System

<<include>>

Mainframe

Post office

AdjudicationAdjudicator

COSC 425/6 29

COSC 425/6 30

Similar to SCDs

Claims Processing

System

Electronic

claim

Postal

System

Mainframe

Claim adjudicator

Fax

Data repair

Postal

System

Data entry

16

COSC 425/6 31

Use Cases

Text - a form of writing.

Describe the system’s behavior as it responds to a request from an actor.

Multiple kinds of use cases

Brief / detailed

Requirement / specification / design

COSC 425/6 32

Use Cases

Use cases describe the sequence of events that happen when the system responds to a request

May also describe alternatives

May also describe error scenarios

17

COSC 425/6 33

Use Cases are Text

Use cases should be easy to read

keep them short

tell a story

write full sentences with active verb phrases

make the actors visible in each sentence

Elements of a use case

Primary actor – who starts it?

Why the use case? Primary actor has goal.

Normal steps

Alternative steps (errors, options)

COSC 425/6 34

18

COSC 425/6 35

Ways to write use cases

User stories

Actor-goal list

Use case briefs

Casual use cases

“Fully dressed” use cases

Let’s consider an example

Imagine, if you will, a health claims processing system…

COSC 425/6 36

19

COSC 425/6 37

Health Claims Processing

R1) Receives health claims and supporting documents via many sources: electronically, fax, on paper.

R2) Scanned paper and fax processed by OCR. Documents first subject to form dropout, deskewing, despeckling.

R3) All images are logged to optical disk.

COSC 425/6 38


R4) Fields with low confidence levels are repaired by hand. Certain types of claims are transmitted to an offshore data entry vendor.

R5) Match the plan and the health care provider.

R6) Existing mainframe system processes accepted claims.

20

COSC 425/6 39


R7) Determine if claim can be paid, and how much. If there are inconsistencies, suspend the claim until a human (adjudicator) can look at it.

R8) Adjudicator looks at documents about claim and history of client and can ask for more information, can accept claim, or can reject claim.

COSC 425/6 40

1. Actor-goal list

Actor Task-level goal Priority

Provider Submit paper claim 1

Provider Submit fax claim 2

Provider Submit electronic claim 3

Adjud. Adjudicate problem 2

21

COSC 425/6 41

2. Use Case Briefs

Actor

Provider

Provider

Adjucator

Goal

Submit paper

claim

Submit fax claim

Adjudicate failed

claim

Brief

Submit claim on paper, which is

converted into electronic form, and

either paid or sent for adjudication

Submit claim by fax, which is

processed by OCR and either paid or

sent for adjudication.

Decide whether a questionable claim

should be paid by the mainframe

payment system or rejected

COSC 425/6 42

3. Casual Use Cases

Submit Fax Claim

The Provider submits a claim by fax. The claim processing system will log the image to optical disk, apply form dropout, deskewing, despeckling, and then process it using OCR. Knowledge workers will repair any fields that seem to be in error. The claim will then either be paid (using existing mainframe processing system) or sent to adjudication.

22

COSC 425/6 43

4. Fully Dressed (detailed)

Primary Actor: Provider

Goal in context: Pay legitimate claims while rejecting bad ones.

Scope: Business - the overall purchasing mechanism, electronic and non-electronic, as seen by the people in the company.

Level: Summary

Stakeholders and interests:

Provider: Wants to be paid for services rendered.

Company: Wants to cut costs and avoid fraud

Precondition: none

Minimal guarantees: Pay only certified providers, pay only for services that are covered by plan, do not pay if there are obvious mistakes

COSC 425/6 44

Includes… Main Success Scenario

and sometimes extensions

Trigger: Claim submitted by fax

1. Provider: submit claim by fax

2. Claim system: drop forms, deskew, despeckle, use OCR to convert to electronic form

3. Claim system: check claim to make sure it is legal

4. Mainframe payment system: pay claim

Extensions:

2a. Some fields have low confidence: Knowledge worker corrects

3a. Claim is not valid: send to adjudication

23

COSC 425/6 45

Use Cases and Requirements

Use Cases are one part of requirements

They help manage requirements

They help facilitate requirements traceability

COSC 425/6 46

Use Cases - Goals

Primary Actor has a goal

System forms subgoals to carry out its responsibility

Goals can fail

A use case describes a set of ways for successfully carrying out the goal, and several ways of failing

24

COSC 425/6 47

Use Cases - Scenarios

Scenarios are concrete and detailed

names of people

$ values, particular dates, particular amounts

Scenarios are test cases

A Use Case is a contract… and it collects together all the scenarios

COSC 425/6 48

When use cases don’t work

Compilers

one use case - compile a program

Despeckler

one use case - remove speckles

No interaction

Complexity is caused by

input format

transformation

25

COSC 425/6 49

Summary

Use cases are useful, but not perfect

Several ways to write use cases

Big projects need big use cases and many of them

Use the simplest way you can!

i.e., without losing necessary detail or compromising clear understanding

COSC 425/6 50

Readings on Use Cases

http://en.wikipedia.org/wiki/Use_case_diagram

http://www.parlezuml.com/tutorials/usecases/usecases_intro.pdf










26

COSC 425/6 51

Other ways of getting

requirements

Business analysts

Systems engineer

Project lead

Program manager

http://blogs.msdn.com/techtalk/archive/2005/12/16/504872.aspx

COSC 425/6 52

Let’s Consider User Stories…



27

COSC 425/6 53

Requirements in XP

Customer writes user stories and sometimes additional detail

Customer interprets user stories

Customer is assumed to actually know the requirements

There is no formal process for learning requirements