Status Future consideration
Categories Application
Created by Tobias Beer
Created on Nov 8, 2019

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.

  • Attach files
  • Marie Sligh
    Jan 3, 2020

    I'm interested in requirements as a stand-alone entity as well. I rely on an integration with Azure DevOps, where engineering (not product) controls the way tickets work. Some tickets have parents, some don't. And there is a complex hierarchical structure that I'm trying to maintain.

    Requirements must have an associated parent feature in Aha but the equivalent ticket type in ADO doesn't require the parent (though it can have one). So when those tickets come across the integration into Aha, they are failing.

    After talking to a rep, I might be able to get around this by having features in ADO sync with master features in Aha and then have requirements in ADO sync with features in Aha (because features don't require parents). This means not only do I have to re-do my integration (which will be a ton of work as I'll have to wipe everything out of the system and start over), but now I'm limited in my hierarchy because I effectively can't use requirements.

  • Admin
    Kelly Sebes
    Nov 8, 2019

    Thank you for sharing how you approach requirements! I recommend reaching out to our customer success team ( They are experienced product managers and Aha! experts. They would love to discuss your use case and can recommend the best way to use Aha! in your scenario.

    We will also watch this idea for more feedback.