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 @ egi.eu.

Difference between revisions of "Requirements Tracking"

From EGIWiki
Jump to navigation Jump to search
Line 535: Line 535:
#Category must be consistent with the Description.  
#Category must be consistent with the Description.  
#Description must be sufficiently detailed: it should include information about the use case that drives the need and a description of the requirement itself  
#Description must be sufficiently detailed: it should include information about the use case that drives the need and a description of the requirement itself  
#Set "Priority" for the ticket based on the “Impact” provided by the requestor  
#Set "Priority" for the ticket based on the “Impact” provided by the requestor.


Change values of fields if necessary. Contact submitter if necessary.
Change values of fields if necessary. Contact submitter if necessary. The ticket status can be either New or Open.
|-
|-
| 2.
| 2.
| Formally accept the ticket
| Formally accept the ticket
| UCST
| UCST
| Formal acceptance of the ticket means:
| Formal acceptance of the ticket means to allocate an owner to the ticket. The owner is responsible for solving the ticket but not necessarily the solution provider. Owner is chosen based on the content of the "Category (level 1)" field of the ticket:  
#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:  
*Support Service --> User Community Support Team  
##Support Service User Community Support Team  
*Support Action --> User Community Support Team  
##Support Action User Community Support Team  
*Unified Middleware Distribution (UMD) --> User Community Support Team  
##Unified Middleware Distribution (UMD) User Community Support Team  
*Operational Tools --> Daniele Cesini (JRA1 leader)  
##Operational Tools Daniele Cesini (JRA1 leader)  
*User Tools and Applications --> User Community Support Team
##User Tools and Applications User Community Support Team  


The ticket status can be either New or Open.
|-
|-
| 3.
| 3.
Line 557: Line 557:
#Description must be detailed enough for owner to find and propose solutions and/or solution providers. Contact requestor if additional information is necessary.  
#Description must be detailed enough for owner to find and propose solutions and/or solution providers. Contact requestor if additional information is necessary.  
#Status must be set to Accepted, Stalled or Rejected:  
#Status must be set to Accepted, Stalled or Rejected:  
##'''Accepted''' if the request is found valid. Ticket owner accepts to provide solution directly/indirectly.  
#*'''Accepted''' if the request is found valid. Ticket owner accepts to provide solution directly/indirectly.  
##'''Rejected''' if the description is found vague, incorrect or incomplete by the owner and requetor refuses to correct it.  
#*'''Rejected''' if the description is found vague, incorrect or incomplete by the owner and requetor refuses to correct it.  
##'''Stalled''' if any external problem blocks the solution of ticket
#*'''Stalled''' if any external problem blocks the solution of ticket


|-
|-
Line 566: Line 566:
| Ticket owner
| Ticket owner
|  
|  
#Investigate and contact project partner / NGIs that could potentially provide a solution
#Investigate and contact project partner / NGIs that could potentially provide a solution (e.g.:)
##Use EGEE/EGI events to find experts
#* Use EGEE/EGI events to find experts
##Survey NGIs???
#* Survey NGIs
#Provide solution / investigation output into ticket
#Provide solution / investigation output into ticket
#Use the UCB to resolve outstanding tickets


<!--
OR
OR


#Investigate and contact projects that could potentially provide solution
#Investigate and contact projects that could potentially provide solution
#Use the UCB to resolve outstanding tickets
#Use the UCB to resolve outstanding tickets
 
-->
|-
|-
| 6.
| 6.
Line 582: Line 584:
|  
|  
#Set status to Resolved
#Set status to Resolved
#Solving a ticket generates an email to requestor
#Solving a ticket generates an e-mail to requestor


|-
|-
Line 590: Line 592:
|  
|  
#Evaluation should happen in a separate process
#Evaluation should happen in a separate process
##User satisfaction form
#*User satisfaction form


|-
|-

Revision as of 16:10, 14 February 2011



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:

  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

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 (UCST; 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

Anyone can submit requirements to EGI through the RT system, as long as they have an EGI SSO account. After login in into the RT system, the user must choose the "Requirements" queue, the place where all requests are stored and analyzed. The ticket requestor needs to specify both mandatory and optional fields, while providing a detailed description of the requirement. If this step is properly done, the requirement is tagged in such a way that the solution providers can be called to take an action upon the ticket in an easy and timely manner. A detailed description on how to submit a requirement can be found here.


Browsing, monitoring requirements - Dashboards

Pre-defined queries, "Dashboards", are available for the RT system to browse requirement tickets and to monitor progress while solving them. All the dashboards are public and thus associated tickets are also publicly visible as well. The RT system can host any number and type of Dashboards. Should your community requires a customized view to the requirements, please request the setup of a new Dashboard by sending an e-mail to the User Community Support Team. A complete list of Dashboards on the EGI RT system can be found here. A brief description of the currently available Dashboards is presented in the next document sub-sections.


List of all the requirements

Dashboard Name Description
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 Description
Astronomy & Astrophysics Astronomy & Astrophysics (potential VRC) requirements listing
Computational Chemistry Computational Chemistry (potential VRC) requirements listing
Earth Sciences Earth Sciences (potential VRC) requirements listing
eHumanities eHumanities (potential VRC)requirements listing
Hydro-meteorology Hydro-meteorology (potential VRC) requirements listing
Life Sciences Grid Community Requirements from the Life Sciences Grid Community: Life Sciences Grid Community (potential VRC), biomed (VO), lsgrid (VO) and vlemed (VO)
WeNMR Requirements from the WeNMR community: WeNMR (potential VRC) and enmr.eu (VO)
WLCG WLCG (potential VRC) requirements listing

Dashboards by Requirements Status

Dashboard Name Description
AllStatus AllStatus tickets ordered by Status
New New Tickets
Open Open Tickets
Accepted Accepted Tickets
Rejected Rejected Tickets
Stalled Stalled Tickets
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 Description
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 Description
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 Description
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 Description
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 Description
NA3 Requirements for software tools that are developed and/or provided by the NA3 work package of EGI-InSPIRE
Operational Tools Requirements for Grid Operational Tools that are developed by the JRA1 work package of EGI-InSPIRE
UMD Requirements for Unified Middleware Distribution (UMD)


Expanding and commenting requirements

While the "Subject", "Requestor", "Category", "Tags" and "Description" fields of a requirement ticket cannot be changed, the submitter, the solution provider(s) or any third party, can attach comments and replies to tickets. Comments and replies are recorded in ticket history and both are publicly visible. Comments are also sent by the RT system in e-mail to the requestor (the person who submitted the requirement ticket), while comments are not sent in e-mail. 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 below.

1) Open the ticket you want to comment/reply.

In order to comment/reply to a ticket, the user should search for the specific ticket in the RT system either through the unique ticket identifier or using keywords. After opening the relevant ticket, the user should click the proper button which triggers the comment/reply (see red box in the figure below).

Reply ticket.PNG

Notes:

Reply - your reply will be annexed to the ticket and an e-mail notification will be sent to both the "Requestor(s)" and "Owner".

Comment - your comment will be annexed to the ticket and no notifications will be sent to "Requestor(s)" or "Owner"; it is considered to be an internal comment.


2) Provide feedback to be annexed into the ticket.

After the previous step, a new window will be presented to the user. You should reply/comment using the EGI RT in-build text editor. Once your feedback was typed, do not forget to hit the "Update Ticket" button. The figure below shows the reply window to a ticket, highlighting in red boxes the relevant ticket fields to this step.

Reply ticket form.PNG

Note:

If we had chosen the "Comment" option instead of "Reply", we would see in the field "Update Type:" the value "Comments (Not sent to requestors)".

Providing solution to a requirement

The workflow below described was defined taking into consideration the following goals:

  • assure that simple requirements are resolved quickly
  • complex requirements are expanded and broken into smaller resolvable units, quickly and efficiently
  • be fair to technology providers: any potential technology or solution provider can see and offer solution to any requirement
  • be transparent: EGI stakeholders can see the evolution or requirements
  • identify potential solution providers without causing too much noise (spam) within the community

Should we keep this comment here???

--->

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.)

--->

With these goals present, EGI requirements are resolved accordingly 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 UCST 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", "Impact" and "Description" fields must be filled.
  3. The Subject must be consistent with the Description.
  4. Category must be consistent with the Description.
  5. Description must be sufficiently detailed: it should include information about the use case that drives the need and a description of the requirement itself
  6. Set "Priority" for the ticket based on the “Impact” provided by the requestor.

Change values of fields if necessary. Contact submitter if necessary. The ticket status can be either New or Open.

2. Formally accept the ticket UCST Formal acceptance of the ticket means to allocate an owner to the ticket. The owner is responsible for solving the ticket but not necessarily the solution provider. Owner is chosen based on the content of the "Category (level 1)" field of the ticket:
  • Support Service --> User Community Support Team
  • Support Action --> User Community Support Team
  • Unified Middleware Distribution (UMD) --> User Community Support Team
  • Operational Tools --> Daniele Cesini (JRA1 leader)
  • User Tools and Applications --> User Community Support Team

The ticket status can be either New or 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:
    • Accepted if the request is found valid. Ticket owner accepts to provide solution directly/indirectly.
    • Rejected if the description is found vague, incorrect or incomplete by the owner and requetor refuses to correct it.
    • Stalled if any external problem blocks the solution of ticket
4./5. Provide solution from the EGI-InSPIRE project or Involve external solution providers Ticket owner
  1. Investigate and contact project partner / NGIs that could potentially provide a solution (e.g.:)
    • Use EGEE/EGI events to find experts
    • Survey NGIs
  2. Provide solution / investigation output into ticket
  3. Use the UCB to resolve outstanding tickets
6. Close the ticket Ticket owner
  1. Set status to Resolved
  2. Solving a ticket generates an e-mail to requestor
7. Validate the solution Requestor
  1. Evaluation should happen in a separate process
    • User satisfaction form

TECHNICAL DETAILS OF TICKET MANAGEMENT

Technical Details of RT system and ticket management