Turn Requirements Into First-Class-Citizens / Independent Objects

Being the driving factors for any application development, I find doing requirements right to be rather mission critical to Aha itself.

For example, one symptom as to why this idea is even needed is reflected in the category listing of an idea such as this: There currently is no category for requirements.

To me, the priorities for evaluating requests/ideas in terms of questions are (in this order):

1. Why?: the requirements, incl. business requirements and expected business value
   1. to discover the why behind the why: ask up to five times
2. What?: the capability/functionality/feature in terms of derived acceptance criteria
   1. but not in terms of...
3. How?: the eventual implementation in a solution, e.g. some button

Both customers and internal teams alike often tend to start at the bottom, and so it's crucial for both to walk their way up the list, ideally in a manner that has the requesting party internalize the need for doing so.

Here's the critical point though:

Requirements belong to point 1, not 2. and I believe it is critical to systemically capture requirements in exactly the same way as ideas or features, independently. As much as I like Aha!, I find the way it currently appears to cater for requirements capture to be rather unsuitable... unless one would maintain a "twin-requirements-product" for each actual solution, somehow tightly coupled with it (as was also suggested in the admin response of AFPR-I-7619), whose "features" actually represent requirements.

Requirements are never aspects or properties of features, but rather precede them. In that sense, a feature doesn't "have" requirements, but rather is defined by them. They are the chisels with which features are given their shape. On the other hand, it is much more appropriate to say that a feature "has" Acceptance Criteria that define what given features are expected to deliver, their functional expression ...which in turn is always defined against a whole catalog of implied implementation standards that I don't think have to be spelled out every time as if also either "requirements" or "acceptance criteria", e.g. "must be tested".

While Aha! lists requirements at features, it doesn't appear to allow managing them as independent records within their own requirements hierarchy. They are treated as if children of features, whereas they should rather be first class citizens in the Aha! object model that can relate to multiple features, or rather to any other object record, really, and definitely not just to a single feature, with requirement records having a related list of features or master features shaped by them, or initiatives, or releases or... anything.

In that sense, I do believe and uphold, there should be AFPR-I-7619 - Master Requirements similar to how there already are Master Features.