the concept of requirement design

the concept of requirement design

Requirement discovery, requirement modeling, and requirement design (design), Requirement engineering, requirement development, requirement management, requirement validation (testing),

(a) Requirements are not just “gathered”, they are “discovered”.
(b) Further, because new business applications are part of business process reengineering, so, requirements are not just discovered, they are “designed”.
(c) Also, even only for “documenting” legacy applications, if you do not try to think about the correct way, then, you can never understand the existing incorrect ways (their outcomes are correct only because of a lot of “workarounds”). And to “think about the correct way” is “design”.

(d) Perhaps “modeling” is a better word, in the sense that it differentiates the effort from lower level “software design”.
(e) However, “modeling” has too much association of “visual modeling”.
(f) Then, if you think about it, if we use “ubiquitous domain language” in programming, it is not that necessary to differentiate the “low level” design from the high level “product design”. It is all a continuum.
(g) As a result, I intentionally use the phrase “requirement design”, just as we say “product design” and “feature design”.
(h) Without “requirement design”, there is no way to understand the requirements, and no way to find missing requirements.