A lot of the times during the bidding phase of a project I receive a software system's requirements from our potential customers in a very unstructured format from various sources [email, word documents, excel]. It is usually a bunch of "product development" guys from the customer's side who come up with these "proposed solutions" to the business problems they have. While they are the experts at the business domain, a lot of the times they don't have the solutions right.

This results in

  • multiple versions of the same requirement
  • mixing up of two requirements into one
  • a few versions of the requirement later down the line, the requirements which were combined together get separated out again, each taking with it some of the new additions

How do you work with such requirements coming in and sort them out into proper use cases and before development begins? What tools can we use to track a particular requirement's history, from the first time it was conceived till the time it gets crystallized into a proper use case? Estimating work against requirements received in such a fashion is a nightmare which ends up in making mistakes in understanding the requirement correctly and estimating the effort against it correctly.

Once we win the project, then the customers have given some more thought to their requirements and have been able to articulate it properly. What happens in this case is that some functionality gets dropped, some enhanced, some take a whole new turn. This basically can nullify some of the work item's estimates that were made before the project was won. I would be interested in knowing if there is any system by which we can build a tree of a particular requirement and how each branch resulted in a different estimate.

Any tips, tools, tricks to make this activity more manageable? I'm just trying to get some insights from someone more experienced than I am in requirements management and effort estimation.

  • 1
    Does anyone from your team work with the "product development" guys in order to do requirements analysis (e.g. a Business Analyst)?
    – Deco
    Commented Oct 25, 2012 at 8:02
  • Yes, I do that in all cases where we don't budget in a BA.
    – user20358
    Commented Oct 25, 2012 at 9:53
  • possible duplicate of Dealing with bad/incomplete/unclear specifications?
    – gnat
    Commented Aug 26, 2013 at 14:53

2 Answers 2


Requirements will grow and change. I don't think anyone could argue that.

How to collect and process incoming requests.

In my experience it helps when gathering requirements if there is a single or very small group of customers acting as a filter for delivering new or updated requirements to a small group of development planners. Anyone from their side can propose or write them up, but delivery should be through only a very small few. The less people that are involved in the exchange from one party to the other, the better.

The purpose of filtering through a smaller set of people isn't to discard or diminish the effort and information others put in, even if duplicate or seemingly unimportant on the surface, but to limit points of failure: lost or mishandled information. It follows on a principle similar to the purpose of encapsulation and interfaces: protect private data, and establish a common protocol for handling similar requests. Let me reiterate: submission of duplicates is ok. As a planner, that tells me the thing they are talking about or proposing is important. Save or record everything.

How to track and organize requirements

In the short term, go low tech

Obviously there are low tech solutions that can be effective to a large degree in organizing and tracking incoming requirements: whiteboards, stickies, posterboards, what have you. These can be great for short term planning. They are highly visible, accept freeform notation, and easy to 'reconfigure'.

In the long term, use a searchable, sortable, linkable software tool

For longer range efforts, some kind of software would be valuable. There are specialized requirements management tools: Doors, Clearcase/Clearquest, and many others. Those highly specialized tools are great at what they do, but are often overkill. Sometimes even a plain old spreadsheet is more than adequate. I personally find general issue tracking systems fairly useful to accomplish this, and right now my favorite is redmine, but others I am sure would be fine too.

With an issue tracking system, anyone you choose to allow can create a 'new issue' or requirement, and add any detail they see fit to include. They can watch the issue, and give feedback to any actions you take with it. You can re-categorize it, adjust priority, rewrite the body, attach supplemental information, associate it with other 'issues', promote to a higher level feature or 'use case' or story or whatever terminology fits your system, ad nauseum. In other words, you can do a lot to create a traceable, sortable, prioritized, history-aware, related list of requirements via issues. Plus being fairly configurable out of the box, and open-source, if the tool isn't quite what I need or want at any point, I can change it fairly easily to better fit the needs of my process.

A final note about tools, some people I have talked with have a good deal of success using plain old text files in a change management and versioning system. They obviously get the benefits of historical versions. They also utilize the base operating system and supplementary tools for finding, linking, and cataloging the requirements. They aren't able to add as much structured, related meta information, but they don't feel they need it, and for their efforts doesn't add enough value. That may or may not be the case for you. The advantage is that is potentially a few less pieces of software on your development stack to manage and maintain.

Post contract award/post project development kickoff requirements

The final aspect of the question, is how to manage requirements after an effort has begun. I think there are two leading thoughts on this, and part of how you handle them depends on the nature of your relationship with the customer: firstly, if under contract at a fixed value, requirements that come in after contract award can be incorporated. The implication is they may change the scope of the effort, so the rate or bill will be higher when those extra items are delivered and accepted; unless an equivalent amount of effort is removed from the accepted proposal. If it is going to a change in scope, you must ensure the customer understands and accepts the consequence, otherwise, those late submissions will have to be tabled.

Second, for the new requirements coming in after the contract is awarded, and the contract is oriented more towards a time and material effort (whatever it takes to get the body of work completed), you can and should be a bit more flexible if the customer insists on including it during that particular go. You will get paid whether you include it or not, so long as everything you say you will do gets done.

If you aren't familiar with them, you may want to look at a Kanban approach and Agile methods. These techniques can help bring focus to the immediate concerns, without necessarily losing sight of longer term development goals.

Present options as 'what if' scenarios and give the customer a choice and the decision

In either case, a 'what if' estimate is a good strategy to employ when negotiating with the customer and your team. Construct a side-by-side comparison of the tasks, their costs, and the schedule as planned, with a column showing the same information for the alternative approaches. Microsoft Project is probably a good candidate for doing this as you can construct different estimates based on a largely similar set of tasks.

However, even a basic spreadsheet is often just as effective for demonstrating how specific changes or inclusions would impact the cost and schedule. A list in this case is probably just as effective as a tree might be in demonstrating the differences. The tool and method you choose to construct these scenarios largely depends on the size of the project and staff (but even triple A software like MS Project has its own limits of usefulness and ability).

Consider these what if scenarios as internal work items and save them for the duration of the project. They were critical demonstrations in the decision making and negotiation process. You may also have to revisit them, or repeat them for a successive round of what ifs.

When preparing what if scenarios, a supplementary explanation of pro's and con's from a technical or implementation perspective (in simplified terms) might be useful for helping to justify why one alternative would have such a significant impact.


I would look at this as an iterative process. Step 1 is to gather requirements. Step 2 is to sort them. Step 3 is to prioritize them. Step 4 is the break each down into small enough bits to estimate effort. Step 5 is to coalesce these bits into a global effort bucket (let's say 84 person-days). Step 6 is to map the effort to resources (84 person-days / 2 devs = 42 days).

So right now you are stuck between step 1 and step 2. You have requirements, but you don't have them in the form you need.

Say you have multiple versions of the same requirement. Are these essentially the same? If so, pick what appears to be the clearest and use it. If they vary in details, pick what seem to be the most logical and use that one. Then send a message to the client asking them to verify the requirement. You may have to go back-and-forth and number of times to get the requirement right. Don't give up or get discouraged. Many a project has failed due to poor requirements.

Use Microsoft project to keep the work and schedule in synch with the changing requirements. If the client requests a change, spec out the additional work, plug that into your model, and tell them about the new date. Don't get sucked into believing you can just bring on new devs at random intervals to pick up the slack. Your schedule must account for ramp up time whenever a new resource is added. You'll only be able to model this properly if you pay attention to each project and learn from it. Say you brought Bob on board project X after it was churning along for 4 months. How productive was he in the 1st month? The 3rd?

You should revisit the project model weekly, making updates wherever required. Keep a historical record of the changes. This will help you provide better estimates in the future.


Not the answer you're looking for? Browse other questions tagged or ask your own question.