Requirements Determining the requirements of software involves determining the needs of the users of the software. Determining the requirements of software.

Slides:



Advertisements
Similar presentations
Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities.
Advertisements

System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different.
UML and Systems Analysis MIS3502: Application Integration and Evaluation David Schuff
Ch 12: Object-Oriented Analysis
Assignment I, part 1. Groups of three students. Specify one as group leader. group names to TA and me. Create an object-oriented conceptualization.
1 Chapter 4 Dynamic Modeling and Analysis (Part I) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence.
CS3773 Software Engineering Lecture 03 UML Use Cases.
Paul Deitel, CEO Deitel & Associates, Inc.. Contact Information  Paul Deitel, CEO  Deitel & Associates, Inc.  Twitter:  Facebook:
Chapter 12 ATM Case Study, Part 1: Object-Oriented Design with the UML
Interaction Diagrams Activity Diagram State Machine Diagram
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
January Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Elaboration Iteration 1: a simple cash-only success scenario of.
Copyright ©2004 Cezary Z Janikow 1 Domain Model n Visualization of entities and relationships n In UP presented as Class Diagrams – Classes, Relationships,
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
© 2005 Prentice Hall3-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
Object-Oriented Analysis and Design
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
USE Case Model.
From Problem Statement to Design
Use Cases 2 ENGR ♯10 Peter Andreae
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Rational Unified Process (Part 1) CS3300 Fall 2015.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
CS 310 Ch8: System models Abstract descriptions of systems being analyzed to help the analyst understand the system functionality communicate with customers.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
ECE 264 Object-Oriented Software Development Instructor: Dr. Honggang Wang Fall 2012 Lecture 3: Requirements Specification, C++ Basics.
1 CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis Activity (Identifying Objects, Scenarios) Janice Regan,
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
Approaching a Problem Where do we start? How do we proceed?
Chapter 7 System models.
 Development is organized in a series of short, fixed-length mini-projects called iterations  Iterations are also incremental  Successive enlargement.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
Copyright © 2013 Curt Hill UML Unified Modeling Language.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
1 Graph Coverage (6). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section
Requirements specification Why is this the first major stage of software development? –Need to understand what customer wants first Goal of requirements.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
UML (Unified Modeling Language)
Session 5 Object Model Development. OOAD with UML / Session 5 / 2 of 19 Review A class icon is a rectangle with three sections within it An object is.
OO DomainModeling With UML Class Diagrams and CRC Cards Chapter 6 Princess Nourah bint Abdulrahman University College of Computer and Information Sciences.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
1 After the scenarios are formulated Find all the use cases in the scenario Describe each of these use cases in more detail Participating actors Describe.
Inf 43: Introduction to Software Engineering May 7, 2016.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
CompSci 280 S Introduction to Software Development
CMPE 135: Object-Oriented Analysis and Design August 31 Class Meeting
Object-oriented and Structured System Models
CMPE 280 Web UI Design and Development August 29 Class Meeting
Storyboarding and Game Design SBG, MBG620 Full Sail University
Use Case Model.
Object-Oriented Static Modeling of the Banking System - I
OO Domain Modeling With UML Class Diagrams and CRC Cards
Abstract descriptions of systems whose requirements are being analysed
Object-Oriented Analysis
Introduction To System Analysis and Design PART 2
Copyright 2007 Oxford Consulting, Ltd
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Presentation transcript:

Requirements Determining the requirements of software involves determining the needs of the users of the software. Determining the requirements of software involves determining the needs of the users of the software.

Requirements This can be done in several ways: This can be done in several ways: Interviewing users to elicit their needs. Interviewing users to elicit their needs. Perform a domain analysis. Perform a domain analysis. Create a need. Create a need.

Using UML to Elicit Requirements UML can be helpful in eliciting requirements UML can be helpful in eliciting requirements Object models (class and object diagrams) and behavior models (use cases and state diagrams) are commonly used. Object models (class and object diagrams) and behavior models (use cases and state diagrams) are commonly used.

Object Models Object models try to model the real world using “objects” that represent real world objects. Object models try to model the real world using “objects” that represent real world objects. The objects in the object model have “properties” (attributes) and “actions” (methods) that represent properties and actions of the real world objects to model the problem domain. The objects in the object model have “properties” (attributes) and “actions” (methods) that represent properties and actions of the real world objects to model the problem domain.

Object Models The following are rules for object models: The following are rules for object models: All real world entities (objects) that are important to understanding the problem domain must be included. All real world entities (objects) that are important to understanding the problem domain must be included. All methods and attributes important to understanding the problem domain must be included. All methods and attributes important to understanding the problem domain must be included. Objects, attributes, and methods only significant for implementation should not be included. Objects, attributes, and methods only significant for implementation should not be included.

Object Model Example Create an object model for depositing and withdrawing money from an ATM machine. Create an object model for depositing and withdrawing money from an ATM machine. We will need three classes, “Customer”, “ATM”, and “Account”. We will need three classes, “Customer”, “ATM”, and “Account”. Customer should have a pin number and should be able to get money from the account and put money into the account. Customer should have a pin number and should be able to get money from the account and put money into the account.

Object Model Example ATM’s should be able to get the pin number from the customer, dispense money to the customer, and receive money from the customer. ATM’s should be able to get the pin number from the customer, dispense money to the customer, and receive money from the customer. Accounts should have a balance and allow deposits and withdrawals. Accounts should have a balance and allow deposits and withdrawals.

Object Model Example

Behavior Modeling (Use Case) A use case diagram represents the functionality of the systems from the users point of view. A use case diagram represents the functionality of the systems from the users point of view. Use case diagrams should be designed and approved by both the software designer and the customer. Use case diagrams should be designed and approved by both the software designer and the customer.

Use Cases The Use case diagram is used to identify the primary elements and processes that form the system. The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The primary elements are termed as "actors" and the processes are called "use cases."

Use Cases The Use case diagram shows which actors interact with each use case. The Use case diagram shows which actors interact with each use case. Due to the simplicity of use case diagrams, and more importantly, because they are devoid of all technical jargon, use case diagrams are a great “storyboard” tool for user meetings. Due to the simplicity of use case diagrams, and more importantly, because they are devoid of all technical jargon, use case diagrams are a great “storyboard” tool for user meetings.

Use Case Example Create a use case diagram for the ATM machine problem for the customer. Create a use case diagram for the ATM machine problem for the customer. The customer can type in the pin number, put money into the ATM (deposit) and take money from the ATM (withdrawal) The customer can type in the pin number, put money into the ATM (deposit) and take money from the ATM (withdrawal)

Use Case Example

Behavior Modeling (Scenarios) A scenario (or use case scenario) is a sequence of actions that accomplishes a user task. A scenario (or use case scenario) is a sequence of actions that accomplishes a user task. Scenarios are used to illustrate an important capability or proposed use of the system. Scenarios are used to illustrate an important capability or proposed use of the system. In UML, an interaction diagram is used to represent a scenario. In UML, an interaction diagram is used to represent a scenario.

Scenario Example Write a scenario for a student withdrawing money from the ATM. Write a scenario for a student withdrawing money from the ATM. 1. Type in pin number. 2. Choose “withdrawal”. 3. Type in the amount. 4. Take the money. 5. Blow the money on a pizza and a six pack.

Differences between “use case” and “Use case scenario” So what’s the difference between a “use case” and a “scenario” (or sometimes called a “use case scenario”)? So what’s the difference between a “use case” and a “scenario” (or sometimes called a “use case scenario”)?

Differences between a “Use Case” and a “Use Case Scenario?” USE CASE: A visible and identifiable system behavior associated with one or more actors external to the system. USE CASE: A visible and identifiable system behavior associated with one or more actors external to the system. USE CASE SCENARIO: An elaboration of a Use Case into a precisely defined statement of system behavior. USE CASE SCENARIO: An elaboration of a Use Case into a precisely defined statement of system behavior. A Scenario is represented as a Use Case plus a set of assumptions (initial conditions) plus a set of outcomes A Scenario is represented as a Use Case plus a set of assumptions (initial conditions) plus a set of outcomes One Use Case creates multiple use case scenarios One Use Case creates multiple use case scenarios The Use Case Scenarios are more detailed and from a user’s task perspective The Use Case Scenarios are more detailed and from a user’s task perspective

State Diagrams A state diagram shows the state of the system and all possible transitions between the states. A state diagram shows the state of the system and all possible transitions between the states. In other words, a state diagram is a finite automaton. In other words, a state diagram is a finite automaton. I hope you remember your theory of computation. I hope you remember your theory of computation.

State Diagrams State diagrams can help to clarify requirements. State diagrams can help to clarify requirements. It is important that the states reflect domain conditions that are understandable to the user. It is important that the states reflect domain conditions that are understandable to the user.

State Diagram Example Create a state diagram for a student using the ATM machine. Create a state diagram for a student using the ATM machine. This is one of those strange automata where there are no final states. This is one of those strange automata where there are no final states.

Other Useful Tools Data dictionaries and systems diagrams can also be used to explain the proposed system to the client. Data dictionaries and systems diagrams can also be used to explain the proposed system to the client.

Data Dictionary A data dictionary is a table about each data element in the system. A data dictionary is a table about each data element in the system. A typical entry includes: A typical entry includes: The name of the item. The name of the item. In which class it is located. In which class it is located. The data type of the item. The data type of the item. The semantics (meaning) of the item. The semantics (meaning) of the item.

Data Dictionary Example A data dictionary for the ATM problem might look like: A data dictionary for the ATM problem might look like: Name Class TypeSemantics Pin Number Customer LongUsed to authenticate the customer Balance Account Float The amount of money in the account

System Diagrams A system diagram is a nonformally defined diagram used to give an overview of the proposed system. A system diagram is a nonformally defined diagram used to give an overview of the proposed system. System diagrams have ovals representing processing, cylinders representing databases, boxes representing data, and stick figures representing persons. System diagrams have ovals representing processing, cylinders representing databases, boxes representing data, and stick figures representing persons.

IEEE Standards for Software Requirements Specification See _public/description/se/ See _public/description/se/ _public/description/se/ _public/description/se/

Homework Pg 120 # 1,5,7,9,11 odd Pg 120 # 1,5,7,9,11 odd