Requirements Engineering is the process of defining, documenting, and maintaining requirements in the engineering design process.

It involves really trying to find out what your customer wants.

It's sadly more than often forgotten, especially in agile environments.

Really going deep with your customer can be a great thing.
Your customer has a vision in mind that he or she might not be able to clearly communicate.

As someone who develops software to solve problems for your customer, it's your job to find out what that vision really is.

Requirements Engineering involves techniques and processes to build that vision up for both of you, so that each side understands the goal of a software project, what exactly is needed, and what maybe even isn't.

The usage of graphical models and text is highly encouraged as a way to help the communication between you and your customer.
This way everything is also documented and can be verified by your customer.
If something is not as ordered later, you still have your documentation.

In agile environments, there's often not much room for Requirements Engineering, as smaller parts of the vision are communicated as sprint goals, and then get worked at.
Actually combining both methods with one another can be considered an art-form.

It's still worth, however, to take some time and learn about RE.

Even if you don't use it later, because you are working in an agile environment.

A lof of the techniques of talking to people and how to deal with stakeholders apply to situations outside of the RE process.

And a lot of the diagram models like UML suggested and acticely used within RE are a great form of documenting software itself.

Even if you don't use them for RE. Why not use a UML class diagram to document your interface DTOs instead of building a table next time?