Presentation is loading. Please wait.

Presentation is loading. Please wait.

Requirements Analysis and Design Engineering

Similar presentations

Presentation on theme: "Requirements Analysis and Design Engineering"— Presentation transcript:

1 Requirements Analysis and Design Engineering
Southern Methodist University CSE 7313

2 Module 13 – Requirements Modeling

3 Agenda Structured English Pseudocode Specifying timing constraints

4 Structured English and Pseudocode

5 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.

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

7 Rewritten in Structured English

8 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)

9 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)

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

11 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.

12 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

13 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

14 Form-based node specification

15 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

16 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

17 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 ; type YEAR_TYPE is range ; 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

18 Size representation for SYSTEM_ID’SIZE use 2*BYTE ;

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

20 Pseudocode

21 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

22 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

23 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

24 Decision Trees and Decision Tables

25 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

26 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)

27 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

28 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

29 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

30 Timing Constraints

31 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

32 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

33 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

34 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)

35 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)

36 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)

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

38 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)

39 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

40 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

41 End of module 13

Download ppt "Requirements Analysis and Design Engineering"

Similar presentations

Ads by Google