Team Skill 6 - Building The Right System Part 1: Applying Use Cases (Chapters 25-26 of the requirements text) CSSE 371 Software Requirements and Specification.

Slides:



Advertisements
Similar presentations
Presentation by Prabhjot Singh
Advertisements

ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
Documenting a Software Architecture By Eng. Mohanned M. Dawoud.
IEC Substation Configuration Language and Its Impact on the Engineering of Distribution Substation Systems Notes Dr. Alexander Apostolov.
Ch 12: Object-Oriented Analysis
1 Use Cases 1 CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 17, 2004.
Team Skill 6 - Building The Right System Part 2: Traceability, Change and Quality (Chapters of the requirements text) CSSE 371 Software Requirements.
Lab/Sessional -CSE-374. SYSTEM DEVELOPMENT LIFE CYCLE.
Elaboration of Use Cases CSSE 371, Software Requirements and Specification Steve Chenoweth, Rose-Hulman Institute October 21, 2004 In the book – This is.
Introduction to Requirements (Chapters 1-3 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman Institute.
1 Team Skill 4 - Team Skill 5 - Scope Refining the Systems Definition (Chapters of the requirements text) CSSE 371 Software Requirements and Specification.
1 Software Testing and Quality Assurance Lecture 26 (a) – Testing Interactions (Chapter 6)
Slide 1 Process, Requirements and Prototyping (Chapters 6-8 of Interaction Design text) CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman.
1 Maintenance Metrics and Measures (M 12) Steve Chenoweth CSSE 375, Rose-Hulman Based on Don Bagert’s 2006 Lecture.
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.
Slide 1 Requirements Wrap-up (Chapter 31 of requirements text) and Interaction Design: Introduction (Chapters 1 of Interaction Design text) CSSE 371 Software.
Use cases and requirement specification - 1 Use case diagrams 3 use cases System boundaries Remember: Use case diagramming is a tool, not the requirements.
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.
1 Quality Assurance in Construction and Maintenance (Section 13.4 of Maintenance Text; Chapter 20 of Code Complete) Steve Chenoweth CSSE 375, Rose-Hulman.
Introduction to Software Engineering Dr. Basem Alkazemi
1 Team Skill 1 - Analyzing the Problem (Chapters 5-7 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman.
Slide 1 Understanding Interaction, Users and Interfaces and Designing for Collaboration and Communication (Chapters 2-5 of Interaction Design text) CSSE.
Use Case Analysis – continued
Recall The Team Skills Analyzing the Problem
Unit Testing CS 414 – Software Engineering I Don Bagert Rose-Hulman Institute of Technology January 16, 2003.
Software System Integration
Unified Modeling Language
TK2023 Object-Oriented Software Engineering CHAPTER 6 SYSTEM SEQUENCE DIAGRAMS.
System Design Chapter 8. Objectives  Understand the verification and validation of the analysis models.  Understand the transition from analysis to.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
CPSC 871 John D. McGregor Module 1 Session 2 Requirements Elicitation/analysis.
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
CIT UPES | Sept 2013 | Unified Modeling Language - UML.
Chapter 1: The Object-Oriented Systems Development Environment Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich,
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,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Chapter 10 Information Systems Analysis and Design
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
Requirements Analysis via Use Cases SE-2030 Dr. Rob Hasker 1 Based on slides written by Dr. Mark L. Hornick Used with permission.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 7: Requirements Engineering Software Engineering: A Practitioner’s Approach, 6/e.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Applying Use Cases to Implementation (Chapters 25,26 - Requirements Text) Steve Chenoweth & Chandan Rupakheti Question 1.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
1)History of water fall model. 2)Features of water fall model. 3)Phase of water fall model. 4)Brief description of phases. 5)Advantages. 6)Disadvantages.
4+1 View Model of Software Architecture
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
CS 350 – Software Design The Facade Pattern – Chapter 6 Many design patterns are catalogued in the “Gang of Four” text. I find their definitions not to.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
Wrap up. Structures and views Quality attribute scenarios Achieving quality attributes via tactics Architectural pattern and styles.
 System Requirement Specification and System Planning.
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.
UML Diagrams By Daniel Damaris Novarianto S..
UML Diagrams Jung Woo.
CS 350 – Software Design The Facade Pattern – Chapter 6
Recall The Team Skills Analyzing the Problem (with 5 steps)
Making the System Operational Implementation & Deployment
Software Design Lecture : 15.
Applying Use Cases (Chapters 25,26)
Team Skill 6 - Building The Right System Part 1: Applying Use Cases
Applying Use Cases (Chapters 25,26)
From Use Cases to Implementation
Presentation transcript:

Team Skill 6 - Building The Right System Part 1: Applying Use Cases (Chapters of the requirements text) CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman Institute of Technology October 3, 2005 Thanks to Steve Chenoweth for some of the slides included.

2 Outline Use Cases in Design and Implementation From Use Cases to Test Cases

3 Use Cases in Design and Implementation

4 What Are the Design Issues? Sometimes it is easier to design and implement a system feature than others For instance, if a feature mostly involves interaction between the software and one or more actors, the use case events correspond well with the steps of the implementation algorithm

5 What Are the Design Issues? (continued) However, in other cases, such as when quality requirements or complex data structures are involved, the design does not follow as directly When the form of the requirements and the form of the design and implementation are different, we say that their correlation is orthogonal.  You have to stir in use cases and those quality attribute scenarios!

6 Solving the Orthogonality Problem A potential solution: comes from the software architecture The software architecture helps us understand what the system does and how it works, how the elements interact, and what type of patterns and pieces or the system are involved

7 Solving the Orthogonality Problem (continued) Architectural views : –Logical (for users) –Implementation (programmers) –Process (integrators) –Deployment (system engineers) –Use-case view (designers/testers; ties things together) Adding design details to a use case can also sometimes help - see

8 From Use Cases to Test Cases

9 Acceptance Test Cases Acceptance (or validation) test cases are ones that are performed from the user’s point-of-view. –They are examples of black-box test cases (i.e. no knowledge of internal working of the software) Use cases are not exactly validation test cases, although use cases do drive the process of validation test case generator Steps in creating a test case: –Identify use-case scenarios (basic and alternate flows) –Identify the test cases –Identify the test conditions –Add data values to the test case

10 Test Case Description Table For a Use Case Test Case Id ScenarioDescriptionCond. 1 Cond. 2 Cond. 3 Expected Result Actual Result Use as many conditions as necessary for a use case,

11 Test Plans 1.There’s a “test plan” for how to do all these test cases. 2.The use cases each become multiple test cases in the test plan.