ANALYSIS REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.

Slides:



Advertisements
Similar presentations
Requirements Elicitation and Use Case Diagrams
Advertisements

OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Interaction Diagrams.
Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 1 Capturing the Requirements as use Cases  Requirements Description  We need to describe –The.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Use-case Modeling.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
Finding Analysis Classes Written by Zvika Gutterman Adam Carmi.
Requirements Analysis 2 What objects collaborate to achieve the goal of a use case?
© Copyright Eliyahu Brutman Programming Techniques Course.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Use Case Analysis – continued
SE 555 Software Requirements & Specification Requirements Analysis.
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
Object Oriented Analysis and Design Using the UML
Unified Modeling Language
USE Case Model.
Introduction To System Analysis and design
RUP Requirements RUP Artifacts and Deliverables
UML - Development Process 1 Software Development Process Using UML (2)
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Chapter 5 Analysis Model. Analysis model (AM) The first step in describing how the system will implement the requirements specification The first step.
CIT UPES | Sept 2013 | Unified Modeling Language - UML.
Software Engineering Chapter 8 Fall Analysis Extension of use cases, use cases are converted into a more formal description of the system.Extension.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
 A software application is like a city  Modeling = Architecture  OOP = Civil Engineering  UML Classes = Blueprints of Buildings  UML is a common.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Object Oriented Analysis and Design using the UML CIS 520 Advanced Object-Oriented Design.
Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Class Diagrams.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
ANALYSIS - II REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
UML-1 4. Architecture. UML-2 Artifact: Analysis Class Abstraction of one or several classes or subsystems –Focuses on handling functional requirements.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
CIS 112 Exam Review. Exam Content 100 questions valued at 1 point each 100 questions valued at 1 point each 100 points total 100 points total 10 each.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Software Engineering Software Engineering - Mr. Ahmad Al-Ghoul.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Unified Software Development Process
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
UML - Development Process 1 Software Development Process Using UML.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Gerhard Dueck -- CS3013Analysis 1. Gerhard Dueck -- CS3013Analysis 2 Why analysis?  Yield a more precise specification of the requirements.  Introduce.
ISMT221 Information Systems Analysis and Design Use case diagram Lab 4 Tony Tam.
1 BTS330 Visual Modeling. What is Visual Modeling? 2 Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship.
Chapter 6: The Analysis Workflow Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes [Arlow and Neustadt, 2005] CS 426 Senior Projects in.
Lecture 5 Introduction to Use Case Analysis and the Analysis Model Introduction to the UML.
Slide 1 Project team 1. gathers requirements from the users (Ch. 4) 2. models the overall business process using __________ 3. identifies _________ using.
Requirements Development An Introduction to the Process and Artifacts November 20, 2001 SIS Analysis Model System Analysis Model SIS Use Case Model System.
Developing Business Processes Developing an activity diagram of the business processes can provide us with an overall view of the system.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Use Case Analysis – Part 4 Analysis Mechanisms.
Use Cases. 2 A use case... –Specifies the behavior of a system or some subset of a system. –Is a system-level function. –Does not indicative how the specified.
University of Houston-Clear Lake
Use Cases.
Copyright 2007 Oxford Consulting, Ltd
Software Analysis.
Design Yaodong Bi.
Use Case Analysis – continued
Design.
Software Development Process Using UML Recap
Presentation transcript:

ANALYSIS REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST

Introduction - 1 u Analyze the requirements Captured. u Refine and Structure them. u Achieve more precise understanding of the requirements. u Achieve description of the requirements that is easy to maintain that helps us give structure to the whole system.

Introduction - 2 u To communicate with customer efficiently l Use cases must be kept as independent to each other as possible. l Use case must be described using the language of the customer. l Use case must be structured to form a complete and intuitive specification of functionality.

Introduction - 3 u The above considerations leads to unresolved issues regarding the system requirements. u The main purpose of the Analysis is to resolve them by analyzing the requirements more in depth. u The language of the developers is used to describe the system. u Internal View of the System.

Characteristics - 1 u Described using language of the developers. u Internal View of the System. u Developed for developers to understand the system. u Should not contain inconsistencies and redundancies. u Outlines how to realize functionality of the system. u Defines use-case realizations each one representing the analysis of a use case from the usecase model u Provides input for shaping up the architecture of the system as a whole.

Characteristics – 2 u Language used in Analysis is called the Analysis Model. u Provides a structure that focuses on maintenance. u Feeds input to the Design and Implementation Phase. u Makes abstractions and avoids solving problems

Purpose of Analysis u Yields a more precise specification of the requirements. u Described using the Language of the developers. u Structure the requirements in a way that facilitates understanding them, preparing them and changing them and in general maintaining them. u First Cut at Design Model and is an essential input when the system is shaped in design and implementation.

Role of Analysis in S/W Life Cycle

The Analysis Model * * 1 Analysis Model Analysis Package Analysis Classes Use Case Realization Analysis * * * * Analysis System

Artifact - The Analysis Model u Analysis Classes l Boundary Classes l Control Classes l Entity Classes u Use Case Realization Analysis l Class Diagram l Interaction Diagram l Flow of Events l Special Requirements u Analysis Packages l Service Package u Architectural Description.

Artifact – Analysis Classes u Represents an abstraction of one or several classes. u The abstraction has the following characteristics. u Focuses on handling functional requirement. u Analysis class defines behavior by responsibilities on a higher and less formal level. u Defines Attributes at a higher Level. u Are involved in relationships. u Classes fit into one of three basic stereotypes Boundary Class, Control Class and Entity Class

ANALYSIS CLASSES Responsibilities Attributes Relationships Special requirements Analysis Class Boundary ClassControl ClassEntity Class

Boundary Classes u Used to model interaction between system and actor. u Represent abstraction of windows, forms, panes, communication Interface, sensors, terminals and API. u Each boundary class relate at least one actor and visa versa Payment Handler Buyer

Entity Classes u Used to model classes that is long lived and often persistent. Entity classes model information and associated behavior of some Phenomena or Concepts such as real time object, individual or real life event. Payment Handler UIBuyer Invoice Browses Payment Scheduler

Control Classes u Represent coordination, sequencing, transactions and control of other objects and are often used to encapsulate control related to a specific usecase. Payment Handler UIBuyer Invoice Browses