Team Skill 3 - Defining the System (Chapters 14-17 of the requirements text ) Sriram Mohan 1.

Slides:



Advertisements
Similar presentations
Information System Engineering
Advertisements

A Linguistics-Based Approach for Use Case Driven Analysis Using Goal and Scenario Authoring Vijayan Sugumaran Oakland University Rochester, Michigan, USA.
1 Use Cases 2 CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 20, 2004.
1 Use Cases 1 CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 17, 2004.
Use-case Modeling.
1 Team Skill 4 - Team Skill 5 - Scope Refining the Systems Definition (Chapters of the requirements text) CSSE 371 Software Requirements and Specification.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
Documenting Requirements using Use Case Diagrams
Use cases and requirement specification - 1 Use case diagrams 3 use cases System boundaries Remember: Use case diagramming is a tool, not the requirements.
Functional Requirements – Use Cases Sriram Mohan/Steve Chenoweth (Chapters 14, 21 – Requirements Text) 1.
1 Team Skill 3 - Defining the System (Chapters of the requirements text) CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
Rose-Hulman Institute of Technology Sriram Mohan 18.September.2008 CSSE 497 Requirements Review.
Functional Requirements – Use Cases Steve Chenoweth & Chandan Rupakheti (Chapters 14, 21 – Requirements Text)  Quiz question 9 relates to this, when you’ve.
Slide 7E.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Organizing Requirements & Managing Scope (Chapters of the requirements text ) Steve Chenoweth & Chandan Rupakheti RHIT Which brings up Question 1,
System Sequence Diagrams
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
Requirements Management with Use Cases Module 6: Define the System Requirements Management with Use Cases Module 6: Define the System.
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.
1 Text Layout Introduction (1-4) Team Skill 1 – Analyzing the problem (5-7) Team Skill 2 – Understanding User and Stakeholder Needs (8-13) Team Skill 3.
1 Objectives  Describe design constraints.  Identify methods of specifying functional requirements.  Describe techniques for writing and structuring.
Interaction Modeling. Introduction (1) Third leg of the modeling tripod. It describes interaction within a system. The class model describes the objects.
Understanding User Requirements. Documenting Use Cases 2 At this stage of the exploration, the participants should be thinking of essential use cases.
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
1 Source: IBM Academic Program IBM Software Group ® Mastering Requirements Management with Use Cases Module 3: Introduction to Use-Case Modeling.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Requirements Specification for Lab3 COP4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of Computer Science University.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Requirements Documentation CSCI 5801: Software Engineering.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 4: Restaurant.
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.
Sept. 18, 2003CS WPI1 CS 509 Design of Software Systems Lecture #3 Thursday, Sept. 18, 2003.
1 Objectives  Define key concepts of use-case modeling.  List the benefits of use-case modeling.  Find actors and use cases.  Describe their relationships.
® 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.
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
Use Case Modeling Chapter 7 Part of Requirements Modeling Designing Concurrent, Distributed, and Real-Time Applications with UML Hassan Gomaa (2001)
1 Structuring Systems Requirements Use Case Description and Diagrams.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Slide 1 Use Case Diagrams.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
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.
Systems Analysis and Design in a Changing World, 6th Edition
Team Skill 3 – Organizing Requirements & Product Management (Chapters of the requirements text ) Sriram Mohan/Steve Chenoweth RHIT 1.
Functional Requirements – Use Cases (Chapters 14, 21) Sriram Mohan 1.
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.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan.
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.
The Vision Document & Product Management CSSE 371, Software Requirements and Specification Steve Chenoweth, Rose-Hulman Institute September 27, 2004 In.
Chapter 6: Structuring Requirements: Use Case Description and Diagrams Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Requirement Discipline Spring 2006/1385 Semester 1.
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.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
Chapter 3: Software Design –Use case Diagram Nouf Alghanmi.
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.
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.
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 5 유스케이스 개요 Introduction to Use Cases
Recall The Team Skills Analyzing the Problem (with 5 steps)
Use Case Model Use case diagram.
Week 10: Object Modeling (1)Use Case Model
Systems Analysis and Design in a Changing World, 6th Edition
Presentation transcript:

Team Skill 3 - Defining the System (Chapters of the requirements text ) Sriram Mohan 1

Outline Use Cases Organizing Requirements Vision Document Product Management 2

Use Cases 3

What is a Use Case? Sequences of actions Performed by system of interest Observable result of value to a particular actor 4

Benefits Easy to write and read Think from the perspective of an user Provides a clear idea of the “what” and the “how” User involvement 5

Use Case Model - Development Steps 1. Identify the actors 2. Identify the use cases 3. Identify actor/use case relationships 4. Outline use cases 5. Refine use cases 6

1. Identify the Actors Who uses the system? Who gets/provides information from/to system? Who supports the system? What other systems interact with this system? 7

2. Identify the Use Cases What are the intentions of each actor with respect to the system? Give a descriptive name: ◦ Start with an action verb ◦ Describes goal or intent Give a one-sentence description 8

3. Identify Actor/Use Case Relationships Draw a diagram showing relationships between actors and use cases 9 Eat foodBuy food Parent Child

4. Outline Use Cases Describe sequence of events in basic flow (sunny day scenario) Describe sequences of events in alternate flows (rainy day scenarios) 10

5. Refine Use Cases Describe sequences of events for flows Describe pre-conditions Describe post-conditions Fill in special requirements 11

Use Case Template A. Name B. Brief description C. Actors D. Basic flow E. Alternate flows F. Pre-conditions G. Post-conditions H. Special requirements 12

Microwave Example 13 User Cook Food

Cook Food Use Case – Slide 1 of 4 A. Name: Cook Food B. Brief description: User places food in microwave and cooks it for desired period of time at desired power level. C. Actors: User 14

Cook Food Use Case – Slide 2 of 4 D. Basic flow: 1.User opens door and places food in unit 2.User enters time for cooking 3.User pushes start button 4.Unit cooks food 5.Unit beeps 15

Cook Food Use Case – Slide 3 of 4 E. Alternate flows 1.User cancels time before starting 2.User cancels cooking before finished 3.User selects reduced power level before pushing start button 16

Cook Food Use Case – Slide 4 of 4 F. Pre-conditions ◦ Unit is plugged in ◦ Unit is in ready state G. Post-conditions ◦ Food is cooked or user cancelled operation H. Special requirements ◦ Timer should display remaining time to finish while cooking ◦ Default power setting should be "high" 17

18 Extending Use Cases Extend an existing use case instead of redefining it

19 Microwave Extension User Cook FoodSlice Food >

20 Including Use Cases Frequent sequences of events may be defined as use cases Including a use case is like calling a subroutine

21 Microwave Inclusion User Cook FoodSet Timer >

22 Cook Food Inclusion D. Basic flow: 1.User opens door and places food in unit 2.User performs Set Timer use case 3.User pushes start button 4.Unit cooks food 5.Unit beeps

Organizing Requirements – Why? Complex system Member of a product family 23

Organization Techniques Dividing requirements for complex systems into subsystems Product Families ◦ A series of products with closely related requirements ◦ Product lines – a new way of viewing software products  Investing in infrastructure to build product families  Develop systematic approach to building flexible application generators  Commonality analysis – used to determine if use of a product line will be beneficial 24

Economics of Families Current Practice 25 Number of Family Members Cumulative Cost Product Line Approach

Example Families Toyota automobiles and trucks IBM 360 computers Software? 26

The Vision Document 27

28 Let’s start with some vision… Do it first, Then the “lessons” might sound familiar… Get out a blank sheet of paper and something to write with. Put your name on it. In 1 minute, verbally sketch your beliefs about the “story” shown at right – 2 years from now – What did it become? Pass it to your left In 1 min, write your reaction to what you see written – Agree? Return it to the author …From your project description. “ This project would enable a user to share the real-time contents and actions of their computer screen with any remote user or group of users… ”

Purpose Comprehensive description of the product High level abstraction of the problem and the solution. Provides “common goals and a common playbook.” 29

Vision Document Template 1. Introduction 2. User Description 3. Product Overview 4. Feature Attributes 5. Product Features 6. Exemplary Use Cases 7. Other Product Requirements 8. Documentation Requirements 9. Glossary 30

31 How does it start? How does it end? Starts like the exercise you just did – ◦ Drawings and beliefs about the future Ends up like Figure 16-1, pp ◦ How this project fits into the development team’s plans ◦ Sample – See “Vision Doc Example” file, under Handouts  ◦ See Appendix A and E in the book

32 So, do we have to do one of these for our project? Problem statement Use cases Supplementary spec Paper prototype Usability Study Code-based prototype And now, for a taste of product management… These are the major artifacts your team will be responsible for delivering about the project  

Product Management 33

Rationale Every project needs an individual champion or a small champion team to advocate for the product. In a software products company, the product manager plays the role of the champion. The product manager drives the whole product solution: the application itself, support, user conveniences, documentation, and the relevant commercial factors. The Product Manager does high-level tasks – ◦ Listens to all the stakeholders ◦ Negotiates amongst them ◦ Manages and funds project people ◦ Communicates features and releases to the outside world ◦ Advocates the product to everyone ◦ “Owns” the vision statement! “to help software teams build products that customers want to buy” 34

Product Manager in the Hierarchy Chart 35

Driving the Product Vision 36

Maintaining the Road Map 37

A Product Manager’s Day Plan scenarios in which products provide answers 38 These pieces make the product manager’s vision!

Product Types from a Marketing POV There are two major variations: ◦ A “custom” product for a particular customer or small group of customers – They often act directly as “external clients” ◦ A “general” product for a target market – An executive or the product manager is the “internal client” for these future customers 39