How do you estimate the cost of developing software requirements?

Question

Many software developers probably would agree that estimation of implementation costs is one of the most complex SDLC issues, even when a good requirements specification is available as a pre-condition.

Now, what about estimation of the cost of developing that requirements specification itself?

Would anyone care to share their experience in this area? What approaches, techniques, heuristics, tools, etc. do you use? What does work and what does not? Do you even care about such estimates when you are at the beginning of the conception phase?

NB: Different people/teams may have different understandings of what exactly constitutes a requirements specification for a software product/system. Perhaps, the most common example of such difference is treatment of user interface (UI) specifications: some people consider UI specs to be a part of requirements specification (sometimes even without clear delineation!), whereas other people prefer to consider UI specs to be a completely separate artefact (and consider UI design to be a completely separate activity from development of requirements). Another common example is separation of so-called "business requirements" from "user(?)/technical(?)/real(?) requirements". (The real purpose and meaning of this separation always escaped me, but somehow it appears to be a very common phenomenon.) In any case, *if you take the trouble to respond to my question, please also clarify your understanding of what requirements are (perhaps just by referring to a book, article, or any other source). I would really appreciate that!

Answer 1

I try to roughly estimate each step in the process.

Add extra time for testing, deployment, support, customer meetings, iterations, etc.

Take your final value and double it. If you are working with others, triple it or discuss your estimates with them first to see what they thing.

Then, keep track of your time and see how accurate your estimates were. Repeat with each project to hone your skills.

Answer 2

I would recommend Software Estimation: Demystifying the Black Art by Steve McConnell.

Link to Amazon
Official Site

Answer 3

Dart. Wall. Done.

Sorry, couldn't resist. Now to be serious ... Estimating the time it will take to gather requirements is definitely more art than science. Generally, I've found that a good estimate of gathering requirements itself requires a halfway decent understanding of what the app's intent is. (It truly helps if you have an example of prior work or proof-of-concept. This is rarely the case, though.)

Personally, I break down "requirements" gathering into two distinct tasks: "Marketing" or "Business" requirements (IE, what the solution must do for the client and basic rules about that), and "technical" requirements (all business rules, logic, data entry inputs, what some folks call the "goes-intos/goes-outtas"). I separate these because the business side often thinks more in line with the first set -- the 10,000 foot overview, and rarely even understands the full spec (technical reqs).

With a halfway decent understanding of the goal and the current state of technology, I can usually estimate the time to get the "Marketing"/"Business" requirements pretty accurately. Depending on the size of a given project, this may be anywhere from a few hours to a couple weeks. When we make that estimate, we also take a WAG at the time for technical requirements. However, the client is made to understand that the technical requirement estimate will change once the MRD/BRD is complete -- much as your overall project timeline will likely change once the TRD is complete.

Once we have a really solid grasp on the marketing/business requirements, we re-estimate the technical requirements. If there are a lot of holes in the MRD, we will pad this estimate accordingly. Usually, the TRD is handled by one or more of our senior developers as well as business analyst(s). Again, the estimating here is based on our understanding of the overall goals, and how long we feel it will take to nail down all of the specifics. There are some heuristics we can apply -- projected number of entry screens, projected number of reports, data set size, etc. -- but at the end of the day, all you have to go on here is really experience.

Estimating the requirements phase, all said and done, is much more art than science. You get better at it the more practice you get, of course.

Answer 4

Very good question. First, I define a requirement as a wish for a feature. Most requirements are user centric and typically take the form of what is known now as a user story or walk through. There are also technical (e.g. specify DBMS vendor), marketing (e.g. integrate with facebook), and business requirements (e.g. HIPAA compliance) too. I contrast this with a technical specification such as a use case document. Requirements are creative. Tech specs are analytical. You really need both as you iterate from the fuzziness of a requirement to the specifics of the kind of instructions that a machine can understand. I go into more detail on this subject in this treatise on developing successful software.

So, how do you estimate the cost of specifying requirements? Well, the short answer is not very well. With enough experience, you can start to tell when requirements are well thought out and when they are half baked. That's pretty subjective and really doesn't give you a precise algorithm for estimating time.

Instead of trying to answer the question of how long it takes to spec out the complete functionality, try answering the question of how much time you should allocate to specifying some functionality before you can have something that is measurably useful. So, instead of asking...

How long does it take to spec out this entire application?

...you should be asking...

If we spend a week writing specs then implement just that, will we have something better than what we have now?

That is the magic behind Agile Development. Iterate and increment. Plan, produce, then measure in short cycles. The upside to this approach is that it is optimizing. The learning aspect of this feedback loop gets you to market faster. The downside to this approach is that it still doesn't answer the most important question that your funder is going to ask. Namely, how long till breakeven time?

Answer 5

You need a list of things to do. With a list of things to do, you can estimate. Without one, you can't do it.

The first reference document is the initial specification provided by the customer. If there isn't a formal document like this, then there will be some sort of specification given by the customer (maybe in the tender, maybe 'I want an application that does something'. The less specific this document is, the less specific your final estimation will be.

Next, take all of the requirements, and list them somewhere - in Excel works for me. Assign them a complexity (High, Medium, Low, something like that) (from the point of view of specification, not technical).

Next, you need to know what to specify, what are the end products of your specification process? Word documents? Data model? Mock-ups? If mock-ups, what sort of mockup? A clickable version of the application, or just screenshots?

To do the specification, you'll need meetings with the client. The number and length of meetings will depend upon the complexities you've allocated above. For each meeting, you'll need an amount of time to prepare for the meeting. After the meeting you'll need time to write the specifications, update the data model, mockup etc.

Then, once the document(s) are done, you'll need to give them to the client, and get their feedback. You'll need to allow time for the updates for the document that come from that. The number of validation cycles depends upon the client and the quality of your specification, usually two or three suffices.

As for how much time to allow for each step, I'm afraid I can't answer that. But it will take longer than you think :-)

You can refine this model as much as you like during the project.

Hope this helps.