Requirements Analysis and Design Engineering

Slides:



Advertisements
Similar presentations
Chapter 11 Describing Process Specifications and Structured Decisions
Advertisements

Software Requirements
Use Case & Use Case Diagram
CSC 123 Systems Analysis & Design
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
Requirement Analysis and Specification Mr. Manoj Kumar Kar.
Chapter 4.
SYSTEM ANALYSIS & DESIGN (DCT 2013)
Systems Analysis and Design 9th Edition
ITEC113 Algorithms and Programming Techniques
Objectives Detailed Object-Oriented Requirements Definitions
Software Engineering COMP 201
Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall Process Specifications and Structured Decisions Systems Analysis and Design, 8e Kendall.
Detailed Design Kenneth M. Anderson Lecture 21
Component-Level Design
Chapter 9 Describing Process Specifications and Structured Decisions
Chapter 9 Describing Process Specifications and Structured Decisions Systems Analysis and Design Kendall & Kendall Sixth Edition © 2005 Pearson Prentice.
Introduction to Software Engineering
Chapter 9 Describing Process Specifications and Structured Decisions
Software Requirements
Software Requirements
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Kendall & KendallCopyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 9 Kendall & Kendall Systems Analysis and Design, 9e Process Specifications.
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.
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 1 Program Design
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
Kendall & KendallCopyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 9 Kendall & Kendall Systems Analysis and Design, 9e Process Specifications.
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
PROCESS MODELING Chapter 8 - Process Modeling
Chapter 9 Describing Process Specifications and Structured Decisions
Real-Time Systems time dependent control oriented driven by events rather than data.
Logic Modeling Logic and timing are not represented on data flow diagrams or entity-relationship diagrams Processes contain logic - what happens under.
Chapter 11 Describing Process Specifications and Structured Decisions Systems Analysis and Design Kendall and Kendall Fifth Edition.
CHAPTER ONE Problem Solving and the Object- Oriented Paradigm.
CS 360 Lecture 6.  A model is a simplification of reality  We build models to better understand the system being developed.  We build models of complex.
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
Software Requirements Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn Lecture 4 & 5.
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.
Selection Control Structures. Simple Program Design, Fourth Edition Chapter 4 2 Objectives In this chapter you will be able to: Elaborate on the uses.
© 2011 Pearson Addison-Wesley. All rights reserved. Addison Wesley is an imprint of Stewart Venit ~ Elizabeth Drake Developing a Program.
Structured Analysis.
Problem Solving Techniques. Compiler n Is a computer program whose purpose is to take a description of a desired program coded in a programming language.
Controlling Execution Programming Right from the Start with Visual Basic.NET 1/e 8.
4. The process specification (プロセス仕様) You will learn: (次の内容を学び) The concept of process specification (プロセス 仕様の概念) Notations for process specification (プロセス.
Requirements Specification. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification”
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
The Software Development Process
1 Program Planning and Design Important stages before actual program is written.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Timing Constraints.
Week 3: Requirement Analysis & specification
Technical Methods for Specifying Requirements 1. When to Use Technical Methods  If the description of the requirement is too complex for natural language.
Systems Analysis and Design 8th Edition
Requirements Analysis
Object Oriented Analysis Unified Modeling Language By Mary Biddle.
Copyright © 2011 Pearson Education Process Specifications and Structured Decisions Systems Analysis and Design, 8e Kendall & Kendall Global Edition 9.
Fundamentals of Algorithms MCS - 2 Lecture # 3. Representation of Algorithms.
How Computers Solve Problems Computers also use Algorithms to solve problems, and change data into information Computers can only perform one simple step.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
1 Software Requirements Descriptions and specifications of a system.
Business Processes A business process describes a set of activities that are necessary to complete a response to a stimulus applied to an organization.
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
Technical Methods for Specifying Requirements
IT316 Software Requirement Engineering
Software Requirements
Software Engineering: A Practitioner’s Approach, 6/e Chapter 11 Component-Level Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Logic Modeling Logic and timing are not represented on data flow diagrams or entity-relationship diagrams Processes contain logic - what happens under.
Describing Process Specifications and Structured Decisions
Chapter 11 Describing Process Specifications and Structured Decisions
Presentation transcript:

Requirements Analysis and Design Engineering Southern Methodist University CSE 7313

Module 13 – Requirements Modeling

Agenda Structured English Pseudocode Specifying timing constraints

Structured English and Pseudocode

Structured English How to write Structured English: Elements keywords: if, then, else, for, ... some symbols: [ ] ( ) some standard functions: GET, SEND, COPY, ... Write English sentences interspersed with the above elements Difficulty: Balance between precision and understandability try to be precise, but generous about syntactic details.

Structured English and requirements specification Example: Consider the following statement (same as in example for decision tree)

Rewritten in Structured English

Informal use of High Level Languages (HLL) Basic idea relax strictness of syntactic rules add systematic commenting procedures Typical constructs required structured description of abstract data items (simple and compound types) external description of routines (procedures, functions) encapsulation (modules)

Informal use of High Level Languages (HLL) import / export of program objects (structures, data, routines, modules) abstract data type (data type with its associated operations) exception handling input and output characterization functional description (structured control constructs)

Informal use of High Level Languages (HLL) Advantages clear and unambiguous "ideal" for communication with programmers potential for automation of analysis and validation

Informal use of High Level Languages (HLL) Disadvantages more difficult to communicate with the user forms prejudice for design and implementation more difficult to keep requirements apart from design.

Structured language specifications A limited form of natural language may be used to express requirements This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of uniformity on a specification Often best supported using a forms-based approach 59

Form-based specifications Definition of the function or entity Description of inputs and where they come from Description of outputs and where they go to Indication of other entities required Pre and post conditions (if appropriate) The side effects (if any) 60

Form-based node specification 61

Interface specification Almost all software systems operate in an environment where there are other systems. They may be interfaces to these systems in different ways Three types of interface may have to be defined in a requirements specification Procedural interfaces. Sub-systems offer a range of services Data interfaces. Data structures are exchanged Representation interfaces. Specific data representation patterns may have to be used 62

Procedural interface example package Print_server is procedure Initialize (P: PRINTER) ; procedure Print (P: PRINTER ; F: PRINT_FILE ) ; procedure Display_print_queue (P: PRINTER ) ; procedure Cancel_print_job (P: PRINTER; N: PRINT_ID) ; procedure Switch_printer (P1, P2: PRINTER; N: PRINT_ID) ; end Print_server ; 63

Data interface example type MESSAGE is record Sender : SYSTEM_ID; Receiver : SYSTEM_ID; Dispatch_time : DATE; Length: MESSAGE_LENGTH ; Terminator: CHARACTER ; Message : TEXT; end record; type SYSTEM_ID is range 20_000..30_000 ; type YEAR_TYPE is range 1980..2080 ; type DATE is record Seconds: NATURAL ; Year: YEAR_TYPE ; end record ; type MESSAGE_LENGTH is range 0..10_000 ; type TEXT is array (MESSAGE_LENGTH) of CHARACTER ; 64

Size representation for SYSTEM_ID’SIZE use 2*BYTE ; for YEAR_TYPE’SIZE use 2*BYTE ; for MESSAGE_LENGTH’SIZE use 2*BYTE ; 65

Representation interface example type STATE is (Halted, Waiting, Ready, Running); for STATE use (Halted => 1, Waiting => 4, Ready => 16, Running => 256); 66

Pseudocode

Pseudocode A “quasi” programming language Combinations of Imperative sentences with a single verb and a single object A limited set, typically not more than 40-50, or action oriented verbs from which the sentences must be constructed Decisions represented with a formal IF-THEN-ELSE structure Iterative activities represented with DO-WHILE or FOR-NEXT structures

Algorithm for calculating deferred service revenue earned for any month Set SUM(x) = 0 FOR each customer X IF customer purchased paid support AND ((Current month) >= (2 months after ship date)) AND ((Current month) <= (14 months after ship date)) THEN Sum(X)=Sum(X) + (amount customer paid)/12

Summary Summarize your present understanding of the problem and all your findings in a concise, complete, well-organized and polished statement (processing narrative ) Important that this step is well done, since this first informal document will serve as anchor for your further work

Decision Trees and Decision Tables

Decision Tables Many requirements deal with combinations of inputs Different combinations lead to different behaviors and outputs Nested IFs are a particular problem to describe with natural language Hard for non-technical users to understand if everything has been covered

Decision Tables Must enumerate all of the combinations of inputs and describe each one explicitly in a table Five input system leads to 2**5 = 32 combinations if the only permissible input values are TRUE and FALSE Represent in a table of 5 rows and 32 columns (00000, 00001, 00010, 00011, etc)

Graphical decision tree Do nothing Did Remote Security Respond? yes Initiate Emergency message no Activate siren Is remote Notification Enabled? yes no yes Activate siren yes Has emergency sequence occurred? Is local Alarm Enabled? no no Do nothing Do nothing

Activity diagram New UML incarnation of the flow chart Visual representation that is easy to understand Same basis information as what you can get with other methods

Activity diagram Get req ref from doc [no more] Remove req from DB Get req text from doc [empty] [not empty] Remove req from doc

Timing Constraints

Timing Constraints Define response time requirements for software and/or the environment Many simple cases key press response time < 10 msec Dasarathy stated four types stimulus-response response-response stimulus-stimulus response-stimulus

Timing Constraints Stimulus is an action performed by the user or environment on the system Response is an action by the system on the user or environment Stimulus-response; constraint that the system must produce a response in accordance with a specified timing relationship to an earlier user stimulus to the system

Timing Constraints Examples “The system shall generate a dial tone within 15 seconds of a user taking the phone off the hook” (maximum constraint) “The system shall arm the door no sooner than 1 minute after the “alarm on” button is pressed” (minimum constraint) Stimulus and response do not need to be adjacent in time

Timing Constraints Response-response; used to specify a temporal relationship that must exist between two arbitrary system responses in the environment Examples “The system shall initiate the door closing operation within 20 seconds of locking the landing gear in the retracted state” (maximum)

Timing Constraints Examples “The system shall generate a “launch missile” command no sooner than 5 seconds after generating a “start battery warm up” command” (minimum)

Timing Constraints Stimulus-stimulus; enables us to specify expected behavior of a user or environment of a system in terms of maximum or minimum timing constraints between two stimuli Examples “Users must type their password within 15 seconds of typing their identification or they will be denied access to the database” (maximum)

Timing Constraints Examples “Pilots must not press the “launch weapon” button sooner than 10 seconds after pressing the “fire ready” button” (minimum)

Timing Constraints Response-stimulus; enables us to specify a temporal relationship that must exist between a system response and a subsequent user stimulus Examples “The user must dial the complete phone number within 1 minute of hearing the dial tone” (maximum)

Timing Constraints Examples “The user may not make a menu selection sooner than 5 seconds after completion of the menu display” (minimum) First two types define timing requirements on the system being specified - function must be implemented in such a way as to be fast enough (or slow enough) to meet the timing requirement

Timing Constraints Later two constraints imply the system must be able to detect a violation of timing constraints by the user or environment Do not imply the software must be rapid or slow but there must be additional software detect inappropriate timed user stimuli generate alternative response to the user warning error message

End of module 13