Presentation is loading. Please wait.

Presentation is loading. Please wait.

Requirements Analysis and Design Engineering Southern Methodist University CSE 7313.

Similar presentations


Presentation on theme: "Requirements Analysis and Design Engineering Southern Methodist University CSE 7313."— Presentation transcript:

1

2 Requirements Analysis and Design Engineering Southern Methodist University CSE 7313

3 Module 13 – Requirements Modeling

4 Agenda Structured English Pseudocode Specifying timing constraints

5 Structured English and Pseudocode

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

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

8 Rewritten in Structured English

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

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

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

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

13 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

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

15 Form-based node specification

16 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

17 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 ;

18 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 ;

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

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

21 Pseudocode

22 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

23 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

24 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

25 Decision Trees and Decision Tables

26 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

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

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

29 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

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

31 Timing Constraints

32 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

33 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

34 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

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

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

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

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

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

40 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

41 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

42 End of module 13


Download ppt "Requirements Analysis and Design Engineering Southern Methodist University CSE 7313."

Similar presentations


Ads by Google