New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Intro Software Eng

by: Ashleigh Dare

Intro Software Eng ECS 160

Ashleigh Dare
GPA 3.75

Premkumar Devanbu

Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Premkumar Devanbu
Class Notes
25 ?




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.

Similar to ECS 160 at UCD

Popular in Engineering Computer Science


Reviews for Intro Software Eng


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

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


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"

Janice Dongeun University of Washington

"I used the money I made selling my notes & study guides to pay for spring break in Olympia, Washington...which was Sweet!"

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.