Introduction

• Incomplete Requirements

• No customer requirements

• Lack of resources

• Unrealisitic expectations

• Uncontrolled changes of requirements

• Customer/User involvement

• Management support

• Clear Statement of requirements

• Proper planning

• Realistiv expectation

• Explore

  • Understanding phenomena and identify problems

• Evaluate

  • Check and improve hypotheses, measure impact

• Describe user tasks which the system needs to support

• Describe system behaviour under specific condition

• Describe the interactions between the system and its environment independent from the implementation

• The user shall be able to choose her destination on the map.

• The system shall recommend the fastest route to a free parking slot.

• The user shall be able to choose one of the recommended routs.

• Describe aspects not directly related to functional behavior

  • “The Feature X of the App must be available without a mobile internet connection”

• Describe properties of the system or the domain

1. Definition: Limits the solution space beyond functional and quality requirements (Pohl 2016).

2. Source: Imposed by customer or environment.

3. Alias: Also called “Pseudo requirements”.

4. Example: “The app must support blinded users using speech.”

5. Affected Areas:

   • Implementation

   • Interface requirements

   • Operation requirements

   • Packaging requirements

   • Legal requirements (e.g., privacy, accessibility, licensing, certification, regulation)

is not covered by functional requirements

• System engineering:

  • discipline concerned by designing, developing, deploying and maintaining systems

• Software engineering

  • sub-discipline that focuses on engineering software-intensive systems

• Requirements elicitation: the process of discovering, reviewing, documenting, and understanding the user’s needs and constraints for a system

• Requirements analysis: The process of refining the user’s needs and constraints

• Requirements specification: The process of documenting the user’s needs and constraints clearly and precisely

• Requirements verification: Ensuring that the system requirements are complete, correct, consistent, and clear

• Requirements management: Scheduling, negotiating, coordinating, and documenting the RE activities

RE is a process of formulating, documenting and maintaining software requirements

• Requirements elicitation

  • Def. of system understood by customer or user

  • “Requirements specification“

• Requirements Analysis

  • Def. of system understood by developer

  • “Technical specification“, “Analysis model“

• Requirements Engineering Process

  • Combination of activities requirements elicitation and analysis

• Both focusing on requirements from users view of system

• Requirements specification

  • uses natural language

• Analysis model

  • uses formal or semi-formal notation

• Goal: Bridging the conceptual gap between end user and developer

• Interview/Surveys

• Observation

• Scenario

• Use case

• Mockup

about

Scheduling, negotiating, coordinating, and documenting

the requirements engineering activities

• Correctness

  • requirements represent the clients view

• Completeness

  • “all” possible scenarios, in which the system can be used

• Consistency

  • no requirements that contradict each other

• Clarity

  • requirements can only be interpreted in one way

• Realism

  • requirements can be implemented and delivered

• Traceability

  • each system component & behaviour can be tracked back to a set of funct. req.

• High priority

  • must be demonstrated at delivery of system

  • addressed during analysis, design and implementation

• Medium priority

  • are usually demonstrated in future iterations

• Low priority

  • illustrates how system going to be in future

  • have impact on analysis model

• is justification for decisions

• Benefit

  • Increase stakeholder understanding of system

  • Ability to explain past decisions