QREME - Quality Requirements Management Model for Supporting Decision-Making

[Context and motivation] Quality requirements (QRs) are inherently diffi-cult to manage as they are often subjective, context-dependent and hard to fully grasp by various stakeholders. Furthermore, there are many sources that can provide input on important QRs and suitable levels. Responding timely to customer needs and realizing them in product portfolio and product scope decisions remain the main challenge. [Question/problem] Data-driven methodologies based on product usage data analysis gain popularity and enable new (bottom-up, feedback-driven) ways of planning and evaluating QRs in product development. Can these be effi-ciently combined with established top-down, forward-driven management of QRs? [Principal idea / Results] We propose a model for how to handle decisions about QRs at a strategic and operational level, encompassing product deci-sions as well as business intelligence and usage data. We inferred the model from an extensive empirical investigation of five years of decision making history at a large B2C company. We illustrate the model by assessing two in-dustrial case studies from different domains. [Contribution] We believe that utilizing the right approach in the right situa-tion will be key for handling QRs, as both different groups of QRs and do-mains have their special characteristics.

💡 Research Summary

The paper addresses the longstanding challenge of managing quality requirements (QRs), also known as non‑functional requirements, which are often subjective, context‑dependent, and difficult for stakeholders to agree upon. While much prior work has focused on eliciting, modeling, and representing QRs, the authors identify a gap in how QRs are actually scoped, prioritized, and realized across product portfolios and release plans. Empirical observations from a large B2C company showed that QRs typically need to be delivered incrementally over several releases, that some quality aspects (e.g., efficiency, usability) are best handled in a bottom‑up, data‑driven manner, whereas others (e.g., security, performance) require top‑down strategic governance, and that multiple, inter‑locking strategies are necessary for a responsive organization.

To bridge the top‑down and bottom‑up approaches, the authors propose QREME (Quality Requirements Management model). QREME is organized around two decision‑making levels: strategic and operational. At the strategic level, decisions concern the overall product portfolio (PStr) and the high‑level product scope (PSc), such as which quality attributes (QAs) to target, which market segments to serve, and the long‑term roadmap. At the operational level, decisions focus on business intelligence (BI) and analytics (An), i.e., gathering market and usage data, defining concrete quality levels (QLs) for specific releases, and running experiments to validate assumptions.

The model introduces four “scope decision areas”: Portfolio Strategy (PStr), Product Scope (PSc), Business Intelligence (BI), and Analytics (An). Each area operates semi‑autonomously, has its own inputs and outputs, and can influence the others. Decision forums are defined for each area (e.g., Portfolio Strategy Forum, Product Scope Forum, BI Forum, Analytics Forum), and specific roles—portfolio manager, product manager, BI manager, data analyst—are assigned responsibilities within these forums. The two loops of QREME— a forward‑driven “forward loop” (strategic, slower) and a feedback‑driven “feedback loop” (data‑driven, faster)—traverse the four decision areas in opposite directions, ensuring that long‑term strategic intent is continuously refined by real‑time usage insights.

Methodologically, the authors employ Canonical Action Research (CAR). They analyzed five years of decision‑making logs (444 feature decisions) from the B2C company, complemented by interviews with key stakeholders. This empirical base yielded three core findings that shaped QREME: (1) QRs require multi‑release planning; (2) different QR categories demand different governance styles; (3) a combination of forward and feedback loops is essential. The model was iteratively refined through workshops and traceable documentation.

Two exploratory case studies illustrate QREME’s applicability. Case A involves a consumer‑oriented software product focusing on user experience, performance, and security. Case B concerns a B2B image‑analysis system where performance, security, and maintainability dominate. In both cases, participants reported improved visibility of strategic versus operational decisions, more systematic QR scoping, and faster reaction to market changes after adopting QREME.

The authors discuss validity threats using Yin’s four validity dimensions and Runeson & Höst’s guidelines. Construct validity is supported by multiple data sources; internal validity acknowledges possible confounding factors when the model is applied outside the studied context; reliability is enhanced by thorough documentation of the model‑building process, though interpretive subjectivity remains; external validity is limited, as the model is derived from a single large organization, necessitating further validation across diverse domains and organizational sizes.

In conclusion, QREME offers a structured, dual‑loop framework that integrates strategic product planning with data‑driven feedback, enabling more effective QR management across portfolios and releases. The authors suggest future work to (i) test QREME in varied industrial settings, (ii) develop tool support for automating the feedback loop, and (iii) quantitatively assess the model’s impact on time‑to‑market, quality improvement, and stakeholder alignment.