Is there any evidence suggesting that time spent on writing up, or thinking about the requirements will have any effect on the development time? Study done by Standish (1995) suggests that incomplete requirements partially (13.1%) contributed to the failure of the projects. Are there any studies done which show that time spent on requirement analysis will have any effect on development time of a project, or how successful the project will be.
See Code Complete, By Steve McConnell, Table 3-1. He compares the average cost of fixing defects based on when they're introduced and detected. Detection at construction time costs 5-10 times more than detection at requirements time, and 10-100 times more post-release.
The table is based on the following sources:
"Design and Code Inspections to Reduce Errors in ProgramnDevelopment" (Fagan 1976)
Software Defect Removal (Dunn 1984)
"Software Process Improvement at Hughes Aircraft" (Humphrey, Snyder, and WIllis 1991)
and several more
Yes, there are plenty of studies on this topic. Of course, the question is too general to answer for all kinds of software development projects, but there is evidence from several contexts that support the notion that properly doing requirements analysis will have a positive impact on the implementation stage. This evidence has been partially collected into "laws", and here are three examples:
Glass' law: Requirement deficiencies are the prime source of project failures.
This law is backed up by case study evidence from large software development projects. Glass found that in the failed cases, there were far too many requirements, they were unstable due to late changes, and they were ambiguous and incomplete.
This suggests that there is a relation between the quality of requirements and the project outcome.
Boehm's first law: Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed.
This is also backed up by case study evidence and contributes to answering the question in the following way: doing the requirements properly will reduce the number of errors in the system, and correcting the errors before starting implementation is going to be less expensive than hunting them down when implementation has already started (or worse, when the system has already shipped).
Boehm's second law: Prototyping (significantly) reduces requirement and design errors, especially for user interfaces.
This is backed up by controlled experiments in a student context. One possible interpretations is that requirements and design phases do not need to be entirely documentation-driven and theoretical. Instead, performing prototyping as part of the requirement and design phases – which amounts to spending time on and thinking about the requirements – is going to affect project success and implementation time.
There is also plenty of other evidence that points in the same direction: spending time on preparing for implementation pays off in the form of less risk and less chance of schedule overrun due to surprises. Although the question was not about testing, proper preparation positively affects testing, too.
The references for these laws are:
Glass' law: Glass, R.L.: Software Runaways. Lessons Learned from Massive Software Project Failures. Upper Saddle River, NJ: Prentice Hall 1998
Boehm's first law: Boehm, B.W., McClean, R.K., Urfrig, D.B.: Some Experience with Automated Aids to the Design of Large-Scale Reliable Software. IEEE Trans on Software Engineering 1, 1 (1975), 125–133
Boehm's second law: Boehm, B.W., Gray, T.E., Seewaldt, T.: Prototyping Versus Specifying: A Multiproject Experiment. IEEE Trans on Software Engineering 10, 3 (1984), 290–302
Also, the following reference may be of interest: Endres, A. and Rombach, D. A Handbook of Software and Systems Engineering. Empirical Observations, Laws and Theories. The Fraunhofer IESE Series on Software Engineering. Addison Wesley, 2003.