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 | Example |
|---|---|
| Theme | Metrics |
Component | Search and Discovery |
Epic | Keyword Searching |
User Story | As a CMR user I want to be able to query datasets using keyword parameters so that I can find the data I want. |
Tools in Use
The CMR will utilize Jama to record, review, and approve system requirements and JIRA to record and track system issues. To gain access to 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.
Themes
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
Examples
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
Participants
Process
Requirement reviews will occur within Jama
Overview
Content Tools