8  The Requirements Engineering Process: An Overview

This chapter introduces Part II, which focuses on the requirements engineering process.

We frame software development as a means of changing the world and present the six phases of requirements engineering in that context:

1. Initiation – Scoping the problem.
2. Exploration – Understanding problems and exploring solutions.
3. Decision – Scoping the solution.
4. Formulation – Working out the details.
5. Quality Assurance – Checking the quality of requirements.
6. Evolution – Managing changes.

The following chapters describe each phase in detail.

8.1 Changing the World

To understand requirements engineering, it is useful to consider the fundamental purpose of software development. What are we really trying to accomplish when we develop software?

In his book User Story Mapping, Jeff Patton provides a though-provoking answer:

“Our job as software developers is not to develop software—our job is to change the world!”

At first, this may sound like an attention-seeking hyperbole—a satirical nod to the arrogance of some tech entrepreneurs. Yet beneath the exaggeration lies an important truth. The quote reminds us that software development isn’t about the software itself—it’s about the outcomes it enables. Software is always a means to an end. Its true value comes from the changes it creates in the world—whether by improving lives, preventing accidents, helping organizations succeed, or making everyday tasks easier.

Patton’s statement also implicitly echoes Zave and Jackson’s ideas about The World and the Machine (Chapter 2). It reinforces their core argument that the purpose of the machine is to be found in the world.

The World Now and Later

This idea that our job is to change the world provides a useful perspective on software engineering, illustrated in Figure 8.1.

Figure 8.1: The Big Picture – How to Change the World (adapted from (Patton 2014))

Changing the world requires considering two distinct worlds: the world as it exists today and the world as it will be after the new software is deployed. We refer to these as the world-as-is and the world-to-be.

In the world-as-is, people may struggle with the technologies they use or face other challenges: tasks may be difficult to perform, businesses may be underperforming, and accidents may occur. Some aspects may be working well, but the world-as-is is also full of problems, dissatisfactions, and opportunities for improvement.

Requirements engineering involves understanding the world-as-is and imagining the world-to-be. Ideas for the world-to-be may include a new software product, enhancements to an existing software system, or adjustments to work practices and the surrounding environment. Not all ideas involve creating or modifying software. Moreover, when they do, those changes often also require modifying parts of the world—such as work processes—at the same time.

Maximising Impact, Minimising Effort

Requirements engineering also involves deciding which ideas to purse and determining which features and qualities to incorporate into the software.

Our goal when developing software is to maximise its positive impact on the world: we want planes to be safer, ambulances to arrive faster, etc. In the world-to-be, we will assess whether we have been successful by measuring outcomes: Has the number of plane accidents decreased? Do ambulances arrive more quickly? etc.

At the same time, we want to minimise the effort required to achieve these outcomes. Realizing the same outcomes at a lower cost-by implementing fewer features or writing less code-is preferable.

As software engineers, we strive to write code that delivers the greatest positive impact while avoiding unnecessary effort. In short, our aim is to maximize impact and minimize effort.

A central part of requirements engineering is therefore making informed decisions about what software should be built in order to achieve the greatest impact with the least effort. These decisions are often challenging, characterized by uncertainty, conflicting opinions, and competing interests. Requirements engineering provides structured approaches to address these challenges.

8.2 The Six Phases

Requirements engineering activities can be divided into six main phases (Figure 8.2):

1. Initiation – laying the groundwork for subsequent phases by defining project goals and scope.
2. Exploration – studying the world-as-is and generating ideas for the world-to-be.
3. Decision – selecting which ideas will be implemented.
4. Formulation – creating detailed, testable requirements for the software features to be delivered.
5. Quality Assurance – evaluating the formulated requirements for qualities such as completeness, relevance, clarity, and testability.
6. Evolution – after deployment, assessing the software’s impact on stakeholder goals, monitoring changes in the world, and identifying opportunities to improve goal satisfaction and adapt to evolving needs.

Figure 8.2: The Six Phases of the Requirements Engineering Process

All six phases apply to every project, regardless of its context (e.g., waterfall or agile). However, different projects will progress through the phases at different speeds and using different practices and techniques.

The phases are presented in a linear order, indicating that earlier phases precede later ones. However, this does not imply a strictly sequential process. We never complete a phase entirely; instead, we move through the phases in waves, with frequent back-and-forth between phases — like waves during a rising tide. This means that while working on one phase, we may still revisit and refine work from earlier phases. For example, during the Decision phase, we might return to Initiation and Exploration phases to address gaps uncovered while making decisions. Like all models, the six-phase model is a simplified representation of reality. Other models of the requirements engineering process are discussed in the end-of-chapter notes.

Phase One: Initiation

The Initiation phase lays the foundations for all subsequent phases. It is a brief phase, typically lasting from a few hours to a few days, with the primary goal of defining the project’s goals, scope, and stakeholders. This involves:

• clarifying the desired impact on the world (project goals).
• determining which aspects of the world need to be understood and could potentially be changed (project scope).
• identifying who will be affected by, or contribute to the project (project stakeholders).

This phase is also known as the “initiation phase” or the “preliminary phase” in various project management or enterprise architecture frameworks.

The Initiation phase is critical to a project’s success. If done poorly, it leaves the project without a clear vision, increasing the risk of failure. When done well, it sets the project on the right track, making all subsequent requirements engineering and software development phases far easier to manage.

Chapter 9 will introduce practices and guidelines to support this phase. These include techniques for defining meaningful domain goals at the right level of abstraction, describing the project scope with context diagrams, and identifying stakeholders using a stakeholder onion diagram.

Phase Two: Exploration

Once the project goals and scope are defined and the main stakeholders identified, we can begin the Exploration phase. Its purpose is to understand the world-as-is and generate ideas for the world-to-be.

Traditionally, this phase is known as requirements elicitation, though other terms such as requirements gathering and requirements discovery are also commonly used. However, these names can be misleading, as they imply that requirements are simply collected from people. In reality, this phase has a broader objective: not just identifying requirements, but deeply understanding the world-as-is and actively generating ideas for the world-to-be.

Understanding the world-as-is means understanding how people see the world (their perspectives), how they talk about it (their terminology), and how they perform their tasks (their processes). It also means identifying the problems they face in the world-as-is, as well as their hopes and concerns for the world-to-be.

Generating ideas for the world-to-be means envisioning concrete changes, either to the machine or the world, to better achieve the project goals. Changes to the machine can include new software features, modifications to existing features, or improvements in qualities such as performance and reliability. A single idea may involve changes to both machine and the world. For example, introducing a new software feature while adjusting the associated work process. Some ideas may not involve any software development at all.

This phase is about generating ideas, not requirements. Not all ideas will be implemented. In the next phase, the Decision phase, we will evaluate these ideas and determine which ones to implement.

A critical function of the Exploration phase is stakeholder engagement—proactively involving and communicating with all persons affected by the project. Failing to engage with key stakeholder groups during requirements exploration is a major risk to a project success. Without proper involvement, you may misunderstand their needs, overlook the importance of some of their concerns, and develop a system that fails to achieve some essential goals. Conversely, genuine stakeholder involvement significantly increases the chances of success. People are far more likely to support the project if they understand its goals and have contributed ideas on how to achieve them.

In Chapter 10, we will examine the challenges of requirements exploration and introduce techniques that requirements engineers use to address them. These techniques include:

• Background research and literature reviews;
• Interviews and surveys;
• Requirements workshops such as domain storytelling, impact mapping, and user story mapping;
• Observations;
• Data collection and analysis;
• Prototyping;
• Modelling the world-as-is and world-to-be.

Phase Three: Decision

Once we have understood the world-as-is and generated ideas for the world-to-be, the next phase is to decide which ideas to implement. This involves deciding the features and qualities that the software should have in the world-to-be.

Two important factors in making these decisions are the predicted cost and the expected impacts of each idea. Predicting cost is difficult because of uncertainty about implementation challenges. Likewise, predicting impacts is challenging. It is often hard to foresee how a new feature will be used and what broader effects it may have on the world.

Requirements decisions must also deal with conflicting stakeholder needs. Some ideas that are favourable to one group of stakeholders may be unfavourable to another.

Chapter 11 will describe common techniques for requirements decisions. These include:

• Requirements prioritisation techniques to establish priorities between the features to be implemented;
• Strategic release planning techniques to plan which features to deliver in multiple future software releases;
  
• Qualitative and quantitative evaluation techniques to analyse the potential impact of software features and qualities on stakeholder goals.

Phase Four: Formulation

The output of the Decision phase is a list of features and qualities for the next software version. During the decision phase, these descriptions remain relatively vague and usually lack detailed descriptions of desired behaviors and quality attributes needed for the software design, implementation, and testing.

The objective of the Formulation phase is to transform feature descriptions into detailed, testable requirements.

In some projects, requirements engineers define these testable specifications upfront before handing them to the development and testing teams. More commonly, however, the product owner, developers, and testers collaborate to co-define detailed requirements just before implementation begins. In this context, developers and testers play an active role in formulating the requirements.

Common requirements formulation techniques include:

• Requirements templates;
• Specification by examples;
• Goal-oriented requirements specification;
• Formal specification.

We introduce these techniques in Chapter 12 and provide detailed guidance on goal-oriented requirements and specification by example in Chapter 19 and Chapter 20, respectively.

Phase Five: Quality Assurance

The purpose of the Quality Assurance phase is to evaluate the formulated requirements for qualities such as completeness, relevance, clarity, and testability.

During this phase, we check for defects that could lead to system failure, create implementation challenges, or cause testing difficulties (see Chapter 4 for an explanation of common requirements defects). When defects are found, software engineers engage in an iterative process to evaluate their severity, fix them, and recheck the requirements.

Checking requirements quality before implementation can save significant time during later development and testing phases. It also improves the system’s overall quality and reduces the risk of failures.

However, requirements are never perfect. A key challenge of this phase is determining when they are “good enough” to proceed with implementation.

Techniques for requirements quality assurance include:

• Requirements reviews: A process where reviewers manually inspect requirements prior to implementation.
• Goal-oriented analysis: A set of techniques for evaluating requirements completeness and relevance with respect to goals, and robustness with respect to obstacles to goals, assumptions and requirements.
• Formal analysis: A set of automated techniques for simulating and verifying requirements expressed in a formal specification language.

These techniques are described in Chapter 13.

Phase Six: Evolution

The Evolution phase begins after the requirements are implemented and deployed. Its primary objectives are to evaluate how well the software satisfies stakeholder goals and to respond to changes.

Once deployed, the software’s impact on the world can be evaluated by observing the system, collecting data, and gathering feedback. Real-world operation may also validate or invalidate initial domain assumptions. The insights gained from this evaluation can then initiate a new requirements engineering cycle to explore, decide upon, and formulate requirements for the next software version.

During this phase, changes in stakeholder needs or context may also necessitate a new requirements engineering cycle. For example:

• New regulations may be introduced, or existing regulations modified.
• Stakeholder priorities may shift.
• Emerging technologies may present new opportunities.

Responding to these changes requires a careful analysis of what requirements need to be changed, as well as assessing the costs and impacts of those changes–both on the world and the software.

Due to the scale and complexity of most software systems, propagating requirements changes often present a significant information management challenge. Changes must be propagated to the system design, code, test cases, documentation, and user manuals. For instance, a single regulatory change, such as a new clause in the EU General Data Protection Regulation (GDPR), might ripple through the code, test cases, and documentation of numerous system features.

Techniques for managing requirements evolution include:

• Run-time monitoring of goals, requirements and assumptions.
• The collection and analysis of stakeholders’ feedback.
• The use of traceability to support change impact analysis and change propagation.

Early-phase vs. late-phase requirements engineering

Requirements engineers distinguish between “early phases” and “late phases” requirements engineering.

The early phases are the first three phases: initiation, exploration, decision. The focus is on deciding what software features and qualities will best serve the stakeholder needs. These activities are primarily lead by business analysts or systems engineers, with software developers playing a minor role, if they are involved at all.

The late phases are the last three phases: formulation, quality assurance, and evolution. The focus during formulation and quality control is on producing detailed, testable requirements suitable for rigorous analysis, design, and testing. Software developers and testers play a much larger, and sometimes leading, role in these phases.

8.3 Notes and Further Reading

Section 8.1 is based on a discussion of the purpose of software development in Jeff Patton’s book on User Story Mapping (Patton 2014) . User story mapping is a technique for requirements exploration and decision covered in Chapter 10.

Real-world requirements engineering processes are inherently complex and can often be chaotic. The six-phase model serves as a simplified representation of these messy realities, designed to be easy to learn and broadly applicable across diverse contexts. While requirements engineering resists one-size-fits-all solutions (as discussed in Chapter 6), these six phases are sufficiently general to accommodate most projects. As noted in Section 8.2, the pace of progression and choice of techniques within each phase will depend on the contextual factors discussed in Chapter 5 and Chapter 6.

The six-phase model builds on the requirements engineering process described in Axel van Lamsweerde’s book (Lamsweerde 2009). It extends that process by adding a preliminary Initiation phase, which corresponds to the initial Project Blastoff phase in the VOLERE requirements process (Robertson and Robertson 2012). Table 8.1 summarizes the correspondences between the six-phase model, van Lamsweerde’s requirements activities, and the VOLERE process.

Table 8.1: Relation of the six-phase model to other requirements process models.

The 6-phase model	Requirements Activities (Lamsweerde 2009)	VOLERE (Robertson and Robertson 2012)
Initiation	n.a.	Project Blastoff
Exploration	Domain Understanding and Requirements Elicitation	Trawl for Knowledge, Prototype, Reuse
Decision	Requirements Evaluation	n.a.
Formulation	Requirements Specification and Documentation	Write the Requirements
Quality Assurance	Requirements Quality Assurance	Quality Gateway, Review
Evolution	Requirements Evolution	n.a.1

Table 8.1 refers to the original VOLERE process (first three editions of “Mastering the Requirements Process”), a widely used method in requirements engineering. The 2024 fourth edition introduces major revisions, such as a stronger focus on prototyping and iterations, which will be discussed later.

The requirements process is often illustrated as a spiral to emphasize its risk-driven, iterative, and incremental nature (Lamsweerde 2009). While Figure 8.2 presents the six-phase model as a linear process, Figure 8.3 provides an alternative spiral representation. This visualization adapts van Lamsweerde’s established requirements engineering spiral, reformulated in the terminology of the six-phase model.

Figure 8.3: The six-phase model represented as a spiral process - Adapted from (Lamsweerde 2009) using six-phase model terminology

The six-phase model can also be related to the traditional taxonomy of requirements engineering activities shown in Figure 8.4.

Figure 8.4: Traditional Taxonomy of Requirements Engineering Activities (Wiegers and Beatty 2013; Washizaki 2024)

Requirements engineering is composed of requirements development and requirements management.

Requirements development focuses on establishing agreement about the desired behavior and qualities of the software. It includes:

• Elicitation: Gathering information about stakeholder needs, the application domain, and the envisioned system from stakeholders and other sources.
• Analysis: Clarifying, structuring, and evaluating the elicited information, along with prioritizing requirements, resolving conflicts, and assessing feasibility.
• Specification: Documenting the software requirements to serve as a definitive reference (or “ground truth”) for the agreed-upon features, their required behaviours and qualities.
• Validation: Ensuring the documented requirements are clear, precise, testable, and accurately reflect stakeholder needs while remaining feasible for implementation.

Requirements management involves maintaining these agreements over time. This includes:

• Managing changes to requirements,
• Maintaining traceability between requirements and related artifacts (e.g., design, code, tests),
• Ensuring alignment with stakeholder needs and project goals throughout the software lifecycle.

In practice, these activities are highly intertwined. For example, during the Exploration phase, understanding the world-as-is and generating ideas for the world-to-be require both elicitation and analysis-that is, the simultaneous gathering, clarification, and structuring of information. Similarly, during the Formulation phase, defining precise, testable requirements involves elicitation and analysis in combination with specification.

Table 8.2 maps each of the six phases to its main activity and the other significant activities that typically occur within it.

Table 8.2: Mapping requirements activities to the six phases

Phase	Main Activity	Other Significant Activities
Initiation	Elicitation	Analysis
Exploration	Elicitation	Analysis
Decision	Analysis	Elicitation
Formulation	Specification	Elicitation, Analysis
Quality Assurance	Validation	–
Evolution	Requirements Management	–

This mapping is approximate because the activities have slightly different interpretations across sources. For example, some classify requirements prioritization as part of requirements analysis (Wiegers and Beatty 2013), while others consider it a requirements management activity (Washizaki 2024). Moreover, requirements management could be viewed as spanning all phases since it includes continuous management of change and the ongoing maintenance of traceability for all information generated throughout the requirements process.

Lamsweerde, Axel van. 2009. Requirements Engineering: From System Goals to UML Models to Software Specifications. John Wiley & Sons.

Patton, Jeff. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. O’Reilly.

Robertson, Suzanne, and James Robertson. 2012. Mastering the Requirements Process: Getting Requirements Right, 3rd Edition. Addison-wesley.

Washizaki, Hironori, ed. 2024. Guide to the Software Engineering Body of Knowledge (SWEBOK Guide). 4.0 ed. IEEE Computer Society. http://www.swebok.org.

Wiegers, Karl, and Joy Beatty. 2013. Software Requirements, 3rd Edition. Pearson Education.

---

1. Refers to the original VOLERE model, not the latest edition.