Notations

Requirements Documentation Typical parts of Requirements Document Functional requirements Behavior of the software system Nonfunctional requirements Quality characteristics of software system Diagrams 1

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

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 3

Use Case Diagrams 4 backcountry skier Use Case #2: Clarify Location and Time Use Case #2: Clarify Location and Time Use Case #1: Report Avalanche

5 backcountry skier Use Case #2: Clarify Location and Time 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 #3b: View by Location Use Case #3a: View by Time Use Case #3a: View by Time

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

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 7

8 UML User + username User + username Avy report + user + time (datetime) + location (geocode) + details (string) Avy report + user + time (datetime) + location (geocode) + details (string) Avy Entry + user + when (datetime) + where (geocode) + details (string) Avy Entry + user + when (datetime) + where (geocode) + details (string) Clarification + when (datetime) + where (geocode) + details (string) Clarification + when (datetime) + where (geocode) + details (string) Avy view + Avy report Avy view + Avy report Table view (time) + HTML Table view (time) + HTML Google map view + JavaScript Google map view + JavaScript 1 * * * * system boundary

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

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 10

11 ERD 1 n r p q User Avy report Avy entry Clarification Avy view Table view (time) Google map view writes yields shows asks for

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

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 13

14 skier report raw message DB raw message DB interpret clarify avy reports DB avy reports DB send clarification geocoder map view table view viewer avy info clarification message message location geocode report raw message clarification message report map html table Dataflow Diagram

Break Time!!! 15

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

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 17

[geocode != null] 18 Message Sequence Diagram User System Database avy report Request to clarify [if geocode == null] Geocoder Geocode create report location info

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

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” 20

State Charts 21 raw avy report (just text) in database Geocoded (geocode != null) record avy info geocoding fails geocoding succeeds receive messag e done

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

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 23

Examples: Support drug and alcohol counseling 24

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 25 Requirements definition: written from external viewpoint; system is like a “black box”

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. 26 Requirements definition: written from external viewpoint; system is like a “black box”

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 27

Class Diagram (UML) 28 Counselor + reports Counselor + reports Counselee + counselor + surveys Counselee + counselor + surveys Survey + questions (String []) + answers (int []) + counselee Survey + questions (String []) + answers (int []) + counselee 1 * User + lastname (string) + PIN (int) User + lastname (string) + PIN (int) 1 * Report + surveys + counselor Report + surveys + counselor * * 1 * System boundary

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. 29 Requirements specification: written from system’s viewpoint, involving internal details of system

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. 30 Requirements specification: written from system’s viewpoint, involving internal details of system

Dataflow Diagram (Use Case #1) 31 Survey DB Survey Survey answers Health Information patient’s answers (ever) Counselee Counselor Create report Postscript Printer Pick up Printout Printout Authenticate User ID Last name & PIN

Message Sequence Diagram (Use Case #1) 32 [survey complete] Counselee Server Database Log in Printer Present question Answer question Record answers Get report data Send report to printer

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 33

Next Steps Get started on your Requirements homework me if you have questions Better yet, come to office hours! Every team member should contribute!! Next lecture: Prototyping 34