Object-Oriented Analysis and Design Evolutionary Requirements.

Slides:



Advertisements
Similar presentations
9/10/2004Use Case Workshop 1 CSC480 Software Engineering Workshop 1 Requirements Modeling.
Advertisements

Use cases.
CS3773 Software Engineering Lecture 03 UML Use Cases.
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 Diagram © copyright 2001 SNU OOPSLA Lab..
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.
Use-case Modeling.
Drawing System Sequence Diagrams
Systems Analysis and Design in a Changing World, Fourth Edition
January Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Elaboration Iteration 1: a simple cash-only success scenario of.
Use Case modelling How to go from a diagram to a further definition.
Use Cases & Requirements Analysis By: Mostafa Elbarbary.
Documenting Requirements using Use Case Diagrams
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
George Blank University Lecturer.
Chapter 6 Applying UML and Patterns Craig Larman
Copyright ©2004 Cezary Z Janikow 1 Use Cases n Within Requirements discipline/workflow n Verbal descriptions of important functional (behavioral, transactional,
NJIT Drawing System Sequence Diagrams Chapter 10 Applying UML and Patterns Craig Larman Presented by Anuradha Dharani.
Chapter 6 USE CASES Objectives Identify and write use cases
The first step in getting what you want is to decide what you want.
Use-Case Model: Writing Requirements in Context
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Interaction Modeling. Introduction (1) Third leg of the modeling tripod. It describes interaction within a system. The class model describes the objects.
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.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 20. Review Software Requirements Requirements Engineering Process.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
Object-Oriented Analysis and Design Jan 14, 2009.
 Development is organized in a series of short, fixed-length mini-projects called iterations  Iterations are also incremental  Successive enlargement.
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 7 Appendix A Object-Oriented Analysis and Design: Use Cases Modern Systems Analysis and Design Seventh Edition Jeffrey A. Hoffer Joey F. George.
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.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
Object Oriented Analysis & Design & UML (Unified Modeling Language) 1 Part II: Requirements The requirements workflow Use case modeling Advanced.
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.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Drawing System Sequence Diagrams
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 Model Use case diagram.
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.
COMP-350 Object-Oriented Analysis and Design Drawing System Sequence Diagrams Reference: Larman, Chapter 9.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Use cases.
1 Chapter 5 Modeling System Requirements Finding the Use Cases Page
Use Case Model Use case diagram. Relevant Requirements Artifacts Use-Case Model Supplementary Specification Use-Case Specifications... Glossary Actors.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Scenario A scenario is a sequence of steps describing an interaction between a user and a system. Use case is a set of scenarios tied together by a common.
Systems Analysis and Design in a Changing World, Fourth Edition
UML (Unified Modeling Language)
Chapter 6: Structuring Requirements: Use Case Description and Diagrams Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
Chapter 3: Software Design –Use case Diagram Nouf Alghanmi.
Requirements capture: Using UML Use Cases David Millard and Yvonne Howard {dem,
© Copyright 2010 Rockwell Collins, Inc. All rights reserved. Practical SysML Applications: A Method to Describe the Problem Space Ray Jorgensen David Lempia.
Systems Analysis and Design in a Changing World, Fourth Edition
Use Case Modeling - II Lecture # 27.
Lec-5 : Use Case Diagrams
Use Case Model.
Inception.
Use Case Model Use case diagram.
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Use Case Model Use case diagram – Part 2.
Use Case Modeling.
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Use Case Modeling Part of the unified modeling language (U M L)
Use cases Dr. X.
Presentation transcript:

Object-Oriented Analysis and Design Evolutionary Requirements

UP Requirements Artifacts Use Case Model – typical scenarios of functional requirements Supplementary Specifications – primarily non- functional requirements Glossary – noteworthy terms including a Data Dictionary (a recording of data requirements) Vision – high-level requirements and business case summary Business Rules – (aka Domain Rules) requirements or policies which apply to many projects required by business or domain (e.g. tax laws)

Object-Oriented Analysis and Design Use Cases Read chapter 6

Define the Problem The most critical question: Is this the right system to make?

Use Case Relationships Domain Model Use Case Model Interaction Diagrams Design Requirements Business Model Objects, attributes, associations VISION GLOSSARY SUPPLEMENTARY SPECIFICATION

Use Cases are not Diagrams Use Cases have a diagram associated with them easy way for analyst to discuss a process with a domain expert Use cases are primarily text text = important; diagram = optional

Why Use Cases? Simple and familiar storytelling makes it easier, especially for customers, to contribute and review goals. They keep it simple They emphasize goals and the user perspective Focus on the essence/intent of requirements Avoid bias of reproducing the existing system

Identify Use Cases Capture specific ways of using the system as dialogue between an actor and the system. Use cases are used to: Capture functional system requirements Communicate with end users and Domain Experts Test the system

Specifying Use Cases Create a written document for each Use Case Clearly define intent of the Use Case Define Main Success Scenario (Happy Path) Define any alternate action paths Use format of Stimulus: Response Each specification must be testable Write from actors perspective, in actors vocabulary

Use Case Template Items Use Case Name Scope (the system under design) Level ("user-goal" or "subfunction") Primary Actor (calls on system to deliver its function) Stakeholders and Interests (Who cares? What do they want?) Preconditions (what must be true at use case start) Success Guarantee (aka Posconditions; what must be true on successful use case completion) Main Success Scenario (happy path/sunny day) Extensions (alternative scenarios) Special Requirements (non-functional requirements)

Suggested Other Use Case Items Technology and Data Variations (I/O methods and data formats) Frequency of Occurrence (of use case) Miscellaneous (e.g. open issues) See Use Case UC1: Process Sale p. 68

Naming Use Cases A complete process from end user viewpoint Usually in verb-object form, (e.g. Register for Classes) Use enough detail to make it specific Use active voice, not passive From viewpoint of the actor, not the system

Use Case Name Examples Excellent - Purchase Concert Ticket Very Good - Purchase Concert Tickets Good - Purchase Ticket (insufficient detail) Fair - Ticket Purchase (passive) Poor - Ticket Order (system view, not user) Unacceptable - Pay for Ticket (procedure, not process)

Singular or Plural? Usually determined by context. Preference for the simplest form, but most common form can be better. In the example of concert tickets, most people buy more than one, but a significant number buy only one. At a supermarket, Buy Items would be best. At a vending machine, it would be Buy Item.

Identify Actors Part of understanding a system is knowing who uses it Direct users Users responsible to operate and maintain it External systems used by the system External systems that interact with the system

Specifying Actors External to the system Non-deterministic May be different roles for one individual user May be other external systems

Identifying Actors Primary Actor Emphasis is on the primary actor for the use case – has goals to be fulfilled Stakeholders and Interests Other actors are listed as stakeholders. The interests of each key actor should be described.

Working with Use Cases Determine the actors that will interact with the system Examine the actors and document their needs For each separate need, create a use case During Analysis, extend use cases with interaction diagrams

Preconditions Anything that must always be true before beginning a scenario is a precondition. Assumed to be true, not tested within the Use Case Ignore obvious preconditions (e.g. power is on)

Success Guarantees (Postconditions) States what must be true if the Use Case is completed successfully May include the main success scenario and some alternative paths Stakeholders should agree on the guarantee.

Scenarios Main Success Scenario, or happy path is expected primary use of the system, without problems or exceptions. Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions.

Happy Path / Sunny Day Scenario Success Scenario (or basic course) gives the best understanding of the use case Each step contains the activities and inputs of the actor and the system response Two column template works well for this If three or more items, create a list Label steps for configuration management and requirements traceability Use present tense and active voice

Extensions (Alternative Flows) Extensions or Alternative Flow Use Cases allow the specification of Different ways of handling transactions Error processes Sections are convenient way to handle alternative courses of action Sections are a segment of a use case executed out of sequence

Essential versus Real Use Cases Essential (black box) use case leaves out technology and focuses only on functionality Real (white box) use case includes technology is fundamental. E.g., essential Withdraw Cash from ATM use case can mention identification or validation Only real Withdraw Cash from ATM use case can mention a key pad or card reader

Extension Use Cases Users appreciate simplicity, so most use cases leave out alternate courses Do this by extending the use case (see Use Case Diagramming section below) while leaving the original use case alone

Use-case driven development Requirements are primarily recorded in the Use Case model. Iterations are planned around implementing particular Use Cases. Use Case Realizations drive design. Use Case often influence the way user manuals are organized.

Diagramming Use Cases read Chapter 30 Object-Oriented Analysis and Design

Actor An actor is an idealized user of a system Actors can be users, processes, and other systems Many users can be one actor, in a common role One user can be different actors, if in different roles An actor is labeled in singular with the name of the role

Non-human Actor Actors can be users, processes, and other systems. Non human actors typically shown as rectangle rather than stick figure Usually not primary users, and thus are usually shown on the right Inventory System

Use Case Is a coherent unit of externally visible functionality provided by a system and expressed by a sequence of messages Additional behavior can be shown with generalize, extend, and include use case relationships Labeled with the use case name

System A system is shown as a rectangle, labeled with the system name Actors are outside the system Use cases are inside the system The rectangle shows the scope or boundary of the system Dont forget the boundary and the system name, unless you are using Rational Rose!

Association Relationship An association is the communication path between an actor and the use case that it participates in It is shown as a solid line It does not have an arrow, and is normally read from left to right Here, the association is between a Modeler and the Create Model use case

Include Relationship Include relationships insert additional behavior into a base use case They are shown as a dotted line with an open arrow and the key word > Shown is a process that I observed in an earlier career

Extend Relationship Extend puts additional, optional behavior in a use case that does not know about it. It is shown as a dotted line with an arrow point and labeled > In this case, a customer can request a catalog when placing an order

Generalize Relationship Is a relationship between a general use case and a more specific use case that inherits and extends its features It is shown as a solid line with a closed arrow point Here, the payment process is modified for cash and charge cards

Use Case Example: Alarm Clock This is a contrived example, to show many relations. Your diagrams should be simpler.