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 48: Line 48:
By default all EGI SSO accounts have access to Requirements queue.
By default all EGI SSO accounts have access to Requirements queue.


= Submitting a new requirement to EGI =
= Submitting a new requirement (ticket) to EGI =


This manual describes how can any member of the EGI collaboration [[New_Requirement_Manual|submit a new requirement]].
This manual describes how can any member of the EGI collaboration [[New_Requirement_Manual|submit a new requirement]].


=== Requirements categories ===


= Categorisation of Requirement tickets in RT =


Names of the fields implemented in the RT system:
The following fields in requirement tickets provide meta-information about the requirement:


*Category (level 1)
*Category (level 1)
Line 66: Line 66:
*Custom Tag
*Custom Tag


== Pre-defined values to choose for these fields ==


==== Category ====
=== Category ===


Legend:
Legend:

Revision as of 17:32, 11 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
  • 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 internal UCST at EGI.eu page to keep tracking of the things related to RT.

Introduction

Requirement tracking in EGI

...

The RT system

...

Software homepage - Request Tracker homepage

RT at EGI.eu

Request Tracker instance at EGI.eu - Request Tracker EGI.eu

Authentication - using EGI Single Sign-On (SSO) - EGI.eu SSO

By default all EGI SSO accounts have access to Requirements queue.

Submitting a new requirement (ticket) to EGI

This manual describes how can any member of the EGI collaboration submit a new requirement.


Categorisation of Requirement tickets in RT

The following fields in requirement tickets provide meta-information about the requirement:

  • Category (level 1)
  • Category (level 2)
  • Requestor (level 1)
  • Requestor (level 2)
  • Requestor (level 3)
  • Non-Functional Tag
  • Technology Tag
  • Custom Tag

Pre-defined values to choose for these fields

Category

Legend:

  • - Category (level 1)
    • - Category (level 2)


  • Support Service
    • Applications Database
    • Training Services
    • VO Services
    • Web Site
    • Other
  • Support Action
    • Consultancy
    • Training
    • Other
  • Unified Middleware Distribution (UMD)
    • Accounting
    • Authentication
    • Authorization
    • Compute
    • Compute Job Scheduling
    • Credential Management
    • Database Access
    • File Access
    • File Encryption/Decryption
    • File Transfer
    • File Transfer Scheduling
    • Information Discovery
    • Messaging
    • Metada Catalogue
    • Monitoring
    • Parallel Job
    • Remote Instrumentation
    • Service Management
    • User Management
    • Virtual Image Management
    • Virtual Machine Management
    • Workflow
  • Operational Tools
    • Accounting Portal
    • Accounting Repository
    • GGUS
    • GOCDB
    • Metrics Portal
    • Network Monitoring
    • Operations Dashboard
    • Operations Portal
    • SAM / ACE
    • SAM / ATP
    • SAM / MyEGI
    • SAM / NCG
    • Other
  • User Tools and Applications
    • Domain specific applications
    • Generic Tools
    • Other
  • Non-Functional
    • (Inter)Operability
    • Availability
    • Installability
    • Performance
    • Portability
    • Recoverability
    • Reliability
    • Safety
    • Scalability
    • Serviceability
    • Usability
    • Other
  • Other


Requestor

Legend:

  • - Requestor (level 1)
    • - Requestor (level 2)
      • - Requestor (level 3)


  • Virtual Research Community
    • Astronomy & Astrophysics
    • Computational Chemistry
    • Earth Sciences
    • eHumanities
    • HealthGrid
    • Hydro-meteorology
    • WeNMR
    • WLCG
    • Other
  • Heavy User Community
    • High-Energy Physics
    • Life Sciences
  • Virtual Organization
    • Astronomy, Astrophysics and Astro-Particle Physics
      • lofar
    • Computational Chemistry
    • Computer Science and Mathematics
    • Earth Sciences
    • Fusion
      • fusion
    • High-Energy Physics
      • calice
      • cdf
      • hone
      • ilc
      • ildg
      • pheno
    • Infrastructure
    • Life Sciences
      • biomed
      • enmr.eu
      • lsgrid
      • vlemed
    • Other
      • desktopgrid.vo.edges-grid.eu
      • vo.complex-systems.eu
    • Multidisciplinary VOs
      • gridmosi.ici.ro
      • nordugrid.org
      • vo.iscpif.fr
      • voce
  • NGI or AERO
    • NDGF
    • NGI_IT
    • NGI_AEGIS
    • NGI_ARMGRID
    • NGI_BA
    • NGI_BG
    • NGI_BY
    • NGI_CH
    • NGI_CYGRID
    • NGI_CZ
    • NGI_DE
    • NGI_FRANCE
    • NGI_GE
    • NGI_GRNET
    • NGI_HR
    • NGI_HU
    • NGI_IBERGRID
    • NGI_IE
    • NGI_IL
    • NGI_MARGI
    • NGI_MD
    • NGI_ME
    • NGI_NL
    • NGI_PL
    • NGI_RO
    • NGI_RU
    • NGI_SI
    • NGI_SK
    • NGI_TR
    • Other
  • Project
    • DRIHMS
    • EGI-InSPIRE
      • UCST
      • EGI Training Working Group
    • ESFRI 28 projects
    • HealthGrid
    • Other
  • Open Grid Forum
  • Other


Non-Functional Tag

  • Feature
  • (Inter)Operability
  • Availability
  • Installability
  • Performance
  • Portability
  • Recoverability
  • Reliability
  • Safety
  • Scalability
  • Serviceability
  • Usability


Technology Tag

  • ARC
  • gLite
  • UNICORE
  • Globus


Custom Tag

Enter any Tag


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
  • Resolved = Implemented (validation must follow)
  • Rejected = EGI discussed then rejected the feature (because no related user requirement exists)
  • Validated = The feature has been validated (responsibilities have to be defined)


Status life cycle

RT status values.png

Priority definitions

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

Dashboards

Currently there are Pre-defined RT Dashboards for each of Requestors available on the RT system

All Dashboards

Candidate Virtual Research Communities (VRCs)

Dashboard Name Link Description
VRCs VRCs All VRCs requirements listing
VRC_WeNMR VRC_WeNMR VRC WeNMR requirements listing including: WeNMR (VRC) and enmr.eu (VO)
VRC_HealthGrid VRC_HealthGrid VRC HealthGrid requirements listing including: HealthGrid (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


Heavy User Communities (HUCs)

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


National Grid Infrastructures (NGIs)

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


Virtual Organizations (VOs)

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


Projects

Dashboard Name Link Description
Projects Projects Projects requirements listing


Operational Tools

Dashboard Name Link Description
Operational Tools Operational Tools Operational Tools requirements listing


Unified Middleware Distribution (UMD)

Dashboard Name Link Description
UMD UMD Unified Middleware Distribution (UMD) requirements listing


NA3

Dashboard Name Link Description
NA3 NA3 NA3 requirements listing


All

Dashboard Name Link Description
All All All requirements listing

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.

e-mail

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.

Subscriptions

Reports