Landon Oy

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?