Requirements Engineering Framework with 7 task areas

My proposal for a Requirements Engineering Framework with 7 task areas:

Demand Analysis: Customer needs and demand situations must be analyzed and understood in close collaboration with the Product Owners. This yields insights into the target audience, audience-specific product quality characteristics, demand for new features, and the possibility of removing features no longer needed. The key is: Being close to the market and customers!

Elicitation: Guided by the KANO model, requirements for basic factors, performance factors, and excitement factors are systematically determined through various elicitation techniques. For example: basic factors through apprenticeship, performance factors through interviews, excitement factors through brainstorming. The key is: Understand the participants and elicitation objectives, choose the right technique, and apply it professionally.

Documentation: Requirements must be structured and standardized as much as possible to effectively communicate them to all stakeholders (e.g., domain experts for validation, architects for system design, test engineers for deriving test cases, developers for implementation). A mix of natural language specification (e.g., in the form of user stories) and model-based specification (e.g., BPMN, UML, domain story telling) is usually suitable. The key is: Precision, understandability, situation-appropriate method (e.g., larger processes should not be described in natural language but modeled with BPMN).

Impact Analysis: The impacts of individual requirements on the target system, surrounding systems, other requirements, test cases, data protection, and security aspects must be identified. This is the only way to minimize risks from side effects. The key is: Technical traceability of relevant artifacts such as system components, interfaces, requirements, architecture decisions, and test cases must be ensured.

Validation: It must be checked before development whether the collected and documented requirements meet stakeholder needs. In agile development, where explicit and implicit (e.g., through measurements of user behavior) customer feedback is also collected in productive operation, validation extends into everyday product management. Stakeholders include obvious ones such as the requirement issuer and the users, but also less obvious ones such as operations, test management, and IT architects. The key is: Good stakeholder management, early involvement, and transparent and understandable communication with all relevant stakeholders.

Verification: After development, it must be verified whether the requirements have been implemented as requested.

Requirements Management: Requirements must be managed as referenceable objects and controlled through the development process using a status model and a workflow based on it. Managing stakeholders and their involvement also falls into this area.

Any attempt to linearly sequence activities into a simple, universally applicable process will fail. The process of Requirements Engineering depends on the software development methodology and is typically not linear. Therefore, my framework covers areas of tasks rather than a process flow. There is no claim to completeness – I’ve only addressed aspects that are often underestimated in my experience and that I have been intensively involved with recently.