1. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 1 The SCR/A7E Specification Technique

2. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 2 Reference Material On This Topic Specifying Software Requirements for Complex Systems: New Techniques and Their Application by K. Heninger Available on CS340 Web site

3. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 3 The SCR/A-7E Technique  Developed At Naval Research Laboratory (NRL)  Part Of Software Cost Reduction (SCR) Project  Extremely Well-Known Work  Very Successful Approach  Combination Of: Restricted Natural Language Some Borrowed Formalisms Simple, New Formalisms  New Types Of Table  New Natural Language Documentation Style

4. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 4 The SCR/A-7E Technique  Technique Evaluated On Flight-Control Software For A-7E Aircraft  Old Computer Hardware Technology  Very Tight Memory Status  One Volume Specification  Several Shelves Of Documents Eliminated  Accurate Reference Provided

5. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 5 Objectives Of A Specification (From A7E Work)  Specify External Behavior Only: Difficult To Achieve  Specify Constraints On The Implementation: Hardware And Hardware Interfaces, Etc.  Be Easy To Change: Specifications Always Change  Serve As A Reference Tool: There Is No Point In Writing It Unless Its Useful  Record Things Likely To Change: Guess At What Might Happen In The Future  Characterize Acceptable Responses To Undesired Events Make Sure Things Like Hardware Failures And User Errors Are Dealt With

6. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 6 Concepts From The A-7E Technique  Modes And Mode Tables: Program Operating State Structure The Specification Defined By Conditions  Conditions: Add Precision To Decisions Define States Of Interest  Symbolic Constants And Associated Glossary: Name For Value That Might Change Centralize Definitions

7. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 7 Concepts From The A-7E Technique  Text Macros And Associated Glossary: Help Clarify Natural Language Centralize Definitions  Events: Things Requiring Software Action Triggering Actions  Condition Tables: Specifying What Is To Be Done When  Event Tables: Specifying Actions Associated With Events

8. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 8 Modes  System State Consisting Of Collection Of Conditions  Group State Information Into Sets Whose Meanings Differ  Typical Uses Might Be: Input Modes Display Modes  Start Building The Specification By Defining: The System’s Modes The Mode Transition Table

9. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 9 Modes  Stylized Visual Delimiters Used When Term Appears In Text: Any Delimiter Will Do A-7E Used Asterisks  Definitions Collected Into Table And Glossary  Hypothetical Example Of A Mode Definition: *NormalOperation*= (!IRsensor!=$Clear$) AND (!DownLinkOperational!) AND (not !MotorsHot!)

10. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 10 Conditions  Predicate On System State  Written As A Boolean Expression (As Opposed To Another Notation)  Purpose Is Precise Statement Of System State  Examples: !LeftMotorTemp! <= $TempLimit$ (!MotorStatus! = $On$) AND (!DownLinkStatus! = $Off$)  More Useful If Combined With Text Macro Definition %MotorSafe% = !LeftMotorTemp! <= $TempLimit$ Amounts To Named Condition—Definition In Glossary  Can Be Used In Text To Define State

11. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 11 Symbolic Constants  Associates A Name With A Value What is this like and why is it a good idea?  Used For Any Value Likely To Be Changed: Hardware Parameters Like Port Numbers Software Parameters Like Sizes  Definitions Collected Into Definitions Glossary - Separate Section In Document

12. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 12 Symbolic Constants  Stylized Visual Delimiters Used When Term Appears In Text: Any Delimiter Will Do A-7E Used Dollar Signs Modern Systems Would Use Fonts, Colors, Hypertext, Etc.  Examples: $WindowHeight$100 $MaxNumberChars$256 $DefaultErrorMessage$"Error In User Input"

13. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 13 Model-Based Specification  This Looks Lot Like Some Kind Of Programming  Hey, I thought We Were Talking About Specification?  What Overall Form Should A Specification Take?  There Are Many Ideas, But One Important One Is A Model  Literally, A Very High-Level “Program”  If We Have A Program, Can’t We Compile It?

14. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 14 Text Macros  Literally A Definition Of Meaning  Used For Any Term Likely To Be Misunderstood: Important Terms Complicated Terms  Stylized Visual Delimiters Used When Term Appears In Text: Any Delimiter Will Do A-7E Used Exclamation Points

15. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 15 Text Macros  Definitions Collected Into Glossary  Example Text In Specification:  !ground range! from !impact point! of last release to !impact point! of present...  Example Glossary Entries:  !ground range!horizontal distance to some point  !impact point!the point on the ground that would be hit by a weapon released now, in any weapon delivery mode...

16. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 16 Events  An Event Occurs When A Condition Changes  Change Might Be To True Or False  A-7E Notations: @T(Condition) @F(Condition)  Easy Way To Defined Complicated Circumstances  Examples: @F(%MotorSafe%) Literal meaning is ‘‘When the temperature of the left motor changes so as to exceed the preset safe limit.’’  Goal Is To Define What Causes Things To Happen  Can Be Restricted: @T(%objectseenbyIR%) WHEN %turning%  Events Will Be Linked To Actions Later

17. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 17 Condition Tables  Specifies Output, In Specific Mode(s), For Specific Condition  Rows Labelled With Modes  Table Entries Are Conditions  Value Detailed At Bottom Of Column  Row Exclusivity And Completeness Requirements Aids Correctness  Table Outline:

18. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 18 Event Tables  Define Action When Event Occurs In Specific Mode  Rows Labelled With Modes  Table Entries Are Events  Action Detailed At Bottom Of Column  Table Outline:

19. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 19 Undesired Events List  What Happens When ‘‘Normal’’ Processing Cannot Continue  Undesired Events Typically: A Hardware Device Stops Working A Hardware Device Starts Giving Bad Data A Software Subsystem Fails, E.g. Divides By Zero A Data Link Receives Unexpectedly Noisy Data User Input Request Times Out Etc.

20. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 20 Undesired Events List  Examples: Memory Checksum Incorrect Radar Stops Working Sensor Data Unreasonable  How Can They Be Determined: Systematically Examine System For Things That Might Go Wrong Ask System Designer For Each Undesired Event, Document Required Response Ask System User/Customer - Software Engineer Not Qualified To Define

21. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 21 Characterizing Change  Think Carefully About What Might Change: Any Aspect Of The Operating Environment:  Input And Output Hardware Devices  Device Connections  Device Performance  Non-Functional Requirements Such As Implementation Language Most Aspects Of Functionality:  User Interface Details  Different Or Enhanced User Functionality  Internal Functionality

22. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 22 Characterizing Change  How Can Changes Be Anticipated: Check Existing System In The Past If Possible Enquire About Similar Systems If Available Interview Users!  Review Carefully ALL Aspects Of Functional And Non-Functional Specification  Assume That Each Will Change Unless You Are Certain They Will Not  Then Check Again

23. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 23 Describing Hardware Interfaces  Very Important For Embedded Systems  Content Organized By I/O Data Item  Symbolic Names Used Extensively Again: Stylized Visual Delimiters Easily Changed, Precisely Defined Permits Separation Of Aspects That Might Change From Rest Of Specification

24. University of Virginia SCR/A7E Specification Technique (CS340 John Knight 2005) 24 Describing Hardware Interfaces  Value Description Templates Used For Information Capture: Systematic Text Layout For All Such Items Same General Representation For All  Simple (Incomplete) Example: Input data itemAir temperature Symbolic value/air_temp/ Hardware connectionPort E, pin 4 Value encoding0C - 0, 100C - 255 Description: Air temperature measured at camera position and represented internally as an 8-bit quantity.