Current Situation

We have two lists currently that hold the requirements from LCG clients.

From the HEP/NA4 list:

https://twiki.cern.ch/twiki/bin/view/EGEE/PriorityList

An interesting use of the votes above is the ability to see whether a particular requirement voting was dominated by one stakeholder or more equally by all. ie. We can make a deduction on the RMS of a voting.

From: https://twiki.cern.ch/twiki/bin/view/EGEE/SA1_TCG

New Requirements Mechanism

A super-set of the data from the above two pages would result in:

* Stakeholder -- a client of the middleware stack.
* Provider -- Activity/Group that will make the necessary software changes according to the requirement.
* TMB -- Group made up of Stakeholders and Providers.

From Steven's email

• Who will benefit.

• Implications (in post EGEE world) of not doing the changes, etc.

These bits of information should be provided by the requirements originator in the original submission to the requirements gathering mechanism (RGM, Savannah or other). As above, this information should be entered into the "Issue/Requirement Description" at time of submission.

Process

The process may not differ much from the current situation.

1. Stakeholders submit their requirements. The requirement must contain:
   1. Title and description.
   2. Who will benefit.
   3. Implications of not following the requirement.
   4. Post EGEE considerations.
2. Duplicate requirements are removed at TMB-wide level.
3. The remaining requirements are voted on by the stakeholders.
   1. The priority of a task is now determined.
4. Requirements are ordered by votes with each category by the TMB.
   1. Provider that will do the work determined.
   2. Starting date may be assigned.
5. Requirements are assigned to the provider that will do the work.
   1. The first assignee is the leader.
   2. Leader subsequently assigns to the group/developer that will do the work.
   3. Starting date may be modified
   4. Ending date can be determined.
6. The work for requirements should be linked to the work plan of the provider.
   1. Subsequently, the provider work plan should be linked to software patches.
7. The progress of the requirements tasks is monitored.
   1. As task end-dates come due, the task should be reviewed.

-- JohnWhite - 15 Jan 2009