The requirements database contains the full list of requirements for EGEE. Write access is granted to one person per activity/application. That person can only modify the requirements database via the procedures below. That person should only modify his/her activity's priority for an existing requirement. The text of a requirement should only be changed with the agreement of the author of a requirement.

The savannah "support" tracking is now used to track the progress of a requirement as well as the text of the requirement itself. Modifications of the available fields should be discussed on the PTF mailing list.

1. Requirements are discussed within each activity. Each requirement is ranked within the activity and reasons given for that ranking. The exact procedure for doing this is entirely under the control of the activity, but should be documented, for example, in the activity's quality plan.
2. The activity's requirements database administrator for that activity verifies that the requirement does not already exist in the database. If the requirement exists, then the administrator should add the activity's priority (e.g. HEP, BIOMED, ...) to the existing record in the database, adding a subgroup or application tag if appropriate. If there is a similar requirement and it could be modified to include the new required functionality, the administrator should initiate this discussion via the "follow-up" comments section of the requirement. If all concerned agree, the requirement is modified and reranked by the PTF. If no agreement on the change can be reached, then a new requirement should be opened as below.
3. The requirements database administrator adds the new requirements to the database. Once the information is complete and correct, the state of the bug should be changed to "New Requirement" and the bug assigned to the Testing Group Representative (currently Diana Bosio).

   NOTE: The text of the requirement goes in the "Requirement" field. The "Original Submission" field should be ignored. The application-specific ranking for the requirement must be specified. The "Rationale" field may contain the reason for the requirement as well as any additional information.

4. The testing group representative should change the state of the requirement to "Testing Group Evaluation" and assign the requirement to one of the test group members. The assignee must review the requirement to ensure that it is:
   • sufficiently clear and precise to reasonably write a test case (in exceptional cases, this may not be possible; for example with some security requirements)
   • each entry describes one and only one requirement
   • there is a use case which corresponds to the requirement (the use case may be in an external document, but must be publicly accessible)
   The testing group representative should use the "follow-up" process within the support tracker to discuss with the originating requirement administrator changes to the requirement necessary to conform to the standards above. Once the testing group representative is satisfied, the bug is reassigned to the JRA1 representative (currently Erwin Laure). The testing group should plan how to add a test case for the requirement to the test suite (and implement it as soon as possible).
5. The JRA1 representative should change the state of the requirement to "Middleware Evaluation" and assign the requirement to one of the middleware developers for review. The reviewer should provide feedback about 1) difficulty in implementing/meeting the requirement, 2) potential conflicts from the requirement, 3) "guess-estimate" time scale on which the necessary development could be done, and 4) which services will be impacted by the requirement. All this should be entered in the requirement via the follow-up information. Once done, the bug should be reassigned to the chair of the PTF (currently Cal Loomis).
6. The chair of the PTF will change the state of the requirement to "PTF Evaluation". The chair will make a recommendation on the rank of the requirement to the full PTF. All PTF members should comment on the ranking via the mailing list. Once a concensus has been reached, the requirement is updated to reflect the ranking and the state of the requirement is changed to "Unsatisfied". In cases where a concensus can't be reached by email, the requirement should be discussed at a PTF meeting. If still no concensus can be reached it is referred to the technical director.
7. Once a release has been made, the middleware and testing groups should review the requirements, changing any the state of any satisfied requirements to "Satisfied" and change the ownership of the requirement to the originator.
8. The originator of the requirement should verify that the requirement is indeed satisfied. If so, the state should be changed to "Satisfied and Verified". If not, the state should be changed to "Unsatisfied" and reassiged to the middleware representative. The "follow-up" field must contain the reasons why the originator feels that the requirement has not been satisfied. This iteration must continue until the requirement is satisfied.

Anyone can comment on an existing requirement--either the applications to more fully describe/change a requirement or someone outside to challenge the validity of a given requirement. If the originator of a requirement agrees to a change. The requirement should be reranked via the process for a new requirement.

The requirements will be ranked with the following course scale. The descriptions are intended only to be informational but are given for both application and operation perspectives.

0. "Rejected": Satisfying the requirement would conflict with satisfying another more important/general requirement. Or the requirement is too difficult to implement because it involves large-scale changes in the architecture, etc.
1. "Luxury": Would like to have, but benefits a very few number of users or is very specific to a particular application. Could be useful to satisfy special needs of some sites, but not needed for general operation.
2. "Desired": Satisfying the requirement would significantly simplify the use of the grid for some set of users. Workarounds exist, but may be difficult or clumsy to use. Satisfying the requirement will significantly simplify the operation of the grid and increase the flexibility of the setup.
3. "Important": Without satisfying the requirement one application group cannot effectively use the grid. Without satisfying this requirement some sites can't operate the software or it will be banned for lack of security. The deployment process will be error prone or extremely time/resources consuming. Without it efficient problem localization will be impossible. The scalable/fault tolerant deployment depends on satisfying this requirement.
4. "Critical": Without satisfying the requirement more than one application group cannot effectively use the grid. Without satisfying this requirement the software can not be operated on several sites or will be banned for lack of security.