Difference between revisions of "Requirements Tracking"
Line 29: | Line 29: | ||
= About this page = | = About this page = | ||
<span style="color:red">'''Page is | <span style="color:red">'''Page is only a draft.'''</span> | ||
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 intends to be a manual to those who wish to | 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 intends to be a manual to those who wish to |
Revision as of 13:05, 12 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
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 intends to be a manual to those who wish to
- Submit requirements and recommendations to EGI
- Browse requirements and monitor progress of resolving requirements
- Expand or comment on requirements
- Providing solution to requirements
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.
Browsing, monitoring requirements - Dashboards
Pre-defined ticket queries, "RT Dashboards" are available for the Requirements queue to provide a simple method for communities to browse and monitor progress with requirement tickets. Available Dashboards:
All Dashboards: The complete list of Requirement Dashboards in the RT system
Dashboards for Virtual Research Communities (VRCs)
These Dashboards filter tickets based on the submitter:
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_HealthGrid | VRC_HealthGrid | 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 |
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 |
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.
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.