Project and System Level Requirements Specification (2 day course)

Monday 11 and Tuesday 12 February 2013

9.00am - 5.00pm

BCS, 1st Floor, The Davidson Building, 5 Southampton Street, London, WC2E 7HA | Maps

Free of charge and open to all (BCS and non-BCS members)

Tom Gilb and Kai Gilb

Applications for places are to be sent directly to Soheir Ghallab

Please specify:

1. Why interested
2. Employment status
3. Which course(s)

This is for under-employed professionals.


Professor Peter Morris, in The Management of Projects found that problems with requirements were top of the list of why projects had problems. Projects in NASA found that they could reduce project overruns substantially (30% to 130% overrun to - 10% to 20%) by investing 5%-9% of the total project time on requirements as opposed to 0.5% to 4%. Investing enough in good requirements has a clear payoff. But it is not a matter of quantity of time spent - but it matters what that time is spent on doing - quality of requirements effort.

We believe that the most critical requirements are few in quantity, but that it is critical to specify them extremely well, and to get them ‘right’ - and to adjust them as experience dictates - and to adjust them to optimize ability to exploit limited resources. We have developed a unique method for requirement specification called ‘Planguage’ (Planning Language). It is not only strong as a requirements specification language, but also strong because it is intimately coupled to corresponding design, quality control, and project management disciplines.

The requirement specification method in Planguage is particularly strong in capturing the top-level critical requirements - performance and quality requirements ‘quantitatively’.

Methods of ‘fainter heart’, focus on ‘functional requirements’ and in fact simply specify (poor) design (like ‘password’) when they are completely missing the main point (in this example the specification of the degrees of ‘security’ they need, the real requirement).

Planguage is able to integrate multiple performance requirements, together with multiple resource budgets, together with multiple constraints. ‘Integrate’ means to be able to determine the current priority of any requirement at any time in the project - so that the project gets the greatest value delivered for a given set of resources.

Planguage is able to keep intimate track of relationships between all requirements, all levels of requirements, and their corresponding designs and stakeholders. Planguage is able to also keep track of all types of risks, dependencies, assumptions and uncertainties - both in requirements and in the related designs and project steps for delivering the requirements.

Planguage is based on well-defined rules for specification, on numeric process entry and exit conditions, on well-defined engineering processes and well-defined concepts (650 glossary concepts are formally defined).

Planguage has proven suitable in practice for all kinds of projects, for small to extremely large, from software, electronics, telecommunications and aircraft, to non-profit charity planning in the Third World. Planguage will be a powerful addition to your current development standards.

Course contents:

  • practical examples of Planguage for requirements
  • the various requirements concepts defined deeply and exemplified
  • requirements templates (to make standards practical)
  • design constraint templates (a type of required design or architecture)
  • how to quantify any qualitative requirement (like intuitiveness or adaptability or security) - this is the key ability that most all other ‘requirements’ courses do not teach!
  • advanced scale of measure specification methods (a ‘scale’ is more than units)
  • how to measure a requirement level numerically (meters and tests for quality)
  • standards for requirements (rules, processes, templates, glossary)
  • principles for requirements (help you to tackle new problems better)
  • quality control of requirements: measuring requirement conformance to standards (reviews, inspections, agile reviews)
  • estimating the quantified impact of a design on requirements
  • evolutionary project management and how it integrates with requirements
  • training requirements writers
  • changing requirements culture
  • expected results from requirements culture improvement
  • a policy for improved requirements
  • instructor-led workshop: participant input requirement problems solved by Gilb
  • how to give information that determines priorities of requirements (example Wish/Goal/Fail and Qualifiers)
  • how to include requirement information about risks and uncertainties
  • how to include requirement information about traceability (up and down)

Intended for:

  • people who write requirements, and their managers
  • project managers and their managers
  • consultants, engineering/IT methods teachers

Further information