Project Analysis Course (2012-2013) Week 2 Activities.

Slides:



Advertisements
Similar presentations
Requirements Elicitation and Use Case Diagrams
Advertisements

Project Analysis Course ( ) Final Project Report Overview.
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Use case tutorial examples.
09/04/2015Unit 2 (b) Back-Office processes Unit 2 Assessment Criteria (b) 10 marks.
© 2010 Bennett, McRobb and Farmer1 Use Case Description Supplementary material to support Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
How to Submit a Matching Gifts Application.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Example of a Problem Statement: Introduction into.
Information System Engineering
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Chapter 15 Application of Computer Simulation and Modeling.
Conversation Form l One path through a use case that emphasizes interactions between an actor and the system l Can show optional and repeated actions l.
SwE 313 Case Study Registration System.
Robustness Analysis Dr. Neal CIS 480. Outline What is robustness analysis? Key roles in robustness analysis Object types found in discovery Diagramming.
Documenting Requirements using Use Case Diagrams
Requirements Elicitation Chapter 4. Establishing Requirements Two questions –What is the purpose of the system –What is inside and what is outside the.
Actor Specification Actor Name: Designer Abstract: No
ARENA Case Study Project for Software Engineering Prepared by: Dalal Al-Shammari 2001/55313 Fall 2005 Supervisor: Dr. Qutaibah Mallohi.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
Gathering Information and Use Case Scenarios
03/12/2001 © Bennett, McRobb and Farmer Use Case Diagrams Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Using UML, Patterns, and Java Object-Oriented Software Engineering Example of a Problem Statement: Introduction into ARENA.
CMPT 275 Software Engineering
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
RUP Requirements RUP Artifacts and Deliverables
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
LBTO IssueTrak User’s Manual Norm Cushing version 1.3 August 8th, 2007.
Project Analysis Course ( ) Final Project Report Overview Prepared by: Sijali Petro Korojelo (Course Assistant)
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
Team ELL System Requirements Ladakeysha Thomas Elizabeth Waldo LaWanda Warren Brandon Williams.
GSA’s Vendor and Customer Self Service (VCSS)
Copyright © 2007, Oracle. All rights reserved. Managing Concurrent Requests.
1 CMPT 275 Phase: Design. Janice Regan, Map of design phase DESIGN HIGH LEVEL DESIGN Modularization User Interface Module Interfaces Data Persistance.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
1 CMPT 275 Software Engineering Requirements Gathering Activity Janice Regan,
Submitted By: Memon Khurshed (Group Leader) Hamed Abdollahpur
Payroll System Bank System Any bank(s) to which direct deposit transactions are sent. Employee A person that works for the company that owns and operates.
Faculty of Computer & Information
OOSE Use Case. Requirement Functional: –Features, capabilities, and security Non Functional: –Usability: Human factors, help, and documentation –Reliability:
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
CPSC 203. Use Case Diagram  A description of a system’s behavior as it responds to a request that originates from outside of that system. Specifies the.
University of Southern California Center for Systems and Software Engineering Common mistakes in Core FC Package.
Use Cases Use Cases are employed to describe the functionality or behavior of a system. Each use case describes a different capability that the system.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
REQUIREMENTS CAPTURE 1 ASU Course Registration System Use-case Model.
Training Slides – Manage Co-Curricular Activities Integrated National Education Information System (iNEIS TM )
 SAP AG 2007, SAP CSUN 2007 Conference Presentation / 1 Presented by Team “Call of Duty” 29 th April 2010 CS 6361, University of Texas At Dallas.
Object-Oriented Analysis and Design Use cases Finding classes Collaboration and Sequence diagrams Associations between classes.
Module Three: Identifying your Patient in SIS. Introduction – Search for 1 st T Specimen The Search for 1 st T Specimen screen is used to access your.
UML - Development Process 1 Software Development Process Using UML.
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.
Chavez, Melesan Karen De Luna, Lin Detera, Patrick Kevin Martinez, Jellene Joy Dental Clinic Database System Functional Requirements.
Page 1  Copyright © 1997 by Rational Software Corporation Putting the UML to Work The ESU University wants to computerize their registration system –
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Chapter 3: Software Design –Use case Diagram Nouf Alghanmi.
Use Case Diagrams A Detailed Description. Use Case Diagrams Use case diagrams describe relationships between users and use cases A use case is a (usually.
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Contents What is “RUP?” What are Requirement Types
Welcome to M301 P2 Software Systems & their Development
CMPE 280 Web UI Design and Development August 29 Class Meeting
Example of a Problem Statement: Introduction into ARENA
UML Use Case Diagrams.
Example of a Problem Statement: Introduction into ARENA
Example of a Problem Statement: Introduction into ARENA
Use Case Analysis – continued
Presentation transcript:

Project Analysis Course ( ) Week 2 Activities

Where we are now?  At the end of week 1, we are familiar with : General description of project area (problem area) Project scope (geographically, technically, borders,..) Selecting Technics Intended users of the system Project Context

Where we go?  Identify requirements (end user point of view) & analyze (Developer point of view) them  Focus of this week includes: Identification of functional requirement of the system Identification of the non functional requirement of the system Identification of constraints Prioritize requirements Validate use case modelling

Functional Requirement  Study the project case carefully and identify functional requirements  Functional requirements describe the interactions between the system and its environment ( in short: WHAT WILL THE SYSTEM DO)  try to identify all possible FR of the system at this stage.  Stating Functional requirements, examples: 1.An operator must be able to define a new game. 2.The system will provide registration of new students 3.The system shall keep track of library members  Remember FR are phrased as actions “Advertise a new league” “Schedule tournament” “Notify an interest group

Non Functional Requirement  Aspects not directly related to functional behavior, but part of the system  Stating non functional requirements, examples: 1.The response time of the system must be less than 1 second 2.The system must recover from failure in less than an hour NFR Categories: - Usability - Reliability Robustness Safety - Performance Response time Scalability Throughput Availability - Supportability Adaptability Maintainability Usability Requirement example: “Viewers must be able to watch a match without prior registration and without prior knowledge of the match.” Performance Requirement example “The system must support 10 parallel tournaments” Supportability Requirement example “The operator must be able to add new games without modifications to the existing system.”

Constrains  Imposed by the client or the environment  Sample constraints requirements: 1.The system must be implemented in Java 2.The system should run under windows operating system only

Prioritize Requirements  From all identified FR & NFR, which are the most important one (must develop)  Rewrite FR & NFR omitting the non important requirements e.g.: for student registration system ALL discovered requirements 1.Register students 2.Manage students (add, delete, update) 3.Attend lectures 4.Assign courses 5.…….  Most important updated are 1, 2, 4  3 is not part of the registration hence- not important requirement

Validate Requirements  Activities: Recall the different roles in the groups ( users, developers, etc) - Ask users/clients if the current requirements conform their defined requirements Go online check for similar project cases implementation – see the match

use cases  Activities includes: Identification of main actors/stakeholders of the system Identifying functions provided by the system to each actor/stakeholder Draw use case diagrams (Check if there is relationship between use cases, show it) Provide use case scenarios Provide full description of use case

use cases……. Identification of Main actors  Example 1 : For Online examination system, actors include: Examiner Examinee (students) System Administrator

use cases……… Identifying functions provided by the system to each actor  Example 1 : For Online examination system, actors include:  Examiner (prepare exam, mark exam, display results)  Examinee (register for an exam, submit exam, view results)  System administrator (manage users, manage exams)

use cases……… Draw use case diagrams (Check if there is relationship between use cases, show it)

use cases……… Provide use case scenarios For above example lots of scenarios can be generated Scenarios come from use cases, example Scenario 1: register for exam Scenario 2: manage users Scenario 3: manage exams Scenario 4: display results Provide a sequence of steps involved in each scenario

use cases……… Provide use case scenarios Example: Scenario 1- register for exam (steps) 1.Examinee fills registration form 2.Examinee submits the form 3.The system verifies payment for exam 4.The system returns a success registration message Do the same for all scenarios

use cases……… Provide full description of use case ( e.g. add a record of a TB patient to database Use Case Name - Add a person record Purpose: This business use case will allow a user to add a "person record" to the Master Person Index (MPI). Pre-conditions: (Those conditions that must be present before the use case can start.) The user must have proper security rights to enter a patient in the system. System is available and operable The user is notified that a person requires TB services and the person satisfies jurisdiction criteria for assessment and/or treatment. The person requires TB assessment and/or treatment needs to be added into the MPI.

Main Flow: 1.User selects register option 2.System displays register screen 3.User enters basic patient information in the register screen. Basic information may include last name, first name, sex, date of birth, address, and if a translator is needed. 4.User enters the reason for adding the person to the MPI which may have the following values: suspect case, confirmed case, contact investigation, targeted testing, etc. 5.User selects the save option 6.System saves registration in the MPI 7.End Use Case Alternate Flow/ Exception: (An optional situation within the activity flow.) 1.The system provides a message that a database record arleady exist 2.System rejects the registration and stops Post-conditions: (Outcome) A person record is created in the MPI.

This week’s presentation Content Heading: Requirement Elicitation & Analysis (summary report) 1.Introduction (elicitation & analysis approaches) 2.Functional Requirements 3.Non Functional Requirements 3.1 security 3.2 performance 3.3 ………… 4.Constraints 5.Use case model 5.1 Actors 5.2 Use case diagram 5.3 use cases specification

This week’s report Content Heading: Requirement Elicitation & Analysis (detailed report) 1.Introduction (elicitation & analysis approaches) 2.Functional Requirements 3.Non Functional Requirements 3.1 security 3.2 performance 3.3 ………… 4.Constraints 5.Use case model 5.1 Actors 5.2 Use case diagram 5.3 use cases specification