Method for gathering and organising the Design Constraints
(As discussed during the March 28, 06, telecon; see http://www.w3.org/2006/03/28-rif-minutes.html)
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:
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;
- 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;
- 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;
- 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:
- Do not add a proposed design constraint if you are not ready to defend that it must make the final list
- If you add a new DC to the structure, you MUST put your name in the list of champions for that DC;
If you add a new proposal, do it using the Template For Design Constraints: you MUST fill all the fields;
The definition of a DC must have structuring information, and at least a proposed level;
- A DC must be justified, e.g. wrt the use cases;
- Be sure to mention the urgency of the proposed design constraint for you;
- Make sure that the DC you want to add is different from any DCs already listed, and be prepared to defend that the difference is significant enough for the DC to make the final list;
- If you find that it is not different enough from some already listed DC to add a new one, amend that or those similar DCs with the appropriate comments in the appropriate fields of the template; be sure to identify your comments as such and yourself as the commentator;
Before adding your own proposed design constraints, check the earlier lists. If possible copy from them: this is the best way to avoid redundant work;
- When commenting a DC, be sure to sign your comments;
Use the Design_Constraints/Terminology when appropriate. Don't just say "RIF must ..."
This page is about consolidating the work done in the WG regarding requirements and Design Goals and finalising it. It builds upon:
As well as the discussion on design goals at F2F2.