Requirements Tracking

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
• Open submission interface for the groups
• 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 of resolving requirements
3. Expand or comment on requirements
4. Provide complete or partial solution to a requirement

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 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 requirement submitted to EGI through the RT system: How to submit a new requirement.

Tickets stored within the Requirements queue are filtered and queried using the data fileds within the tickets.

Each of the requirement tickets store the following information:

1. Subject: A short but informative and if possible unique name to describe the requirement.
2. 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.)
3. Category: Defines the particular software, human or other entity of the EGI collaboration that need to be changed as requested in the ticket.
4. Tags: associate words to requirements in order to simplify the lookup and grouping of requirements.

Browsing, monitoring requirements - Dashboards

Pre-defined ticket queries, "Dashboards" are available for the RT system to browse and monitor progress of requirement tickets. All the dashboards are public and requirement tickets through the dashare accessible for viewing by anybody.

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

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

Unfiltered list of 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 VRC, NGI or other entity who submitted requirements.

Dashboards for Virtual Research Communities (VRCs)

These Dashboards list tickets that were submitted by VRCs. VRCs are groups of researchers, possibly widely dispersed, working together effectively through the use of information and communications technology (ICT). There can be any number of Virtual Organisations associated with each VRC. These Dashboards list tickets that were submitted by the VOs too:

Dashboard Name	Link	Description
VRCs	VRCs	Requirements that have "VRC" as submitter.
VRC_WeNMR	VRC_WeNMR	Requirements from the WeNMR community: WeNMR (VRC) and enmr.eu (VO)
VRC_Life_Sciences_Grid_Community	VRC_Life_Sciences_Grid_Community	Requirements from the Life Sciences Grid Community: LifeSciencesGridCommunity (VRC), HealthGrid (Project), biomed (VO), lsgrid (VO) and vlemed (VO)
VRC_WLCG	VRC_WLCG	VRC WLCG requirements listing
VRC_Astronomy_&_Astrophysics	VRC_Astronomy_&_Astrophysics	VRC Astronomy & Astrophysics requirements listing
VRC_Computational_Chemistry	VRC_Computational_Chemistry	VRC Computational Chemistry requirements listing
VRC_Earth_Sciences	VRC_Earth_Sciences	VRC Earth Sciences requirements listing
VRC_eHumanities	VRC_eHumanities	VRC eHumanities requirements listing
VRC_Hydro-meteorology	VRC_Hydro-meteorology	VRC Hydro-meteorology requirements listing

Dashboard for Heavy User Communities (HUCs)

This Dashboard lists tickets that were submitted by HUCs. HUCs are ...:

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

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

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

Priority definitions

• 0 - Unknown
• 1 - Low
• 2 - Medium
• 3 - Important
• 4 - Critical

Authorization

User Rights reference - http://requesttracker.wikia.com/wiki/Rights

Rights should be the same, from e-mail and from RT WEB UI.

• CreateTicket:
• ReplyToTicket:
• Update Ticket properties:

• for requirements queue members - ModifyTicket properties + all user actions
• for ops-tools-roadmap queue members - ModifyTicket properties + all user actions
• for user-tools-roadmap queue memebers - ModifyTicket properties + all user actions
• all the rest of users - seeQueue, CreateTicket, ReplyToTicket - same rights for e-mail and RT WEB UI. - no ModifyTicket properties role.

New Requirement

RT Web

Please refer to the New Requirement Manual.

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.