THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

LOOKING AT THE SPECS

by Gerard Fonte

Start ý Are You Flexible? ý Whoýs the Boss? ý So, What are Your Options? ý What are the Hazards? ý To be or Not to be Specified? ý Unhappy Customers ý Sources and PDF

TO BE OR NOT TO BE SPECIFIED?

This article wouldnýt be complete without some mention of software specifications (stop laughing). It is true that Microsoft has managed to create a powerful software monopoly without any specifications or performance guarantees for its operating system. Microsoftýs "End User License Agreement" is remarkable reading, but the rest of us have to provide a product that works.

There seems to be a lack of specifications for software (as compared to hardware). With software, if it works, it must be okay. Part of the reason is that extensive testing of software is difficult. There are few standard tests and tools. Generating specialized software tests is difficult and expensive.

That said, it doesnýt mean that software shouldnýt be specified. Often, software is operationally specified. These software goal specifications are generated at the start of the project, defining what the software does. But, how do you know how well it works? There are a few numbers, like lines of code and execution speed, but these donýt tell you much. Of course, there are hardware requirement specifications, which detail what is needed for the software to operate. These are important, but also donýt indicate how well the software works.

It would be nice to have an index of complexity. For example, the ratio of branch instructions to in-line code or a MTTR (Mean Time to Repair) specification. Perhaps a comment to code ratio could be standardized. Unfortunately, I donýt see this happening soon.

PREVIOUS • NEXT