Intro Software Eng
Intro Software Eng ECS 160
Popular in Course
Popular in Engineering Computer Science
This 14 page Class Notes was uploaded by Ashleigh Dare on Tuesday September 8, 2015. The Class Notes belongs to ECS 160 at University of California - Davis taught by Premkumar Devanbu in Fall. Since its upload, it has received 178 views. For similar materials see /class/187711/ecs-160-university-of-california-davis in Engineering Computer Science at University of California - Davis.
Reviews for Intro Software Eng
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 09/08/15
ECS 160 Devanbu L4 Requirements Formal Approach 0 Motivation why get Requirements right 0 The AYE Case Study and why 0 Lessons How to royally screw up on requirements 0 Getting it Right Approach 2 AYE Method today Reference HENNINGER KATHRYN L Specifying Software Requirements for Complex Systems New Techniques and their applications IEEE Transactions on Software Engineering January 1980 Vol SE6 No 1 Typeset by FoiITEX P Devanbu 1 ECS 160 Devanbu L4 Why After Shipping Cost of Fixing Testing Implementation Design Reqmnts When Fault Found Typeset by FoiITEX P Devanbu ECS 160 Devanbu L4 The A7E Document Context 0 Late 1970 s 120000 Assembly instructions IBM Minicomputer 16K bytes of main memory Second implementation Guess what lifecycle Embedded Control System 22 Devices connected safety critical with real time deadlines Input sensors cockpit switches keyboard Output heads up disp targeting Steering Cuesetc Two types of functions periodic and eventresponse Analogy to biological systems Re design and rebuilt of existing system Functionally identical to old program Must pass same tests have same footprint etc Why study this One of the earliest attempts to identify requirements analysis as a separate activity and study it The results are widely acknowledged to be very successful Good documentation of goals methodology results and main lessons learned A simple introduction to formal approaches Question Why waterfall Here Typeset by FoilTEX P Devanbu 3 ECS 160 Devanbu L4 Reminder What was in the document oRequirements document help communication between stakeholders Depending on which process waterfall prototype etc o The document contains Functional Requirements The system must control targeting on the main gun using the pilot s helmet NonFunctional Requirements The system must respond to pilot s command in under 200 ms PlatformArchitecture Requirements The system must run on PowerPC 750 and be CORBA compatible Typeset by FoilTEX P Devanbu 4 ECS 160 Devanbu L4 How to write a bad requirements doc 1 Say different things in different places eguse same words with different meanings 2 Make the document hard to change eg when speed is between 0 and 5 knots all over the document 3 Leave important non direct functional details out eg What happens when the gun jams 4 Leave out important external non functional requirements like cost performance etc characteristics of environment engines guns control surfaces etc 5 Talk about internal details of the system Internal architecture not What it does How about C ORBA compatibility 6 Don t maintain it as lifecycle proceeds eg developers fix a particular feature interaction that was noticed but don t modify document 7 Don t get all the right people involved Typeset by FoilTEX P Devanbu 5 ECS 160 Devanbu L4 Consistency amp Maintainability Techniques 0 Use the same terminology everywhere this promotes understandability consistency and makes the document easy to read write and check Data Items inputdataitem outputdata item stringvalue Each one described using a standard document template Events Described as changes in values using conditions TFuel g WinCap ampamp Targeting quotengagedquot F 0 Use Text Macros this makes the document easier to maintain Example lStaII Air Speed g 85 knots Typeset by FoilTEX P Devanbu 6 ECS 160 Devanbu L4 Dealing with Complexity 0 Too many variables 0 Too many functions from inputs to outputs 0 Too may internal states Solution Simplify using Modes Use significant mission states cruising terrainfollowing engaged stealth etc to organize requirements 0 Modes defined in terms of Mode Condition Tables which modes are active in which states of input variable values 0 Recognized two types of functions periodic and eventdriven o Computation of periodic homeostasis functions defined in Function Condition Tables 0 Responses to events defined in Event Condition Tables Typeset by FoilTEX P Devanbu 7 ECS 160 Devanbu L4 Completeness Techniques Different types of Tables were used Mode Condition Tables MODE Terrain Autopilot Altitude Latitude Follow Manual OFF OFF X X Cruise OFF ON gt 100m 4 7o0 Terrain ON x 4 100m 4 70U Following The above says row 1 In manual mode the terrain follow and auto pilot switches are off and it doesn t matter where or how high the plane is 2 In cruise mode the terrain follow switch is off and the altitude is over 100m and the latitude is less than 70 degrees etc Note 0 Some entries may have don39t carequot conditions 0 Can help spot inconsistencies and errors 0 Can help find missing data conditions that are applicable to a mode Typeset by FoiITEX P Devanbu 8 ECS 160 Devanbu L4 Function Condition Table Output Value Condition Tables Specifies an output value for a given function in different mode conditions Terrain Atitud j 100 Atitud gt 100 Following MODE2 Condition 11 Condition 12 MODE3 Condition 21 Condition 22 MODE4 Condition 31 Condition 32 CompDisp Value 1 Value 2 Value 3 0 Bottom row indicates different ways the function computes the output 0 Each column is a mutually exclusive condition for which the function works the same way 0 Each row is a different Major mode Only one mode is active at a time Typeset by FoiITEX P Devanbu ECS 160 Devanbu L4 Event Condition Table Responses to events Specifies state changes or other actions responding to input events Assume AtHigh lt gt Altitude j 100m Terrain TAItHigh FAItHigh Following MODE2 Condition 11 Condition 21 MODE3 Condition 21 Condition 22 MODE4 Condition 31 Condition 32 Action buzzer 2 off buzzer 2 on 0 Bottom row indicates the responses to events in various modes 0 Each column is a mutually exclusive condition which causes an identical response 0 Each row is a different Major mode only one mode active at any time Typeset by FoiITEX P Devanbu ECS 160 Devanbu L4 Why did this work with the A7E 0 System of moderate complexity 22 inputoutput variables a small number of modes 0 Previous system and expertise available This was the second system of it39s kind Customers were experts in the domain 0 Market demand for highquality system Demand for Quality and the willingness to pay and willingess to wait 0 Support for a formal requirements document Typeset by FoilTEX P Devanbu 11 ECS 160 Devanbu L4 Applicability o The terminologymacro stuff is pretty widely applicable 0 Applicable to Small Control Systems Medical Devices public transit vehicles wellestablished highreliability wellunderstood customers are experts moderately complex slowmoving markets 0 Less applicable to Space Shuttle Too many variables Chess Player Too many States Telephone Switches not wellunderstood too complex Video Games market too fastmoving Typeset by FoilTEX P Devanbu 12 ECS 160 Devanbu L4 Questions So How about Video Game Simulation of AYE Radiation Therapy Equipment A Home Burglar Alarm A Home Robot Tax Computation Software Next cass Use Case Method and using them with Rapid prototypes a very different approach Typeset by FoiITEX P Devanbu 13 ECS 160 Devanbu L4 Burglar Alarm example Variables input intruder cardreader outputAarm buzzer door 0 Modes BurglarAlarm BA is On or OFF If BA is On and someone is at the door for more that 5 seconds without putting a card in sound the alarm otherwise open the door to let them in and sound the buzzer while the door is open 0 If BA is On and someone opens the door from the inside then sound the alarm and the buzzer Typeset by FoilTEX P Devanbu 14