Garbage in, garbage out: poor inputs result in poor outputs

“Garbage In, Garbage Out” (GIGO) is a concept in information technology and computer science that emphasizes the importance of input quality. It implies that if the data input into a system is flawed or inaccurate, the resulting output will also be flawed or inaccurate.

Poor definition of software requirements can lead to failure of software development projects

Software development requirements are pivotal and central to every successful software development project. Poor requirements practices alone can doom any application development process. No matter how well designed and constructed or well tested an application might be, it is essentially useless if it fails to meet the business needs.

Defects in software development requirements are the sources of the majority of defects that are identified during testing and problems with requirements are among the top causes of project failure.

Common software development requirements problems include incomplete or inaccurate requirements, poorly managed requirements change and missed requirements. The first step of requirements management is accurately capturing the requirements and defining it. Confusion about what is required pretty much guarantees the requirements will not be met and increases the chance of product failure.

The inability to identify all the impacts and notify anyone impacted by a change leads to poor change management. A poorly executed change means wasted efforts, outdated information and design conflict. This drives up cost and creates project delay.

Significant documentation is required of companies who must comply with regulations or meet standards. Those that lack requirements traceability must invest significant time preparing records to prove compliance. Those that have traceability have a far easier time producing reports and records that support compliance as they can automatically trace the regulatory down to the details proving it was satisfied.

Software requirements sit in a tricky zone between business and technical thinking

Depending on who writes them they can fall too far toward one camp or the other. A technically written set of requirements may concentrate too much on implementation issues, e.g. data design, and miss out on the actual benefits the business was after. Conversely, specifications written by non-technical people can be wordy, ambiguous, and repetitive.

FAQ