notations. requirements documentation typical parts of requirements document functional requirements...

Notations

2

Requirements Documentation

• Typical parts of Requirements Document• Functional requirements

• Behavior of the software system

• Nonfunctional requirements • Quality characteristics of software system

• Diagrams

3

Outline

• Use Case diagram• Unified Modeling Language (UML) • Entity Relationship Diagram (ERD)• Dataflow diagram• Message Sequence diagram• State chart• Putting it all together

4

Use Case Diagrams

• Stick man for users• Ovals for use cases (UCs)

• Italicize “abstract” use cases

• Simple arrows when a UC “calls” another• Open arrowheads for specialization

• Similar to the role that subclassing plays in OO

5

Use Case Diagrams

backcountry skier

Use Case #2:Clarify Location

and Time

Use Case #1:Report

Avalanche

6

backcountry skier

Use Case #2:Clarify Location

and Time

Use Case #1:Report

Avalanche

avalanche forecaster

Use Case #3:View Recent

Avalanche Activity

Use Case #3b:View by Location

Use Case #3a:View by Time

7

Outline


8

Unified Modeling Language (UML)

• One box per kind of entity, listing attributes• Italicize abstract entities, attributes

• Lines without arrowheads show references• Similar to member variables in OO• Labeled with cardinality (multiplicity)

• Integers, ranges, or asterisk (for unlimited)

• Lines with open arrowheads for specialization• Lines with regular arrowheads can be used to indicate

dependencies• Usually omitted in requirements’ class diagrams

9

UML

User+ username

Avy report+ user+ time (datetime)+ location (geocode)+ details (string)

Avy Entry+ user+ when (datetime)+ where (geocode)+ details (string)

Clarification+ when (datetime)+ where (geocode)+ details (string)

Avy view+ Avy report

Table view (time)+ HTML

Google map view+ JavaScript

1

*

1

0..1

1

*

*

*

system boundary

10

Outline


11

Entity-Relationship Diagrams (ERDs)

• One box per kind of entity• List entities on branches• Lines with a diamond show relationships

• Diamond label indicates role of relationships

• Numbers or variables on lines show cardinality

12

ERD

1

n

1

0..1 1

r

pq

User

Avy report

Avy entry

Clarification

Avy view

Table view (time)Google map view

writes

yields

shows

asks for

13

Outline


14

Dataflow Diagram

• Each oval is a “function” provided by system• Each inward arrow is a parameter (labeled)• Each outward arrow is an output (labeled)

• Each rectangle is an actor• A person, place, or thing that can do stuff and/or initiate events

• Each “half-rectangle” is a data store• Best practices: separate dataflow diagram for each use case

15

skierreport

raw messageDB

interpret

clarify

avy reportsDB

send clarification

geocoder

map view

table view

viewer

avy info

clarification message

message

message

message

location

geocode

report

raw messag

e

clarification message

report

report

map

html table

Dataflow Diagram

16

Break Time!!!

17

Outline


18

Message Sequence Diagram

• One box per entity involved• If you have two users interacting with each other, then you would have

two boxes• Each box has a dashed line, showing its “lifetime”, which can end if an

object is destroyed

• Arrows show messages• Also, draw an arrow back if there’s a return value

• Conditionals are written with brackets [ ]• Loops can be enclosed in a shaded box

[geocode != null]

19

Message Sequence Diagram

User System Database

avy report

Request to clarify[if geocode == null]

Geocoder

Geocode

create report

location info

20

Outline


21

State Charts

• Shows change over time• One box per state• Arrows show a possible state transition

• Annotated to indicate under what conditions the transition occurs

• Filled circle shows where you “start”• Nested filled circle shows where you “stop”

22

State Charts

raw avy report (just text)

in database

Geocoded (geocode != null)

record avy info

geocoding fails

geocoding succeeds

receive message

done

23

Outline


24

Requirements Documentation

• Requirements definition– Unstructured text: functional & non-functional requirements– Use case descriptions– Class diagrams or ERDs showing external entities

• Requirements specification– Unstructured text: functional & non-functional requirements– Dataflow diagram– Message sequence diagrams or state charts

25

Examples: Support drug and alcohol counseling

http://cf.polarishealth.com/demo/start_demo.html

26

Requirements Definition: Functional Requirements

• Before each counseling visit, each counselee takes a survey• After each survey, the system prints a report showing the

counselee’s progress• Administrative assistants can add counselees and their

counselors to the system

Requirements definition: written from external viewpoint; system is like a “black box”

27

Requirements Definition: Non-functional Requirements

• Each survey will be short enough for an average user to complete within 10 minutes.

• Progress reports will each be 2 pages or less.• The system will print progress reports within 2 minutes of a

survey’s completion.• Users can take a survey using a Windows machine that has a

Pentium II 550 MHz CPU, with 0.5 GB of RAM.

Requirements definition: written from external viewpoint; system is like a “black box”

28

Use Case #1: Survey and Report

• Actor: Counselee• Precondition: Counselee registered in system• Postconditions:

• Counselee progress data is recorded in system• Report is printed for use by counselor

• Flow of events:• Counselee logs in (lastname + PIN)• System collects survey data from counselee• System prints report

29

Class Diagram (UML)

Counselor+ reports

Counselee+ counselor+ surveys

Survey+ questions (String [])+ answers (int [])+ counselee

1

*

User+ lastname (string)+ PIN (int)

1

*

Report+ surveys+ counselor

**

1

*

System boundary

30

Requirements Specification: Functional Requirements

• The system will provide screens so that when counselee and counselor data are entered into the system, these data are transferred to a database or other permanent storage.

• When survey data arrive, they will be saved and a report will be output to the printer.

Requirements specification: written from system’s viewpoint, involving internal details of system

31

Requirements Specifications: Non-Functional Requirements

• 95% of the code will be platform-independent (Java or platform-independent JavaScript).

• The system will record completed surveys in the database within 30 seconds; reports will be sent to the printer within 30 seconds and emerge within 60 seconds.

Requirements specification: written from system’s viewpoint, involving internal details of system

32

Dataflow Diagram (Use Case #1)

Survey DB

Survey

Surveyanswers

HealthInformation

patient’sanswers (ever)

Counselee

Counselor

Create reportPostscript

PrinterPick up Printout

Printout

Authenticate

User ID

Last name & PIN

33

Message Sequence Diagram (Use Case #1)

[survey complete]

Counselee Server Database

Log in

Printer

Present question

Answer question

Record answers

Get report data

Send report to printer

34

A Few Comments

• These are just the basic diagrams.• Sufficient for our homework, exams, and probably 90% of what you’ll see

after graduation• Fancier versions of these diagrams do exist

• It’s OK to draw diagrams by hand• As long as you respect the notation

35

Next Steps

• Get started on your Requirements homework• Email me if you have questions• Better yet, come to office hours!

• Every team member should contribute!!

• Next lecture: Prototyping

notations. requirements documentation typical parts of requirements document functional requirements...

Documents