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 management and the requirements process are sometimes used to mean the same thing, but customers should be aware that there are ...continue reading
To prevent feature creep, product requirements should satisfy the actual business requirements. Creep can occur when product requirements are ...continue reading
Testers often complain that software requirements specifications are too vague, but verbose requirements can have the negative impact of being so ...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.