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

Requirements Requirements specify what a software system must do and not how it must do it The what vs. how dilemma: what for someone is “what”, for other people is “how”

Requirement classes (1) Requirements belong to four classes Functional requirements – They specify a function the system must execute Non-functional requirements – Performances, reliability, efficiency, portability, modifiability, etc – Generally they are global

Requirement classes (2) Inverse requirements – They specify operations the system must not execute – They are related to the security Implementation/project specifications – They are specific to the technology (for example, WWW, XML, Java)

Requirement priorities Requirements are also subdivided into priority classes MUST: requirements the system must absolutely have to be able to provide the functionalities required by the facilitator SHOULD: requirements making the system better or anyway more acceptable for the facilitator MAY: requirements which would improve the system and may be added if time and budget permit it

Analysis and negotiation Analysis of requirements collected during the previous phase to identify ambiguities and conflicts A negotiation among all stakeholders is required

Formalization Requirements recording in a document which must be shared among developers, users and management Use of formal or semiformal languages Specify relationships (e.g. dependency) among requirements

Validation Control of formalized requirements to remove redundancies and ambiguities Requirement quality control Dependency validation FINE