Date: Thu, 28 Mar 2024 21:52:13 -0400 (EDT) Message-ID: <1739828413.1890.1711677133294@gs-ed-prod-wiki1.earthdata.nasa.gov> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1889_367467489.1711677133293" ------=_Part_1889_367467489.1711677133293 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Common Metadata Repository (CMR) must ensure that the needs of = existing systems (GCMD, ECHO and EMS) are met. In order to achieve this goa= l, the system will have to evolve its own requirements by collecting use ca= ses and goals from users, customers and other stakeholders. These efforts w= ill benefit from a common and consistent vocabulary, structure, and process= for requirements gathering and tracking. This guide is intended to documen= t these items. This guide is intended for use by the entire integrated CMR = development team.
While it's almost certain that these practices will evolve over time, the i=
tems covered here will help keep the CMR team focused on developing the sys=
tem with minimum distraction from confusing terminology and inconsistent wo=
rkflows.
The CMR will utilize Jama to record, review, app= rove, and manage system requirements and JIRA to r= ecord and track system issues and manage development tasks. 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= a>
It is assumed that all requirements will be developed and maintained in =
the Jama tool. If requirements have previously been maintained in Word or E=
xcel, these requirements shall be imported into Jama.
CMR Systems Requirements will be an evolution of existing ECHO and GCMD Re=
quirements. As different system components are developed and implemented, t=
hose requirements should be reconciled with existing system requirements to=
eliminate duplication and obsolete functionality.
Requirement Level |
Tracking Location |
Summary |
Example |
---|---|---|---|
Theme |
Jama via tags |
Cross-cutting aspects that may span several c= omponents, these should be associated with Epics in Jama using tags on Epic= s or user stories. |
Metrics; Monitoring; User Experience |
Component |
Jama |
CMR Sub-system |
Search; Ingest Adaptors; Bulk Change Tool |
Epic |
Jama |
Large piece of functionality; a feature = td> | Fast Keyword Searching; Controlled Vocabulary= Adaptation |
User Story |
Jama/JIRA |
Small, independent and testable piece of functionality that can be com= pleted in 1-3 days. These are the lowest level of requirements tracking wit= hin Jama. |
|
Bootstrap Story |
JIRA |
Internal development activity, not necessaril= y demonstrable to end users, should be associated with one or more user sto= ries, may be longer in duration than a user story |
|
Task |
JIRA |
In JIRA, user stories may be even further broken down into tasks. This= is not required and is not tracked within Jama. |
|
Establishing a common vocabulary for requirements will help the team foc= used on the work at hand without creating confusion. Some of these terms ca= n be become semantically confusing so it helps to document how they are def= ined within the context of CMR requirements. The following terms should be = used as specified.
Note: Some of these definitions borrow heavily from Agile 101, available= here: http://agile101.wordpress.com/2009/08/10/the-difference-bet= ween-agile-themes-epics-and-user-stories/
A Theme is a top-level=
objective that may span projects and products but is does not assign funct=
ionality to a sub-component. Themes will describe how the CMR as a system w=
ill interact with external interfaces and systems, as well as exhibit the b=
ehaviors that span projects and products. Themes may be broken down into sub-themes, which are more likely to be=
product-specific.
F=
or CMR requirements, themes can be tracked via tagging in JIRA. The =
exact mechanism for recording and tracking themes is still to be worked out=
.
The CMR will consist of several sub-system components that are descended= from the system level requirements for the CMR, and are the result of assi= gning the CMR level functionality to specific implementation-level componen= ts. Requirements in Jama will be developed for each of these sub-systems an= d 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 und= erneath a component for organizational purposes.
Each component within the CMR will have an owner responsible for trackin= g epics and stories within that component and conducting reviews on that co= mponent as need. This owner should also be involved in prioritizing work, p= lanning sprint activities, and maintaining the component's work backlo= g. 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 stakeho= lders.
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 traced back to on= e 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 Stor= ies so to reduce uncertainty. A component's owner will ensure that eac= h Epic is integrated and properly regression tested.
User stories represent a specific piece of functionality that is to be d=
eveloped for the system. Stories are written from the perspective of the ac=
tor (e.g. "As an authenticated user, I want to perform a spatial search wit=
h 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 a=
re allocated to sprints (usually several stories are planned in a single sp=
rint) and are generally the unit of discussion for sprint planning. User st=
ories should be traced back to one or more Epics.
Agile projects are also assumed to need a JIRA connector that will allow U=
ser Stories from the Jama project to be synced to and from their correspond=
ing JIRA project for development purposes.
The acronym "INVEST" can remind you that good user stor= ies are:
http://xp123.com/articles/in= vest-in-good-stories-and-smart-tasks/
In addition to the more traditional user stories, the CMR development ef= fort will introduce the concept of Bootstrap Stories. These stories are lon= ger in duration than User Stories (maybe as long as several weeks) and migh= t not result in end-user demonstrable functionality. It is expected that in= itially there will be much "behind the scenes" work to set up databases and= environments for development and deployment. Laying the groundwork for fut= ure development efforts may result in several weeks delay before the first = user stories are ready. The Bootstrap Story is intended to track these acti= vities and will be maintained in JIRA, but is not directly applicable to sy= stem requirements and therefore will not be in Jama.
Tasks are subcomponents of User Stories and Bootstrap stories that are n= ot tracked in Jama and are intended to aid the development team during spri= nts. Tasks should be short in duration and very specific in scope and shoul= d be directly related to a parent story.
When a Component and its initial descendant Epics and User Stories are g=
athered, a review of that component should be conducted using Jama's Review=
Center. Because reviews done using Jama can occur via the web, meetings ar=
e not required, allowing reviews to span several days among several reviewe=
rs.
It is expected that after initial component requirements are established, =
new requirements will continue to be introduced to the various sub-system c=
omponents. 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 subje=
ct to the same longer review process as the initial component requirements.=
The CMR requirements review team should consist of at least one particip= ant from ESDIS, ECHO, GCMD and EMS and will ideally include other stakehold= ers from DAACs or other interested Earthdata systems and projects (e.g. GIB= S).
As mentioned above component requirement reviews will occur within Jama =
and will span several days. The component owner will initiate this review a=
nd 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.
Once the review is complete and outstanding issues have been addressed, th=
e requirements/stories are approved and work may be prioritized in upcoming=
sprints.
For guidance on using the Review Center tool, please refer to the releva=
nt section Jama User's Guide, found at the following link: https://rms.earthdata.nasa.gov/help/index.h=
tml?review_center.htm
The following video might also be of use htt=
p://www.jamasoftware.com/how-to-review-center/