REQUIREMENTS ENGINEERING LECTURE 2015/2016. Dr. Jörg Dörr. Introduction. Fraunhofer IESE

Transcription

1 REQUIREMENTS ENGINEERING LECTURE 2015/2016 Dr. Jörg Dörr Introduction

2 Motivation & Overview WHAT IS REQUIREMENTS ENGINEERING? 2

3 What Do You Think? 3

4 What is Requirements Engineering? In Your Opinion 4

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 5

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) 6

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!) 7

8 Lecture Lecture Time: Friday, 13:45-15:15 at Fraunhofer IESE! Lecturer: Dr. Jörg Dörr (Fraunhofer IESE) In order to have your correct -addresses for short term notices, please send an with subject Requirements Lecture to my secretary Simone Mieger at this week! 8

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. 9

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 10

11 Questions? Meet Dr. Jörg Dörr: By appointment, (IESE, room: C3-06, Phone: ), or by 11

12 Now, back to RE 12

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 13

14 Requirements Engineering The requirements analysis for a software system. 14

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] 15

16 Definition of Requirements Engineering (RE) A systematic and disciplined approach to the specification and management These three of goals requirements address important with the facets following of RE goals: 1. Knowing Process orientation the relevant requirements, achieving a consensus among the 2. stakeholders Stakeholder about focus these requirements, documenting them according to given standards, and managing them systematically; 3. Importance of risk and value consideration 2. Understanding and documenting the stakeholders desires and needs; 3. Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders desires and needs. [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 16

17 History of Requirements Engineering 1968: 1977: since 1978: 1983: since 1993: 1993: since 1996: since 1998: Conference in Garmisch: Software Engineering Transactions of SE, Issue on RE international Conference on SE (ICSE) IEEE-Standard RE international conference/symposium on RE new IEEE-standard on RE RE Journal additional RE standards 17

18 Motivation & Overview REASONS FOR REQUIREMENTS ENGINEERING 18

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 19

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 % 20

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 21

22 Requirements are the Key to Software Engineering Documentation User Handbook User Requirements, Basis for Development Software Development Requirements Analysis Specifikation Design Implementation Test cases, Test plan Quality Management Product Process Evolution New Releases Reuse Impact- Analyses, Feature- Search Project-plan, Cost Estimation, Contracts Management Team Cost Milestones Configuration Contracting/Subcontr acting 23

23 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! 24

24 Still true The hardest single part of building a software system is deciding precisely what to build. [Brooks, 1987] 25

25 Motivation & Overview BASIC CONCEPTS 26

26 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) 27

27 Definition of a Stakeholder A person or organization that has a (direct or indirect) influence on a system s requirements. Indirect influence also includes situations where a person or organization is impacted by the system. Stakeholders are the most important source for requirements! 28

28 Definition of a Requirement 1. A condition or capability needed by a user to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. 3. A documented representation of a condition or capability as in (1) or (2). [IEEE Std ] A requirement is a statement about a condition, property or capability of a system that is needed for achieving a goal of a system s stakeholder 29

29 Requirements in the Logical V-Modell Problem Description Used System User Requirements Usable System Developer Requirements Executable System System design Unit Requirements Executable Units Unit design Units (Code) 32