U.S. IOOS® Requirements Marketplace?

March 8, 2013

Carl Gouldman, Debra Hernandez

1

Problem?

We need to collect and manage IOOS enterprise-wide requirements across the regions, federal agencies and the IOOS program office?

Requirements = needs identified through user surveys, stakeholder assessments, interviews, etc.

IOOS Summit Recommendation for engagement, coordination, integration, telling the story, & fighting for $s

…and how do this without creating a tedious, cumbersome, churning, & cost-prohibitive process?

2

What?

Why?

How?

Questions of the Day

1. Regions exchange best practices & lessons learned from regions’ requirements processes?

2. Discussion: – Is this a mutual need we should pursue? – Do we want to work together to develop a

requirements marketplace?– Next Steps?

3

From U.S. IOOS Summit

“The job of the U.S. IOOS Program Office, the Regional Associations, and [the IOOS Association] is to focus on a viable process for collecting, prioritizing, and assessing progress against regional user requirements and integrate them with national and global requirements”

4

Create a “match.com” for IOOS Requirements…

= ID / Collect / Sort / Prioritize needs

= ID / Find / Connect … to Solutions to meet those needs

Vision

Smartphone with App for entering IOOS needs and receiving IOOS solutions

Requirements In

IOOS Solutions ID’d

Solutions Realized

Platform to collect, analyze, and

allocate requirements

Submission of requirements

Allocation of identified requirements for

development

PLATFORM REQUIREMENTS PERSONNEL/ANALYSIS

Developing Concepts

Proposal

In the short term, develop a mechanism for collecting requirements from any stakeholder

Note: Collecting requirements from stakeholders for the U.S. IOOS enterprise is a huge undertaking

– Variety and number of provider organizations

– Variety and number of users

– Dynamic nature of needs

– Differing priorities among users and provider organizations

– Expectation Management is a must!

7

Assumptions for a short-term solution to requirements collection

• Open forum for all stakeholders to submit requirements – Low bar for entry so submission process is not an obstacle to

participation

• Requirements are stored until needed for development or analytic efforts

• Design must accommodate collection of all information needed to process a requirement

• Design must accommodate the different types of requirements

• Design must allow data mining by both Regions and IOOS program office

8

What would this ‘Requirements Marketplace’ look like?

Notional Information Requested from Stakeholders during Collections Phase (not complete)

Description of Requirement

First Name

Last Name

E-mail Address

Phone Number

Organization Name

Organization Type: (have user check all applicable categories. Examples below)Program OfficeIOOS AssociationData collectorData provider……

References (e.g. list the name of the planning document if the requirement comes from one)

Subm

itter

Org

aniz

ation

Requirement

Immediate Review Requested? (If yes, have user check justification. Examples below)Current capability inadequate to support mission……

10

Requirements Marketplace

• Requirements stored in searchable database

• Web-based with easy interface– To help users input requirements, will provide

instructions, Frequently Asked Questions, POCs for questions

• Requirements collection database prototype– Develop with Google collaboration tools– Also establish procedures, roles, and responsibilities

11

Discussion Topics

• What methods do the Regions have for collecting/managing requirements?– Can the U.S. IOOS Program use any of those methods

at a national level?

• What role does the IOOS Association want in developing the requirements process?

• Way ahead for future development of a complete, formal requirements process? – Proceed now with user requirements marketplace

development?– Consider phased testing by theme or topic area?

12

Backup Slides

13

Proposed Requirements Life Cycle Model

Collection

Analysis

Allocation

Focus here first

Solicitation

Collection

Quality Control

Classification

Harvesting

Elaboration

Processing

Allocation

Disposition

14

Proposed Requirements Life Cycle Model

Analyze costs, benefits, feasibility and efficacy; then requirement approved/disapproved

Solicitation

Collection

Quality Control

Classification

Harvesting

Elaboration

Processing

Allocation

Disposition

Encourage stakeholders to use the collection system through communications and public relations

Stakeholders input requirements into web-based requirements marketplace

Automated review of input, rejecting incomplete requirement records

Classify requirements by category—manual process conducted by IOOS Program Office

Pull prioritized sub-set of requirements for further processing

Interpret, clarify, and rewrite stakeholder inputs into complete requirements

Allocate validated requirements to a development effort

Determine fate of requirement: e.g., close, rewrite, reallocate

15

Benefits of this Lifecycle Model

• Allows for immediate collection of requirements

• Allows requirements to be collected from any stakeholder

• Collected requirements can be reviewed and harvested as needed

16

Understanding IOOS Requirements• Requirements are what a program is meant to do—

understanding the problem so you can provide a solution for it

• Within U.S. IOOS, there are two major types of requirements:– System (Program needs)

• Data structure• DMAC infrastructure• R&D• Communications• Policy & Procedures• Training & Education

– Capabilities (User needs)• Observation• Modeling & Analysis

17