1. U.S. IOOS ® Requirements Marketplace? March 8, 2013 Carl Gouldman, Debra Hernandez 1

2. 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?

3. 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

4. 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

5. Vision Smartphone with App for entering IOOS needs and receiving IOOS solutions Requirements In IOOS Solutions ID’d Solutions Realized

6. Platform to collect, analyze, and allocate requirements Submission of requirements Allocation of identified requirements for development PLATFORMREQUIREMENTSPERSONNEL/ANALYSIS Developing Concepts

7. 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

8. 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

9. What would this ‘Requirements Marketplace’ look like?

10. 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 Office  IOOS Association  Data collector  Data provider  …… Organization Type: (have user check all applicable categories. Examples below)  Program Office  IOOS Association  Data collector  Data provider  …… References (e.g. list the name of the planning document if the requirement comes from one) Submitter Organization Requirement Immediate Review Requested? (If yes, have user check justification. Examples below)  Current capability inadequate to support mission  … Immediate Review Requested? (If yes, have user check justification. Examples below)  Current capability inadequate to support mission  … 10

11. 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

12. 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

13. Backup Slides 13

14. Proposed Requirements Life Cycle Model Collection Analysis Allocation Focus here first Solicitation Collection Quality Control Classification Harvesting Elaboration Processing Allocation Disposition 14

15. 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

16. 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

17. 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