1.1
Why perform requirements engineering?
How the requirements of a system are handled is a significant cause for project failures and/or time and budget overruns.
1.1.1 Requirements engineering as a cause of errors
- 60 percent of all errors in system development projects originate during RE phase
- Missing requirements often remain undetected during design and realization
- 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.
1.1.1 Costs of errors during requirements engineering
requirements engineering
The later in the development project a defect in the requirements is corrected, the higher are the costs associated with fixing it.
1.1.1 Symptoms and causes of deficient requirements engineering
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.
1.1.1 The significance of good requirements engineering
Complete requirements free from defects are the basis for successful system development.
1.1.2 Definition 1-1 : 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).
1.1.2 Definition 1-2: Stakeholder
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
1.1.2 Stakholders
- Stakeholders are the most important sources of requirements.
- 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
1.1.2 Goal of requirements engineering
- ELICIT the stakeholders’ requirements
- DOCUMENT the requirements in a suitable manner
- VALIDATE the requirements
- VERIFY the requirements
- MANAGE the requirements over the course of the entire life cycle of the system
1.1.2 Definition 1-3: Requirements Engineering
(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
1.1.2 Four core activities of requirements engineering
- ELICITATION: different techniques are used to obtain requirements from stakeholders and other sources and to refine the requirements in greater detai
- DOCUMENTATION: the elicited requirements are described adequately. Different techniques are used to document the requirements by using natural language or conceptual models
- VALIDATION AND NEGOTIATION: must happen early on
- 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
1.1.2 Constraints
project constraints influence requirements engineering
- people
- domain factors
- organizational constraints (e.g., spatial distribution or temporal availability of project members)
have a large impact on the choice of suitable techniques
(1.1.3 Embedding Requirements Engineering into Process Models )
Requirements engineering as a self-contained phase
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.
1.1.3 Requirements engineering as a continuous, collateral process
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.
( 1.2 Fundamentals of Communication Theory )
–> Language as a medium for requirement communication
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
1.2 Type of communication medium
- successful verbal communication = redundancy (e.g., language and gestures or language and intonation) and feedback
- successful written technical communication = a minimum of redundancy and feedback
1.2 Language comfort
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
1.2 Implicit background knowledge
communication = simplifying in nature
problem since this causes requirements to be interpretable in different ways ( no no fore requirements!! )
1.2 communication definition
language based expression of knowledge
( 1.3 Characteristics of a Requirements Engineer )
Central role
requirements engineer =
- translator ( understands the domain nand its jargon + has IT know-how to communicate with devs on the same level )
- only one who has direct contact with the stakeholders
- ability + responsibility to understand domain
- identifies needs underlying the stakeholders’ statements
- amends needs so that architects and developers can understand and implement them
1.3 Seven necessary capabilities of a requirements engineer
- Analytic thinking :
- understand and analyze complicated problems and relationships
- abstract from the concrete statements of the stakeholder - Empathy :
- must identify actual needs of stakeholder so good intuition and empathy are a must - Communication skills :
- listen
- right questions, right time
- notice when replay doesn’t contain desired info - Conflict resolution skill :
- identify conflicts
- mediate between parties - Moderation skills:
- mediate between different opinions
- lead discussions - Self-confidence :
- exposed to criticism so defend herself and not take it personally - Persuasiveness :
- attorney for the requirements of the stakeholders
( 1.4 Requirement Types )
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 )
1.4 Definition 1-4: Functional Requirement
requirement concerning a result of behavior that shall be provided by a function of the system.
1.4 Definition 1-5: Quality Requirement
requirement that pertains to a quality concern that is not covered by functional requirements.
