There's an old saying that if you don't know where you're going, any road will do. The analysis stage of the software development life cycle (SDLC) is intended to tell the project where it is going so that it can take an appropriate road which indeed leads to the project's delivering desired value.
If the analysis is skipped, the project is unlikely to get where it needs to be, and certainly not in the most expedient way. Actually, the analysis stage is not skipped, but rather "skipping" means it's done in an inadequately-informed informal non-explicit manner based largely on presumptions which probably are going to be illusory and misleading.
However, the answer is more complicated. While it's true that skipping the analysis undoubtedly produces problems, it's not true that merely doing something you call "analysis" prevents those problems. The analysis has to be done appropriately and must be followed by adequate design and implementation. Too often none of the above occurs.
Analysis should be discovering what I call the REAL business requirements deliverable whats that provide value when satisfied by the product/system how. Very often, though, what is called "analysis" actually is design, which means that the project has skipped to the how without adequately identifying the whats the how must accomplish in order to provide value.
Techniques used for documenting the requirements, which are the output of analysis, don't change the likelihood that things such as use cases and user stories, which often are believed to be the "requirements," often actually are forms of design.
Analysis is a function which needs to precede design. Neither has to be considered an explicit stage. For instance, those following agile methodologies probably wouldn't refer to analysis and design as stages; but effective development depends on doing an applicable amount of analysis and design in order to define what the code should be.
Dig deeper on Building security into the SDLC (Software development life cycle)
Related Q&A from Robin F. Goldsmith
Requirements expert Robin Goldsmith explains how and why a software performance metric must relate to the type of performance one considers important.continue reading
Requirements expert Robin Goldsmith explains why test-first development reduces technical debt.continue reading
There are many considerations that need to be taken into account when measuring usability, such as low respondent rates.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.