Tool to track requirements and assumptions

Question

I am leading a fairly massive project right now that is in it's idea phase (just getting off the ground) that has more questions than answers today. With all of the uncertainty, our standard methodology for tracking requirements and gathering estimates won't cut it. However, I still have to build a model and get the data that management needs for corporate accounting and budgeting purposes.

I've been asked to simply document the assumptions we're making as a project team and that the developers and application owners would be able to provide a very high level estimate for the work as needed by the business for budgeting purposes...

I need a tool that will also allow assumptions to be tied to high level requirements in a 1 to many relationship so that any changes to an assumption will allow us to identify where more estimation work is required.

Example...

Assumption:
We will operate with a single facility responsible for x, y, and z.

Requirement/Scope:
- This system will need to have an additional facility added.
- This other system will need to be capable of processing x, y, and z.

So at the end of the day, if my assumption changes I want to quickly see that I have at least an impact to 2 of my requirements/scope lines...

Answer 1

I need a tool that will also allow assumptions to be tied to high level requirements in a 1 to many relationship so that any changes to an assumption will allow us to identify where more estimation work is required.

I think this is called "traceability" (for example Requirements traceability) so, include that word in your search terms.

Answer 2

I take it you need a cheap and quick solution. There are lots of tools to do this that can cost lots of $$$$. One that I like was Compuware's test and requirements management suite. TrackRecord I think the name was.

A cheaper solution could be MindMapping the requirements. You could tie in the requirements to the many parts of the solution etc.

Another thing you could look into are UML tools.

Answer 3

When things are ill-structured, you don't need much of a tool.

http://www.w3.org/2001/tag/doc/leastPower.html

You need a lot of patience and clarity to get from what you have to more formal requirements.

Plain-old word-processing is often best.

Since you want to do estimating, a spreadsheet is about all the structure that the problem can stand right now.

A big-old-matrix with requirements on one axis and assumptions on the other will allow you to teak, adjust and assess impact.

If you spend time loading all your questions and answers into some tool, you spend a lot of time playing with the tool -- not the issues. Also, as ideas come and go, you hate to delete the really EPIC FAIL ideas from the tool.

Often, you should feel free to start again "from scratch", discarding the bad ideas.

Write, write and rewrite until the questions, answers and requirements get to a level of manageability.

Then migrate the easy stuff until a more rigid and formal tool. Leave the complex, ill-defined and unfocused stuff in a word processor.

Answer 4

Try out Ultimate Trace. It is free and it provides two-way n-to-m association between any traceables.

Answer 5

Assumptions don't exist in tandem with specific requirements. Once an assumption has been confirmed and becomes a requirement, the assumption goes away.

I always put assumptions in the same artifact with the requirements. So any tool that tracks requirements can be used to track related assumptions. I've put them in BRDs (Business Requirements Documents), use cases, IBM's RequisitePro...

Answer 6

To clarify: When you start gathering requirements you have stated req'ts and assumptions about various things including what some requirements should be. At that point, yes I track them in the same artifact for convenience.

Now, as I said, some of the assumptions are about req'ts, but some, or many, are not. These other assumptions may be about design or they may be about dependencies, to give two examples. I expect all assumptions that are about req'ts to resolve by the time the req'ts are approved. The others I will roll forward into the next artifact where they get resolved in design.

The exception to resolving assumptions is if the "scope" of the assumption goes beyond the project. I've seen one or two assumptions that were so basic and/or difficult to prove that the assumption was an underpinning of the project.