As a couple others have commented, this post seems a little muddled, and there is a huge formal set of work in the world dealing with what Requirements are, how to elicit them, and then work on design. For example, see the INCOSE Requirements Working Group [0], and their Guide to Writing Requirements [1].

It’s key to remember that the requirements of a Thing are the WHAT and not the HOW. Keep the requirements separate from the Design, then the requirements can stay pretty short and sweet.

It takes a very specific type of engineer or analyst to be able to think at this level of abstraction and not jump into solutionineering (design) when trying to establish exactly what the stakeholders want the system to do.

[0] https://www.incose.org/incose-member-resources/working-group...

[1] https://www.incose.org/docs/default-source/working-groups/re...