CMSC 345 Fall 2000 Requirements Expression

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

S1S1 S2S2 X (a) S1S1 S3S3 S2S (b)

(Null) Requested On waiting list Confirmed Used Canceled Archived

S1S1 S2S2 condition actions

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

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

Event1Event2Event3 Mode1Action1Action2X Mode2XAction3, Action4 0 Mode30Action5Action6

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

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

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