1 / 18

CS 425/625 Software Engineering

Requirements Engineering Processes

Based on Chapter 6 of the textbook [Somm00] Ian Sommerville,Software Engineering, 6th Ed., Addison-Wesley, 2000 and on theCh6 PowerPoint presentation available at the book’s web-site:www.comp.lancs.ac.uk/computing/resources/IanS/SE6/Slides/index.html

September 22, 2003

2 / 18

OutlineOutline

Introduction Feasibility Studies Requirements Elicitation and Analysis Requirements Validation Requirements Management

3 / 18

Introduction The requirements engineering process [Fig. 6.1, Somm00]

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

4 / 18

Feasibility Studies

The input of a feasibility study is an outline description of the system

The output is a report which recommends or not continuing the development process

Activities: Information collection Information assessment Report writing

Questions asked during feasibility studies: What contribution brings the new system to the

organization? Can the system be built given its specific constraints? Can the system be integrated with already existing

systems in the organization?

5 / 18

Requirements Elicitation & Analysis……

Involves work with costumers and end-users to define the services and constraints of the system

Stakeholders = people who have direct or indirect influence on the way the system’s requirements are shaped

Challenges of requirements elicitation and analysis: Stakeholders not clear about what they want Domain knowledge implicitly assumed Various ways of expressing requirements Political considerations involved Dynamic business and economic environment

6 / 18

.Requirements Elicitation & Analysis….

The requirements elicitation & analysis process

[Fig. 6.2, Somm00]

Requirementsvalidation

Domainunderstanding

Prioritization

Requirementscollection

Conflictresolution

Classification

Requirementsdefinition andspecification

Processentry

7 / 18

..Requirements Elicitation & Analysis…

Three techniques for requirements elicitation and analysis: Viewpoint-oriented elicitation: various stakeholders’

points of view are taken into consideration (section 6.2.1 in [Somm00])

Scenario-based elicitation and analysis: using concrete sections of operations the details of the system’s requirements emerge

Ethnography: technique that focuses on understanding social and organizational requirements (section 6. 2.3 in [Somm00])

8 / 18

…Requirements Elicitation & Analysis..

Event scenarios [Fig. 6.10, SE-6]

Validate user

Request PIN

Selectservice

Timeout

Return card

Invalid card

Return card

Stolen card

Retain card

Incorrect PIN

Re-enter PIN

Incorrect PIN

Return card

Card

PIN

Card present

Accountnumber

PIN

Accountnumber

Valid card

User OK

9 / 18

….Requirements Elicitation & Analysis.

Use-cases [Fig. 6.12, Somm00]

Lending services

User administration

Supplier Catalog services

LibraryUser

LibraryStaff

10 / 18

…..Requirements Elicitation & Analysis

Sequence diagram [Fig. 6.13, Somm00]

Bookshop:Supplier

Cataloguer:Library Staff

Item:Library Item

Books:Catalog

Acquire New

Catalog Item

Uncatalog Item

Dispose

11 / 18

Requirements Validation..

Requirements validation has the goal of ensuring that the system requirements do represent in fact what the user wants

It is a form of requirements analysis which works with a complete set of requirements

Very important activity since discovering problems with requirements at this stage saves a significant amount of money

12 / 18

.Requirements Validation.

Types of checks for requirements validation: Validity checks Consistency checks Completeness checks Reality/feasibility checks Verifiability

Techniques for requirements validation: Reviews Prototyping Test-case generation Automated consistency analysis

13 / 18

..Requirements Validation Automated consistency analysis of requirements

[Fig. 6.15, Somm00]

Requirementsdatabase

Requirementsanalyser

Requirementsproblem report

Requirementsprocessor

Requirementsin a formal language

14 / 18

Requirements Management….

Requirements management is necessary because new requirements tend to emerge continuously. Its goal is to understand and control new requirements

Reasons for new requirements: Large systems have many users, with distinct sets of

requirements, preferences, and priorities Differences between the views of customers (who

pay for the system) and end-users (who actually work with the system)

The system’s environment evolves continuously

15 / 18

.Requirements Management…

Requirements from an evolution standpoint: Enduring requirements Volatile requirements:

Mutable Emergent Consequential Compatibility requirements

Requirements management planning involves decisions on: Identification of new requirements Change management process Traceability of requirements Tool support

16 / 18

..Requirements Management.. Requirements Evolution [Fig. 6.16, Somm00]

Changedunderstanding

of problem

Initialunderstanding

of problem

Changedrequirements

Initialrequirements

Time

17 / 18

……Requirements Management.Requirements Management.

Traceability Matrix [Fig. 6.18, Somm00]

18 / 18

….Requirements Management

Change management [Fig. 6.19, SE-6]

Changeimplementation

Change analysisand costing

Problem analysis andchange specification

Identifiedproblem

Revisedrequirements