Specifying a computer-based system (CBS) in a formal specification
language can reduce downstream, development errors and rework, but the
resulting formal specifications are considered expensive to write and
to maintain, discouraging their adoption. With a single-subject
experiment this paper explores the costs of modifying specifications
written in two different specification languages: a Parnas-Table
specification language, Software Cost Reduction (SCR), and a
state-of-the-practice specification language, Real-Time Unified
Modeling Language (RT-UML). In the experiment, the subject specified
two different CBSs, (1) a bidirectional formatter (BDF) and (2) a
bicycle computer (BC), with each specification language, but in the
opposite order, to balance an expected learning effect arising from
specifying the same problem twice with different specification
languages. Later in the experiment, the requirements for each CBS were
modified, and the subject modified each specification to reflect the
changes. The subject recorded (1) the number of hours he needed to
write and update each specification, (2) the number of defects he
inserted into each specification, and (3) the number of hours the
subject needed to repair these defects.

The results show that the cost to modify a specification are highly
dependent on both the problem and the specification language used.
There is no evidence that a specification written in a Parnas-Table
specification language is easier to modify than a specification written
in state-of-the-practice specification language.