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
Top Related