DOC PREVIEW
Toronto CSC 340 - Lecture 2 Notes

This preview shows page 1 out of 3 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 3 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 3 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 2:What are Requirements? Two basic principles of requirements engineering: Separate the problem from the solution Problems and solutions intertwine with one another Describing problems: Application Domains vs. Machine Domains Verification vs. Validation Systems Engineering Systems vs. softwareUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Separate the problem from the solutionProblemStatementImplementationStatementSystemCorrespondenceCorrectnessValidationVerification A separate problemdescription is useful: Most obvious problem mightnot the right one to solve Problem statement can bediscussed with stakeholders Problem statement can beused to evaluate designchoices Problem statement is asource of good test cases Still need to check: Solution correctly solves thestated problem Problem statementcorresponds to the needs ofthe stakeholdersProblemSituationUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3ProblemSituationBut design changes the world…abstractmodel of worldimplementationstatementproblemstatementchangeSystemUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Intertwining of problems and solutionsImplementation DependenceDependentIndependentGeneralDetailedLevelofDetailImplementationStatementProblemStatementPath of exploration2University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Some observations about RE RE is not necessarily a sequential process: Don’t have to write the problem statement before the solution statement (Re-)writing a problem statement can be useful at any stage of development RE activities continue throughout the development process The problem statement will be imperfect RE models are approximations of the world will contain inaccuracies and inconsistencies will omit some information. analysis should reduce the risk that these will cause serious problems… Perfecting a specification may not be cost-effective Requirements analysis has a cost For different projects, the cost-benefit balance will be different Problem statement should never be treated as fixed Change is inevitable, and therefore must be planned for There should be a way of incorporating changes periodicallyUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6A problem to describe… E.g. “prevent unauthorized access to CSG machines”encryption algorithmsstudentsintruderspasswordallocationprocessstickies withpasswords onT-cardssysadminssigned formspasswordsusernamestyping at keyboardpassword filesmemory managementcache contentssecure socketsthings the machinecannot observethings private to the machinesharedthingsUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Application DomainMachine DomainD - domain propertiesR - requirementsC - computersP - programsWhat are requirements? Domain Properties: things in the application domain that are true whether or not we ever build theproposed system Requirements: things in the application domain that we wish to be made true by delivering theproposed systemMany of which will involve phenomena the machine has no access to A Specification: is a description of the behaviours that the program must have in order to meet therequirementsCan only be written in terms of shared phenomena!University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8Fitness for purpose? Two correctness (verification) criteria: The Program running on a particular Computer satisfies the Specification The Specification, in the context of the given domain properties, satisfiesthe requirements Two completeness (validation) criteria: We discovered all the important requirements We discovered all the relevant domain properties Example: Requirement R: “Reverse thrust shall only be enabled when the aircraft is moving on the runway” Domain Properties D: Wheel pulses on if and only if wheels turning Wheels turning if and only if moving on runway Specification S: Reverse thrust enabled if and only if wheel pulses on Verification: S, D R3University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9Another Example Requirement R: “The database shall only be accessible by authorized personnel” Domain Properties D: Authorized personnel have passwords Passwords are never shared with non-authorized personnel Specification S: Access to the database shall only be granted after the user types anauthorized password S + D entail R But what if the domain assumptions are wrong?University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10But we can also move the boundaries… E.g. Elevator control system:people waitingpeople in the elevatorpeople wanting to go toa particular floor Elevator motorsElevator call buttonsFloor request buttonsCurrent floor indicatorsScheduling algorithmSafety rulesMotor on/offDoor open/closeControl programbutton lightsWe can shift things around:E.g. Add some sensors to detect when people are waitingThis changes the nature of the problem to be solvedUniversity


View Full Document

Toronto CSC 340 - Lecture 2 Notes

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download Lecture 2 Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 2 Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 2 Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?