Filling in the template.

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

  • Introduction: The introduction should give a brief overview. Ideally it should be a short first paragraph summarising the rest of the section.

  • General explications and context: (Optional) If the introduction 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.

  • Specification:Details on how a requirement should be satisfied. Specifications must reference Requirements, Specifications with no requirements shoudl be removed. For example how a job can get the number of cores it is allowed to execute upon.

  • External Resources: Confused with this section!!!!!!!!!!

  • 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 the specifications need to be investigated further, if development should be commissioned based upon the specifications.

Note: 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 ...

General explications and context

The topic of this chapter is ...



Use cases

General explications

List of use cases

1. first use case: active party : experiment

1.1 ...

1.2 ...

2. second use case: active party: site


General explications

List of requirements

1. The service needs to be (use cases : 1.2, 2.5) 2. The service has to provide (use cases: 1.3, 3.5, ...)

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 | r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2012-03-02 - OwenMillingtonSyngeExCern
    • 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