This is an archive of an inactive wiki and cannot be modified.

Method for gathering and organising the Design Constraints

(As discussed during the March 28, 06, telecon; see

We use Design Constraint (DC) as a common term to denote requirements, design goals, critical success factors etc. The list of Design Contraints builds on the earlier work and reflects the group's growing understanding. The objective is to converge quickly towards a stable list of Design Constraints, as complete and comprehensive as possible, and towards a stable structure for these Design Constraints.

The method we adopted (see the minutes of the March 28 telecon) is as follows:

  1. Participants propose design constraints, by adding them to the list of proposed Design Constraints, including information about the proposed position in the DC structure (according to the Template For Design Constraints). The main structuring principles are :

    • The level to which the DC belongs, according to the Goals, Critical Success Factors, Requirements hierachy as described in Franck's email;

    • The dependencies to other DCs;
  2. Participants discuss the proposals on the mailing list, add comments in the DC definition, as libitum
    • Each proposed DC is defended by at least one champion, see the rules below;

    • Discussion and comments strive to come to a consensus regarding the description of a Dc and its position in the structure;
  3. At some points, a DC will be discussed at the telecon
    • One of the reason to put a DC on the agenda of the telecon is if all or part of its definition (e.g. its description, its level etc) appears ready to be frozen or if a frozen DC needs to be reopened to discussion due to new evidence;
  4. The process is complete when the complete definitions of all the DCs are frozen and nobody wants to add a new DC.


To support the process and make it convergent, here are some rules to follow:

Earlier work

This page is about consolidating the work done in the WG regarding requirements and Design Goals and finalising it. It builds upon:

  1. Preliminary work based on the requirements sections from the initial Use Cases;

  2. The requirements listed during the brain storming sessions at F2F2;

  3. Allen's list of Design Goals;

  4. As well as the discussion on design goals at F2F2.