Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 1 Capturing the Requirements as use Cases  Requirements Description  We need to describe –The.

Slides:



Advertisements
Similar presentations
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
Advertisements

Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services
Requirements wg RUP Materiały na seminarium „Metodyki tworzenia SI” Wykonał Marcin Wiącek Styczeń 2006 Wojskowa Akademia Techniczna Wydział Cybernetyki.
Static Structure: Process Description
Mastering Object-Oriented Analysis and Design with UML Module 4: Analysis and Design Overview.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
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.
Chapter 21 Object-Oriented Analysis
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
SwE 313 Introduction to Rational Unified Process (RUP)
Copyright  Larry Dribin, Ph.D. SE470_EngFlows_v1.ppt SE470 EngFlows - 1 Excellence in Software Engineering Repeatable Level Defined Level Manage.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
SE 555 Software Requirements & Specification Requirements Analysis.
Source: Peter Eeles, Kelli Houston, and Wojtek Kozaczynsky, Building J2EE Applicationa with the Rational Unified Process, Addison Wesley, 2003 Prepared.
Slide 7E.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
1 Business Models Modeling. 2 Why Model the Business Business modeling is a technique to help answer critical questions, such as: What do the workers.
Object Oriented Analysis and Design Using the UML
Slide 1 Requirements Workflow. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical.
Chapter 7: The Object-Oriented Approach to Requirements
2005/05/25 Unified Modeling Lanauage 1 Introduction to Unified Modeling Language (UML) – Part One Ku-Yaw Chang Assistant Professor.
RUP Requirements RUP Artifacts and Deliverables
UML - Development Process 1 Software Development Process Using UML (2)
Unified Software Development Process (UP) Also known as software engineering process SEP describes how requirements are turned into software Defines who,
Business Modeling : basic concepts Extracted from Rational UML Profile for business modeling.mht.
ANALYSIS REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Software Engineering Chapter 8 Fall Analysis Extension of use cases, use cases are converted into a more formal description of the system.Extension.
From Use Cases to Test Cases 1. A Tester’s Perspective  Without use cases testers will approach the system to be tested as a “black box”. “What, exactly,
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
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.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Approaching a Problem Where do we start? How do we proceed?
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.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
UML-1 3. Capturing Requirements and Use Case Model.
Object Oriented Analysis and Design using the UML CIS 520 Advanced Object-Oriented Design.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
UML-1 8. Capturing Requirements and Use Case Model.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
ANALYSIS - II REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
1 Use Case Diagrams Use Case Actor Use case description Use case realization (Scenario) Use case relationships –Extends –Uses.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
Use Cases, Part I Understanding the Business Dynamics  Understand the business workflow  Identify system support points the system 'use cases'
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Rational Unified Process Fundamentals Module 3: Disciplines I.
Gerhard Dueck -- CS3013Requirements Capture 1  From Vision to Requirements  Why it is difficult?  Developers are not users  Inadequate requirements.
The Rational Unified Process 1 EECS810: Software Engineering.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
UML Diagrams for Caradon developers Daniel DG Moth Core Development Group, Research Student University of Brighton, MSc Object Oriented Software Technology.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
UML - Development Process 1 Software Development Process Using UML.
Business Modeling and Analysis
Gerhard Dueck -- CS3013Analysis 1. Gerhard Dueck -- CS3013Analysis 2 Why analysis?  Yield a more precise specification of the requirements.  Introduce.
Requirement Discipline Spring 2006/1385 Semester 1.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
UML: Unified modeling language
Product Life cycle (RUP)
Appendix A Object-Oriented Analysis and Design
Appendix A Object-Oriented Analysis and Design
Software Development Process Using UML Recap
Presentation transcript:

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 1 Capturing the Requirements as use Cases  Requirements Description  We need to describe –The artifacts created in the requirements workflow –The workers participating in the requirements workflow –The requirements capture workflow activities.  Fig 7.1 p. 133

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 2 Artifact: Use-Case Model  The system's functional requirements  The conditions or capabilities to which the system must conform  Agreement between the customer and the developer  Essential input for analysis, design, and testing  May be broken up into packages

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 3 Artifact: Actor  Actors represents parties outside the system that collaborate with the system  Actors correspond to workers and/or business actors in a business  An actor plays one role for each use case which it collaborates  An instance of an actor is a specific user interacting with the system

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 4 Artifact: Use Case  A use case represents one way in which the actors use the system  A use case is a chunk of functionality that the system offers to add a result of value to its actors.  A use case specifies a sequence of actions, including alternatives of the sequence, that the system can perform, interacting with actors of the system.  Use-case instance –A use case specifies the behavior of dynamic use-case instances or a scenario of use of the system –A use-case instance is the performance or execution of a use case –A use-case instance interacts with an actor instance –A use-case instance does not interact with another use-case instances

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 5 Artifact: Architecture Description  An architectural view of the use-case model.  It depicts the architecturally significant use cases.  An architecturally significant use case has some important and critical functionality, or involves some important requirement that must be developed early in the software's life cycle.  The architectural view is used as input when use cases are prioritized to be developed within an iteration.

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 6 Artifact: Glossary  To define important and common terms used by analysts to describe the system  Useful in reaching a consensus among developers –Regarding the definitions of various concepts and notions, and –Reducing the risk of misunderstandings  It can be derived from a business or domain model  It is more focused on the system to be built instead of the system's context.

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 7 Artifact: User-Interface Prototype  Help understand and specify the interactions between human actors and the system.  One user-interface prototype for each use case.

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 8 Workers  A worker is a position in the unified development process to which a real person can be assigned.  With each worker there is a description of the responsibilities and the expected behavior of that worker.

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 9 Worker: System Analyst  Responsible for –The whole set of requirements that are modeled as use cases –Delimiting the system –Finding the actors and use cases –Ensuring that the use-case model is consistent and complete –The modeling leader and coordinator  Not responsible for –Individual use cases

Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 10  Worker: Use-Case Specifier –Responsible for the detailed description of one or more of the use cases. –Work closely with the real users of the use case that s/he is responsible.  Worker: User-Interface Designer –Responsible for »visually shaping the user interface developing, for each actor, a user-interface prototype for some use cases  Worker: Architect –Responsible for describing the architectural view of the use-case model.