Working on requirements means working on other people’s predictions of their own future preferences, of others’ future preferences, and of future situations in which these preferences realize.
When someone says something as simple as “the system should do this, instead of that”, which looks like a requirement, this is only the tip of an iceberg.
Working with requirements means, in other words, working with a lot of data which is unstructured, unstable, and is about unobservable phenomena (other people’s intentions, beliefs, knowledge, desires, expectations, etc.). It means working in a setting where problems are unclear, solutions need to be made from scratch, and there is no definite and general notion of what an optimal solution looks like.
Understanding how people think about requirements, how they express them, how to design solutions to these requirements, how they evaluate if their requirements are satisfied, are only some of the many relevant questions.
Developing such an understanding also means that you will better understand how people solve unclear problems which have no available solution, how they make decisions as they do design and engineering.
Working on these topics thoroughly easily takes you to interesting places, such as philosophy of decisions, human psychology, communication, sociology, and economics, as well as software engineering, product and service design and management.
Having worked on this for almost 15 years, I am convinced that anyone who wants to understand how people work, could work, and should work together can benefit from learning about requirements engineering, that is, how to elicit, specify, analyze, evaluate, verify, validate, and negotiate requirements.