Software engineering Module 1 -Introduction to software process Teaching unit 1 – Requirements engineering Ernesto Damiani Fee University of Bozen-Bolzano Lesson 1 – Requirements engineering

What is requirements engineering? It is the systematic process for setting up requirements It is a fundamental process for the software project success But it is also a critical process – Appropriate methodologies and devices are necessary

Why should we use requirements engineering? 73% of software projects are left or do not meet expectations because of wrong requirements

Failure: a classic case study (1) Retail software The failure and the interruption (with legal developments) of CONFIRM (American Airlines, Budget-rent-a-car, Marriott, Hilton) integrate system of air booking, car rental and hotel booking, whose cost is 165 million dollars (1994).

Failure: a classic case study (2) Packet software Stop after the beta release production of CorelOffice for Java project to create a Java system which is functionally compatible with Microsoft Office (1998).

Failure: a classic case study (3) In both cases study, the failure causes were ascribed to: – initial requirement errors – lack of user involvement – incapability to manage changes of requirements themselves

Impact on costs The cost of correcting in requirements increases of one order of magnitude if it is executed after the delivery

Extraction Requirements engineering is carried out through: – a cooperative and iterative analysis of the problem – the result documentation in a standard format of representation – the control of the problem understanding which has been reached

Refinement Refinement of requirements is carried out through some talks with the person interested in the system (stakeholder) Techniques: – market analysis – interviews to domain experts and customers

Elicitation phases Stakeholder identification –Users –Customers –Domain experts Setting up of useful questions to increase problem understanding Gathering information analysis for detecting conflicts and inconsistencies Control of the understanding acquired with stakeholders Informal writing of requirements FINE