u.s. ioos ® requirements marketplace? march 8, 2013 carl gouldman, debra hernandez 1
TRANSCRIPT
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
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
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