10/12/2015 1 Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.

Slides:



Advertisements
Similar presentations
Writing Good Use Cases - Instructor Notes
Advertisements

Chapter 3 Requirements Analysis, Negotiation and Modeling Part 3 Dr. Eman Al-Maghary Requirements Engineering.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 1.Gain agreement on the problem definition. 2.Understand the root causes 3.Identify the.
Design by Contract.
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
9/10/2004Use Case Workshop 1 CSC480 Software Engineering Workshop 1 Requirements Modeling.
Actors and use cases Use-case diagram Brief notation Prioritization Fully dressed notation Requirements Functional requirements  Use-cases.
Information System Engineering
Use-case Modeling.
WEEK 4 Material Lecture 4a (Wed.). Use Cases/Actors o What is a use case ? l A sequence of actions performed by a system that yields an observable result.
Use Case Modelling.
Functional Requirements – Use Cases Sriram Mohan/Steve Chenoweth (Chapters 14, 21 – Requirements Text) 1.
A use case describes one “case” of how a user can use the system.
Rose-Hulman Institute of Technology Sriram Mohan 18.September.2008 CSSE 497 Requirements Review.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews 2. Workshops 3. Brainstorming.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
Functional Requirements – Use Cases Steve Chenoweth & Chandan Rupakheti (Chapters 14, 21 – Requirements Text)  Quiz question 9 relates to this, when you’ve.
Functional Modeling Chapter 6.
Recall The Team Skills Analyzing the Problem
USE Case Model.
Modeling System Requirements:Events and Things
SYS366 Systems Use Case Descriptions. SYS3662 Contents Review Systems Use Case Descriptions Systems Use Case Authoring.
Use Cases Why use ‘em? How do they work? UC diagrams Using them later in the software development cycle.
RUP Requirements RUP Artifacts and Deliverables
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
Object-Oriented Analysis - Instructor Notes
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Business Analysis and Essential Competencies
Software engineering lec4 Requirements. Developing requirements Start thinking about particular problem Understand the problem  Domain analysis Gather.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
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 Requirements (Advanced Topics) “Walking on water and developing software from a specification are easy if both are frozen.” --Edward V Berard.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
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.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
Requirements Analysis and Design Engineering Southern Methodist University CSE 7313.
1 Use Case Modeling Reference: RUP Doc. Use Case Example 2.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
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.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
1 Chapter 4 Analyzing End-to-End Business Processes.
Functional Requirements – Use Cases (Chapters 14, 21) Sriram Mohan 1.
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.
(c) Addison Wesley Copyright © 2000 by Addison Wesley Version 1.0
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Use cases.
SYS466 Casual Use Case Specifications. Systems Use Case Diagrams and Specifications Based on the dialog metaphor Based on the dialog metaphor The process.
Use Case Model Use case diagram. Relevant Requirements Artifacts Use-Case Model Supplementary Specification Use-Case Specifications... Glossary Actors.
Week IV in SOS  Tuesday Project Time -- 4:15pm-5pm URL for project(s) due to Judy by Friday 5pm  Friday Paper  OOAD Handouts thru last Thursday (see.
UML - Development Process 1 Software Development Process Using UML.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Requirement Discipline Spring 2006/1385 Semester 1.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
George Wang, Ph.D. COMP 380/L Lesson 2. Use Case Use cases are a way to capture system functionalities (i.e., functional requirements) Based on use case.
Lecture 5d: Systems Use Case Descriptions.  Review  Systems Use Case Descriptions  Systems Use Case Authoring SYS3662.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Recall The Team Skills Analyzing the Problem (with 5 steps)
Use Case Model.
Use Case Model Use case diagram.
Recall The Team Skills Analyzing the Problem
Recall The Team Skills Analyzing the Problem (with 5 steps)
Using Use Case Diagrams
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Object-Oriented Software Engineering
Use Case Modeling Part of the unified modeling language (U M L)
Software Development Process Using UML Recap
Presentation transcript:

10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires 2. Workshops 3. Brainstorming and idea reduction 4. Storyboarding 3. Defining the System 4. Managing Scope 5. Refining the System Definition 6. Building the Right System

10/12/ Team Skill 3: Defining the System Define the system by focusing more on the features and deal with the increased amount of information. Ch 14: A Use Case Primer Ch 15: Organizing Requirements Information Ch 16: The Vision Document Ch 17: Product Management (skipped)

10/12/ Chapter 14 A Use Case Primer Use cases basics Benefits of use cases Steps of building use case model Use cases, storyboarding, and user interface design

10/12/ Use Case Basics A use case describes a sequence of actions the system performs that yield an observable result of value to a particular actor. An actor is someone or something that interacts with the system. Users, other systems, or devices Documenting use cases by using use case templates: Name, decscriptions, Covered in the labs (UML Notes)

10/12/ Use Case Basics Documenting use cases (Covered in the labs) by using use case templates: Name Description Actor(s) Flow of events Pre-conditions Post-conditions Etc... UML Diagrams

10/12/ Example

10/12/ The Benefits of Use Cases They are relatively easy to write and easier to read. They force developers to think through the design of a system from the perspective of a user. They engage the users in the requirements process: helping them understand the system that is being proposed. giving them a way to communicate and document their needs. They give context for the requirements of the system: One can understand why a requirement is what it is as well as how the system meets its objectives.

10/12/ The Benefits of Use Cases They provide an ordering mechanism for requirements: one can tell what has to happen before the next thing happens, and so on. In most circumstances, developers write the use cases. That means not only that there actually are understood requirements but also that the developers know they are responsible for determining them. It is a critical tool in the analysis process, helping us understand what the system needs to do and how it might go about doing it.

10/12/ The Benefits of Use Cases It is a critical tool in the design and implementation process, reducing the risk of transitioning from an expression of requirements to a differing implementation They carry over directly into the testing process, helping to assure that the system actually does what it was intended to do They serve as inputs to the user documentation, conveniently organized in a step-by-step format.

10/12/ Use Case Model Individual use case describes how a particular actor interacts with the system to achieve a result of value to the specific actor. The set of all use cases together describes the complete behavior of the system. The complete set of use cases, actors, and their interactions constitutes the use-case model for the system.

10/12/ Building a uses case model write individual use cases and then add them all.. Not a good idea. Instead, build a context model of the system and successively refine it. That’s better for understanding, communicating, and refining the behavior of the system in an iterative development.

10/12/ Building the Use-Case Model Step 1: Identify and Describe the Actors Step 2: Identify the Use Cases and Write a Brief Description Step 3: Identify the Actor and Use-Case Relationships Step 4: Outline the Individual Use Cases Step 5: Refine the Use Cases

10/12/ Step 1: Identify and Describe the Actors Who uses the system? Who gets info from the system? Who provides info to the system? Where in the company is the system used? Who supports the and maintain the system? What other systems use this system?

10/12/ Step 2: Identify the Use Cases and Write a Brief Description Typically, the use-case name is a few words or a short phrase that starts with an action verb and communicates what the actor achieves with the use case. To identify the use cases, ask the following for each actor:

10/12/ Step 2: Identify the Use Cases and Write a Brief Description What will the actor use the system for? Will the actor create, store, change, remove, or read data in the system? Will the actor need to inform the system about external events or changes? Will the actor need to be informed about certain occurrences in the system?

10/12/ Step 3: Identify the Actor and Use-Case Relationships Only one actor can initiate a use case However, many actors can be involved in a use case. Each use case is analyzed to see what actors interact with it and Each actor’s behavior is reviewed to make sure that all of the results he needs to see are achieved the system. If this becomes complex, uses diagrams.

10/12/ Step 4: Outline the Individual Use Cases To understand the system more think about the flow of events (basic and alternatives) for each use case. Basic flow: the most common path from start to finish through the system Alternative flows: other possible paths based on regular or exceptional circumstances.

10/12/ Step 4: Outline the Individual Use Cases To do that ask the following questions: Basic flow: What events start the use case? How does the use case end? How does the use case repeat some behavior? Alternative Flows: Are there optional situations in the use case? What odd cases might happen? What variants might happen? What may go wrong?..etc

10/12/ Step 5: Refine the Use Cases When to refine and think about the next level of details? Depends on All alternative flows including exception conditions Pre- and post-conditions

Use Case template 10/12/ Use caseAccept Payment Brief descriptionThis use case allows an Employee to accept the payment from Customer for a video rental. ActorsEmployee, Customer. PreconditionsCustomer expresses readiness to rent the video and he/she possesses valid membership card and the video is available for rental. Main flowThe use case begins when the Customer decides to pay for the video rental and offers cash or debit/credit card payment. The Employee requests the system to display the rental charge... Alternative flowsThe Customer does not have sufficient cash and does not offer the card payment. The Employee asks the system to verify... PostconditionsIf the use case was successful, the payment is recorded in the system’s database. Otherwise,...

10/12/ Use Cases and User Interfaces User interface design and use-case specification tend to be parallel. For example, inside the context of a specific use case, the team must decide: What choices the user makes given the screens, dialog boxes, and so on that we have presented to the user, what the system does based on those selections, and what screens, choices, and so on the system presents to the user.

10/12/ Use Cases and User Interfaces In other words, each step in a use case is achieved via the presentation of a GUI of some kind, followed by a user selection of some kind, followed by a presentation of a new GUI that moves the user to the next system context, and so on.

10/12/ Use Cases and Storyboarding A Use Case Storyboard Example

10/12/ Use Cases and Storyboarding You can use Microsoft PowerPoint as your storyboard presentation tool to build one PowerPoint slide for each of the steps in the use case to show the user how you intend the system to work. In this fashion, you can develop the use case and the GUIs in parallel while involving the user in the concept review process at the same time.

10/12/ Storyboard slide for step 1 of a use case

10/12/ Storyboard slide for step 4 of a use case

10/12/ Reading Assignment Read the case study of the HOLIS use cases pages:

10/12/ Key Points Use cases carry the majority of the requirements for the system. The development team, with user involvement, writes the use cases. Use cases are built on a common, standard format. Use cases later drive test case development.