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.



The topic of this chapter is ...


The topic of this chapter is ...



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)


General explications

List of requirements

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

External Resources

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


Things to be clarified:
  • ...
  • ...


The TEG recommends to
  • ...
  • ...



1/ http://.....
Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2012-03-06 - UlrichSchwickerath
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback