IREB requirements engineering. Processes and project management methodologies
Just as you can’t apply the same methodology to every project, there is no single universal requirements engineering (RE) process. It always needs to be individually tailored to the project at hand. The question is: do we really need to reinvent the wheel every time and configure all the elements of the requirements engineering from scratch? Fortunately, we don’t! We can fall back on available RE practices that offer helpful recommendations and configurations we can juggle with in different projects. One such practice is the IREB (International Requirements Engineering Board) template, which we will discuss in more detail below.
What are the benefits of a well-designed RE process?
Let us start with a simple question: why even bother configuring the RE process? Why follow any project methodology at all? The answer is simple: to systematise and structure our work. By establishing a framework for what we do, we can rely on tried and tested standards developed on the basis of good practices and experiences.
Requirements engineering and the entire software development process as such are based on project templates. In practice, this means that when we opt for this or that configuration, we will be acting in accordance with a given standard of collecting and documenting requirements. It would be inadmissible, for instance, for every analyst in a project to write requirements in a completely different form or for testers to work in one way and analysts in another.
Accordingly, agreeing on a methodology right at the outset of the project will allow us to sort out all the important issues and then proceed in keeping with a transparent template that defines, in advance, how requirements will be written and managed.
How to pick your software development methodology?
The IREB gives us clear guidelines on how to organise the entire RE process. They can even come in handy early on in the project when we are still learning about our client’s needs and objectives. But this is also the moment when it really makes sense to discuss our system development methodology, which will also impact the shape of our contract and all other formal matters.
Fortunately, we also have relevant IREB guidelines to help us out here. They tell us which factors influence the RE process and how they affect project development methodology. Requirements engineering (analysis) should be matched to the overall methodology and mode of work in the project.
Example: if the analysts decide they will be collecting requirements in a traditional, waterfall manner, while the entire team prefers to work incrementally (in scrum or agile), these two models cannot be reconciled. Such aspects have to be agreed on beforehand. If the entire team is to be agile, then testers, analysts and developers must all work in a single methodology.
Whether we choose a more traditional or agile path also depends on the context of the system, such as, for example, legal regulations (e.g. public tenders) or regulatory authorities that impose specific standards of work or documentation. This should also be considered when choosing the framework, so that at the end of the project we can deliver all the required documents and products.
Another issue to consider is how available our stakeholders are. In waterfall methodologies, stakeholders are usually available at the start of the project (analysis) and then only at the end (delivery). By contrast, in agile frameworks, they actively participate in the project from start to finish.
Of course, we can ask our stakeholders about their availability directly or draw conclusions from what we see. This is a good point of departure in talks with the client, where we should try to get a picture of how they envision their role in the project. Let’s not forget, though, that sometimes we will just have to tell them straight out how much contact, and when, we will need to have with the stakeholders.
Another, often problematic issue in waterfall projects is an expectation that stakeholders will define their requirements right at the outset. The question is: do they really have enough knowledge to formulate them? More often than not, all they have is a general idea of high-level objectives (e.g. they need to create an app with high-level functionalities but without any specific requirements).
This means that, at first, the requirements can be nebulous; they will only be pinned down in detail as the project goes along. However, this already gives us an idea of how to talk with the client, and in this case, the agile framework will fare much better than the waterfall approach.
Other factors that determine the choice of software development methodology include:
- the complexity and criticality of the system for the company;
- project duration and budget;
- requirement variability as a function of market evolution and competition.
It is important to keep in mind that if the variability is high, iterative deployment will be recommended.
Facets of the RE process in IREB
In the IREB methodology, the above factors are accompanied by so-called facets, or elements that we need to consider before we configure the process. IREB creators list three such facets that should determine our choice of methodology:
For each of the above, we need to pick one of two mutually exclusive options. For the time facet, we need to pick between linear and integrative; for the purpose facet, between prescriptive and explorative and for the target facet, between customer-specific or market-oriented. Configuring the process, i.e. deciding how we will work, requires us to choose one alternative for each facet, which can give us different feature combinations.
- The time facet defines how our requirements engineering is distributed over time. It can be linear (requirements will be set out in advance) or iterative, incremental (requirements will be narrowed down during the project). If we opt for the iterative approach, the recommended methodology would be agile (scrum, kanban), but if we prefer a linear process, we will be better off with traditional plan-based methodologies (waterfall, Prince 2);
- The purpose facet can have two modalities: prescriptive or explorative. The prescriptive approach means that the requirements specification is a kind of contract: all the requirements it lays down are binding and must be deployed. In an explorative process, by contrast, we know the purpose upfront and the requirements are defined as we go.
In outsourcing services or tendered development projects, companies usually opt for a prescriptive process. However, whenever the clients talk about their goals, rather than their requirements, and want to hammer out the details later, an explorative approach, i.e. an agile methodology, will be a better fit;
- The last facet to consider when choosing our project methodology is whether the target is market-oriented or customer-specific. The target is customer-specific when the system under development is to be used by a given organisation. Market-orientation means that the system is developed to be sold as a product or service.
Iterative vs linear
In a linear process, stakeholders list all their requirements in advance and specify the processes upfront. In contrast, in an iterative approach, we start from high-level requirements and pin down the details in cooperation with our business partner as the project moves forward.
Moreover, with the iterative approach, there is always the question of time (for iterative work to make sense, we always need to have enough time set aside). For a project where a feature or process are to be delivered within a month, for example, there is no space for iterative work. To meet the deadline, we need to have specific and detailed requirements spelled out in advance, which forces a linear process.
However, if it is important for our business partner to be able to make changes and juggle their requirements throughout the project, iterative processes will be a much better fit.
Prescriptive vs explorative
When deciding between a prescriptive and an explorative approach, we should ask ourselves: what matters more in the project: functionality and scope, or costs and deadlines? Of course, usually it’s everything all at once ?
In this situation, we need to take a closer look at our features and their scope. If we know a simplified, trimmed-down feature will be enough to deliver the first deployment within the deadline, let’s pick the explorative option. If, however, there is no wiggle room and the functionality is required as a whole, the prescriptive process will be a better pick.
Customer-specific vs market-oriented
With customer-specific processes, system users can be identified in advance. They are usually the employees of the company that has ordered the software in the first place; they are the people we need to collect the requirements from. Once collected, the requirements then need to be verified to make sure they deliver the expected value.
But for products that are meant to be released to the market and used by anyone who downloads or installs the app, system users are not so easily identified. We will only know them once they start using the app. This is why it is so important to collect user feedback as soon as possible after the software is released. This approach will be better served by agile methodologies.
Typical IREB configurations
IREB creators suggest three typical configurations that they think will work best for software projects.
Participatory RE process
A participatory process is typically iterative, explorative and customer-specific, and typically found in situations where the client commissions an application for internal use.
A process of this kind requires an agile methodology, and the configuration will mainly be used in settings where the commissioning party and the app/system developer intend to closely collaborate with each other, and stakeholders (e.g. business) are highly involved in requirements engineering.
What products are created in projects of this type? Prototypes, mock-ups, product backlogs or user stories, i.e. typical documentation elements required by the customer. As for communication, continual interaction between the development team and the business is required.
An important role is played by the product owner, or the person on the business side who is responsible for the direction and features of the system being developed. Sometimes, a proxy product owner may step in, especially when the PO as such is focused on content and business decisions but needs some project management support.
Contractual RE process
Another possible configuration combines linear, prescriptive and customer-specific approaches, and is typically found in a situation when a client commissions a system for their own use, but the team works within a waterfall framework. Accordingly, the contract between the customer and the developer is based on a requirements specification. Another difference is that the interaction with stakeholders, or business, will be limited. After the analysis stage, they will only show up for the release.
What documents and work products will we expect here? A classic system requirements specification, written documents, models, diagrams (UML or BPMN).
Product-oriented RE process
The third of the typical configurations is recommended when an organisation commissions a system that it will then sell to users. This is best matched by an iterative, agile process.
Work products will be very much like those in the first configuration type (backlog, stories, prototypes). The difference is that if the product is market-oriented and not for internal use, we will not have access to all the potential users. Consequently, we might want to organise a product discovery workshop or a UX survey.
In such projects, releases will be more frequent than in projects that develop an internal system.
The IREB offers a certain algorithm to better organise software project work between the customer and the developer. Of course, software houses that work on dozens, if not hundreds of projects, already know what matters most and to ask the customer at the outset so as to set up the development process well.
Understanding how to choose and configure RE processes in accordance with IREB guidelines allows companies to adapt to customer expectations while delivering well-defined processes.
This is of key importance, especially for companies that handle multiple projects, enabling effective work planning and communication with clients.