H1 Foundations

Question 1

1.1

Why perform requirements engineering?

Answer 1

How the requirements of a system are handled is a significant cause for project failures and/or time and budget overruns.

Question 2

1.1.1 Requirements engineering as a cause of errors

Answer 2

1. 60 percent of all errors in system development projects originate during RE phase
2. Missing requirements often remain undetected during design and realization
3. Unclear, incomplete, or wrong requirements inevitably lead to the development of a system that does not possess critical properties or possesses properties that were not requested.

Question 3

1.1.1 Costs of errors during requirements engineering

Answer 3

requirements engineering
The later in the development project a defect in the requirements is corrected, the higher are the costs associated with fixing it.

Question 4

1.1.1 Symptoms and causes of deficient requirements engineering

Answer 4

The most common reason for deficient requirements is the misconception of the stakeholders that much is self-evident and does not need to be stated explicitly. This results in problems in communication among the involved parties that arise from differences in experience and knowledge.

Question 5

1.1.1 The significance of good requirements engineering

Answer 5

Complete requirements free from defects are the basis for successful system development.

Question 6

1.1.2 Definition 1-1 : Requirement

Answer 6

(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).

Question 7

1.1.2 Definition 1-2: Stakeholder

Answer 7

Definition 1-2: Stakeholder A stakeholder of a system is a person or an organization that has an (direct or indirect) influence on the requirements of the system

Question 8

1.1.2 Stakholders

Answer 8

1. Stakeholders are the most important sources of requirements.
2. Not considering a stakeholder often results in fragmentally elicited requirements, i.e., incomplete requirements.

ex of stakeholders: a hacker, management, stakholders of competing systems, users, admins, legal entities, institutions

Question 9

1.1.2 Goal of requirements engineering

Answer 9

1. ELICIT the stakeholders’ requirements
2. DOCUMENT the requirements in a suitable manner
3. VALIDATE the requirements
4. VERIFY the requirements
5. MANAGE the requirements over the course of the entire life cycle of the system

Question 10

1.1.2 Definition 1-3: Requirements Engineering

Answer 10

(1) Requirements engineering is a systematic and disciplined approach to the specification and management of requirements with the following goals:
(1. 1) Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards, and managing them systematically
(1. 2) Understanding and documenting the stakeholders’ desires and needs, they specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs

Question 11

1.1.2 Four core activities of requirements engineering

Answer 11

1. ELICITATION: different techniques are used to obtain requirements from stakeholders and other sources and to refine the requirements in greater detai
2. DOCUMENTATION: the elicited requirements are described adequately. Different techniques are used to document the requirements by using natural language or conceptual models
3. VALIDATION AND NEGOTIATION: must happen early on
4. MANAGEMENT :
   - is orthogonal to all other activities
   - comprises any measures that are necessary to :
   * structure requirements
   * prepare them so that they can be used by different roles
   * maintain consistency after changes
   * ensure their implementation

Question 12

1.1.2 Constraints

Answer 12

project constraints influence requirements engineering

1. people
2. domain factors
3. organizational constraints (e.g., spatial distribution or temporal availability of project members)

have a large impact on the choice of suitable techniques

Question 13

(1.1.3 Embedding Requirements Engineering into Process Models )

Requirements engineering as a self-contained phase

Answer 13

Waterfall model / V-Model
goal = elicit all requirements prior to the actual development

In these process models, requirements engineering is understood to be a finite, time-restricted initial phase of system development.

Question 14

1.1.3 Requirements engineering as a continuous, collateral process

Answer 14

Lightweight process models (e.g., eXtreme Programming)

• elicit necessary requirements once they are supposed to be implemented
• ( “foretelling” future functionalities is difficult and requirements change over the course of the project ) .

In these process models, requirements engineering is treated as a continuous, comprehensive process that comprises and integrates all phases of system development.

Question 15

( 1.2 Fundamentals of Communication Theory )

–> Language as a medium for requirement communication

Answer 15

Ideal communication conditions = similar the cultural and educational background, same area of expertise, similar experiences etc

Ideal communication conditions most often do not exist between stakeholders.

It is therefore sensible to agree upon a common language and how this common language is to be used

Question 16

1.2 Type of communication medium

Answer 16

1. successful verbal communication = redundancy (e.g., language and gestures or language and intonation) and feedback
2. successful written technical communication = a minimum of redundancy and feedback

Question 17

1.2 Language comfort

Answer 17

In addition to the problems arising from differing domain vocabularies and different communication media, it can often be observed that :

• information is not adequately transmitted or not transmitted at all
• this because of natural transformations that occur during human perception, aka focusing and simplification

Question 18

1.2 Implicit background knowledge

Answer 18

communication = simplifying in nature

problem since this causes requirements to be interpretable in different ways ( no no fore requirements!! )

Question 19

1.2 communication definition

Answer 19

language based expression of knowledge

Question 20

( 1.3 Characteristics of a Requirements Engineer )

Central role

Answer 20

requirements engineer =

1. translator ( understands the domain nand its jargon + has IT know-how to communicate with devs on the same level )
2. only one who has direct contact with the stakeholders
3. ability + responsibility to understand domain
4. identifies needs underlying the stakeholders’ statements
5. amends needs so that architects and developers can understand and implement them

Question 21

1.3 Seven necessary capabilities of a requirements engineer

Answer 21

1. Analytic thinking :
   - understand and analyze complicated problems and relationships
   - abstract from the concrete statements of the stakeholder
2. Empathy :
   - must identify actual needs of stakeholder so good intuition and empathy are a must
3. Communication skills :
   - listen
   - right questions, right time
   - notice when replay doesn’t contain desired info
4. Conflict resolution skill :
   - identify conflicts
   - mediate between parties
5. Moderation skills:
   - mediate between different opinions
   - lead discussions
6. Self-confidence :
   - exposed to criticism so defend herself and not take it personally
7. Persuasiveness :
   - attorney for the requirements of the stakeholders

Question 22

( 1.4 Requirement Types )

Answer 22

1. Functional requirements = define functionality 
sub catgs:
 - functional requirements 
- behavioral requirements
- data requirements
2. Quality requirements =  about the 
- performance, 
-availability, 
-dependability, 
- scalability, or 
- portability of a system.
3. Constraint = cannot be influenced by team members ( not implemented but adhered,  they limit solution space )

Question 23

1.4 Definition 1-4: Functional Requirement

Answer 23

requirement concerning a result of behavior that shall be provided by a function of the system.

Question 24

1.4 Definition 1-5: Quality Requirement

Answer 24

requirement that pertains to a quality concern that is not covered by functional requirements.

Question 25

1.4 Definition 1-6: Constraint

Answer 25

requirement that limits the solution space beyond what is necessary for meeting the given functional requirements and quality requirements.

Question 26

( 1.5 Importance and Categorization of Quality Requirements )

Answer 26

reality = Quality Requirements often:

• not documented,
• inadequately documented,
• improperly negotiated

RE = special emphasis on QR!!!

classification schemes for QR exist, example ISO
(excerpt catgs :
- R’s for quality system functions
- R’s for dependability of functinalities
- R’s for rubustness
- R’s for sys efficiency,
etc )

QR documented in natural language but there are models too

QR’s always kept separate from functional requirements because they are related to multiple of them simultaneously

Question 27

1.6 Summary

Answer 27

goal of requirements engineering =

1. document customer requirements as completely as possible in good quality
2. identify and resolve problems in the requirements as early as possible

Successful requirements engineering =
1. including the right stakeholders
2 doing four core activities of requirements engineering ( elicitation, documentation, validation/ negotiation, and management)

REr =

• at center
• primary contact person
• domain knowledge
• process knowledge
• soft skills