Requirements Engineering

Major Steps to Start With RE

Requirements Engineering: First Major Steps

  • 13 May 2020
  • 6 minutes to read

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. In Part 1 of this series, we discussed the pros and cons of Requirements Engineering . However valuable that knowledge may be, the question still remains how to get the ball rolling in a meaningful way. Generally speaking, many people already use requirements engineering fairly well and largely intuitively, although there is certainly room for improvement here or there. To make the individual steps more accessible, I would like to introduce a model project that I will return to repeatedly in my blog posts.

The Model Project

The project we will use as an example in the blog series involves planning a team event. A team of ten people (including 1 team leader, who is also the project manager) wants to celebrate their well-earned accomplishments of the last 12 months by organizing a get-together. It is not clear whether everyone can contribute to the planning, so the team leader – and therefore the project manager – decides to organize a two-day team event.

The project manager starts by asking himself two important questions:

  1. Who has a legitimate interest in the team event?
  2. What do we need to make the team event successful?

Communication Difficulties with the Customer

These two questions lead to the following three points, which I always address right at the beginning of a new project:

  1. Create a basis for communication
  2. Identify and include the stakeholders
  3. Define and write down the aims

I always decide on a case-by-case basis whether I will work on these three points in the same order for each project. Most commonly I will create a basis for communication during discussions with the customer. We use these occasions to identify misunderstandings or define technical terms, which are written in a shared glossary as a means of developing a ‘common language’. In most projects the glossary – which needs to be kept-up-to-date and valid throughout the project (or even beyond) – will contain various technical terms, abbreviations and synonyms, as well as the frequently more important homonyms.

Who are the Stakeholders?

Answering question 1 reveals the identity of the stakeholders (who has a legitimate interest in the team event?). Stakeholders are of vital importance to the project’s success and are not necessarily always people. A stakeholder has a legitimate interest in a project if he or she, for instance

  • intends to use the outcome,
  • funds the project, or
  • is a mandatory regulation.

The general rule of thumb for the number of stakeholders per project ranges between two or three. In our case it would probably be the team, the team leader and possibly the company. In reality, though, the actual number is at least three times higher. The stakeholders in our model project might be, to name just a few:

  • team members
  • the team leader
  • employees in other departments/teams if they work on shared projects
  • the company, as the employees will be ‘absent’ and it will have to fund the event
  • the employees’ families, usually their life partners and children
  • event providers, e.g. go-kart tracks, restaurant owners, hoteliers
  • insurance restrictions, laws
  • heads of department to approve the team event

We would doubtless come up with a few more stakeholders if we invest the time, but the above list should be enough for now.

Type Natural person,
legal person,
system or
First name Only sensible for persons
Contact If different to the person or it is a regulation
Relevance High
Function / Role User,
Project manager
Available when / where?  
Area and extent of knowledge  
Aims and interests in the project  

I could write down the following for the team leader in our model project:

Type Natural person
Name Leader
First name Team
Contact Team leader
Relevance Normal
Function / Role Project manager
Available when / where? Workdays from 8:00 am to 6:00 pm, room R1234
Area and extent of knowledge Has already organized several events
Experienced in the company’s organizational workflows
Aims and interests in the project Satisfied and relaxed staff
Greater cohesion within the team
Phone +12 345 678

The information might be as follows for a normal team member:

Type Natural person
Name Member
First name Team
Contact Team member
Relevance High
Function / Role User
Available when / where? Workdays from 10:00 am to 4:00 pm, room R5678
Area and extent of knowledge New in the company and still open to many things
/Very active and sociable
Aims and interests in the project Active and outdoorsy team event
Not too many days because of family and children
Phone +12 345 678


We have now examined one of the two most crucial aspects: who is important for my project? We have also learned to keep a glossary to avoid misunderstandings. I will only be able to ask the right people or read documents once I have identified who will ultimately determine whether or not the project is successful. This is the starting point for all my future goals, which I will identify with question two and will answer in Part 3 of this series.

Looking for Support?

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
  • IT Market, User Productivity
  • Strategy, Specification, Requirements Engineering

Comment on this article

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

Leave a comment

Related Articles

M365 Enterprise Search – Search and find at its best

The new way of searching information of any kind across your enterprise regardless of the systems used. A guide to Microsoft's new Enterprise Search.

An Introduction to Application Development
  • 16 September 2021
  • Blog Editorial Team
  • application services, Future Workplace, User Productivity, Digital Transformation
  • Application Modernization, Digital Transformation

Outdated applications are not a necessity - An introduction to application modernization

What application modernization options are available? How does such a project proceed? We show you how applications can be made performant again.

  • 19 July 2021
  • Jochen Wilde
  • Unified Communications, User Productivity, Future Workplace, Digital Transformation

UCNext – a modular support for new communication channels

For the digital linking of communication and collaboration, UCNext offers a reliable foundation for your UC infrastructure with connectable modules.