In software development, quality is the main priority of the company. Specific standards and specifications help programmers to follow high quality and meet the needs and demands of the customers. Typically, a programmer starts to work from a written specification (or spec, as it is commonly known). A specification is a document describing the function the program is to perform and may also include technical details about the program. In most projects I have been involved, the quality was achieved by high-performance standards and controls. For instance, a programmer’s job was to translate the specification into a working program.
There were different types of specifications: A functional specification was simply a description of what the program was to do, while a technical specification outlines how it was to work. These may be combined into one document. Reading and understanding specifications are important parts of programming; writing them is part of the analysis function. Someone with the common title of programmer/analyst may be expected both to read and to write specifications. It is impossible to overdo quality procedures and processes because they stipulate certain standards and requirements, and when these requirements are met, the work is done.
Total quality management and ISO and CMMI allow programmers to avoid mistakes and maintain high-quality standards in their organizations. Like other resources, ISO and CMMI have their virtues and their drawbacks. Ideally, they provide enough guidance so that a programmer is clear about what is expected, but it should still leave the details of implementation to the programmer. The client is really part of the system. In many ways, it is the most unpredictable element. To programmer/analysts, who often have little direct contact with clients, they appear capricious and often frustrating, and specifications serve to provide programmer/analysts with some control over this volatility.