Embed Size (px)
Citation preview
© Fraunhofer IESE
REQUIREMENTS ENGINEERINGLECTURE 2015/2016
Dr. Jörg Dörr
Introduction
© Fraunhofer IESE
2
WHAT IS REQUIREMENTS ENGINEERING?
Motivation & Overview
© Fraunhofer IESE
3
What Do You Think?
© Fraunhofer IESE
4
What is Requirements Engineering? – In Your Opinion…
© Fraunhofer IESE
5
Goals of Lecture (1/2)
Requirements Engineering (RE) is a challenging engineering task It requires appropriate principles, techniques, methods & tools This lecture focuses on various aspects of requirements engineering, which
are rather independent of the specifics of the information systems or embedded systems domain
© Fraunhofer IESE
6
Goals of Lecture (2/2)
The goals are to understand the specific tasks, principles and challenges of requirements
engineering the elicitation and documentation activities in more detail basic principles and techniques for quality assurance requirements management
specific RE modeling approaches (Embedded, Information Systems) Further specific topics if time allows (e.g, crowd-based RE)
© Fraunhofer IESE
7
Prerequisites for Lecture
Basic knowledge about SE process/methods/tools, e.g. by Bachelor /Lecture "Grundlagen des Software Engineering (GSE)"
Interest in Software Quality Engineering (high demand in industry!)
© Fraunhofer IESE
8
Lecture
Lecture Time:
Friday, 13:45 - 15:15 at Fraunhofer IESE!
Lecturer:
Dr. Jörg Dörr (Fraunhofer IESE)
http://wwwagse.informatik.uni-kl.de/teaching/re/ws2015/
In order to have your correct email-addresses for short term notices, please send an email with subject “Requirements Lecture” to my secretary Simone Mieger at [email protected] this week!
© Fraunhofer IESE
9
Lecture Style and Credits
Active Participation required!
Not just “Vorlesung”
Active Exercises & Discussion of challenges in class
The mode of the final examination will be written.
© Fraunhofer IESE
10
Exercise Class
Exercise Time:
To be announced (irregularly)
Exercises will be blocked into 7-8 meetings á 1.5 hours
Moderators:
Dr. Jörg Dörr
Further lecturers
Voluntary Assignments (Übungsblätter):
if applicable, handed out during or before class
© Fraunhofer IESE
11
Questions ?
Meet Dr. Jörg Dörr:By appointment,(IESE, room: C3-06, Phone: 6800-1601), or by email:[email protected]
© Fraunhofer IESE
12
Now, back to RE…
© Fraunhofer IESE
13
AGENDA
What is Requirements Engineering?
Reasons for Requirements Engineering
Basic Concepts
Requirements Engineering Practices
Role of Communication
Requirements Types
Requirements Engineering in Development Approaches
© Fraunhofer IESE
14
Requirements Engineering
Therequirementsanalysisforasoftwaresystem.
© Fraunhofer IESE
15
What is Requirements Engineering? (2)
Systematic Engineering
by using an iterative, cooperative process during problem analysis
by documenting all observations from the problem analysis in a variety of formats and
by validating the accuracy of the achieved understanding
[Pohl 93]
© Fraunhofer IESE
16
Definition of “Requirements Engineering” (RE)
These three goals address important facets of RE
1. Process orientation
2. Stakeholder focus
3. Importance of risk and value consideration
Asystematicanddisciplinedapproachtothespecification andmanagementofrequirementswiththefollowinggoals:1. Knowingtherelevantrequirements,achievingaconsensusamongthestakeholders abouttheserequirements,documentingthemaccordingtogivenstandards,andmanagingthemsystematically;
2. Understandinganddocumentingthestakeholders’desiresandneeds;3. Specifyingandmanagingrequirements tominimizetheriskofdeliveringasystem thatdoesnotmeetthestakeholders’desiresandneeds.
[IEEE, also used by IREB]
These three goals address important facets of RE
1. Process orientation
2. Stakeholder focus
3. Importance of risk and value consideration
© Fraunhofer IESE
17
History of Requirements Engineering
1968: Conference in Garmisch: Software Engineering
1977: Transactions of SE, Issue on RE
since 1978: international Conference on SE (ICSE)
1983: IEEE-Standard RE
since 1993: international conference/symposium on RE
1993: new IEEE-standard on RE
since 1996: RE Journal
since 1998: additional RE standards
© Fraunhofer IESE
18
REASONS FOR REQUIREMENTSENGINEERING
Motivation & Overview
© Fraunhofer IESE
19
Today’s Software Projects
Standish Group’s CHAOS Report:
31% of all projects ended without any results
53% of all projects exceed their plans:time schedule exceeded on average by 222%planned costs exceeded on average by 189%
45% of the implemented features won‘t be used at all
German industry wastes more than 10 billion € each year due to quality or efficiency problems in software projects
© Fraunhofer IESE
20
Reasons
Incomplete requirements 13.1%
Clients not involved sufficiently 12.4 %
Insufficient funds 10.6 %
Unrealistic expectations 9.9 %
Insufficient management support 9.3 %
Changing requirements 8.7 %
Insufficient planning 8.1 %
Bad requirements analysis in general 12.0 %
© Fraunhofer IESE
21
And…
Problems in requirements are often detected in late phases
Costs for correcting errors increase with project progress
Factor 1 if found in requirements specification
Factor 10 if detected during implementation
Factor 200 if detected during operation and maintenance
Corrections often result in new problems / errors
© Fraunhofer IESE
23
Software Development
•Requirements Analysis
•Specifikation
•Design
•Implementation
Quality Management
•Product
•Process
Evolution
•New Releases
•Reuse
Management
•Team
•Cost
•Milestones
•Configuration
•Contracting/Subcontracting
Documentation
Project-plan,Cost Estimation,
Contracts
User Handbook
Impact-Analyses,Feature-Search
Test cases,Test plan
User Requirements, Basis for Development
Requirements are the Key to Software Engineering
© Fraunhofer IESE
24
Effects of Inadequate Requirements Engineering (Airbus-Example)
Requirement:
„Reverse thrust may only be used, when the airplane is landed.“
Translation:
„Reverse thrust may only be used while the wheels are rotating.“
Implementation:
„Reverse thrust may only be used while the wheels are rotating fast enough.“
Result: Rainstorm Aquaplaning Crash due to overshooting the runway!
© Fraunhofer IESE
25
Still true…
„The hardest single part of building a softwaresystem is deciding precisely what to build.”
[Brooks, 1987]
© Fraunhofer IESE
26
BASIC CONCEPTSMotivation & Overview
© Fraunhofer IESE
27
Basic Concepts of Requirements Engineering
Stakeholder
Person or organization interested in the developed system
Requirement
Request of a user, client or another stakeholder
(Requirements) Documentation
Written description of the requirements
Specification
Description of the software to design for developers (sometimes used as synonym for requirements)
© Fraunhofer IESE
28
Definition of a “Stakeholder”
Apersonororganizationthathasa(directorindirect)influenceonasystem’s requirements.
Indirectinfluencealsoincludessituationswhereapersonororganizationisimpactedbythesystem.
Stakeholders are the most important source for requirements!
© Fraunhofer IESE
29
Definition of a “Requirement”
1. Aconditionorcapabilityneededbyauser tosolveaproblemorachieveanobjective.
2. Aconditionorcapabilitythatmustbemetorpossessedbyasystemorsystemcomponent tosatisfyacontract,standard,specification,orotherformallyimposeddocuments.
3. Adocumentedrepresentationofaconditionorcapabilityasin(1)or(2).
[IEEEStd.610.12‐1990]
Arequirementisastatementaboutacondition,propertyorcapabilityofasystemthatisneededforachievingagoalofasystem‘sstakeholder
© Fraunhofer IESE
32
ProblemDescription
UnitRequirements
DeveloperRequirements
Systemdesign
UserRequirements
Unitdesign
Units(Code)
ExecutableUnits
ExecutableSystem
UsableSystem
Used System
Requirements in the Logical V-Modell
