Ibrahim Al-sharif ID: 220080051

Slides:



Advertisements
Similar presentations
Introduction to Defining Classes. Objectives: Design and implement a simple class from user requirements. Organize a program in terms of a view class.
Advertisements

Entity-Relationship (ER) Modeling
Operant Behavior and Operant Contingencies AILUN – 2008 Lecture 2 – S Glenn.
Analysis Modeling.
Our First Real System.
P449. p450 Figure 15-1 p451 Figure 15-2 p453 Figure 15-2a p453.
Sketchify Tutorial Timers sketchify.sf.net Željko Obrenović
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
12.5 Record Modifications Jayalakshmi Jagadeesan Id 106.
1 / 26 CS 425/625 Software Engineering Software Requirements Based on Chapter 5 of the textbook [Somm00] Ian Sommerville, Software Engineering, 6 th Ed.,
From Questionnaires to Survey Results By Hasan M. Al-Sharif I.D # Graduate Seminar (CEM 599)
CS 425/625 Software Engineering Software Requirements
© 2005 Prentice Hall3-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Views Chapter 12. What Are Views? A virtual table that comprises the fields of one or more tables in the database It is a virtual table since it does.
Accounting Information Systems: A Business Process Approach Chapter One: Introduction to Accounting Information Systems.
1 Software Requirements Specification Lecture 14.
2Object-Oriented Analysis and Design with the Unified Process Events and Use Cases  Use case  Activity the system carries out  Entry point into the.
Cmpt-225 Simulation. Application: Simulation Simulation  A technique for modeling the behavior of both natural and human-made systems  Goal Generate.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
ELECTRICAL ACCESSORIES
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 The requirements engineering process.
Modeling and Simulation CS 313
Lesson 1.2 – Page 17 Desk Standards: Reason quantitatively and use units to solve problems.
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
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.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Chapter 9 요구사항 모델링: 시나리오 기반 방법론 Requirements Modeling: Scenario-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim.
CS 4310: Software Engineering Lecture 4 System Modeling The Analysis Stage.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
1. Objectives At the end of this chapter you should be able to:  Discuss the use and features of a data model  Define the terms entity and attribute.
T Iteration Demo Group name [PP|I1|I2] Iteration
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Slide 1 Analysis Workflow l The primary activities of the Analysis workflow are.
Systems Analysis and Design in a Changing World, 6th Edition
Simple and Efficient Strategies for Collecting Behavioral Data in the Classroom Environment.
Time Management.  Time management is concerned with OS facilities and services which measure real time, and is essential to the operation of timesharing.
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.
Conformance Test Experiments for Distributed Real-Time Systems Rachel Cardell-Oliver Complex Systems Group Department of Computer Science & Software Engineering.
1 Quality Attributes of Requirements Documents Lecture # 25.
Timing Tolerances in Safety-Critical Software Alan Wassyng, Mark Lawford, Xiayong Hu FM 2005 Software Quality Research Laboratory McMaster University.
Software Requirements Specification (SRS)
1 7.3 RANDOM VARIABLES When the variables in question are quantitative, they are known as random variables. A random variable, X, is a quantitative variable.
Software Requirements Specification Document (SRS)
Single-Subject and Correlational Research Bring Schraw et al.
1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
Stepper Motor – Types, Advantages And Applications
 System Requirement Specification and System Planning.
Chapter 5 – System Modeling
Software Engineering Lecture 4 System Modeling The Analysis Stage.
Classifications of Software Requirements
SECTION 2 SETUP, WRITING AND CREATING
Chapter 5 – System Modeling
State Transition Diagram for A System
Rational Functions: Graphs, Applications, and Models
Accounting Information Systems: A Business Process Approach
Abstract descriptions of systems whose requirements are being analysed
Section 11.1 Class Variables and Methods
8-bit Timer/Counter0 with PWM
CSCI1600: Embedded and Real Time Software
Software : TableDesigner
Classes & Objects – Revisited…
CSCI1600: Embedded and Real Time Software
2P13 Week 7.
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Timer/Counter Timer/Counter 0 Timer/Counter 1 Timer/Counter 2 8 bit
Week 8 Lecture 1: Identifying Actors and Activities
Overview Activities from additional UP disciplines are needed to bring a system into being Implementation Testing Deployment Configuration and change management.
Presentation transcript:

Ibrahim Al-sharif ID:

8.1: The Use-Case Approach 8.2: Event-Response Tables

A nother way to organize and document user requirements is to identify the external events to which the system must respond An event is some change or activity that takes place in the user's environment that stimulates a response from the software system ( McMenamin and Palmer 1984; Wiley 2000 ). An event-response table (event table or an event list) lists all such events and the behavior the system is expected to exhibit in reaction to each event. There are several types of system events, as shown in Figure 8-9.Figure : Event-Response Tables

Figure 8-9: Examples of system events and responses

8.2 : Event-Response Tables Unlike use cases, T he event-response table does not describe the user's goal in using the system or state why this event-response sequence provides value to the user. E vent-response tables are particularly appropriate for real- time control systems. Table 8-1 contains a sample event- response table that partially describes the behavior of an automobile's windshield wipersTable 8-1 N ote that the expected response depends not only on the event but also on the state the system is in at the time the event takes place.

Table 8-1: Event-Response Table for an Automobile Windshield-Wiper System IDEventSystem StateSystem Response 1.1set wiper control to low speed wiper offset wiper motor to low speed 1.2set wiper control to low speed wiper on high speed set wiper motor to low speed 1.3set wiper control to low speed wiper on intermittent set wiper motor to low speed 2.1set wiper control to high speed wiper offset wiper motor to high speed Table 8-1: Event-Response Table for an Automobile Windshield-Wiper System Sample from Table 8-1

8.2 : Event-Response Tables F or instance, events 4 and 5.1 in Table 8-1 result in slightly different behaviors depending on whether the wipers were on at the time the user set the wiper control to the intermittent setting.Table 8-1 A response might simply alter some internal system information (events 4 and 7.1 in the table) or it could result in an externally visible result (most other events). 4set wiper control to intermittent wiper off1.read wipe time interval setting 2.initialize wipe timer 5.1set wiper control to intermittent wiper on high speed 1.read wipe time interval setting 2.complete current wipe cycle 3.initialize wipe timer IDEventSystem StateSystem Response

7.1change intermittent wiper interval wiper on intermittent 1.read wipe time interval setting 2.initialize wipe timer 7.2change intermittent wiper interval wiper offno response 7.3change intermittent wiper interval wiper on high speed no response 7.4change intermittent wiper interval wiper on low speed no response IDEventSystem StateSystem Response Sample from Table 8-1

T he event-response table records information at the user-requirements level. If the table defines and labels every possible combination of event, state, and response (including exception conditions), the table can also serve as part of the functional requirements for that portion of the system. H owever, the analyst must supply additional functional and nonfunctional requirements in the SRS. F or example, how many cycles per minute does the wiper perform on the slow and fast wipe settings? Do the intermittent wipes operate at the slow or fast speed? 8.2 : Event-Response Tables

Is the intermittent setting continuously variable or does it have discrete settings? What are the minimum and maximum delay times between intermittent wipes? If you stop requirements specification at the user-requirements level, the developer has to track down this sort of information himself. Remember, the goal is to specify the requirements precisely enough that a developer knows what to build. 8.2 : Event-Response Tables Cont …

8.2 : Event-Response Tables N otice that the events listed in Table 8-1 are written at the essential level (describing the essence of the event), not at the implementation level (describing the specifics of the implementation).Table 8-1 Table 8-1 shows nothing about what the windshield wiper controls look like or how the user manipulates them.Table 8-1