Requirements Analysis

Slides:



Advertisements
Similar presentations
Use Case Diagrams Damian Gordon.
Advertisements

CPSC 333: Foundations of Software EngineeringJ. Denzinger 2.2. Use Cases: Scenario based requirements modeling Recommended: Booch, Rumbaugh, Jacobson:
Use Case & Use Case Diagram
Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt
Use Case Modeling SJTU. Unified Modeling Language (UML) l Standardized notation for object-oriented development l Needs to be used with an analysis and.
Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt
Lecture 8 Electronic Commerce Modelling Techniques
Information System Design IT60105 Lecture 3 System Requirement Specification.
CS3773 Software Engineering Lecture 03 UML Use Cases.
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
1 CS 425 Software Engineering Project Preparation Use Case Modeling [Based on Chapters 3 & 4, Arlow and Neustadt, “UML and the Unified Process,” Addison-Wesley,
Use Case Modeling. Use case diagram For each use case we develop  Object class diagram (with attributes only)  System sequence diagram (analysis) 
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Software Waterfall Life Cycle Requirements Construction Design Testing Delivery and Installation Operations and Maintenance Concept Exploration Prototype.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 The requirements engineering process.
Faculty of Computer & Information Software Engineering Third year
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.
USE CASE Bayu Adhi Tama, MTI Faculty of Computer Science, University of Sriwijaya Slides are adapted from Petrus Mursanto
Approaching a Problem Where do we start? How do we proceed?
 Development is organized in a series of short, fixed-length mini-projects called iterations  Iterations are also incremental  Successive enlargement.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
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.
Requirements Engineering Southern Methodist University CSE 7316 – Chapter 3.
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.
Unified Modeling Language User Guide Section 4 - Basic Behavioral Modeling Chapter 16 - Use Cases Chapter 17 - Use Case Diagrams.
1 Graph Coverage (6). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section
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.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
Chapter 3: Software Design –Use case Diagram Nouf Alghanmi.
UC Diagram & Scenario RKPL C & D. Using Use Case Diagram Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior.
1 Object-Oriented Static Modeling of the Banking System - III Lecture # 33.
1 Case Study and Use Cases for Case Study Lecture # 28.
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.
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
Systems Analysis and Design in a Changing World, Fourth Edition
CMPE 135: Object-Oriented Analysis and Design August 31 Class Meeting
Using Use Case Diagrams
Chapter 4: Business Process and Functional Modeling, continued
Introduction Edited by Enas Naffar using the following textbooks: - A concise introduction to Software Engineering - Software Engineering for students-
Paul Ammann & Jeff Offutt
CMPE 280 Web UI Design and Development August 29 Class Meeting
Use Case Modeling - II Lecture # 27.
Structured Analysis and Design Technique
TQS - Teste e Qualidade de Software (Software Testing and Quality) Test Case Design – Model Based Testing João Pascoal.
Recall The Team Skills Refining the Use cases
User-centred system design process
Prototyping Lecture # 08.
Dynamic Modeling of Banking System Case Study - I
Use Case Model.
Object-Oriented Static Modeling of the Banking System - I
Exercices & Corrections Week 3
Software Processes (a)
Part 3 Design What does design mean in different fields?
Introduction Edited by Enas Naffar using the following textbooks: - A concise introduction to Software Engineering - Software Engineering for students-
Chapter 3: The Requirements Workflow
Concepts, Specifications, and Diagrams
SAD ::: Spring 2018 Sabbir Muhammad Saleh
Paul Ammann & Jeff Offutt
Use Cases & Use Case Diagrams
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Software Design Lecture : 15.
Using Use Case Diagrams
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Engineering Quality Software
CS 420/620 HCI Use Case Modeling Project Preparation
CS 425 Software Engineering
Chapter 5 Architectural Design.
CS 425/625 Software Engineering
Presentation transcript:

Requirements Analysis Requirement Analysis (CS340 John Knight 2005)

The Software Lifecycle Requirement Analysis (CS340 John Knight 2005)

Find Out What Software Has To Do Requirements Requirements Analysis: Find Out What Software Has To Do What The Software Has To Do, Not How - Important Distinction Very Hard To Effect - Not Clear That It Is Really The Right Thing To Do Requirements Specification: Document Requirements Requirements Analysis Is The Most ‘‘Influential’’ Phase Of Lifecycle Cost Of Defect Repair Highest Requirement Analysis (CS340 John Knight 2005)

Why Is Cost Of Repair Highest? So What If Requirements Are Wrong? Factors Of 10 ... Have To: Correct Specification Have To: Repair Design Have To: Modify Implementation Have To: Change Functional Tests Have To: Regression Test System Have To: Update All Documents Have To: Recall Copies In The Field Interestingly, Requirements Errors Are The Most Common Hmmmm. This looks like a BIG risk. It is Requirement Analysis (CS340 John Knight 2005)

Requirements Analysis Summary Requirement Analysis (CS340 John Knight 2005)

Requirements Analysis Very Difficult To Get Right... Capture Ideas/Concepts/Thoughts: Domain Knowledge Required By Software Engineer Computer Knowledge Required By User Language(s) Of Communication - What Is A “Variable”? Documentation Structure And Format? Requirement Analysis (CS340 John Knight 2005)

Requirements Analysis Fundamentally Same As Other Engineering Areas, BUT.... Computer Changes Environment: Much Faster More Accurate Greater Flexibility Users Learn Potential Hence Requirements Change: During Requirements Analysis All Other Phases Of Lifecycle Requirement Analysis (CS340 John Knight 2005)

Functional Requirements System Overview/Architecture System Inputs And Outputs: Formats Completeness Adequacy Of User Interfaces Response To Every Input Especially Invalid Inputs Correct Outputs And Special Cases Requirement Analysis (CS340 John Knight 2005)

Non-Functional Requirements Constraints On Implementation Hardware Details, Software Context, Timing Performance: Response Time, Processor Usage, Memory Usage, I/O System Demand Dependability: Reliability Availability Security And Safety Requirement Analysis (CS340 John Knight 2005)

Non-Functional Requirements Implementability: Can This Be Implemented? Excessive Implementation Resources? Execution-Time Resources? Maintainability: Long-Lived System? Short-Lived System? Throw-Away System? Testability: Can Requirements Be Tested Properly? Can Requirements Be Tested At All? Requirement Analysis (CS340 John Knight 2005)

Requirement Analysis (CS340 John Knight 2005) Anticipated Change Most Likely User Modifications Most Likely User Enhancements External Effects : Computer Language Operating System Document As Part Of Requirements Analysis/Definition Requirement Analysis (CS340 John Knight 2005)

Requirements Analysis Techniques Carefully Separate: Functional Requirements Non-Functional Requirements Ways Of Structuring The Analysis: Top Down Bottom Up Object Oriented Document Oriented Requirement Analysis (CS340 John Knight 2005)

Requirements Analysis Techniques Information Acquisition Methods: Intelligent Query Of Customers Or Users Careful Review Of Specification By Both Sides Prototyping Of Ideas For Evaluation Build Models (“Structured Analysis”) Requirements Analysis Is A Learning Process - Focus On Risk Customers Cannot State What They Want But They Can Criticize Requirement Analysis (CS340 John Knight 2005)

Use Cases - Part Of The UML Idea Is To Have Well-defined Method For Capturing User Interface Requirements. Clever! Simple Idea Hard To Do Well. Use Case: Defines A Goal-oriented Set Of Interactions Between External Actors And The Required System Literally A Description Of The Interaction Between the User And The System Requirement Analysis (CS340 John Knight 2005)

Requirement Analysis (CS340 John Knight 2005) Use Cases Use-case Modeling To Describe User Needs. Use case: “a sequence of actions a system performs to yield an observable result of value to a particular actor.” Actor: someone or something outside the system that interacts with the system. Remember: We Want An “External” View Of The System. How It Interacts With Its Environment Use Cases Are Described As Flows Of Events, Usually In Text Form Requirement Analysis (CS340 John Knight 2005)

Requirement Analysis (CS340 John Knight 2005) Use Cases Actors: Parties Outside The System That Interact With The System. Actor May Be A Class Of Users, Roles Users Can Play, Or Other Systems. Example: Robot Driver. But How About Other Robots? Robot Terrain? Use Case Describes All Possible Sequence Of Interactions Between Actors & System From Initiating Event (Goal) To Completion Of Event (Goal Satisfied). Requirement Analysis (CS340 John Knight 2005)

Requirement Analysis (CS340 John Knight 2005) Use Cases Includes Possible Variants Of Main Sequence: Sequences That Also Satisfy The Goal Sequences That Might Lead To Failure Because Of Exceptions. System Is A “Black Box”, Interactions With System, Including System Responses, Are As Seen From Outside The System. Requirement Analysis (CS340 John Knight 2005)

Requirement Analysis (CS340 John Knight 2005) Use Cases Use Cases Capture Who (Actor) Does What (Interaction) With The System, For What Purpose (Goal). Complete Set Of Use Cases Specifies All The Different Ways To Use The System Defines All Behavior Required Of The System, If Done Completely Question: How Can One Be Sure That Use Case Is Complete? Requirement Analysis (CS340 John Knight 2005)

Requirement Analysis (CS340 John Knight 2005) Use Cases Generally, Use Case Steps Documented In Natural Language. Scenarios: A Scenario Is An Instance Of A Use Case Single Path Through The Use Case. Possible Approach: Construct Scenario For The Usual Path Through The Use Case Construct Other Scenarios For Each Possible Variation Of Flow Through The Use Case, E.g., Triggered By Optional Paths, Error Conditions, Etc.). Requirement Analysis (CS340 John Knight 2005)

Example: ATM Withdrawal Three Use Cases For ATM: Withdraw Money; Transfer Money; Check Balance Withdraw Money Description—User Withdraws Money From Automatic Bank-teller Machine: Client inserts card and system reads it System prompts for PIN. Client enters and it's validated. System asks “which operation” and Client selects “withdrawal”. Client chooses which account (checking, savings). System requests amount and Client enters it. System communicates with ATM Network to validate account ID, PIN, amount. System asks Client if they want a receipt (if there is paper left to print one). System asks Client to withdraw their card. Client does this. System dispenses requested amount of cash. System prints receipt. (End of use case Withdraw Money.) Requirement Analysis (CS340 John Knight 2005)

Example: ATM Withdrawal Actors: Client, System, ATM Network But It's More Complex, Isn't It? Alternative Branches (“Quick Cash” Withdrawal). Exceptions And Errors (Invalid PIN, Network Down). We Group All Of These Into One Single Use Case A Use Case Is Thus A Family Or Class Of Scenarios. Scenarios Are Instances Of A Use Case. Most Systems Described By Only A Small Number Of Use Cases, Each With A Lot Of Variation. Relations Between Use Cases In Our Models: Some Use Cases Are “Included” In Others (E.g. Insert Card And Check PIN) Some Use Cases Extend Functionality In A Base Use Case. Requirement Analysis (CS340 John Knight 2005)

Advantages of Use Cases Represent An External View Of The System. (Helps Avoid The Pitfall Of Designing Too Early.) Easily Understood By Customers And Engineers. (Customers And Users Can Validate Them.) Provide A Natural Organization For System Functionality Force Us To Think How The User Interacts With The System—Very Helpful In User-interface Design Can Form A Basis For Testing The Software Using Functional Testing Can Validate A Design By Stepping Through It To See How It “Executes” Each Scenario But: Not The Whole Story: Constraints, Non-functional Requirements Part Of Requirements Documentation, Not All Of It Requirement Analysis (CS340 John Knight 2005)

Use Case Example Sketch Goal: Move Robot Under Sequence Control To New Location Actors: Driver, Robot Possible Sequence Of Commands (Completely Hypothetical): Set interface To Motion Command Mode (Position Camera To Required Direction) Set Motion Limits (Speed, Turning Radius, Direction, Etc.) Turn On Robot Sensors Define Initiate And Continue Movement Sequence Other Scenarios To Consider: Robot Hits Something Robot Exceeds Performance Limits Robot Loses Communication Etc. Requirement Analysis (CS340 John Knight 2005)

Requirement Analysis (CS340 John Knight 2005) Use-Case Resources Web Sites: http://www.usecases.org/ http://www.pols.co.uk/usecasezone/ http://www.bredemeyer.com/use_cases.htm http://members.aol.com/acockburn/papers/usecases.htm http://ootips.org/use-cases-done.html Textbooks: Object-Oriented Software Engineering: A Use-Case Driven Approach, Jacobson, I. et al. The Unified Modeling Language User Guide, Grady Booch, et al The Unified Modeling Language Reference Manual, James Rumbaugh, et al Requirement Analysis (CS340 John Knight 2005)

Basic Requirements Analysis Sub-Process Develop Milestones, Schedule, WBS—Remember Risks And Slack Time Get All Available Documentation About Project: Domain/Application Information Target Computer System Operating Environment Develop And Document Use Cases Develop Draft Specification Document Including: All Required/Structural Material (Boilerplate) Overview To Characterize System To New Reader Functional Requirements Non-Functional Requirements Develop Mockup Of Critical Elements (Prototype)—"Is This OK?" Review Inside Corporation—Develop Detailed Question List Review With Customer Revise Document And Repeat Requirement Analysis (CS340 John Knight 2005)

Always Remember Once Implemented, Wrong Requirements Are Very Expensive To Repair Once Software Is In The Field, Wrong Requirements Are Extremely Expensive To Repair Customers think that requirements can be changed very easily. You must make the costs clear. Requirement Analysis (CS340 John Knight 2005)