Specifying Software Requirements for Complex System:

1. Specifying Software Requirements for Complex System: New Techniques and Their Application Guanghui Weng

2. About this paper • Author: Kathryn L. Heninger • Published in IEEE Transactions on software Engineering VOL. SE-6 • January 1980

3. A-7 aircraft • Model Type: • Attack Bomber • Tactical Fighter • Trainer • First flew in 1965 • Flew in 1990 Gulf War • Retired in 1993 • One of the most successful military aircraft • greatest bargain in the weapon system

4. A-7 aircraft continued • New Techs used: • Head-up display • Central navigation-weapon delivery software system • Many other avionics innovations • Capability • Heavy weapon loads (up to 20,000 pounds) • Low maintenance requirements • Superior weapon delivery accuracy • Long range ( up to 4,250 nautical miles) • Low loss rate in combat (0.04%) • Very low accident rate

5. Abstract • Purpose: • Create a model that make the specs • Precise • Concise • Unambiguous • Complex real-time software system • Example: • Navy’s A-7 aircraft operation software

6. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion and Conclusion

7. Introduction Problem: Software is difficult to understand, change and maintain New techniques: Modularity Information hiding Abstract Interface Formal spec Cooperating sequential processes Process synchronization routines Resource monitors Naval Research Lab and Naval Weapons Center tried to use above techs to redesign and rebuilt the A-7 aircraft operation software

8. Why redesign? Identical to the existing program Old program is hard to update No spec! Very common in the real world Barclays

9. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion and Conclusion

10. A-7 Program Characteristics Tight memory(16K) Time constrains 12,000 assembler instructions Part of the Navigation/Weapon Delivery System Inputs Sensors Cockpits Panel It controls display devices and position sensors 22 devices are connected to the computer

11. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion and Conclusion

12. Requirements Document Objectives Specify external behavior only Without implying implementation Specify constraints on the implementation Be easy to change Serve as a reference tool Record forethought about the life cycle of the system Characterize acceptable responses to undesired events

13. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion and Conclusion

14. Requirements Document Design Principles State questions before trying to answer them. Timing constraints? Accuracy constraints? Changes expected? Separate concerns Divide and conquer Be as formal as possible

15. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion Conclusion

16. Organization by data Item Data item: for each input or output that changes value independently Input Data Items: Barometric altitude Radar-measured distance to a ground point Inertial platform ready signal Output Data Items: Coordinates Rader antenna steering commands Computer failed lights

17. Data Item Designed a form to be completed for each data item Start with the following question How to read or write these data? How to represent the value using bit? Valid or not?

18. Symbolic Names Two kinds of info about data items Essential characteristics shared by similar device Barometric altitude Arbitrary details changes with device Resolution Representation Accuracy Timing

19. Symbolic names for data item and value Essential info must be expressed without referencing the arbitrary details Essential info is given a mnemonic names with different brackets /input-data-item/ //output-data-item/ $nonnumeric-value$ Fixed set of possible values ON/OFF

20. Templates for value description • Blanks to be completed for specific data item • Advantage: • Easier to describe • Consistent • Apply to the same standard • Example: • Angle (?) is measured from line (?) to line (?) in the (?) direction, looking (?).

21. Input data independent of software use • Refrain mentioning how the data is used by the software. • Avoid making any assumptions about the software function • Define numerical values in term of what they measure • /RADALT/ • Radar altimeter

22. Example of Input Data Item • Input Data Item: IMS Mode Switch • Acronym: /IMSMODE/ • Hardware: Inertial Measurement Set • Description: /IMSMODE/ indicates the position of a six-position rotary switch on the IMS control panel Switch nomenclature: OFF; GND ALIGN; NORM; INERTIAL; MAG SL; GRID • Characteristics of Values • Value Encoding: $Offnone$ (00000) $Gndal$ (10000) $Norm$ (01000) $Iner$ (00100) $Grid$ (00010) $Magsl$ (00001) • Instruction Sequence: READ 24 (Channel 0) • Data Representation: Bits 3-7 • Comments: /IMSMODE/ = $Offnone$ when the switch is between two positions

23. Output Data Items Described in Terms of Effects on External Hardware //STEERAZ// & //STEEREL// Communicate the direction to point the antenna of the radar //FPANGL// Determine the climb or dive angle Avoid giving any meaning to an output value that is not a characteristic of the hardware

24. Example of Output Data Item Description • Output Data Item: Steering Error • Acronym: //STERROR// • Hardware: Attitude Direction Indicator (ADI) • Description: //STEEROR// controls the position of the vertical needle on the ADI. A positive value moves the pointer to the right when looking at the display. A value of zero centers the needle. • Characteristics of Values • Unit: Degrees • Range: -2.5 to +2.5 • Accuracy: .1 • Resolution: .00122 • Instruction Sequence: WRITE 229 (Channel 7) Test Carry Bit = 0 for request acknowledged if not, restart • Data Representation: 11-bit two’s complement number, bit 0 and bits 3-12 scale = 512/1.25=409.6 offset =0 output value = scale * (stand value + offset) () not used ( ) 0 0 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 • Timing Characteristics: Digital to DC voltage conversion. • Comments: The pointer hits a mechanical stop at 2.5 degrees

25. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion and Conclusion

26. Organization by Functions Each function determines the values for one or more output data items Each output data item is given values by exactly one functions Every function can be described in terms of externally visible effects. Not fit all the project Most output data items are used for only as small set of purposes

27. Function type Demand function Request by the occurrence of some event Computer failed light Periodic function Performed repeatedly without request If a periodic function need not be performed all the time, it should be stopped by specific events Maximum delay can be tolerated between request and action - required repetition rates.

28. Output values as functions of conditions and events Express requirements by giving output values as functions of aircraft operating conditions Condition is aspect of the system for a measurable period of time /IMSMODE/ = $Gndal$ is a condition that is T when the switch is set to the GND ALIGN position Event occurs when condition changes T to F or F to T //LATGT70// should change value when the aircraft crosses 70 degree latitude Events start and stop periodic functions and trigger demand functions how the program detects this event is left to the implementation

29. Text Macros Bracketed in exclamation points defined in an alphabetical dictionary Abbreviations for compound conditions that are frequently used or very detailed Only one place in the dictionary need to be changed if criteria change Example: !Desig! Condition that is T when the pilot perform a sequence of actions that designates a target to computer

30. Events @T(condition 1) denote condition 1 becoming true @T(!ground track angle! < 30) @F(condition 2) denote condition 2 becoming false @T(condition 3) WHEN (condition 4) An event only occurs if condition 3 changes when condition 4 is true @T(condition 3) WHEN (condition 4)

31. Mode Organize conditions into groups Mnemonic name enclosed in asterisks Advantage: Keep the function descriptions simple If something goes wrong during flight, remember the mode instead of conditions Example: *DIG*: Doppler-Inertial-Gyrocompassing

32. Mode condition table Example • Navigation mode condition table • X indicates that info is never appropriate for that mode

33. Special tables for precision and completeness • Condition table: • Define some aspect of an output value that is determined by an active mode and a condition that occurs within that mode • Periodic functions • Mutual exclusive of each row • Exactly one row should be T • Event table: • When demand functions should be perform • Periodic functions start and stop point • Each row in an event table corresponds to a group of mode

34. Example of a conditional table • Magnetic heading (//MAGHDGH//) output value

35. Example of an event table • When AUTOCAL Light Switched on/off

36. Full demand function example • Demand Function Name: Change scale factor • Mode in which function required: • *Lautocal* *Sautocal* *Landaln* *SINSaln* *HUDaln*, *Airaln* • Output data item: //IMSSCAL// • Function Request and Output Description: • Event Table: When the scale factor is changed

37. Completed periodic function form • Periodic function name: update flight path marker coordinates • Modes in which function required: • *DIG* *DI* *I* *Mag sl* *Grid* *IMS fail* • Output data item: //FPMAZ//, //FPMEL// • Initiation and termination events: • Start: @T(//HUDVEL// = $On$) • Stop: @T(//HUDVEL// = $Off$) • Output description: • The flight Path marker (FPM) symbol on the head-up display shows the direction of the aircraft velocity vector. …… Condition table: Coordinates of the Flight Path Marker

38. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion and Conclusion

39. List of undesired event • Classification scheme • Resource Failure • Temporary • Permanent • Incorrect input data • Detected by examining input only • Detected by comparison with internal data • Detected by user realizing he made a mistake • Detected by user from incorrect output • Incorrect internal data • Detected by internal inconsistency • Detected by comparison with input data • Detected by user from incorrect output

40. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion and Conclusion

41. Techs for characterizing types of changes Discover possible changes Make a feasible changes list Example: Assignment of devices to channels The rate of symbol movement on the display in response to joystick displacement New sensors may be added More weapons Self test might be required in the air Cease lower priority functions to free resources for higher

42. Outline Introduction A-7 Program Characteristics Objectives Design Principles Techs for Describing Hardware Interface Describing Software Functions Specifying Undesired Events Characterizing Types of Change Discussion and Conclusion

43. Discussion and Conclusion • These techs are not limited to this project • These techs helps: • Obtaining information • Controlling its complexity • Avoiding with implementation details • Plan for project systematically

44. Q & A