UP | HOME
../../ | Slides

Software Specifications 101

Table of Contents

This is a "graduate level 101" intro to specs.

1 About Specifications

1.1 Spec Techniques

  1. Prescriptive/ Operational?
  2. Declarative Preferred
  3. Another Program as a spec of this one?
  4. English v Math + Logic

1.2 Specifications v Requirements

  1. mostly a question of points of view
  2. requ: POV of the clients/users
  3. spec: POV the designer/developer
  4. Should the Structure of Spec influence Design?
    1. Explicit admonition

1.3 Specifications meet Requirements

  1. Goal: Spec S meets requirements R: S \(\models\) R (S "models" R)
  2. How to verify? R is in English prose, S in some notations
  3. We seek consensus of humans readers: Give them S and R, and ask "What do you think? Are they the same?"

1.4 Different Axes of Specs

  1. Functional Specs
  2. Performance/ Resources Specs
  3. Maintainability
  4. A list of different specs by Hoare

1.5 Functional Specifications

  1. Input/Output relation
  2. Input = any thing the prg "reads" (depends on)
  3. Output =any thing the prg "writes" (generates)

1.6 Performance Specifications

  1. What and How-much is "consumed"?
    1. CPU time, memory, stack, heap, file space, …
  2. Big-Oh notations?

1.7 Robustness Specs

  1. Must not crash (no matter what the inputs are?)
  2. Must not hang
  3. Must not do "disastrous" operations
    • (e.g., delete hundreds of files)
    • unless undo/redo are available

1.8 Resource Specs

  1. PL used
  2. RAM, CPU, speed
  3. man hours

1.9 Miscellaneous Specifications

  1. PL-, IDE tools, … (to be used)
  2. Source code, documentation, … (to be produced)
  3. Software qualities expected [see Hoare's list]

2 Notations For Specs

  1. Discrete Math
  2. Mathematical Logic
  3. Functional Programming
  4. ../Assertions/math-logic.html

2.1 Formal or Informal?

  1. What is rigor? precision?
  2. Specification Languages
  3. Another Program as a spec of this one?
  4. Can every existing program be specified?
  5. Is every spec "mathematically" specifiable?

3 Seven Sins of a Specifier

  1. Noise The presence in the document of an element that does not carry information relevant to any feature of the problem. Variants: redundancy; remorse.
  2. Silence The existence of a feature of the problem that is not covered by any element of the document.
  3. Overspecification The presence in the document of an element that corresponds not to a feature of the problem but to features of a possible solution.
  4. Contradiction The presence in the document of two or more elements that define a feature of the system in an incompatible way.

3.1 Seven Sins of a Specifier #2

  1. Ambiguity The presence in the document of an element that makes it possible to interpret a feature of the problem in at least two different ways.
  2. Forward Reference The presence in the document of an element that uses features of the problem not defined until later in the document.
  3. Wishful Thinking The presence in the document of an element that defines a feature of the problem in such a way that a candidate solution cannot realistically be validated with respect to this feature.
  4. [cite Bertrand Meyer, see Refs; visit also http://deadlysins.com]
  5. Aren't these: Seven Sins of the Requirements Writer?

4 Correct wrt Assertions

  1. What is the notion of "correct" that you are using?
  2. It can never be a unary property. A program is correct with respect to (wrt) to something: another program, e.g.
  3. In this course it is never independent of its entry- and exit assertions.

4.1 Correct wrt Assertions: Vacuously

  1. If we give impossible to hold entry assertion,
  2. or if we give trivial to hold exit assertion,
  3. then any program will be correct with respect to those assertions.

4.2 Correct wrt Assertions: For-All

  1. There is an implicit for-all (symbol ∀) in the assertions.
  2. E.g., when we write n >= 0 in the entry assertions, it includes for all n that we may give so that n >= 0. The n that is bound here is taken in all subsequent assertions – in loop invariants and in the exit assertion.

4.3 Correct wrt Assertions: sorting-alg Example

  1. Our assertions for sorting: 
{n >= 0} sorting-alg {sorted(a[0 .. n-1]) and permutation(a, a')}

5 Specs v Final Programs

  1. Expect that declarative specs are shorter than programs written in languages like Java or C++.
  2. Not always so. Consider the pseudo random number generators that do x = m*x + c. The initial choice of x, m and c have an impact on the random number sequence. The specification of this sequence is considerably longer than the one liner implementation.

6 References

  1. Meyer, Bertrand, "On Formalism In Specifications", IEEE Software, 1985, vol. 2, no. 1. pp. 6-26. (Meyer is the designer of the excellent OOPL named Eiffel.) Required Reading.
  2. Others and Bertrand Meyer, "How Specifications Change and Why You Should Care", Jan 2013. Recommended Reading.
  3. Joel Spolsky, "Painless Functional Specifications - Part1. Why Bother?", 2000. "Painless Functional Specifications - Part 2: What's a Spec?" "Painless Functional Specifications - Part 3: But… How?" "Painless Functional Specifications - Part 4: Tips" (Spolsky is the designer and original builder of Stack Overflow.) Recommended Reading.
Copyright © 2016 pmateti@wright.edu • www.wright.edu/~pmateti 2016-01-27