Competitive Engineering

The idea​

Gilb's claim is simple and hard to live with: most of what we call requirements are adjectives. "Fast", "secure", "easy to use". Nobody can tell when they're met, so nobody can tell when they're not. His answer is Planguage, a specification language that forces every quality into a number on a defined scale.

How it looks​

A Planguage requirement names the quality, says what's being counted, says how it will be measured, and sets levels: where we are, where we must not fall below, and where we're aiming.

Verifiability:
  Scale:     % of production images whose digest
             was verified before the job ran
  Meter:     pipeline logs, sampled weekly
  Past:      0%   [before signing]
  Fail:      90%  [below this, stop and fix]
  Goal:      100% [by end of quarter]

My example, not the book's: a Planguage requirement for the image-signing experiment.

How I use it​

I use it in two places. At work, it's how I turn "make the supply chain more secure" into something a pipeline can report against. Outside work, it sits under my life plan: each goal has a scale and a meter, and the plan changes when the numbers say it should.

Where it connects​

• Malotaux, Evo and TaskCycle Evo at the scale of a week: plan, do, check, in short cycles.
• Kasser, The Systems Thinker's Toolbox Look at the problem from several perspectives before quantifying it.
• Wirth, Systematic Programming Stepwise refinement: decompose until each part can be checked. (draft)
• Minto, The Pyramid Principle Lead with the answer; Planguage leads with the number. (draft)

References​

1. T. Gilb, Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Oxford, U.K.: Elsevier Butterworth-Heinemann, 2005.