The authors were recently involved in the development of a COBOL parse
r, specified formally in Z. The type of problem tackled was well suite
d to a formal language. The specification process was part of a life-c
ycle characterized by the front-loading of effort in the specification
stage and the inclusion of a statistical testing stage. The specifica
tion was found to be error dense and difficult to comprehend. The Z wa
s used to specify inappropriate procedural rather than declarative det
ail. Modularity and style problems in the Z specification made it diff
icult to review. In this sense, the application of formal methods was
not successful. Despite these problems the estimated fault density for
the product was 1.3 faults per KLOC, before delivery, which compares
favorably with IBM's Cleanroom method. This was achieved, despite the
low quality of the Z specification, through meticulous and effort-inte
nsive reviews. However, because the faults were in critical locations,
the reliability of the product was assessed to be unacceptably low. T
his demonstrates the necessity of assessing reliability as well as ''c
orrectness'' during system testing. Overall, the experiences reported
in this paper suggest a range of important lessons for anyone contempl
ating the practical application of formal methods.