1 Objectives  Describe design constraints.  Identify methods of specifying functional requirements.  Describe techniques for writing and structuring.

Slides:



Advertisements
Similar presentations
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Advertisements

Use-Cases.
Use cases Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself A set.
CPSC 333: Foundations of Software EngineeringJ. Denzinger 2.2. Use Cases: Scenario based requirements modeling Recommended: Booch, Rumbaugh, Jacobson:
Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Interaction Diagrams.
Use cases.
1 Dilbert Scott Adams Writing Effective Use Cases, Alistair Cockburn Use Cases: Requirements in Context, Daryl Kulak Applying Use Cases: A Practical.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
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.
Fall 2009ACS-3913 Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability,
Uml and Use Cases CS 414, Software Engineering I Mark Ardis Rose-Hulman Institute January 9, 2003.
SwE 313 Case Study Registration System.
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.
Understanding Requirements
Use cases and requirement specification - 1 Use case diagrams 3 use cases System boundaries Remember: Use case diagramming is a tool, not the requirements.
Copyright ©2004 Cezary Z Janikow 1 Use Cases n Within Requirements discipline/workflow n Verbal descriptions of important functional (behavioral, transactional,
Use Cases: The Technique
InceptionPhase Mesekach Kaleem Ullah, Melody Parsa, Charmie Dela Cruz, Setareh Vali S C K M MeSeKaCh.
Source: Peter Eeles, Kelli Houston, and Wojtek Kozaczynsky, Building J2EE Applicationa with the Rational Unified Process, Addison Wesley, 2003 Prepared.
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.
The first step in getting what you want is to decide what you want.
RUP Requirements RUP Artifacts and Deliverables
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
Requirements Management with Use Cases Module 6: Define the System Requirements Management with Use Cases Module 6: Define the System.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Rational Unified Process (Part 1) CS3300 Fall 2015.
Managing Changing Requirements: Structure the Use Case Model PowerPoint Presentation derived from IBM/Rational course Mastering Requirements Management.
Team ELL System Requirements Ladakeysha Thomas Elizabeth Waldo LaWanda Warren Brandon Williams.
Chapter 8: Actor-System Interaction Modeling
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 10: Structure the Use-Case Model.
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.
Chapter 6 A Use-Case-Driven Process. 2 Definitions The choice of models and the choice of techniques used to express them have a significant impact on.
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.
Use Cases 7/09. lnot part of the system lrepresents roles a user can play lrepresents a human, a machine or another system lactively exchanges information.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Submitted By: Memon Khurshed (Group Leader) Hamed Abdollahpur
 Development is organized in a series of short, fixed-length mini-projects called iterations  Iterations are also incremental  Successive enlargement.
Payroll System Bank System Any bank(s) to which direct deposit transactions are sent. Employee A person that works for the company that owns and operates.
OOSE Use Case. Requirement Functional: –Features, capabilities, and security Non Functional: –Usability: Human factors, help, and documentation –Reliability:
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.
UML-1 3. Capturing Requirements and Use Case Model.
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.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
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.
Writing Good Use Cases Outlining Use Cases. Process of writing use cases Find actors Find use cases Outline a use case Detail a use case  Outline the.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Use cases.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
1 High Level Design Phase Refining Use Cases User Interface Information.
Setting Up TGO User Accounts. Creating User Accounts for Other Users If your company has other users who need to use the Active Orders system, your company’s.
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Writing Use Cases: Requirements in Context.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 3: Outlining Use Cases.
UML - Development Process 1 Software Development Process Using UML.
Use Case Model Use case description.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Jan Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability,
Use Case Diagrams A Detailed Description. Use Case Diagrams Use case diagrams describe relationships between users and use cases A use case is a (usually.
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Chapter 6 유스케이스를 이용한 서비스 요구명세 Specification with Use Cases
Use Case Modeling - II Lecture # 27.
Recall The Team Skills Analyzing the Problem (with 5 steps)
UML Use Case Diagrams.
Use Case Document Example
Requirements Very High level specification of what system should do
Presentation transcript:

1 Objectives  Describe design constraints.  Identify methods of specifying functional requirements.  Describe techniques for writing and structuring use cases.  Detail the use case flows.  Flows of Events  Pre- and postconditions  Use case structure  Specify nonfunctional requirements.  Usability, Reliability, Performance, Supportability

2 Where Are We in the Requirements Discipline?

3 Refine the System Definition: Activities and Artifacts

4 Features Drive Software Requirements Feat 63 - the defect tracking system will provide trending information to help the project manager assess project status Trending information will be charted with a line graph showing time on the x axis, and number of defects found on the y axis. Trending periods can be entered in units of days, weeks, or months. Print Status Report Operator Project Manager

5 Detail Each Use Case 1.Identify actors and use cases.  Brief Description. 2.Outline each use case.  Basic Flow of Events.  Alternative Flows of Events. 3.Detail each use case.  Detail the flow of events.  Structure each use case flows of events.  Add detail. Pre- and postconditions, special requirements, relationships, use-case diagrams, and so on.

6 Why Detail Use Cases?  Specify the software requirements.  Create a specification that can be implemented.  Clarify important details in flow of events.  What the actor does.  What the system does in response.  What information is exchanged.  Describe additional information.  Preconditions  Postconditions

7 Detail a Use Case 1. Find the actors and use cases. 2. Detail the use cases. 1. Brief Description 2. Flow of Events Basic Flow of Events Alternative Flows of Events 3. Special Requirements 4. Preconditions 5. Postconditions 6. Extension Points 7. Relationships 8. Use-Case Diagrams 9. Other Diagrams/Enclosures 1. Brief Description 2. Flow of Events Basic Flow of Events Alternative Flows of Events 3. Special Requirements 4. Preconditions 5. Postconditions 6. Extension Points 7. Relationships 8. Use-Case Diagrams 9. Other Diagrams/Enclosures Brief Outline Add Detail RUCS6: Get Quote Use-Case Description

8 Detail the Basic Flow of Events Structure the flow into steps Number and title each step Describe steps (completely and concisely) Make each step a roundtrip of events Get Quote 1.1 Basic Flow 1. Customer Logs On The use case starts when the Trading Customer logs on. The system validates the customer id and password. The system presents a list of available functions. 2. Customer Selects “Get Quote” Function The Trading Customer chooses to get a quote. The system displays the list of trading symbols and names of securities. 3. Customer Selects Security The Trading Customer selects from the list of securities or enters the trading symbol for a security. 4. System Gets Quote from Quote System The system sends the trading symbol to the Quote System, and receives the Quote System Response. The system presents the corresponding Quote Display (see fields to display in Supplementary Specifications) to the Trading Customer.

9 Review: Flows of Events (Basic and Alternative)  One Basic Flow  Happy day scenario  Successful scenario from start to finish  Many Alternative Flows  Regular variants  Odd cases  Exceptional (error) flows Flow: A sequential set of steps.

10 Alternative Flows A3 Request Additional Quotes In Step 3, Customer Gets Quote, in the Basic Flow, if the customer wants additional quotes. The use case continues at Step 3. A4 Quit If at any time the Trading Customer decides to quit. The use case ends. A5 Unknown Trading Symbol In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at the beginning of Step 3. Alternative Flows A3 Request Additional Quotes In Step 3, Customer Gets Quote, in the Basic Flow, if the customer wants additional quotes. The use case continues at Step 3. A4 Quit If at any time the Trading Customer decides to quit. The use case ends. A5 Unknown Trading Symbol In Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the Trading Customer that the trading symbol is not recognizable. The use case continues at the beginning of Step 3. Detail Alternative Flows Describe what happens Condition Actions Resume location Location

11 Avoid Inline Conditional Behavior  Make identifying scenarios difficult.  Harder to test and implement. Preference should be for alternative flows.

12 Avoid Inline Repetitive Behavior  Make identifying scenarios difficult.  Harder to test and implement. Preference should be for alternative flows.

13 Alternative Flows Versus Inline Conditional Behavior  Alternative Flows  Pros Can be used anywhere there is conditional behavior.  REPEAT-UNTIL, IF-THEN-ELSE-ENDIF Make identifying scenarios simpler.  Helps testing and implementation  Cons Increased complexity in maintaining cross-references.  Inline Conditional Behavior  Pros Easier to handle small variations in flows.  Cons Harder to identify scenarios, test and implement.

14 Visualize Alternative Behavior Trading System Quote System Customer

15 Subflows  Increase clarity.  Allow internal reuse of requirements.  Unlike an alternative flow, are explicitly called.  Always return to the line after they were called. Alternative Flows Subflow

16 Example Subflow RUCS6.2: Execute Trade UC Spec

17 Leave the User Interface Out of the Use Case  Text is not good at describing visual things.  Use cases are user-interface agnostic.  Describe user Interfaces during Analysis and Design with:  User-experience model or prototypes RUCS11: Use-Case Modeling Guidelines Click Drag Form Open Close Drop Button Field Drop-down Pop-up Scroll Browse Record Window Prompts Chooses Initiates Specifies Submits Selects Starts Displays Informs Words to AVOIDWords to Use

18 Use the Glossary Effectively Glossary Customer Details: Information that uniquely identifies and provides contact information for a customer located in the U.S.A. The information consists of: Name, two address lines, city, state, zip code, and daytime phone number. Use Case 5. Enter Customer Info The system prompts the Customer to enter their Customer Details. The Customer enters the Customer Details. The Customer creates the account. Implementation