University of Toronto University of Toronto Department of Computer Science Importance of RE background Lecture 2 Basics of RE Last Last Week Week INTRO INTRO Syllabus Syllabus Course Course Goals Goals Literature Literature on on RE RE Problems Increased reliance on software E g cars dishwashers cell phones web services Software now the biggest cost element for mission critical systems E g Boeing 777 Wastage on failed projects This This Week Week E g 1997 GAO report 145 billion over 6 years on software that was never delivered Basics Basics of of RE RE RE RE inin the the lifecycle lifecycle Types Types of of problem problem domain domain High consequences of failure E g Ariane 5 500 million payload E g Intel Pentium bug 475 million Processes Processes methods methods techniques techniques AA little little systems systems theory theory E g Boeing 777 40 of software budget spent on testing Re work from defect removal E g Motorola 60 80 of software budget was spent on re work Changing Requirements E g California DMV system 2000 2003 Steve Easterbrook 1 University of Toronto Key factors Certification costs Next Next Week Week Elicitation Elicitation I I Traditional Traditional approaches approaches Interviews Interviews Questionnaires Questionnaires Prototyping Prototyping 2000 2003 Steve Easterbrook No Silver Bullet Brooks A condition or capability that must be met or possessed by a system or system component to satisfy a contract standard specification or other formally imposed document The set of all requirements forms the basis for subsequent development of the system or system component IEEE Std But Early modeling and analysis is important Early modeling and analysis is not enough to to to to to communicate requirements to everyone seek agreement from all stakeholders understand the context for the system understand the context for the development process keep up to date as the requirements evolve 2000 2003 Steve Easterbrook Refs Brooks 1987 Boehm 1981 Lutz 1993 What is Requirements Engineering Requirements Requirements Engineering is the branch of systems engineering concerned with real world goals for services provided by and constraints on software systems Requirements Engineering is also concerned with the relationship of these factors to precise specifications of system behaviour and to their evolution over time and across system families Zave94 E g Voyager and Galileo Need Need Need Need Need What is a Requirement Something that someone needs to solve a problem or achieve an objective Defects are cheaper to remove the earlier they are found Boehm Requirements defects are more likely to be safety related Lutz Department of Computer Science Basic Definitions Software is complex for its size Software is invisible and abstract No fabrication step hence software is modifiable 2 University of Toronto Department of Computer Science Solutions Department of Computer Science RE is concerned with identifying the purpose of a software system and the contexts in which it will be used Hence RE acts as the bridge between the real world needs of users customers and other constituencies affected by a software system and the capabilities and opportunities afforded by software intensive technologies RE 01 CfP 3 2000 2003 Steve Easterbrook 4 1 University of Toronto Department of Computer Science University of Toronto Department of Computer Science RE vs Systems Analysis Waterfall Model perceived need RE grew out of systems analysis Systems analysis focuses on information systems within an organization Has developed or adopted mostly informal notations tools and methodologies View of development a process of stepwise refinement requirements E g DFDs E R OO diagrams Widely practiced largely through management consulting companies Taught at undergraduate and graduate level in Management Studies and increasingly Industrial Engineering and Computer Science programmes largely a high level management view design RE goes beyond systems analysis Encompasses the entire formalization problem Problems Takes a static view of requirements ignores volatility code From a business need to a precise specification Expands the scope beyond information systems real time systems embedded systems interactive applications component based software web services Lack of user involvement once specification is written test integrate But perhaps less emphasis on management issues business processes 2000 2003 Steve Easterbrook 5 University of Toronto Department of Computer Science Prototyping lifecycle Unrealistic separation of specification from design 2000 2003 Steve Easterbrook Doesn t accommodate prototyping reuse etc University of Toronto Department of Computer Science Phased Lifecycle Models Source Adapted from Dorfman 1997 p9 Release 1 design design prototype build prototype document requirements test prototype design code test design Incremental development each release adds more functionality integrate O M test integrate O M test integrate O M code test integrate integrate O M code release 3 design integrate code design O M version 1 Prototyping is used for reqts design code version 2 reqts Problems Evolutionary development each version incorporates new requirements users treat the prototype as the solution a prototype is only a partial specification 2000 2003 Steve Easterbrook test release 4 understanding the requirements for the user interface examining feasibility of a proposed design approach exploring system performance issues code release 2 Requirements requirements 6 Source Adapted from Dorfman 1997 p7 Loucopoulos Karakostas 1995 p29 7 2000 2003 Steve Easterbrook test lessons learnt design code integrate O M lessons learnt version 3 reqts test design Source Adapted from Dorfman 1997 p10 code test integrate 8 2 University of Toronto aint str es r ive n s na 2 te er at Al alt egr ati on and Plan elo tes pm budget 1 requ ire lifec ments ycle plan ent pla ris n prototype 1 concept of operation tation pl an lys r lys is 4 ac Spiral model is a risk management model For each iteration plan next phases is determine objectives constraints evaluate alternatives 3 prototype 2 resolve risks prototype 3 prototype 4 ated valid ts emen equir tp lan implemen ka na ka na ri ana sk lys is 2 es tiv risk na nts i er analys alt stra is1 n o c budget 2 dev int s3 str Con s2 aint tiv na er alt budget 3 ris aint 3 tiv es 4 con s4 develop product det aile d des ign str ed dat ign vali des ied if r ve em syst test ceptance it un t