Requirements Engineering I

What is a requirement?

1. A need perceived by a stakeholder.

2. A capability or property that a system shall have.

3. A documented representation of a need, capability or property.

What is a stakeholder?

A Stakeholder is a person or organization who influences a system’s requirements or who is impacted by that system.

Where do we need and use requirements?

What are Cyber-physical systems?

Cyber-physical systems contain both software and physical components.

What are Socio-technical systems?

Socio-technical systems span software, hardware, people and organizational aspects.

What is a system?

1. A principle for ordering and structuring.

2. A coherent, delimitable set of elements that – by coordinated action – achieve some purpose.

A system may comprise other systems.

How can the purpose achieved by a system be delivered?

What are the forms of requirements?

What is the traditional definition of Requirements Engineering (RE)?

The application of a systematic, disciplined, quantifiable approach to the specification and management of requirements; that is the application of engineering to requirements.

What is the customer-oriented definition of RE?

Understanding and documenting the customers’ desires and needs.

What is the risk-oriented definition of RE?

Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.

What is the contemporary definition of RE?

The systematic and disciplined approach to the specification and management of requirements with the goal of understanding the stakeholders’ desires and needs and minimizing the risk of delivering a system that does not meet these desires and needs.

What are the four major tasks of RE?

• Eliciting the requirements

• Analyzing and documenting the requirements

• Validating the requirements

• Managing and evolving the requirements

Who are requirements engineers?

People act as requirements engineers if they:

• elicit, document, validate and manage requirements,

• have in-depth knowledge of Requirements Engineering, enabling them to define RE processes, select appropriate RE practices and apply them properly,

• are able to bridge the gap between the problem and potential solutions

What are the costs and benefits of RE?

What are the nine principles of RE?

What is the value of a requirement?

• The benefit of reducing development risk (i.e. the risk of not meeting the stakeholders’ desires and needs)

• minus the cost of specifying the requirement

How is the risk of a requirement assessed?

• Specification effort

• Distinctiveness

• Shared understanding

• Reference systems

• Length of feedback-cycle

• Kind of customer-supplier relationship

• Certification required

The effort invested into requirements engineering shall be inversely proportional to the risk that one is willing to take.

How are specification and implementation intertwined?

• Hierarchical intertwinement: high-level design decisions inform lower-level requirements

• Technical feasibility: non-feasible requirements are useless

• Validation: what you see is what you require

How can requirements be classified?

How can requirements be classified by kind?

DEFINITION. Functional requirement – A requirement concerning a result or behavior that shall be provided by a function of a system.

DEFINITION. Quality requirement – A requirements that pertains to a quality concern that is not covered by functional requirements

Can be sub-classified into:

• performance requirement

• specific quality requirement

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

How can requirements be classified by representation?

How can requirements be classified by satisfaction?

How can requirements be classified by role?

How can requirements be classified by purpose?

Why do we classify requirements in so many different ways?

How should we classify requirements when in doubt?

Classify the following requirements with respect to their kind, representation, satisfaction, role, and purpose.

a) When the system is in normal mode, the system shall unlock a turnstile for a single turn if the turnstile’s sensor unit senses a valid access card.

b) The system shall be compliant with GDPR.

What forms of shared understanding exist?

What does value mean in the context of specifications?

Value means

• The benefit of an explicit specification

  • Bringing down the probability for developing a system that doesn’t satisfy its stakeholders’ expectations and needs to an acceptable level

minus

• The cost of writing, reading and maintaining this specification

What are enablers and obstacles in shared understanding?

+ Domain knowledge

+ Previous joint work or collaboration

+ Existence of reference systems

+ Shared culture and values

+ Mutual trust

+/– Contractual situation

+/– Normal vs. radical design

– Geographic distance

– Outsourcing

– Regulatory constraints

– Large and/or diverse teams

– Fluctuation

What does context mean in the context of specifications?

What is the system boundary and the context boundary?

What are context models?

Modeling a system in its context

• Determine the level of specification

• Usually no system internals (➜ system as black box)

• Model actors which interact directly with the system

• Model interaction between the system und its actors

• Model interaction among actors

• Represent result graphically

What is the scope of a system development?

How do we distinguish between requirements and design decisions?

Distinguish operationally:

• If a statement is owned by stakeholders (i.e., changing it requires stakeholder approval), it’s a requirement

• If a statement is owned by the supplier (i.e. the supplier may change it freely), it’s part of the technical solution

What competencies are contributed by RE and product design?

What are work products and their characteristics?

What are single requirements?

What are sets of requirements?

What are the four document types?

What is a glossary?

What are rules for creating and maintaining a glossary?

What are prototypes?

What forms of prototypes exist?

What are examples of exploratory prototypes?

a) Wireframe

b) Mock-up (depending on whether there is some functionality, this could also be a native prototype)

What aspects need to be documented?

What are ways to document?

What are general rules for requirements documentation?

• Specify requirements as small, identifiable units whenever possible

• Record metadata such as source, author, date, status

• Use structure templates

• Adapt the degree of detail to the risk associated with a requirement

• Specify normal and exceptional cases

• Don’t forget quality requirements and constraints

How do we measure the quality of individual requirements?

How do we measure the quality of requirements work products?