1. OAS Requirements Experience
Cecelia DeLuca/NESII, Ligia Bernardet/DTC-GMTB, Mark Iredell/EMC, Jim Doyle/NRL, Mariana Vertenstein/NCAR, Jim Kinter/COLA, Larry Marx/COLA, Fei Liu/NRL-SAIC, Gerhard Theurich/NRL-SAIC, Patrick Tripp/EMC, Vijay Tallapragada/EMC, plus many involved with coupled system development
NGGPS Annual Meeting
August 5-6, 2016 1

2. Purpose of this talk
Several groups have begun collecting requirements.
It may be useful to initiate some level of coordination.
This talk describes initial requirements collection activities from the OAS team (including GMTB and others) 2

3. Requirements Format
Initiated a standard requirements format (from the Code/Data/Doc management document) Id
Type
Item
Reason
Source
Status
SM1
Goal
Minimize the number of software repositories required. Best practices in software configuration management recommend using a shared common repository for development where feasible.  New development can be managed using branches (or forks or equivalent) with the understanding of a common authoritative source (master/trunk) and a procedure for integrating new development into the source repository.  This approach utilizes the strengths of configuration management tools, while minimizing the work and risk involved in maintaining duplicate repositories.
OP, avoid duplication.
GMTB
No policy in place. 3

4. Requirements Format
This standard requirements format could probably use improvement.
Id - Requirement short identifier and number, e.g. SM1 (Software Management 1)
Type - Current classifications include goal (general guidance or direction), expectation (exp; an assumption), requirement (req; a necessity), and recommendation (rec; a desire or suggestion).
Item - Description of the entry.
Reason - Rationale or motivation for the entry (OP = operating principle).
Source - Person or group that originated the entry.
Status - Implementation status or timeline associated with the entry. 4

5. Operating Principles
Initiated a set of operating principles that serve as the rationale for numerous requirements.
Serve the NOAA mission. Every decision should have the end goal of producing the best possible forecasts with the resources available.
Avoid duplication. Avoid duplication of code, files, documentation, repositories, products, and other technical artifacts. This leads to errors and confusion, and increases the maintenance burden.
Automate. Minimize manual processes to reduce errors and increase efficiency.
Formalize sharing. Where code, files, and other technical artifacts can be shared, create clear areas and protocols for doing so. This reduces errors and increases development efficiency.
Open for viewing. Promote public visibility of code, documentation, plans, and other technical artifacts. This minimizes delays and effort associated with gaining special access and encourages efficient, informed development.
Open for participation. Encourage open processes that enable multiple contributors. This brings more resources and expertise to bear on development and documentation.
Make accountable. Implementation and maintenance require clear task responsibilities and accountability.
Engage expertise through clarity. Make every effort to ensure that others can understand processes, design, implementation, and status of projects and products. 5

6. Collection Process
Initiated requirements collection in several areas, including code management and standards, land, and ensembles.
OAS Process:
Prioritize needs and identify a scope
Identify one or more coordinators
Identify a group – preferably EMC + research participants together, since that allows for discussion and mutual education
Set up calls and document inputs, make every effort to expose and vet draft requirements to as broad a group as possible
Use the requirements to develop strategy and design – the step after requirements is NOT building 6

7. Requirements Collected
Requirements were initiated by OAS in the areas of:
Land surface as it relates to system architecture
Ensembles as they relate to system architecture
Coding standards (from GMTB)
Source code
Documentation
Input data
Output data (from the research community)
Other teams:
The V&V team collected requirements from all NGGPS teams 7

8. Requirements Organization
Organized known requirements in a single place - the requirements we have are under "Requirements“ Documentation Category on the documentation inventory sheet.
This is important! NOAA sometimes seems to have the problem of people not knowing what planning documents exist or where planning documents are. 8