GCI Suggested Initial Scope
Purpose of this overview
Current requirements and other analysis documents are written to provide an understanding of an entire, big-picture,
ideal-conditions system component (e.g., Budget UTG's recommendations, which describe all aspects of the budget process in
full complexity). These do not necessarily lend themselves to viewing system development in a phased manner. This document
takes a high-level view of major areas of the system, with priorities and also suggestions for phasing in individual
requirements one piece at a time.
This document is not a technical evaluation. It expresses the idea of what users might consider to be the "core"
functionalities within each system component, which ones might be essential for user acceptance right away, vs. which ones
users might be willing to live without as components are improved with each new release. It will be necessary for GCI
developers to review and assess this scope from a technical and feasibility perspective; all items listed below are only
suggestions, negotiable depending on the needs of the project.
The columns (which have been changed from "release 1" and "release 2" to "soon", "later" and "much later" to differentiate
them from a real project plan) represent broad categories of timing suggested to be acceptable to users. Within each column,
the components listed could be divided even further (e.g., column 1, "soon", could represent functions which are phased in
during small releases 1, 2 and 3 before proceeding to column 2, "later", with release 4 or 5) depending on the development and
scheduling strategies used.
Suggestions by component
| 1st Release |
2nd Release |
Later |
BioSketch/CV
|
Maintain & link to downloadable BioSketch form template(s)
Users create own BioSketch documents using templates and attach on personnel user interface (UI)
Question: which file formats will we support, and how will we convert them for PDF printing?
|
Look into central storage for previously-used BioSketch documents, with separate system & UI to select &
re-use in other proposals
Questions: how long will we keep documents around, and how will we control access to them, if at all?
|
Question: will Commons XML/EDI require that we move BioSketch text into GCI system?
|
Other Support
|
Maintain & link to downloadable Other Support form template(s)
Users create own Other Support documents using templates and attach on personnel UI
Question: which file formats will we support, and how will we convert them for PDF printing?
|
Look into central storage for previously-used Other Support documents, with separate system & UI to select
& re-use in other proposals
Questions: how long will we keep documents around, and how will we control access to them, if at all?
|
Question: will Commons XML/EDI require that we move this
functionality into GCI system? |
Research plan ("science")
|
Maintain & link to downloadable continuation page form template(s)
Users create own research plan documents using templates and attach on a research page UI; users can specify
correct sequence for files, if attaching more than one
Question: which file formats will we support, and how will we convert them for PDF printing?
|
Consider support for additional file formats
|
Look into Table of Contents and page numbering
Question: will Commons XML/EDI require that we move this functionality into GCI system?
|
Abstract
|
Separate data fields for UW & sponsor abstract in GCI system
Users can copy text between fields
Question: how will we validate for NIH formatting compliance?
|
Look into policy change on UW/sponsor format differences
|
Look into specian character & format handling; we will need to follow Commons' lead
|
Access control
|
ASTRA; need to authenticate twice, once upon entry to GCI and once upon entry to Ariba
Suggest preparer/PI/reviewer access only for this release
Question: how do we ensure that users only need to enter authentication data once?
|
Look into expanding access to entire proposal by other users
Question: how will we specify who those other users are for each proposal?
|
Look into specifying visibility & editability differently for different users
Consider editability rules after submission
|
Accessibility
|
Design according to UW guidelines; don't implement any known non-accessible features
|
Test with assistive browsers
|
Look into adding additional features to facilitate use by asistive browsers
|
Output
|
Work with Commons on XML research; hold off on implementation
|
Print PDF documents, no Table of Contents or page numbering (can test without this, but must have for go-live
release)
Question: how will we convert attached files from native formats?
|
Consider Commons XML/EDI implementation
Look into Table of Contents and page numbering
|
Routing & approval
|
Use Ariba R&A capabilities:
- Display status in Ariba
- Reviewer email and preferences functions from Ariba
- No automatic escalation
- Push back to GCI system when R&A process is complete
Look into defining approval roles within GCI system and pushing to Ariba (or possibly combination of both); use
Ariba rules to set order of roles within approval graph
|
Look into displaying status in GCI system (outside of Ariba), adding automatic escalation functionality
Look into generating approval graph in GCI system & pushing into Ariba
|
Consider replacing remaining Ariba functionality in GCI system
Look into generating custom "pre-review" approval graph for partially-completed or separate sections of
proposal
|
Budget
|
Model line items as parent class with subclasses for personnel, nonpersonnel and subcontracts
Automatically copy new entries to all forward years (but not backward)
Pull salary/wage/benefit information from UW financial systems; determine "calculated base" salary/wage
according to B-UTG's rules. Allow user override of base salary to accommodate raises & manual inflation
settings
(but no automatic inflation)
Provide link to graduate student rates in helpfiles
Create & populate indirect cost rate lookup table; suggest set up single indirect cost rate per proposal in
this phase; find out whether initial release can work without ability to define custom rates
Integrate cost sharing with budget line items; collect source information for each item
Create & populate budget category map(s); write business logic to apply MTDC exclusions by category where
appropriate, including subcontract IDC
Calculate subtotals by category, total personnel, subcontracts direct/indirect, total direct, MTDC, total
indirect, total sharing, total costs, sharing % of total costs, for each year and all years
Maintain & link to downloadable continuation page form template(s) for justification
Users choose whether to enter justification text in form field or create own justification documents using
templates and attach on budget UI
Apply various inflation rates
Copy specific budget items from one year to another
|
Set up multiple indirect cost rates using location data (preponderance & ratio methods)
Create & populate graduate student compensation lookup table
Calculate cost sharing subtotals by source
Set target totals amount for individual year and/or all years; validate that totals add up; display
difference
|
Set up sub-budgets for APL, center grants, program projects, & subcontracts; if OMB compliance issues are
resolved, make sub-budgets available for multiple indirect cost rates also
Select & adjust budget line items to satisfy target total
|
Personnel
|
See personnel scope document
For PI "personal data," no boilerplate initally
|
|
Look into designing full personnel profile (for NSF) and include PI boilerplate data at this time also
|
Proposal details
|
Create & populate lookup table of sponsor information, sub-agencies & institutes
Collect preparer contact info
|
|
|
Performance sites & Resources
|
Create & populate lookup table of performance sites; allow new entries
Collect facilities & resources descriptions
Question: associate indirect cost reates with locationa?
|
|
|
Yes/no questions
|
Create & populate lookup table with question text (for maintainability & GCS compatibility), but identify
question-related rules and a way to keep rules separate from data structure
|
|
Implement additional (long) list of NSf questions (see EDI spec)
|
User help, human guidance, training
|
Single help link leading to a topic index
Support via email; contacts as defined by GC-PET
Bug reporting dB and web page for testers & users to enter
|
Context-sensitive help links on each page leading to topics relevant to that page
|
|
General proposal management (entire/all areas)
|
|
Copy entire proposal to new proposal
|
|
Protocols
|
Generate human subjects letter of intent via email; prompt for user OK before sending (at submission time)
|
|
|
|