REQUIREMENTS ENGINEERING LECTURE 2018/2019. Dr. Jörg Dörr. Introduction. Fraunhofer IESE

Transcription

1 REQUIREMENTS ENGINEERING LECTURE 2018/2019 Dr. Jörg Dörr Introduction

2 GI-FG (RE) 2

3 Motivation & Overview WHAT IS REQUIREMENTS ENGINEERING? 3

4 What Do You Think? 4

5 Goals of Lecture (1/2) Requirements Engineering (RE) is a challenging engineering task It requires appropriate principles, techniques, methods & tools This lecture First focuses on basic aspects of requirements engineering, which are rather independent of the specifics of the information systems or embedded systems domain and later on deals with specific approaches for information systems and embedded systems 6

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 crosscutting topics like crowd-based RE, agile RE, and creativity techniques 7

7 Prerequisites for Lecture Basic knowledge about Software Engineering process/methods/tools, e.g. by Bachelor /Lecture "Grundlagen des Software Engineering (GSE)" 8

8 Lecture Lecture Time: Friday, 13:45-15:15 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 assistant Stefanie Obradovic at this week! 9

9 Lecture Style and Credits Active Participation required! Not just Vorlesung, please ask questions and give comments Active exercises & discussion of challenges in class The mode of the final examination will be written. 10

10 Exercise Class Exercise Time: To be announced (irregularly) Probably two groups Exercises will be blocked into 7-8 meetings á 1.5 hours In your to my assistant, please state if you plan to regularly attend the exercise group and mention for which selected slots in the week you are available. Voluntary Assignments (Übungsblätter): if applicable, handed out during or before class But most classes will be in-class modeling (i.e., you will perform the exercise tasks in the exercise class) 11

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

12 Now, back to RE 13

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 14

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

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

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 17

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 18

18 Motivation & Overview REASONS FOR REQUIREMENTS ENGINEERING 19

19 The Success of Software Projects 100% 90% 22% 17% 19% 17% 19% Standish Group: Yearly analysis of project success 80% 70% 60% 50% 40% 30% 49% 56% 50% 55% 52% Successful: on time, within budget, and accepted by customer Challenged: late, over budget, or with customer acceptance problems Failed: not completed or rejected by customer 20% 10% 29% 27% 31% 28% 29% 0% Successful Challenging Failed [Source: 20

20 Reasons for Bad Projects Incomplete requirements 13.1 % Clients insufficiently involved 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 % [Source: Chaos Report, Standish Group] 21

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 22

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 Impact- Analyses, Feature- Search Evolution New Releases Reuse Project-plan, Cost Estimation, Contracts Management Team Cost Milestones Configuration Contracting/Subcontr acting 23

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

24 Motivation & Overview BASIC CONCEPTS 26

25 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

26 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

27 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

28 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) 30