Show TOC Hide TOC

Filling in the template.

The following points are guides to filling in the sections of the template:

• Abstract: An introduction into the topic which should give a brief overview. Ideally it should be a short first paragraph summarising the rest of the section so that the reader can decide if he's interested in the topic or not

• Introduction General explications and context: If the abstract does not explain the rest of the text one or two further paragraphs can explain in a little more detail the scoping and area examined.

• • Definitions: All domain specific terms used in the rest of the sections should be added here.

• • Assumptions: Anything that a people without experience in this subject would not see. This is a place holder for criticism and refutation.

• Use cases: Use cases describe what a specific service is expected to be able to do, and not how it does it. Use cases are given as an enumerated list. The "Actor" or the person who wants to do complete a task should be explicitly stated for each use case. Expected relevant actors are expected to include sites, VO, experiment member, ROC. Use cases should not include how actors use the system, only what they want to do.

• Requirements: Describe mechanisms/consequences for the service, and actors which are needed to complete one or more use cases. The numbers of use cases leading to a requirement must be quoted for each Requirement, referring to the number of the use case in the list. Requirements with no use cases are considered invalid and should be removed.

• External Resources: If external specifications exist which match most or all of the requirements listed above, they should be quoted here.

• Impact: Who should work on which Requirement/Specification to solve the use case.

• Recommendations: The groups conclusion on if this is a valid topic of work,
  • if the use cases should be further explored into requirements,
  • if specifications already exist and need to be investigated further,
  • if new specifications are required and why,
  • if development should be commissioned based upon the specifications.

• Conclusions: a short summary of the position of the TEG on the topic

Notes: Filling in Use cases is enough, for a TEG. Under special cases Specifications have also been agreed. The TEG should not recommend developing/changing software without specifications. It is reasonable for the TEG to request Requirements and Specifications be developed.

Template

Abstract

Introduction

Definitions

Assumptions

Use cases

General explications

List of use cases

Requirements

General explications

List of requirements

External Resources

• active development of in 1/ may be relevant because
• an example of a fitting requirement is 2/

Impact

• ...
• ...

Recommendations

• ...
• ...

Conclusions

References

http://