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

The topic of this chapter is ...

Introduction

The topic of this chapter is ...

Definitions

Assumptions

Use cases

General explications

List of use cases

Identifier	Actors	Pre-conditions	Scenario	Outcome	(Optional) What to avoid
Comment	e.g. users, VO robots, sysadmins (tuning configurations at sites), NGI etc	this is where the actors start: e.g., a VO has a pilot framework, and a site has multi-core nodes	What the actors do, what do they try to achieve	What is expected to be achieved	Any unwanted outcome (e.g., no bottlenecks, no new services needed, etc)
1.1
2.
2.1
2.2

Requirements

General explications

List of requirements

Identifier	Requirement	Originating use cases	(Optional) Comments
Comment	Describe the requirement for the service	Comma separated list of use case identifiers from the table above	additional comments on this requirement
1.	The service must be ....	1.2, 3.5	bla
2.1	The service must have ...	2, 6.5	blabla