Problems caused by skipping analysis stage of SDLC

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Building security into the SDLC (Software development life cycle) Inexpensive phase of SDLC to catch and fix bugs GatherSpace beefs up cloud-based requirements management ALM: Best of breed vs. complete systems Software development life cycle phases, iterations, explained step by step The role of quality assurance (QA) pros in software security Common software security risks and oversights Why the quality assurance department should be involved in testing How to develop secure applications Secure software development practices 'not rocket science' How to prevent HTTP response splitting Software Requirements Gathering, Analysis, Quality and Testing How to write a Software Requirements Specification (SRS) document Software development life cycle phases, iterations, explained step by step Waterfall versus iterative development misconceptions Differentiating between Functional and Nonfunctional Requirements Writing a software requirements specification (SRS) for a portal app Should QA check changes from outside the requirements document? Software testing metrics for a medium-sized project Template for requirements use cases What should a business analyst's requirements document include? Is a requirements freeze in a software project a bad idea?

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

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.