Requirements Tracking
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 communicated by user communities and NGIs to EGI. The page provides manuals and background information to those who wish to:
- Submit requirements and recommendations to EGI
- Browse requirements and monitor progress
- Expand or comment requirements
- Provide complete or partial solution to requirements
Introduction
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 to technology operators and providers, is a key goal for the User Community Support Team (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" has been setup in the EGI RT (Request Tracker) system to store requirement tickets, to monitor user demands and to resolve problems. Throughout this page the term "Requirement Tracker" and the acronym "RT" refer to the "Requirements" queue of the EGI Request Tracker system.
The high level description of the requirement gathering and processing workflow of EGI can be found on this page and in this EGI-InSPIRE project Milestone Document.
Submitting a new requirement (ticket) to EGI
This section describes how a person with an EGI SSO account can 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 includes the following information (See also figure below):
- Subject (Mandatory): A short, but informative and, if possible, a unique name to describe the requirement.
- Category (Level 1 is Mandatory): Defines the particular software, human or other entity of the EGI collaboration that need to be changed as requested in the ticket.
- Requestor (Level 1 is Mandatory): 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.)
- Tags: associate words to requirements in order to simplify the lookup and grouping of requirements.(Optional)
- Impact (Mandatory): choose the impact of your requirement
- Description (Mandatory): Description of the requirement. This part evolves and expands over time as the requestor and solution provider(s) investigate and identify particular needs.
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 (ucst@egi.eu).
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 and stores in the RT system |
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 enmr.eu (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 |
Projects
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 attach comments and replies to tickets. Comments and replies are recorded in ticket history and both comments and replies are publicly visible. Comments are also sent by the RT system in email to the requestor (the person who submitted the requirement ticket), while comments are not sent in email. Comments and replies must be used to attach details and background information to a requirement ticket, to discuss the reported demand and possible solutions. Any user with an EGI SSO account can attach comments to requirement tickets. This process is described in this manual:
1) Open the ticket you want to put the comment or reply to and choose either option within a red rectangle:
- Note: Reply - Your reply will be entered into ticket and sent to Requestor and Owner (if set) by e-mail. Comment - reply is not sent to Requestor or Owner by e-mail, but entered into the ticket and is considered to be internal comment.
2) We have chosen option "Reply" and another window with a form to fill appears, fill up your reply in the big red rectangle using text editor and hit "Update Ticket":
- Note: if we would choose "comment" option we would see in the field of "Update Type:" the value "Comments (Not sent to requestors)"
Providing solution to a requirement
The below described workflow has been defined with the goals to:
- assure that simple requirements are resolved quickly
- complex requirements are expanded and broken into smaller, resolvable units quickly and efficiently
- being fair to technology providers: any potential technology or solution provider can see and offer solution to any requirement
- being transparent: EGI stakeholders can see the evolution or requirements
- identify potential solution providers without causing too much noise (spam) within the community
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:
- Consistency check
- Allocation to responsible person/group
- Completeness check
- Providing solution from the EGI-InSPIRE project
- Involving external solution providers
- Closing the ticket
- Validating the solution
Step # | Action | Responsible party | Description of action |
---|---|---|---|
1. | Consistency check | Delegate from User Community Support Team | Actions performed in this step:
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:
|
3. | Evaluate the technical completeness and correctness of the request | Ticket owner | Evaluation at this stage means:
|
4./5. | Provide solution from the EGI-InSPIRE project or Involve external solution providers | Ticket owner |
OR
|
6. | Close the ticket | Ticket owner |
|
7. | Validate the solution | Requestor |
|