I come across this topic about 4 - 8 times a year.

Normally a project starts with an original idea and this is detailled to an initial idea during one or a few meetings. This initial idea the customer calls requirements.

From time to time we use Mr Skip Pletchers approach (open requirements, fixed costs, fixed deadline, fixed quality) to solve the conflict and to limit the controlling overhead. For us! The customer's effort increases (do not underestimate this amount!).

Most of the time the customer does not agree to this approach. Then we suggest to split the project into a small kickoff-project und the main project. In the kickoff project we get to know each other und normally we can convince the customer to use the above approach or the split the main-project into reasonable small pieces, Here our experience (especially with this customer) comes into play.

Another end happend: The customer started thinking about his requirements, needed some minor help for specification but managed to provide them.

If the customer does not agree to one of these terms: No project.

we can predict the cost from the type and size of the organization and the type of software or the purpose of software for which it will be developed. More over experience of Analyst also play a vital role. If he has involved in developing similar software then he can predict the software cost.

e.g if a client/company demand for a payroll software then ultimately its cost will be round about the same as previously developed payroll software.

I myself as a developer experienced that client in the beginning demand very little functional/non-functional requirements but after the release of the first version they demand for more and more requirements. So I suggest a little over estimate.

Yes it is right; sometimes we have to estimate the cost of software even if requirements are not available. In that case approximate cost can be made based on past experience of similar kind of software. No estimation model can compute the accurate cost of software even if requirements are available. Domain knowledge and previous experience is always desirable.

Thank you sir, Mr. Sunil Sikka

But if we try to create any model or technic for software cost estimation before requirements collection by thesis(Actually I want to do a thesis on this topics ), How then can we move forward?

It always depends on the project scope, but, if you don't know the system requirements, you cannot be sure how reliable your cost estimation actually is. I agree that many times projects are so similar that a good prediction can be done as a function of previous knowledge on equivalent projects, both by using mathematical models as the analysts' experience (in this scenario, this may be the key factor for success). Nevertheless, from my experience, you cannot be sure this estimation actually covers the whole system and just a little deviation can have great implications in the actual cost and effort and induce project failure. I always recommend a cost review after technical and non-technical requirements analysis and, if not possible, working with an experienced team and a little over-estimation. But, take into account, the bigger the project, the greater the probability of failing in the estimation with an uncomplete knowledge.

Also remember a prediction is a *probabilistic statement* and not just a point value. This means that if you have very little information about the software that's required then you will have upper and lower bounds that are widely separated coupled with relatively low confidence. For example I might have 50% confidence that the actual cost will fall between 1m and 5m euros/dollars/pounds (or whatever your favourite currency is).

It is not possible to estimate the cost of software before requirements. Based on the number of software installed at user site some predictions can be made with an assumption that user's request for the new software will be similar to the software already he/she has been using as on date.

You can use different software cost/effort estimation techniques to estimate cost of a software product to be developed but you can not implement any of the cost estimation techniques that exist as on date without knowing requirements of a software process. It is very important to understand the requirements of a software process or a solution to estimate efforts. The unambiguous, complete and correct understanding of requirement of a system to be developed is the driving force for the software cost estimation.

In the profession, we have a consensus that the most important factor in estimation is the size of the system (or software), but paradoxically we don't know how to measure the size. This explains why so many previous responders suggested that an experienced professional can help and make a good judgement. Studies comparing public and proprietary estimation models found no superiority in the latter.

Beside the size, which is by far the most important factor, other factors considered important are the familiarity with the technology and how well-structured (or defined) the system is. The latter considers the issue of creeping commitments and changing requirements.

Without understanding the requirements, we cannot estimate the size of the system and we are reduced to guesstimation. In these cases, we may be better off by endorsing agile approach and not bother with the formal (and proven) models.

Every one of the above answers neglected to ask why the estimate was being prepared. It is necessary to know whether the estimate is needed to support a strategy planning session or a work-product development plan. If it is a development plan, then the uncertainty associated to unknown requirements is too great to develop a believable plan.

Always ask "For what planning process is this estimate requested?" Don't be surprised however, if the requester does not know. Just send him back to ask.

I agree with Sasha, expirience is the most helpfull, ALL methhods give us just orientation.

There is another approach which can provide a rather precise and generally accurate estimate of cost for a software (no hardware) solution without any prior knowledge of functional requirements. Fix the scope of the software to be developed on time, not requirements*. .If I have a team of 8 working for 13 two-weeks sprints, it will cost about X (units of currency). In contract terms, this is time and expenses. The software product is initially undefined, but we will show working, tested software every two weeks and can change direction any fortnight. Work with us and at the end of any sprint, you can decide whether to release the tested software into production and use feedback from usage to navigate new or changed requirements.

* This estimate might assume certain constraints (e.g. the solution will be a web site or Android app or COBOL module for a batch run) which have been called + requirements in the FURPS+ construct.

I come across this topic about 4 - 8 times a year.

Normally a project starts with an original idea and this is detailled to an initial idea during one or a few meetings. This initial idea the customer calls requirements.

From time to time we use Mr Skip Pletchers approach (open requirements, fixed costs, fixed deadline, fixed quality) to solve the conflict and to limit the controlling overhead. For us! The customer's effort increases (do not underestimate this amount!).

Most of the time the customer does not agree to this approach. Then we suggest to split the project into a small kickoff-project und the main project. In the kickoff project we get to know each other und normally we can convince the customer to use the above approach or the split the main-project into reasonable small pieces, Here our experience (especially with this customer) comes into play.

Another end happend: The customer started thinking about his requirements, needed some minor help for specification but managed to provide them.

If the customer does not agree to one of these terms: No project.

Majority of software projects across the world fail to deliver the software product within the estimated budget and time because of estimation errors. Estimation can not be made before software requirements are analysed. Software requirements dictate the type of technology required, required skill levels for the team members, the environment under which the software must work, training requirements for the user etc etc. Each one of these parameters involves cost. Hence it is required to specify the requirements before taking up effort estimation. Then we can estimate the effort using at least four to five methods. As per Boehm, if we can understand why different methods give different effort values, then we will able to reasonable estimate the effort.

The majority of projects that I have witnessed to fail are indeed because of estimation errors. The solution Nageswara Yogi gives is only a small part of the solution. The most destructive estimation error, as Martin Sheppard has already hinted, is the point estimate. And even more destructive, the point estimate is in many cases the most optimistic scenario in what should have been a range estimate. So in Martin's example the true estimate should have been that the software is going to cost between 1 and 5 million with a 50% confidence. Anyone with a proper estimation experience knows that this means that there is a 50% chance that the software is NOT going to cost between 1 and 5 million. When I use this estimate to allocate a 5 million budget I still have a 50% on a budget overrun (only a very small fraction of software projects costs less then estimated). In practice the proper range is communicated as "this project will probably cost 1 million" (or 3 if you're lucky) with a chance of budget overrun of nearly 100%.

In april the AACEi and Nesma have issued a recommended practice to make a Basis of Estimate as applied for the Software Service Industry. This document sums up all the aspects you have to take into account when you make an estimation. It can be downloaded for free from http://www.aacei.org/non/rps/74R-13.pdf.

There are some critical reasons why Pletcher's answer is unsatisfactory. If you are developing a product that requires an external certification such as FDA approval in the US, then you must demonstrate traceability of requirements through design and test. Failure to meet this standard has cost many companies their entire development cost for no return. Further, the "define as you go" strategy makes an implicit assumption that the architecture is 90%+ predefined. An android app is built on a predefined architecture. Few modifications can be made to the architecture of the standard.

Larger applications (say >100,000 SLOC or 1,200 FP) really require a significant look at the architecture and about equal portions of design-to-code effort ratio. Failure to do either of these tends to result in major quality problems and a highly unpredictable system test cycle.

I think part of the problem may be a failure to create a distinction between requirements and specifications. Think of the requirements as the user's definition of capabilities and desired performance attributes. Certainly there are user requests that do not have sufficient clarity but the required questions should be easy enough for most analysts.

The specification, on the other hand, is the testable detail and is extraordinarily difficult to get right on the first try. It is impossible to have a perfect specification for almost anything. Try writing a perfect specification for a box of kleenex. It will cost you more than a carload of kleenex boxes unless you have a really good relationship with the supplier and trust his standard to meet your need.

Thank you Sir, Mr. Martin Shepperd,

I am impressed by your valuable feedback.

Sir, you said that by considering the upper and lower bounds cost estimation feasible. This point is very important to me. Sir please let me know if there are any similar types of bounds or techniques or methods that can be applied ?

Read the Software Engineering Institute research on QUELCE-Quantifying Uncertainty in Early LifeCycle Estimation. Experts can make judgments about bounds for size and frequency of change. Expert judgment should be calibrated, otherwise experts may be optimistic. The QUELCE goal is to make judgements about scenarios of change and use the results of the scenarios to make claims about ranges for schedule and efforts.

If you look at cost estimation approaches for software, you'll discover it can only be done in a reliable manner if you can elaborate a scheme of how the system will look like and you have 'historical data' for the time and effort/cost for each of the components in this scheme. For innovative products, you will be more guessing than knowing. Software development cost estimation is only for "more of the same projects".

However IMHO the most correct statement on this matter - from Tom De Marco - is that the benefits of the right software development targets are so substantial that even very large cost/time overruns (300%) will not make you go into the red figures (as the end beneficiary). If not, you are wasting effort on the wrong objectives.

Cost estimates depends on many aspects of the project like resources etc. The scope of the project to be delivered to a customer may also define the cost of the software. Once the requirement freezes the scope is accepted the task of development and project charter is done the task of cost estimation can be done correctly.

yes indeed it is a big problem