🔧 Requirements Engineering and its applications for Business Analysis

Requirement engineering is a systematic and disciplined approach to the specification and management of requirements with the following goals:

1. Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards and managing them systematically.

2. Understanding and documenting the stakeholders’ desire and needs, they specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.

As Stan Bühne, the managing director of the International Requirements Engineering Board, defined in an interview:

So for me, the requirements engineering is really about eliciting requirements, this means understanding user needs on the one hand; getting out of the users and stakeholders, what are their needs, and what do they really need that needs to be solved by software. And then documenting these requirements in a proper way that on the one hand, the stakeholders, mostly from business areas or business organizations, can understand and that we can create a kind of shared understanding with them. But also, on the other hand, that we have inputs for architects and developers, and they are able to shape the best solution and implement the software that is really needed.

That requirements are changing continuously because business is changing. People forget something and then there is another competitor coming up with some several new features and so on. Requirements Engineering is also about managing of requirements and important change management work and how to handle requirements looking for the real impact.

In the US, Requirements Engineers are usually called System Analyst.

For Stan, working with requirements is a form of engineering:

When talking about requirements, it is a kind of engineering because you need to be precise when documenting requirements. We need to create specification that will lead for architects and developers later on having something that they can really work with and that they can develop the right and fitting solution for their customers and stakeholders.

🏭 Requirements Engineering is applicable in any industry and especially in ones more sensitive for customers and regulations:

In theory, in general, requirements engineering can and should be used everywhere. Now, Requirements Engineering plays a major role in areas where you have an impact on people. So, for instance, in automotive industry, in the aviation, in medical domains

So let’s look in the automotive industry. They need requirements engineering because in the automotive industry you need to define your requirements properly. They most often don’t have them only text-based, they are using models for simulations. They need to be pre-signed. On the other hand, you need to know when you are doing a change, you need to know what is the impact and what things within the system need to be adapted. Traceability there is really handy. With it, you are sure if you change a certain requirement or if you change some measures on a requirement that you understand what is the impact outside of it and what is the impact to the user, to the driver, to a human being.

Requirements Engineering allows you to be sure that you have the accuracy to prevent certain negative impacts of changes:

And these [impacts] could be mankind-related, but this also could be financial. If you’re looking to the financial domain,there are a lot of regulations that need to be considered when developing systems. There engineering needs to look on not only on stakeholders as human beings, but also on stakeholders like regulations and laws. They need to be considered when defining the requirements for a system. Stakeholders should be made aware of regulations if there are any conflicts between business requirements and regulations.

Requirements Engineers can’t kill people, but their work is not less important for big picture business outcomes:

When I work as a requirements engineer, I don’t have any risks of killing people when defining wrong requirements. It was a good thing. When I was working telecommunications domain what could happen is that the bill was not correct, that some features were not available.

Most often at the end we are working with human beings and if you develop software for such people it doesn’t matter if it’s the sales system, this is a customer care agent, or whomever. They also have fears. They also need to go this change transition. From Business Analysis you know that you need to make people aware of changes, that change is not always bad, that change can also give some new opportunities.

This is the same for software development. If people are used to this system, it doesn’t matter how bad the system is at the moment. When there is something new, they have fears, and they need to be covered right in the beginning, because otherwise, when you just ignore such topics, then software will not be used at the end.

🧠 Requirements Engineering may be successfully used in Agile setting:

When I worked as a consultant, in the very beginning the organizations were trying to move from a plan-based approach to an agile approach, so they just thought: “Hey, we don’t need this requirements engineering stuff or testing stuff anymore. Just put a bunch of people in a room and they know what to do. And then everything will work out.” Big surprise – that does not happen.

Most companies learned step by step that the skills are still needed: skills for requirements engineering, for business analysis, but also for testing and so on. Maybe in another way, maybe in a kind of other frequency, maybe in another wait.

As Requirements Engineers we have to consider value orientation. For requirements we document certain things, we want to create a kind of awareness, common and shared understanding to reduce risk. This is exactly what should be done in agile environment too: you have several user stories that need to be discussed, you need to create a shared understanding and you need to kind of at least tiny documentation if the development is really done in-house. Most often development is not done in-house and this means you need far more documentation as it is a kind of contract with vendors: 1) that they know wat needs to be developed, and 2) that you have some kind of checklist and checkpoint to make your tests afterwards against. And this is really something that is also required in Agile.

When doing Requirements Engineering for Agile you can focus firstly on things that create value and you don’t have to define the of requirements for the whole system at once. You define an MVP and then you add new requirements step by step. Efforts then are more linear then a big upfront effort with waterfall. But at the end the job needs to be done.

The artifacts we are building are being shared with other humans who may not be in the same location that you are. And more and more you might have developers in one part of the world and testers in another part of the world, and customers in yet another part of the world. Many of Agile Frameworks suggest to get everybody into a room and it’s just not possible sometimes. When organizations introduce agile into their working environments they don’t often consider where the people are and how can BA make sure that everybody has what they need in order to do their work. Requirements engineering, particularly for systems development, is a very necessary part in reducing risk and providing people with what they need.

Many principles in Agile match with principles we have created for requirements engineering because at the end talk about common understanding before documentation. The way to document requirements, doesn’t matter as it is a vehicle to create a shared understanding. And this is also true when we talk about the source of truth in the implementation. But on the other hand, we first need to identify what is really needed. Some of the Agile principles were fit into Requirements Engineering as well.

🤝 There is a lot of synergies between Requirements Engineering and Business Analysis:

During my work as a consultant in requirements engineering, I also often have worked with business analysts. If you have new strategy for the entire business on how you want to sell your products, this is really something where you need someone who has some strategic analysis skills, who’s going into the details talking to business and looking at the existing processes: how they could be defined, or how are they working, and look what could be done a bit better. At a certain point in time these people want to support the business, say, as a consultant, and here we really need a kind of skills on how to define systems because. If you want to support business processes by IT the Requirements Engineering comes into action.

At the same time Requirements Engineers sometimes perform the research like BAs:

What I have done quite often in the communications industry, for instance, when a new sales process was designed by business owners and I was talking to the business:

— What do you think needs to be done?

— And this, and this, and this step.

— How can this be supported by a new piece of software?

And so on. There we have quite nice synergies in skillsets, because we are doing similar things, maybe with another focus. But we need to work hand in hand and we need to work together at the end to come up with the best solution at the end.

🪓 As opposed to usual functional/non-functional requirements types, Requirements Engineering splits requirements into three categories:

One thing is functional requirements. It’s about functionality that is provided by the system.

Non-functional requirements can be, in our point of view, quality requirements and constraints. Quality requirement is something that is really shifting or lifting the quality of the system. Could be performance, availability, security, reliability, whatever. In the ISO 2510 you have also a set of quality criteria for a system or for a system in use.

In addition, we have constraints. Constraints are requirements that limit the solution space. For instance, that we need to consider that a certain hardware or a certain operation system needs to be used, or a certain framework needs to be used for the development. It is necessary that they are met by the functional and quality requirements.

Requirements Elicitation is still one of the most tricky tasks for Requirements Engineering:

We have to, firstly, identify the right stakeholders and second to let them speak out.In the requirements engineering, we have different techniques for eliciting requirement like brainstorming, interviews, broad analysis, etc. So we also use the Kano model to see what each requirement really is: delighter, dissatisfier, and so on. If we want to search for requirements that the people are mostly not talking about, for instance, because it’s just their daily work, we need to use observation techniques just see what the user is really doing and how to account these requirements.

To collect Quality Requirements it’s a good idea to use industry-specific checklists:

This could be the quality model of ISO. They provide several categories and within this categories, they have different aspects that are considered by this model. Here as a requirements engineer you have something at hand to ask people about: Do we need to do something for interoperability? Does the system has to run on different platforms? What about scalability? What about the performance of the system? What is the time that a certain functionality has to respond to the user? You can ask these questions for each and every functional requirement if there is some quality behind.

For me it’s kind of a checklist. I’m using this quality model and I’m just going through functional requirements checking if there is some kind of quality aspects that are needed.

💭 Critical thinking is a really important part of the Requirements Engineering. There is newly established connection between AI and Requirements Engineering:

On the one hand, there is AI for requirements engineering. This means how can artificial intelligence support requirements engineering process. I think in the future, AI could support us in defining requirements in a proper form. In our SumaB we introduce templates just to have a clear structure of requirements, because every requirements document should be formulated in the same way. This is something that could easily be checked by kind of artificial intelligence.

AI may be also applies as some kind of prompt engineering: introduce a kind of AI persona to chat to. What needs to be considered that the requirements artificial intelligence is still artificial intelligence and that the requirements engineer talking with this tool needs to differentiate what is true and what is false. I think this will be a critical skill for Requirements Engineers in the future. And this truth AI develops needs to be validated with the real users somehow.

Another aspect is what needs to be done during requirements engineering when designing systems with artificial intelligence.

📚 There is a plenty of tools for Requirements Engineering:

There are big ones like DOORS from IBM. There are smaller ones like Catalyst. There are also many web-based tools that could be used without installing a bunch of software in your companies.

You can find a comprehensive list of tools for Requirements Engineering at MakingOfSoftware. IREB is a nonprofit organization based in Germany that focuses on promoting and improving the discipline of requirements engineering. It provides not only paid certifications, but a lot of free resources, such as:

• Requirements Engineering Magazine

• Number of free handbooks and syllabi

• Free self-assessment on CPRE and RE for Agile

• Requirements Engineering Glossary

Article based on the interview conducted by IIBA.