With the rollout of enhanced Kanban boards, I'm only now realizing that certain record types actually are much closer to being first class citizens in Aha than thought, although with limited capabilities, i.e. I'm surprised to find a Kanban board for Requirements.
Unlike the Aha design philosophy expressed under "how_aha_works", I would argue a requirement does not "belong to a feature". Instead, it precedes and defines about everything from strategies to products, to master features, to features, to ideas, even releases. The overall status of a requirement should also be distinct from the status of its relation to records of any other record type, e.g. an imaginary requirement "PM must publish release notes" could have a general status as "Shipped", meaning the general process of publishing them is established, but then it could also have a relation to every single release and each relation status could be marked as "Shipped" at some point, when the release notes for Release 19.xx are published. Or, take "the right to be forgotten". This could be associated with a range of master features, features, ideas, etc... It seems that, right now, what you would model as a "requirement" in Aha, actually represents the individual relationship of a requirement to a feature. However, any actual requirement "REQ-123 Right to be forgotten" would have to be defined and managed outside of Aha, based on which you then assign a bunch of "requirements" named REQ-123 in aha to your features, depending on what features are implicated by it.
Put differently, aha appears to be rather limited in its requirements handling capabilities, and currently unfit to model and manage a "requirements master". Perhaps the best way to overcome these limitations would be to introduce "Master Requirements" similar to how there are "Master features" and features.
However, those should generally be much less tied to product iterations than features ...while they should also be relatable to more than just features. Assigning such a master requirement to a feature would then basically instantiate the type of record aha currently calls "a requirement".
Thank you for submitting this idea. It's possible that existing functionality can help to capture high level requirements today:
You may decide to capture high level requirements as custom fields that you then link with records.
Another solution might be to create a standalone product that acts as a requirement repository (i.e. imagine capturing high level requirements as master features or features in another product). You could then link your work in other products to those features or master features.
There are many ways you can customize Aha! to match how your team works. For teams that need to customize their account beyond custom fields and add their own data objects, we offer custom tables as part of the Enterprise+ plan. Our Customer Success team would be happy to assist with these options. Please reach out to firstname.lastname@example.org.
At this time, we do not have near-term plans to build this specific functionality based on the existing customization capabilities available and current priorities. We hope you understand.