HN Explorer

Ask HN: Requirements-Based Project Management

7 points by Bognar ↗ HN
My company has used quite a few project management tools over the years, but none of them have fully satisfied us. Currently we're on JIRA which is great for tracking at the task and issue level, but we feel that it doesn't have great support for managing documentation and application requirements.

Our vision for a PM tool is based around writing requirements and documentation first, then generating tasks based on creation of or editing those requirements. A requirements list might look like:

    Business
    |-Orders allowed only from 8AM-5PM
    |-Order minimum is $5
    |-...
    UI
    |-All tables have an 'Export' button
    Etc
Each requirement is a first-class item that can be modified, can have comments attached, etc. When changing a requirement, you can generate a task that is inserted into a backlog or sprint for a developer to work on. The requirements document would be version controlled along with the tasks that are generated for each requirement or change, so you can view requirements of a previous release. You would also be able to diff the requirements between versions to see changes between each and the tasks completed for those changes. Bugs could be filed against a requirement that is not working as intended.

The benefit we see is that your documentation is directly tied to your project management. Before a work task is generated, a requirement must be written in the documentation so it forces the documentation to be written (which is usually so rarely/poorly done). A lot of PM tools can integrate with Wikis, but it always feels like an after-thought and the wiki inevitably rots in many projects as effort isn't put forth to maintain it.

So, do any tools exist that do what we're searching for? We're not opposed to writing one ourselves, but obviously we'd like to save time and money by adopting an existing tool. Would anyone else be interested in using a tool like this? What issues or problems do you see with it?

5 comments

[ 2.2 ms ] story [ 23.4 ms ] thread
codegeek
I actually had a very similar idea that I never really implemented but documented it in my notes a while back. Basically, it will revolve around "Deliverables" or "Requirements" and everything will be tied to it whether an enhancement, a bug, issue etc. This way, all you need to do is roll up all your "deliverables" and you know where you are in the project in terms of timelines, issues,risks etc.

JIRA is an awesome tool to manage issues/bugs (I use it extensively at work) but like you said, it is hard to keep track of a particular requirement/deliverable against the JIRAs. When I say keep track, I mean the ever changing requirements, customer priorities, new risks/issues that could hinder the progress, audit history etc.

sharemywin
I always thought having messaging(email) tied to the documentation would be nice to so the reasoning behind decision could be documented.
swanson
Have you tried just using Jira for this as well?

* "First-class item" => Make a custom work-item type for "Requirement"

* "have comments attached" => Jira comments

* "Generate a task/see tasks completed" => Add items as sub-tasks

* "Version control" => Jira history tab

* "Bugs filed against req" => New issue, link to Requirement

Confluence also has pretty good integration with Jira if you want to write longer/formal documents - you can link to Jira items and the wiki page will update the status of the item automatically.

Bognar
We considered doing something like that briefly, but decided against it since it wouldn't be easy to get an organized list of the current requirements. With some of our more zealous clients, business rules might have modifications every week. With that amount of changes going through, I could see Jira getting unwieldy.

If you had to change a requirement, would you create a new one delete the old requirement or update the existing one? If there is a complex system with a couple hundred requirements, how would you organize them? Nested "folders" would be our ideal choice, but I think that we would just have to stick to some kind of label system in Jira.

I don't think it's a bad idea, but for me it doesn't feel like the requirement is driving the project management. By convention it certainly could be, but I don't like having to rely on people following the convention.

sahil_videology
I have also needed a tool like this when doing acceptance tests. We had acceptance tests that needed to be traced back to requirements. A QA guy used an XML document to write all the requirements and tests and then wrote a Python script to generate HTML that presented the requirements, tests, and traceability. Obviously, this is not interactive; it's basically a static site generator for a specific domain. Not ideal.