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 specification61

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 ;
for YEAR_TYPE’SIZE use 2*BYTE ;
for MESSAGE_LENGTH’SIZE use 2*BYTE ; 65

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