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 systemMany 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 therequirementsCan 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 lightsWe can shift things around:E.g. Add some sensors to detect when people are waitingThis changes the nature of the problem to be solvedUniversity
View Full Document