Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @

Difference between revisions of "Requirements Tracking"

From EGIWiki
Jump to navigation Jump to search
Line 608: Line 608:
=== Priority & Impact definitions ===
=== Priority & Impact definitions ===

*Custom Field - Impact

*Impact of Requirement
*** a
The requestor/proposer of a new Requirement needs to assess the likely impact that the modification will have to users both within the immediate user community and EGI community at large.  In turn, this will enable the work to satisfy the new Requirement to be correctly prioritised.  The majority of new Requirements should normally be considered to be “Important with a significant benefit to this user community”.
*Impact categories:
**4.  -  Essential to the effectiveness of this user community/the wider user community
**3.  -  Important with a measurable benefit to this user community
**2.  -  Useful – will be of some benefit to this user community
**1.  -  Nice to have - slight improvement
**0.  -  Don’t know

*'''0''' - Unknown
The User Community Support Team will consider the new Requirement and prioritise any work effort as necessary in relation to other proposals.
*'''1''' - Low
*'''2''' - Medium
*'''3''' - Important
*'''4''' - Critical

== Authorization ==
== Authorization ==

Revision as of 19:15, 26 January 2011

Actions from 2010-12-15 Meeting NA3-SA1-SA2-JRA1

  • Rename: Tools and applications -> User tools and applications Done
  • Rename: Metrics store -> Metrics portal Done
  • Multi-selection lists should be available for tags, some of the categories For Tags is possible, for Categories just for the lowest level
  • Define the mandatory and the optional fields Done. Mandatory: Category (level 1), Requestor (level 1)
  • Non-functional tags should be separated from technology tags on the GUI Done
  • Possibility to add custom tags Done
  • Adding more status values: Done
    • for requirements queue: new status value - "Accepted"
    • for roadmaps queues: new status values - "Developed"
  • Multiple priorities for a request – requester’s priority, implementation priority Same 0-5 in both types of queues. Same definitions. Decoupling of requirements from features allows the usage of different priorities on the requester and the implementer sides
  • Invite group leaders to check ticket submission interface Done
  • Open submission interface for the groups Done
  • All SSO users by default should be able to access requirements queue In progress
  • New queues: Done
    • ops-tools-roadmap
    • user-tools-roadmap
  • Re-assign “feature” tickets to feature queues Done
  • Associate feature tickets with requirement tickets (from the “Requirements” queue)
  • Add “release” tickets to the features queues. Link features tickets to release tickets.
  • Release tickets should have Release date instead of Time Estimated (Can the “Reminder” feature be used for this?)

About this page

This page is only a draft.

This page provides technical details about the Requirement Tracker tool (RT), used by the EGI collaboration to store, monitor and resolve requirements and recommendations communcated by user communities and NGIs to EGI. The page provides manuals and background information to those who wish to

  1. Submit requirements and recommendations to EGI
  2. Browse requirements and monitor progress
  3. Expand or comment requirements
  4. Provide complete or partial solution to requirements


The evolution of the European Grid Infrastructure is driven by the users. Therefore capturing and communicating feedback from users to the infrastructure as well as technology operators and providers is a key goal for User Community Support (NA3 activity of EGI-InSPIRE) and for the project as a whole. The EGI-InSPIRE project has established and runs a well-defined process to collect, capture, process, and resolve user requirements and recommendations. Requirements and recommendations are collected from users through various electronic channels and face-to-face communication mechanisms. A queue called "Requirements" hase been setup in the EGI RT (Request Tracker) system to store requirement tickets, to monitor user demands and to resolve problems. This page uses the "Requirement Tracker" name and the "RT" acronym to refer to the "Requirements" queue of the EGI Request Tracker system.

Additional background information on requirement gathering and processing in EGI can be found on this page and in this Milestone Document.

Submitting a new requirement (ticket) to EGI

This manual describes how can any person with an EGI SSO account submit a requirement to EGI through the RT system: How to submit a new requirement.

Requirements are stored as tickets within the RT system. Such a ticket stores the following information (See also figure below):

  1. Subject: A short, but informative and, if possible, a unique name to describe the requirement.
  2. Category: Defines the particular software, human or other entity of the EGI collaboration that need to be changed as requested in the ticket.
  3. Requestor: Defines the entity (VRC, VO, NGI, etc.) that communicated the requirement to EGI. (This is not necessarily the same who will use the required new feature.)
  4. Tags: associate words to requirements in order to simplify the lookup and grouping of requirements.
  5. Description: Description of the requirement. This part expands over time as the result of discussion between the requestor and solution provider(s).


Browsing, monitoring requirements - Dashboards

Pre-defined queries, "Dashboards" are available for the RT system to browse requirement tickets and to monitor progress of solving them. All the dashboards are public and tickets are publicly visible through these Dashboards.

The RT system can host any number and type of Dashboards. Should your community require custom view to the requirements, please request the setup of a new Dashboard by sending an email to the User Community Support Team (

A complete list of Dashboards of the RT system: All Dashboards

List of all the requirements

Dashboard Name Link Description
All All This dashboard lists all the requirements that EGI is aware of

Filtering requirements by the submitter

These Dashboards filter tickets by Submitter, i.e. by the potential VRC, NGI or other entity who submitted requirements.

Dashboards for science disciplines and more

Dashboard Name Link Description
WeNMR WeNMR Requirements from the WeNMR community: WeNMR (potential VRC) and (VO)
Life Sciences Grid Community Life Sciences Grid Community Requirements from the Life Sciences Grid Community: Life Sciences Grid Community (potential VRC), biomed (VO), lsgrid (VO) and vlemed (VO)
WLCG WLCG WLCG (potential VRC) requirements listing
Astronomy & Astrophysics Astronomy & Astrophysics Astronomy & Astrophysics (potential VRC) requirements listing
Computational Chemistry Computational Chemistry Computational Chemistry (potential VRC) requirements listing
Earth Sciences Earth Sciences Earth Sciences (potential VRC) requirements listing
eHumanities eHumanities eHumanities (potential VRC)requirements listing
Hydro-meteorology Hydro-meteorology Hydro-meteorology (potential VRC) requirements listing

Dashboards by Requirements Status

Dashboard Name Link Description
AllStatus AllStatus AllStatus tickets ordered by Status
New New New Tickets
Open Open Open Tickets
Accepted Accepted Accepted Tickets
Rejected Rejected Rejected Tickets
Stalled Stalled Stalled Tickets
Resolved Resolved Resolved Tickets

Dashboard for Heavy User Communities (HUCs)

This Dashboard lists tickets that were submitted by HUCs. HUCs are User communities that are advanced and experienced in terms of grid usage, operate (at least to some extent) support services for their own members and therefore are less dependent on EGI user support services.

Dashboard Name Link Description
HUCs HUCs HUCs (Heavy User Communities) requirements listing

Dashboard for National Grid Infrastructures (NGIs)

This Dashboard lists tickets that were submitted by NGIs. NGIs are National Grid Infrastructures/Initiatives those provide the resources within EGI.

Dashboard Name Link Description
NGIs NGIs NGIs (National Grid Infrastructures) requirements listing

Virtual Organisations (VOs)

This Dashboard lists tickets that were submitted by VOs. A VO is a group of people with similar interests and requirements, who have physical access to the European Grid Infrastructure thus are able to work collaboratively with other members and/or can share resources regardless of geographical location. A VO can be associated to a VRC, or can exist independently from VRCs.

Dashboard Name Link Description
VOs VOs VOs (Virtual Organisations) requirements listing


This Dashboard lists tickets that were submitted by projects that are part of the EGI community.

Dashboard Name Link Description
Projects Projects Projects requirements listing

Filtering requirements by category

These Dashboards filter tickets based on the subject of the requirements (Subject here means the entity that the requirements refers to.)

Dashboard Name Link Description
Operational Tools Operational Tools Requirements for Grid Operational Tools that are developed by the JRA1 work package of EGI-InSPIRE
UMD UMD Requirements for Unified Middleware Distribution (UMD)
NA3 NA3 Requirements for software tools that are developed and/or provided by the NA3 work package of EGI-InSPIRE

Expanding and commenting requirements

While the Subject, Requestor, Category, Tags and Description part of a requirement ticket cannot be changed, the submitter, solution provider(s) or any third party can add comments to tickets and can reply to a ticket. Comments and replies are recorded in ticket history and both comments and replies are publicly visible. Comments are sent by RT in email to the requestor (the person who opened the requirement ticket), while comments are not. Comments and replies must be used to attach details or background information to a requirement ticket, to discuss the reported demand or to discuss possible solutions. Any user with an EGI SSO account can attach comments to requirement tickets as it is described in this manual: Adding a comment to a requirementWrite this page. Insert a screenshot into it

Providing solution to a requirement

Comment: (in terms of requirements solving market there is a suggestion to make access right to take the ticket (become Owner of the ticket) for All SSO accounts. The Owner could indicate that ticket/requirement was taken and is in the solving process after the solution will be provided by the Owner.)

EGI requirements are resolved according to the following high level workflow:

  1. Consistency check
  2. Allocation to responsible person/group
  3. Completeness check
  4. Providing solution from the EGI-InSPIRE project
  5. Involving external solution providers
  6. Closing the ticket
  7. Validating the solution
Step # Action Responsible party Description of action
1. Consistency check Delegate from User Community Support Team Actions performed in this step:
  1. Check that the ticket describes a requirement and not a bug. Bugs must be redirected to GGUS. (Manually until RT and GGUS become connected.)
  2. The "Subject", "Requestor", "Category" and "Description" fields must be filled out.
  3. Tags must be attached if possible.
  4. The Subject must be consistent with the Description.
  5. Category must be consistent with the Description.
  6. Description must be detailed enough: it should include information about the use case that motivates the feature and a description of the requirement.
  7. Set the proper "Priority" value of the ticket based on the priority provided by the requestor in the textfield.
  8. Check that the ticket describe a requirement, or a bug? Redirect bugs to GGUS.

Change values of fields if necessary. Contact submitter if necessary.

2. Formally accept the ticket User Community Support Team Formal acceptance of the ticket means:
  1. Allocate an owner to the ticket. The owner is responsible for solving the ticket and not necessarily the solution provider. Owner is chosen based on the content of the "Category (level1)" field of the ticket:
    1. Support Service --> User Community Support Team
    2. Support Action --> User Community Support Team
    3. Unified Middleware Distribution (UMD) --> User Community Support Team
    4. Operational Tools --> Daniele Cesini (JRA1 leader)
    5. User Tools and Applications --> User Community Support Team
  2. Set the status of the ticket from NEW to OPEN
3. Evaluate the technical completeness and correctness of the request Ticket owner Evaluation at this stage means:
  1. Description must be detailed enough for owner to find and propose solutions and/or solution providers. Contact requestor if additional information is necessary.
  2. Status must be set to Accepted, Stalled or Rejected:
    1. Accepted if the request is found valid. Ticket owner accepts to provide solution directly/indirectly.
    2. Rejected if the description is found vague, incorrect or incomplete by the owner and requetor refuses to correct it.
    3. Stalled if the ...
4. Provide solution from the EGI-InSPIRE project Ticket owner
5. Involve external solution providers Ticket owner
6. Close the ticket Ticket owner
7. Validate the solution - IS THIS POSSIBLE? Requestor


Status definitions

Requirements queue status values definitions:

  • New = just arrived, no action taken yet (ticket must be Opened)
  • Open = to be discussed (Ticket is allocated to a person/group. This person/group should attach a deadline to the ticket - e.g. when it will be discussed)
  • Stalled = discussion/implementation is on hold for some reason
  • Resolved = solved (validation may or may not have happened. There will be no "validated" status at the moment. If we need, we can add it later)
  • Rejected = EGI discussed then rejected the request (reason of rejection must be attached to the ticket)
  • Accepted = to be implemented (Requested feature/action will be implemented. The owner of the ticket is responsible for the implementation)

ops-tools-roadmap and user-tools-roadmap queues status values definitions:

  • New = Feature that is not necessarily linked to any requirement yet. Feature that is not necessarily allocated to any release yet. (This status can be used for features that need to be discussed, finalised to meet a requirement/request)
  • Open = Feature to be included in the next release (the feature is currently under development). The ticket must depend on at least one requirements ticket from the requirements queue
  • Stalled = Feature to be included in some future release (not in the next release). The ticket must depend on at least one requirements ticket from the requirements queue
  • Developed = The feature has been developed (responsibilities have to be defined to validate) is it pre-release or production release ?
  • Resolved = Implemented (developed feature was validated and can be understood as solved issue)
  • Rejected = EGI discussed then rejected the feature (because no related user requirement exists)

Status life cycle

RT status values.png

Priority & Impact definitions

  • Impact of Requirement

The requestor/proposer of a new Requirement needs to assess the likely impact that the modification will have to users both within the immediate user community and EGI community at large. In turn, this will enable the work to satisfy the new Requirement to be correctly prioritised. The majority of new Requirements should normally be considered to be “Important with a significant benefit to this user community”.

  • Impact categories:
    • 4. - Essential to the effectiveness of this user community/the wider user community
    • 3. - Important with a measurable benefit to this user community
    • 2. - Useful – will be of some benefit to this user community
    • 1. - Nice to have - slight improvement
    • 0. - Don’t know
  • Priority

The User Community Support Team will consider the new Requirement and prioritise any work effort as necessary in relation to other proposals.


Requirements queue access rights

New Requirement

RT Web

Please refer to the New Requirement Manual.


Web Form

Requirement dependencies

Ticket in the Requirements queue can have the dependencies or be depended on by another ticket.

RT WEB UI Links section must be used for that.

i.e. for the existing ticket #111 which is Requirement we put the dependency for another ticket #222 which is Feature request in the user-tools-roadmap queue. The ticket #111 cant be Resolved untill ticket #222 will be Resolved or Rejected or Deleted.

All Tickets in Requirements queue RT at a Glance interface will have additional mark "(pending 1 other ticket)" if they have at least one dependency which is not Resolved or Rejected or Deleted.

Ticket Watchers

Watcher is superset term for Requestors, Ccs and AdminCcs.

More details:

Watcher is a user who gets a copy of correspondence on the ticket.

Watcher (type CC) gets the same things as a Requestor.

Watcher (type AdminCC) gets the same things as CC + comments those are not sent to requestors.

Only Admins of the Queue can set up and remove the Watchers.

Ticket AdminCC & CC

An *AdminCC* is like a joint Owner of a Ticket. A ticket's AdminCCs are Users, typically Staff, who receive both Comments and Correspondence. A CC, who might be outside the company, only gets Correspondence.

This role could be used for a manager who is not directly responsible for a Ticket but wants to follow its progress and be able to comment on it or Reply to the Requestor.

A ticket's AdminCCs will have Rights to the ticket by virtue of being AdminCCs.

Firefox & ticket search

Create New Bookmark using these instructions:

1) go to firefox menu bar "Bookmarks"

2) choose "organize bookmarks"

3) choose "bookmarks menu"

4) right click on "bookmarks menu" -> "New Folder..." and fill the details below:

Location: %3D 'requirements' AND ( Subject LIKE '%s' OR Content LIKE '%s' )

Keyword: rt

Now you can search rt by typing 'rt [some search terms]' in the address bar of firefox.


For Firefox use "Live Bookmark"



Useful Links about RT