REEL Requirements Elicitation

Linked Knowledge Nuggets:
arrow_forward "AI supported requirements management"

person Author: Manuel Schmidt, Alexander Feulner
How is modern requirements engineering implemented in practice, and what role does artificial intelligence play across the entire lifecycle—from creation and analysis to the quality assurance of requirements?
Together with our partner Innovigate, the developer of the Tracelane tool, we illustrate this with a practical demonstration. Tracelane is a modern requirements management tool with an intelligent AI assistant that creates, analyzes, evaluates, and provides concrete suggestions for improvement.

• school Webinar recording and slides
  

arrow_forward "How do I bring levels to my requirement chaos?"

person Author: Timo Karasch
First, our processes constantly ask us to specify requirements. Then we have to bother with quite a lot of documents and specifications. Even the relevant literature cannot explain to me in an understandable way what the difference between all these requirements is supposed to be. And finally, an assessor comes and evaluates my specification as insufficient. This is the end of it! In this webinar we want to bring levels into our requirements chaos. Using simple examples, we will show the different types of requirements and learn a few helpful methods for working with requirements.

• school Webinar recording and slides
  

arrow_forward "What is the difference between need, expectation and requirement?"

person Author: Process Fellows
Typically the terms Need, Expectation, and Requirement are distinguished as follows:

1. A Need describes a fundamental problem or desire of a stakeholder that should be addressed. It is often vague and not directly actionable. Needs arise from the stakeholder’s context, goals, or challenges.
   Example: “I want to be able to work faster.”
2. An Expectation is a stakeholder’s specific idea or assumption about how a Need might be fulfilled. It is subjective and can be expressed explicitly or implicitly.
   Example: “I expect the system to automatically suggest options.”
3. A Requirement is a documented, verifiable, and actionable specification derived from a Need or Expectation. It serves as the basis for design, implementation, and testing.
   Example: “The system shall display three relevant suggestions to the user within 2 seconds.”

Summary:

• Need: motivates development
• Expectation: expresses a concrete idea
• Requirement: a clearly defined, verifiable specification describing what is expected to be fulfilled

This distinction helps structure the process of eliciting, analyzing, and documenting requirements.

• O1 Exchange of stakeholder expectations is established
• O2 Stakeholder requirements (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) are agreed
• O3 Stakeholder needs are monitored continuously
• O4 Evolving stakeholder requirements (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) are continuously evaluated

BP1 Obtain stakeholder expectations and requests. ( O1 )

Obtain and define stakeholder expectations and requests through direct solicitation of stakeholder input and other sources containing inputs to stakeholder requirements (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …), considering the target operating and hardware (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) environment.
Note 1: Requirements elicitation may involve project (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements.) partners up and downstream.

Linked Knowledge Nuggets:
arrow_forward "Documenting stakeholder needs effectively"

person Author: Process Fellows
Go beyond “the customer said so.” Capture stakeholder needs with context, rationale, and validation criteria. Use personas, usage scenarios, or interviews. Make it testable – even if it’s fuzzy. This is not an easy task - but crucial to project success and the invest will be returned on within all subsequent processes.

BP2 Agree on requirements. ( O2 )

Formalize the stakeholder’s expectations and requests into requirements. Reach a common understanding of the set of stakeholder requirements (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) among affected parties by obtaining an explicit agreement from all affected parties.
Note 2: Reviewing the requirements and requests with the stakeholder supports a better understanding of stakeholder needs and expectations.
Note 3: The agreed stakeholder requirements (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) may be influenced by feasibility studies, effort and schedule impact analysis.

Linked Knowledge Nuggets:
arrow_forward "How to handle conflicting requirements?"

person Author: Process Fellows
Don’t sweep conflicts under the rug. Document them. Bring stakeholders together. Use impact analysis. Ultimately ensure consistency. Clarity today avoids chaos tomorrow.

arrow_forward "The role of assumptions in (system) requirements analysis"

person Author: Process Fellows
When deriving system requirements, assumptions fill the gaps. Example: assuming 4G connectivity is always available. Make such assumptions explicit and document their impact. Validate together with stakeholders if such assumptions are correct! If they change, system behavior might too – and that needs tracking.