Page MenuHomePhabricator

Requirements Management / Tracking / Traceability Utility or Feature
Closed, ResolvedPublic

Description

It would be very useful if software requirements could be managed within Phabricator.

In my company's use case, a contract phase essentially involves the following steps:

  • the top-level requirements are defined, either as dictated by the customer, or after some negotiation.
  • for some top-level requirements, derived requirements may be defined to sub-divide the work
  • for each requirement, test cases are defined to indicate how the requirement would be verified
  • development would begin, with code changes mapping to assigned requirements.
  • once development, code review, and verification testing has been completed, a requirement will ultimately be marked as having been satisfied

As I see it, the features provided by a Task already provide almost all of the desirable functionality because a Task supports:

  • discussion of the task (ie requirement) including, but not limited to:
    • planning
    • modification
    • clarification
    • preserved explanation of actions taken (add, change, delete, etc.)
  • bi-directional traceability from top level task (ie. customer requirement) to subtask (ie. derived requirement) to code review and modification.

However, if using Tasks to represent a requirements, I am not aware of a clean easy way to segregate base requirements, derived requirements, and all other types of tasks.

As explained or the Phabricator Feature Request page, I'm trying to focus on explaining my problem, rather than my solution. That said, I have a few ideas that I'm guessing would be relatively simple to implement and would have utility beyond the scope of the particular problem I'm trying to solve:

  • a simple, flexible feature that might address this problem adequately would be to add a generic "tag" field to a Task. This "tag" field would behave much like the project field, except it would serve as nothing more than a search key. Given a tag field utility, a team could employ tags such as "req" and "dreq" to indicate "base requirement" and "derived requirement", and then key off of these tags in a query to form a list of all requirements for a particular project.
  • an even simpler feature that could be enabling would be to add a field in the custom search query to search only the tasks' titles. Given this, users could add things like "#req" or "#dreq" to a Task's title - a hashtag that a query could search titles for. (Yes, this could be done now, searching through the entire text for the hashtag, but it's not quite as clean.)
    • for bonus points, it would be cool if search queries could support regular expression syntax

Still, an explicit tool/entity for requirements, though it would look a lot like Maniphest Tasks, would probably ultimately be best because it could support requirements-specific features, such as report generation. (Maybe this is already somewhere in the roadmap?)

Thank you for reading.


More info here:
http://en.wikipedia.org/wiki/Requirements_traceability
http://en.wikipedia.org/wiki/Requirements_management

Related Objects

Event Timeline

arr_sea raised the priority of this task from to Wishlist.
arr_sea updated the task description. (Show Details)
arr_sea added a subscriber: arr_sea.

How would the "tag" field differ from the existing projects field?

Specifically, why isn't it a good solution to create tags called "req", "dreq", etc., give them a "tag" icon and a special color, and use them as tags?

Perhaps I was thinking of the projects field incorrectly by taking the word "projects" too literally. Thus, I was thinking that using the projects field as a tag would be an abuse of the field. However, after looking more closely at your use of the projects field here, I can see that it is used in a tag-like fashion for projects like "Cowboy Commits" and "Easy".

Thank you very much for helping me understand this.

I think that my company can achieve our basic goals using the projects field for tagging requirements. Given my problem statement, does this seem like a good way to use the available tools for requirements tracking, or would you recommend something else?

arr_sea claimed this task.

I'm going to go ahead and close this now that I know that the "projects" field can be effectively used as a "tags" field. I believe that will provide sufficient functionality for my purposes. If anyone wants to discuss this further they can re-open the task.

Thank you for your time!