Requirements Engineering: Pros and Cons

Requirements Engineering

Pros and Cons

Requirements Engineering: Pros and Cons

Have you ever worked on a comprehensive and complex software development with different parties involved and a long lifecycle to develop? Then, a fundamental planning of processes, documentations and requirements prior to this project is crucial. So called Requirements Engineering (RE) is an expansive term within the framework of a project meaning to gather everything you need in advance to make this project a successful one.

Indeed, it is so intricate that people can easily lose their way in no time at all. Over the next couple of weeks I will introduce you to some fundamentals of RE, Do's and Don't and like to share plenty of my working experience with you. Today, I would like to start with an example project.

Situations RE is Used

I have often noticed that both the customer and the service provider generally steer clear of requirements engineering and view it as price gouging. For instance, tenders created by customers will already incorporate requirements analysis, as any tender that does not state what is needed will be a waste of paper. Only by defining what must be produced will it be possible to identify the right candidates. Other examples in which RE is inevitable, besides classic projects in various industries, are negotiations between two parties to a contract in which they gradually harmonize what each of them wants; car configurations to ensure that the future owner is pleased with the individual features; or the planning of a birthday party to surprise and delight the person celebrating.

So basically, RE is used in some shape or form every day – although it is rarely described by this name. As a rule, RE is consciously used whenever the parties realize far too late that they have misunderstood what each of them wants – for example, when the business application is already finished but the users shun it due to a variety of shortcomings.

Running Projects Without Using RE

All too often in IT projects, a new technical application will be partly or completely rejected by the target group. From experience, the most common reason for this is the lack of requirements engineering. The service provider does not understand or grasp what the customers want, and the customers are unable to express themselves in a manner that is intelligible to the service provider. And to make matters worse, what the customer wants is not necessarily what the customer needs. And the biggest difficulty of all is to identify what is truly required, instead of just implementing what was said or how it was understood.

As long as you don't know what your customer expects, you will almost certainly make the wrong choice, unless you flip a coin to define the customer expectations – in this case your chance to make the right decision is at 50 percent. It follows, therefore, that requirements are intrinsically linked to expectations and hence to objectives as well. All these things need to be clarified before starting the project.

If you do not clarify the requirements and expectations, you will encounter resistance time and again and even more frequently as the project progresses, accompanied by the following questions and statements:

  • Why did you do it that way?
  • Why can’t I see X at this point?
  • Who told you to put that thing there/insert that color?
  • Well, our experts would have done it this way …

These questions and statements will eventually derail any project, because – sooner or later – you will be unable to provide adequate answers seeing as you neglected to record and document the requirements from the beginning.

Situations RE Should be Used

RE should be used deliberately far more often. It is not always necessary to apply each of the steps down to the last meticulous detail, but certain basic principles ought to be implemented in every project. In the course of my work in this field, I have managed several projects and have noted the following situations in which RE could have worked out:

  1. I have not worked with the customer before
  2. I have not worked in this sector before
  3. The regional circumstances are new to me (generally only relevant in other countries in Europe), e.g.: the religion, cultural customs, language
  4. I am unfamiliar with the project at hand, e.g. if I have never designed a contract management tool
  5. I am unfamiliar with the project on behalf of this customer, e.g. the customer wants to launch a new project

The attentive reader will recognize that RE only becomes unnecessary if I was personally responsible for the project groundwork, e.g. for the contract management tool, on behalf of this customer, although even then I would assume that the customer will arrive carrying a series of new and different requirements.


In the end this means that there are either no reasons why RE shouldn’t be used, or at least none that I can think of. RE makes sense in any professional or personal project, even if it is restricted to a one-hour brainstorming session, resulting in three requirements, e.g. for a new terrace:

  1. Material: Wood
  2. Location: Half in the shadow, close to the stream
  3. Size: Enough space for three sun beds and a large dinner table with four chairs

Are you curious to learn more about how to start your project wisely? Then watch out for Part 2 of this series where I will show you one way (but certainly not the only one).

Looking for Support With Your IT Project?

Would you like individual advice, or do you have questions about project management in your company? No problem. We are happy to assist you.

Contact Us
  • User Productivity, IT Market
  • Strategy

Comment on this article

Leave a comment to let us know what you think about this topic!

Leave a comment


Henrik Krumbholz

Senior Consultant

Microsoft SharePoint

Related Articles


Why Teams Breakout Rooms are a Game Changer for Collaboration

Several new updates to Microsoft Teams Breakout Rooms have been rolled out in an effort to make the workplace more productive than ever. Learn more.

Principles for Working with Microsoft 365
  • 14 April 2021
  • Herbert van Sintemaartensdijk
  • User Productivity, Digital Transformation
  • Future Workplace, Microsoft 365

Principles for Working with M365

Four principles to consider when setting up and working with Microsoft 365.

IT Insights in March 2021 | SoftwareONE Blog

IT Insights in March

The tech world is such a rapidly developing field that it may sometimes be hard to stay up to date. With our monthly IT insights, you won’t lose the overview. Read about the latest vendor news and trending topics.