1. CMSC 345 Fall 2000 Requirements Expression

2. How To Express Requirements Often performed best by working top- down Express general attributes of system at very highest level Express more specific attributes at subsequent levels

3. Expressing Requirements in Natural Language All stakeholders may not interpret meaning in same way – imprecise and ambiguous Requirements not always separable by system element – NL confuses tracing back from system characteristic to defining/affecting requirement(s) Need more rigorous and controlled formal notation – accompanying tools can check specification for completeness and consistency, and ease tracing and management

4. Static Descriptions Lists system entities or objects Lists their attributes, including functions performed by or to them Lists relationships with each other Does not describe how relationships change with time - thus static

5. Indirect Reference Define mathematical problem for system to solve No guarantee that solution exists Example: series of k equations in n variables

6. Recurrence Relations Specify initial condition Specify transformation from one condition to the next May be stated as recursive function or procedure Examples: Fibonacci numbers, artificial life

7. Axiomatic Definition Specify basic system properties (axioms) System behavior generates new properties (theorems) Requires complete and consistent set of axioms Examples: expert systems, abstract data types

8. Language Appropriate for systems that process sets of data strings Express acceptable strings as the syntax rules of a language Checking completeness and consistency can be automated (parsing) Examples: compilers, text processors

9. Data Abstraction, 1 Focus on data instead of functions Describe what data are for as well as their names and contents (forms) Data Dictionary: Categorize data and group like elements together Organized according to relationships and shared characteristics

10. Data Abstraction, 2 Explain permissible actions to different kinds of data States data can be in Operations to establish new states Probes to report information about a state

11. Student Student number Credit-hours Compute tuition In-state student Student number In-state rate Compute tuition Out-of-state student Student number Out-of-state rate Compute tuition

12. Dynamic Descriptions Describe how system reacts over time – thus dynamic - to events that change system behavior System considered to be in particular state until some stimulus causes change in state Try to describe all possible states and stimuli

13. Decision Tables Describe system as set of possible conditions satisfied at any given time Rules for reacting to stimuli when certain sets of those conditions are met Actions to be taken as result Tables may be very large: n conditions implies 2 n combinations of conditions Can eliminate redundant rules (covered by other rules), check that every possible set of conditions results in an action, and examine for consistency – detect and remove conflicting cases

14. R 1R2R3R4R5 High Exam ScoresTFFFF High Grades-TFFF Outside Activities--TFF Good Recommendations ---TF Send RejectionXXX Send AcceptanceXX

15. Transition Diagrams View system as set of states where system reacts to possible events Event may cause change to another state, or remaining in state but producing output Depict as diagram showing movement from one state to another Circle for each state in system For each input, directed arrow shows transition (may be to same state)

16. S1S1 S2S2 X (a) S1S1 S3S3 S2S2 1 0 0 1 0 1 (b)

17. (Null) Requested On waiting list Confirmed Used Canceled Archived

18. S1S1 S2S2 condition actions

19. NullRequested customer pays increment room count room request none ConfirmedOn waiting listUsedCanceledArchived room available decrement room count no room available put on list customer gives up remove from list customer cancels increment room count room available decrement room count customer moves in none

20. Event Tables Tabular form for states and transitions Treats states as “modes” Indicates system action responding to each event when in each mode Some configurations may not be possible

21. Event1Event2Event3 Mode1Action1Action2X Mode2XAction3, Action4 0 Mode30Action5Action6

22. Object Oriented Specification Sometimes more appropriate than a functional one. Focuses on the entities rather than the input/output transformations Objects and method descriptions are closely related with application domain

23. Data Flow Diagrams Consider the system as a transformer of data Show data that flow into the system, how they are transformed and how they leave the system Emphasis on flow of the data, not the flow of control

24. Physical exam Patient records Accounting records Physician Patient Accounting Medical experience and knowledge Diagnosis Symptoms Medication Bill List of tests, services performed Diagnosis Patient history Tests and services Prices