Many companies have started fixing their operations from back to front. First it was bug fixes really, then testing and now many have looked their development process approach and gone into agile methodologies.
This is good, but why don't you do like the Engineering text book tells you: Place your bets in the front end of the process, and everything else will follow.
Writing good requirements makes the project start on the right foot, and having good portfolio management gives your focus to the best-value-for-the-customer decisions.
It all sounds very easy but not many companies are actually doing this well. And these companies do not even themselves know their shortcomings.
Requirements Engineering has many names. Terminology is not consistent, and many companies use terms based on their historical developments in the company.
We define the terms in academic sense later, but a senior leader should view Requirements Engineering/ Management/ development as one of your companies key processes.
Why, well just simply because the requirements are the vehicle from your customers to your product - what are the features that fulfill the customer needs?
Additionally, requirements actually define the work you and your staff are doing. Too many requirements in, and you have an implementation problem.
We have noticed that many companies “front-load” their projects so that they would actually get more out in finished features if they would put less things to do as an input.
Customers have either visible or hidden needs and you as a company have the answers in the form of functionality being built, hence the work that is done either in waterfall, or increasingly in agile format projects/ programs. Keeping track on your requirements, and their priority is essential in operative product development!
Additionally it is curious how often we hear that testing is bad and the process and tools needs to be renewed. This might be the case, but often enough there is no reference to requirements. Namely often inefficient testing is due to missing (non-functional) requirements. "system is fast" as a requirement is a bad basis for good test cases. Often i.e. boot up time, time to pair the bluetooth connection etc are missing. Well, how then one could test the system?