Notations. Requirements Documentation Typical parts of Requirements Document Functional requirements Behavior of the software system Nonfunctional requirements.

Slides:



Advertisements
Similar presentations
Architecture. Outline Example Decomposition Style Activity 1.
Advertisements

Use Case & Use Case Diagram
Diagram Notations
Paper Prototyping.
Object-Oriented Design
Object-Oriented Analysis and Design
Android programming club Thursdays 5-7pm Info… Ryley Herrington iOS programming club Info… Ben Lanegan or.
Systems Analysis and Design in a Changing World, Fourth Edition
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
Diagram Notations
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Requirements
Copyright W. Howden1 Lecture 2: Elaboration Tasks and Domain Modeling.
Object-Oriented Design
03/12/2001 © Bennett, McRobb and Farmer Use Case Diagrams Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
SE-565 Software System Requirements More UML Diagrams.
Unified Modeling Language
Chapter 7: The Object-Oriented Approach to Requirements
UML for Java Programmers Object Mentor, Inc. Copyright  by Object Mentor, Inc All Rights Reserved
Lecture Outline 11 The Development of Information Systems Chapter 8 page 390+
CMIS 470 Structured Systems Design
CS 4310: Software Engineering Lecture 3 Requirements and Design.
Systems Analysis and Design in a Changing World, Tuesday, Feb 27
Lecture 6 Unified Modeling Language (UML)
程建群 博士(Dr. Jason Cheng) 年03月
Diagram Notations
5 Systems Analysis and Design in a Changing World, Fourth Edition.
4 2009/10 Object Oriented Technology 1 Topic 4: The Object-Oriented Approach to Requirements Adopted from: Ch.7 The Object-Oriented Approach to Requirements.
Systems Analysis and Design in a Changing World, Fifth Edition
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 20. Review Software Requirements Requirements Engineering Process.
Requirements Analysis Visual Modeling] Lab 02 Visual Modeling (from Visual Modeling with Rational Rose and UML) A way of thinking about problems using.
Requirements Documentation CSCI 5801: Software Engineering.
In-Class Interviewing Activity (Grocery example) You can conduct a semi-structured/unstructured interview: How: Use the process outlined here. Individually.
Systems Analysis and Design 8 th Edition Chapter 6 Object Modeling.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour UML Sequence Diagram.
(c) Addison Wesley Copyright © 2000 by Addison Wesley Version 1.0
Object-Oriented Design
7. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
Systems Analysis and Design in a Changing World, Fourth Edition
Object-Oriented Design. 1 Objects and concerns Objects have a concern, meaning they have a purpose Not concerned as in worried All code should have a.
Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall Object-Oriented Systems Analysis and Design Using UML Systems Analysis and Design,
Chapter 3: Introducing the UML
Capturing Requirements. Questions to Ask about Requirements 1)Are the requirements correct? 2)Consistent? 3)Unambiguous? 4)Complete? 5)Feasible? 6)Relevant?
Use Case Diagrams. Introduction In the previous Lecture, you saw a brief review of the nine UML diagrams. Now that you have the clear, you'll start to.
7 Systems Analysis – ITEC 3155 The Object Oriented Approach – Use Cases.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
TA: Shreya Rawal.  A use case is a description of a system’s behavior as it responds to a request that originates from outside of that system (Usually.
CHAPTER 6 OBJECT ANALYSIS.
5 Systems Analysis and Design in a Changing World, Fourth Edition.
E- Patient Medical History System
Systems Analysis and Design in a Changing World, Fourth Edition
DATA REQIREMENT ANALYSIS
System Sequence Diagrams and Operation Contracts
Object-Oriented Analysis and Design
Unified Modeling Language
OO Domain Modeling With UML Class Diagrams and CRC Cards
System Modeling Chapter 4
The Development of Information Systems Chapter 8 page 348+
SAD ::: Spring 2018 Sabbir Muhammad Saleh
CIS 375 Bruce R. Maxim UM-Dearborn
Interaction diagrams Interaction diagrams are models that describe how groups of objects collaborate in some behavior. Typically, an interaction diagram.
Systems Analysis – ITEC 3155 Modeling System Requirements – Part 2
Using Use Case Diagrams
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Diagram Notations
CIS 375 Bruce R. Maxim UM-Dearborn
Presentation transcript:

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