- Created by Kathleen Baynes, last modified on Feb 05, 2014
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 15 Next »
Note: This document is still in work.
Overview
In addition to ensuring that the requirements of existing systems (GCMD, ECHO and EMS) are fulfilled, the Common Metadata Repository (CMR) will have to evolve its own requirements by collecting use cases and goals from users, customers and other stakeholders. These efforts will benefit from a common and consistent vocabulary, structure, and process for requirements gathering and tracking. This guide is intended to document these items.
While it's almost certain that these practices will evolve over time, the items covered here will help keep the CMR team focused on developing the system with minimum distraction from confusing terminology and inconsistent workflows.
Tools in Use
The CMR will utilize Jama to record, review, and approve system requirements and JIRA to record and track system issues. Both tools utilize URS (https://urs.eosdis.nasa.gov/) for authentication. To gain authorization for either the Jama or JIRA tool, please request CMR Jama Access via support@earthdata.nasa.gov
Resource
The Jama User Guide can be a valuable resource for people using the tool: https://rms.earthdata.nasa.gov/help/index.html
Assumptions
It is assumed that all requirements will be developed and maintained in the Jama tool. If requirements have previously been maintained in Word or Excel, these requirements shall be imported into Jama.
CMR Requirements Hierarchy At Glance
Requirement Level | Summary | Example |
---|---|---|
Theme | Cross-cutting aspects that may span several components, these are not recorded in Jama but may be part of JIRA tracking capabilities | Metrics; Monitoring; User Experience |
Component | CMR Sub-system | Search; Ingest Adaptors; Bulk Change Tool |
Epic | Large piece of functionality; a feature | Fast Keyword Searching; Controlled Vocabulary Adaptation |
User Story | Small, independent and testable piece of functionality that can be completed in 1-3 days |
|
Visual Hierarchy of CMR Components, Epics and User Stories
Vocabulary
Establishing a common vocabulary for requirements will help the team focused on the work at hand without creating confusion. Some of these terms can be become semantically confusing so it helps to document how they are defined within the context of CMR requirements. The following terms should be used as specified.
Resource
Note: Some of these definitions borrow heavily from Agile 101, available here: http://agile101.wordpress.com/2009/08/10/the-difference-between-agile-themes-epics-and-user-stories/
Themes
A Theme is a top-level objective that may span projects and products. Themes may be broken down into sub-themes, which are more likely to be product-specific.
For CMR requirements, themes can be tracked via tagging in JIRA. The exact mechanism for recording and tracking themes is still to be worked out.
Components
The CMR will consist of several sub-system components. Requirements in Jama will be developed for each of these sub-systems and will have a corresponding component within the tool. These components can be created as needed and have a set of Epics and a set of User Stories underneath a component for organizational purposes.
Component Ownership
Each component within the CMR will have an owner responsible for tracking epics and stories within that component and conducting reviews on that component as need. This owner should also be involved in prioritizing work, planning sprint activities, and maintaining the component's work backlog. Owners are ideally are not members of the development team but should be able to understand the wider impact of the component and work with stakeholders.
Katie's Note: We should assign and record these owners as soon as possible.
Epics
Epics represent a high level piece of functionality that rolls up one or more related user stories. Epics are frequently bigger than a single sprint's worth of effort. These are often also referred to as features of a system. Epics should be completed in one release. If an epic is too big to complete in one release, it should be decomposed into smaller epics. Epics should be traced back to one or more SOW Requirements. You would be unlikely to introduce an Epic into a sprint without first breaking it down into it’s component User Stories so to reduce uncertainty.
User Stories
User stories represent a specific piece of functionality that is to be developed for the system. Stories are written from the perspective of the actor (e.g. "As an authenticated user, I want to perform a spatial search with a 4 point Cartesian bounding box."). User stories are typically 1-3 days in implementation length. Exceptions can be made to 4 days, but in general stories longer than 3 days should be split into multiple stories. Stories are allocated to sprints (usually several stories are planned in a single sprint) and are generally the unit of discussion for sprint planning. User stories should be traced back to one or more Epics.
Agile projects are also assumed to need a JIRA connector that will allow User Stories from the Jama project to be synced to and from their corresponding JIRA project for development purposes.
Good User Stories
The acronym "INVEST" can remind you that good user stories are:
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Review and Approval Process
Frequency
When a Component and its initial descendant Epics and User Stories are gathered, a review of that component should be conducted using Jama's Review Center. Because reviews done using Jama can occur via the web, meetings are not required, allowing reviews to span several days among several reviewers.
It is expected that after initial component requirements are established, new requirements will continue to be introduced to the various sub-system components. These additional requirements will generally be reviewed by the CMR team on a bi-weekly or monthly basis.
If a large group of related requirements are added, the group may be subject to the same longer review process as the initial component requirements.
Participants
The CMR requirements review team should consist of at least one participant from ESDIS, ECHO, GCMD and EMS and will ideally include other stakeholders from DAACs or other interested Earthdata systems and projects (e.g. GIBS).
Process
As mentioned about component requirement reviews will occur within Jama and will span several days. The component owner will initiate this review and determine participants. Depending on the outcome of the web-based review, the component owner may choose to call a meeting (WebEx or in-person) to hash out details for particularly contentious stories.
Review Resources
For guidance on using the Review Center tool, please refer to the relevant section Jama User's Guide, found at the following link: https://rms.earthdata.nasa.gov/help/index.html?review_center.htm
The following video might also be of use
- No labels