Theory

The NaPiRE initiative, through repeated global surveys of requirements engineering practitioners, produces the “Status Quo” theory about what is common practice in requirements engineering.

Reading the Theory

The theory consists of several sets of binary propositions, which - when supported - imply a common practice in requirements engineering. The following tables list all of these propositions and their evolution across the major iterations of NaPiRE:

• 2012: Fernández, D. M., & Wagner, S. (2013, April). Naming the pain in requirements engineering: design of a global family of surveys and first results from Germany. In Proceedings of the 17th International Conference on Evaluation and Assessment in Software Engineering (pp. 183-194).
• 2014: Wagner, S., Fernández, D. M., Felderer, M., Vetrò, A., Kalinowski, M., Wieringa, R., … & Winkler, D. (2019). Status quo in requirements engineering: A theory and a global family of surveys. ACM Transactions on Software Engineering and Methodology (TOSEM), 28(2), 1-48.
• 2024: Wagner, S., Mombrey, C., Frattini, J., Mendez, D., … (2026). Status Quo in Requirements Engineering: An Updated Theory and Longitudinal Perspective. Under Review.

Interpret each cell in the tables (i.e., each combination of proposition and year) as follows:

Theory

Elicitation

Elicitation refers to one of the core activities in requirements engineering, where requirements are obtained from its various sources, i.e., relevant stakeholders.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E1 (for P1, P3, P5, P51, P52): Interviews, prototyping, observations, experimentation with users, and document analysis allow requirements engineers to include many different viewpoints, including those from non-technical stakeholders.
• E2 (for P3, P52): Prototypes and experimentation with users promote a shared understanding of the requirements among stakeholders.

Documentation

Documentation refers to another one of the core activities in requirements engineering, where requirements are manifested in requirements artifacts which can be shared, versioned, and reused.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E3 (for P6, P7, P11): Free-form and constraint textual requirements are sufficient for many contexts such as in agile projects where they only act as reminders for further conversations.
• E5 (for P13): The quantification depends on the type of non-functional requirement. Performance is rather documented quantitatively while maintainability is rather documented non-quantitatively.
• E7 (for P53): Requirements knowledge is often tacit; engineers who are deeply familiar with the system may not perceive documentation as necessary.

Requirements Changes

Change management pertains to the constant challenge of keeping requirements up-to-date.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E6 (P14): In many development processes, requirements are fixed at some point(s) in time. A formal change management is only needed afterwards.
• E7 (P14a): In agile development process, change is continuous.
• E8 (P15, P16) Requirements change during a development project and also after the initial release. Many organisations only work with change requests in issue trackers. Agile organisations work with some kind of product backlog (as in Scrum) and change it regularly between iterations.
• E9 (P17, P18): Explicit traces make impact analysis more effective and efficient. P 17, P 18
• E10 (P19, P20): Despite traces between requirements and code, the effect of changes is most directly seen on the code level.

Test Alignment

To guarantee that a system meets its requirements, it is necessary to align them with tests.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E11 (P21-P23): To fully align tests with requirements, organizational and artifact-based measures are necessary to link requirements and tests.

Standards

Standards pertain to normative rules governing the RE process at a company.

Application and Tailoring of Requirements Engineering Process Standards

The NaPiRE initiative conjectured the following explanations for the propositions:

• E13 (P25, P26) Requirements engineering differs quite strongly over domains and contexts and, thus, needs to adapt to these to be effective.
• E14 (P25a): Many practiced development processes prescribe or are associated with a specific way of performing requirements engineering.
• E15 (P28): The project lead knows the specific of the domain and project context best.

Reasons and Barriers for Defining a Requirements Engineering Process Standard

The NaPiRE initiative conjectured the following explanations for the propositions:

• E16 (P30): An RE standard can help to integrate RE activities and artefacts with other development activities and artefacts.
• E17 (P31): It is more efficient to build or acquire tool support for RE if the activities and artefacts are standardised.
• E18 (P34): Standardised RE artefacts make it easier to check if they are created and, hence, support progress control.
• E19 (P35): If RE artefacts are standardised, then standardised QA can be used such as checklists or automatic checks.
• E20 (P37): If the project lead can rely on a standardised RE, then the planning can rely on the standardised activities and artefacts.
• E21 (P38): A standardised RE allows the project participants to become experts in it and, therefore, become more efficient.
• E22 (P39): The RE standard codifies good practices and experiences, which can be transferred to new projects and project participants.
• E23 (P40): An RE standard might force projects to a more complex RE process than necessary for the concrete context.
• E24 (P42): Using RE process standards is considered more efficient (see also P38).
• E25 (P43): People in general are resistant to change.

Requirements Engineering Improvement

Improvement is important for any software engineering practice and particularly for a volatile and complex part like requirements engineering.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E26 (P45, P46): Many companies have realised the importance of requirements engineering and of continuous improvement of development processes and methods.Working on it continuously helps to not forget strengths and weaknesses of the current RE approach.
• E27 (P47): RE improvement is performed by internally defined standards and best supported by an own business unit or role.
• E28 (P48): External normative standards are often considered too complex and elaborate to apply.

Communication

Communication is key to requirements engineering, both with external stakeholder, but also within the project team and the overall company.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E8 (P54–P57): Close and frequent interaction within the project team and with the customer promotes shared understanding and enables effective requirements elicitation and validation.

Handling Missing Information

Oftentimes, requirements engineering practitioners encounter lack of knowledge or missing information.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E9 (P58): Direct consultation of the customer is the most reliable way to resolve ambiguities and avoid incorrect assumptions propagating into downstream development.

Reaction to Unknown Documentation Benefit

The benefit of effort invested into the requirements engineering phase may not always be obvious to those investing it.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E10 (P59-P60): Practitioners distinguish between current utility and long-term essentialness; the perception that a document is essential for the project outweighs the lack of an immediately identifiable beneficiary.

Non-Functional Requirements

Non-functional requirements describe system properties and qualities beyond functional aspects of a system.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E12 (P61): These NFR classes correspond to widely recognised quality attribute categories, making them more likely to be systematically addressed during requirements engineering.

Stopping Criteria

Stopping the requirements analysis can occur for different reasons in practice.

The NaPiRE initiative conjectured the following explanations for the propositions:

• E13 (P62-P63): Collective agreement distributes the decision to stop requirements analysis across the team, reflecting shared ownership of the RE process; unilateral pressure from project leads is not accepted as a legitimate stopping criterion.