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.
CMR Requirements Hierarchy At Glance
Requirement Level | Summary | Example |
|---|---|---|
| Theme | Cross-cutting aspects that may span several components | Metrics; Monitoring |
Component | CMR Sub-system | Search and Discovery; Ingest Adaptors |
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 |
|
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
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.
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.
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. At its most granular form, a Theme may be an Epic.
Examples
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.
Examples
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.
Examples
- High performance spatial search
- Controlled Vocabulary Adaptation
- High performance faceted search with dynamic facets
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.
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/
Examples
Importing Existing Requirements
Review and Approval Process
Frequency
Requirements review will be done on an as-needed basis. Because reviews conducted via Jama do not require The CMR team will
Participants
Process
Requirement reviews will occur within Jama.
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
http://www.jamasoftware.com/how-to-review-center/
Overview
Content Tools