1
Kuali Coeus
System Requirements Specification
KC_AWD-Create an Award Hierarchy
Module - Awards
Abstract:
Functionality that supports the division of an Award into Units of Organization
(such as budget periods or departmental allocations) defined by an institution.
Author(s):
Neil Maxwell
Contributor(s):
Kenton Hensley, Susan Mundt, Rosemary Hanlon, Marcus Fricke, Renee Dolan
Current Owner:
Neil Maxwell
Revision:
Version 1.0
Create Date:
5/6/2008 3:42:00 PM
Last Save Date:
07/09/2009 6:02 PM by Susan Mundt
© Kuali Foundation 2008
Contents
CONTENTS .........................................................................................................................................................2
TABLES ...............................................................................................................................................................4
FIGURES ............................................................................................................................................................4
1. INTRODUCTION ...........................................................................................................................................6
1.1.
Purpose ................................................................................................................................................... 6
1.2.
Review ..................................................................................................................................................... 6
1.3.
Document Revision History ......................................................................................................... 6
1.4.
References ............................................................................................................................................ 6
1.5.
Terms and Definitions .................................................................................................................... 6
2. BUSINESS REQUIREMENTS AND OBJECTIVES.....................................................................................7
3. BUSINESS RULES ........................................................................................................................................7
4. USER REQUIREMENTS ...............................................................................................................................7
4.1.
Narrative – User Story ................................................................................................................... 7
4.1.1. Introduction .................................................................................................................................... 7
4.2.
Important Concepts and Background ................................................................................... 9
4.2.1. Examples of How the Hierarchy is Used in Coeus ............................................................ 9
4.2.1.1.Berkeley Method .....................................................................................................9
4.2.1.2.MIT Method .............................................................................................................11
4.2.1.3.Rutgers Method .....................................................................................................11
4.3. User Classes and Roles ..................................................................................................................... 13
4.4. User Requirements .............................................................................................................................. 13
4.5.
Index to Use Cases ........................................................................................................................ 14
4.6.
Use Cases............................................................................................................................................. 15
4.6.1. UC1 – Maintain an Award Hierarchy.................................................................................... 15
4.6.2.UC2 – Copy an Award ................................................................................................................. 17
5. FUNCTIONAL REQUIREMENTS ...............................................................................................................19
6. DATA DICTIONARY ..................................................................................................................................21
6.1.
Data Dictionary Items .................................................................................................................. 21
6.2.
Grouping and Sort Order ............................................................................................................ 21
7. USER INTERFACE DESIGN ......................................................................................................................21
7.1.
User Interface Workflow ............................................................................................................ 21
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 2 of 37
7.1.1. Tab Order of Fields ..................................................................................................................... 21
7.1.2.Hierarchy Icons ............................................................................................................................. 21
7.2. Design Requirements ......................................................................................................................... 21
7.3. User Interface Mock-up .................................................................................................................... 22
8. USER DOCUMENTATION NOTES ............................................................................................................26
9. DIFFERENCES FROM COEUS...................................................................................................................26
10. DESIGN AND IMPLEMENTATION NOTES ........................................................................................27
10.1. Constraints and Issues ................................................................................................................ 27
10.2. Other Technical ................................................................................................................................ 27
10.2.1. UCSD Modified Hierarchy Screen ........................................................................................ 27
10.2.2.Technical Implementation of UC Berkeley Hierarchy ................................................... 28
10.2.3.Icon Decorators .......................................................................................................................... 29
11.APPENDIX ................................................................................................................................................30
11.1. Document Change Log ................................................................................................................. 30
11.1.1. [2/16/09, Susan Mundt input from UofA] ....................................................................... 30
11.1.2.[2/19/09, Marcus Fricke input from ISU] ......................................................................... 30
11.1.3.[2/20/09, Rosemary Hanlon input from MIT] ................................................................. 30
11.1.4.[2/27/09, Neil Maxwell]........................................................................................................... 30
11.1.5.[3/4/09, Neil Maxwell] ............................................................................................................. 30
11.1.6.[3/20/09, Renee Dolan input from MSU] ......................................................................... 30
11.1.7.[3/20/09, Neil Maxwell]........................................................................................................... 30
11.1.8.[3/24/09, Neil Maxwell ............................................................................................................ 30
11.1.9.[3/31/09, Susan Mundt] ......................................................................................................... 30
11.1.10.[4/8/09, Neil Maxwell]........................................................................................................... 30
11.1.11.[5/19/09, Neil Maxwell] ........................................................................................................ 31
11.1.12.[6/9/09, Neil Maxwell]........................................................................................................... 31
11.1.13.[6/12/09, Neil Maxwell] ........................................................................................................ 31
11.1.14.[6/12/09-06/14/09, Susan Mundt] .................................................................................. 31
11.1.15.[7/9/09, Susan Mundt] ......................................................................................................... 31
11.2.Issues List .............................................................................................................................................. 31
11.2.1.Open/In Progress ....................................................................................................................... 31
11.2.1.Resolved ........................................................................................................................................ 34
12.APPENDIX 2: POTENTIAL FUTURE ENHANCEMENTS ....................................................................36
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 3 of 37
Tables
Table 1 Document Reviewers .........................................................................................................6
Table 2 Document Revision History .............................................................................................6
Table 3 Relevant Documents ..........................................................................................................6
Table 4 Terms and Definitions .......................................................................................................6
Table 5 User Roles and Classes ...................................................................................................13
Table 8 Functional Requirements................................................................................................19
Table 9: UC? Filtered Search for a Hierarchy .........................................................................36
Table 10: UC? Navigate to an Award ........................................................................................37
Figures
Figure 1: UC Berkeley Model, Project, History, Project Period and Budget Period
Levels ................................................................................................................................................9
Figure 2: UC Berkeley Customized Coeus Interface showing Hierarchy Tier selection
on search screen .........................................................................................................................10
Figure 3: UC Berkeley QuickSearch interface showing “Narrow by Tier” feature ....10
Figure 4: UC Berkeley Hierarchy Model Classes ...................................................................11
Figure 5: KC mock, Hierarchy Actions panel, showing details7/9/09 ..........................22
Figure 6: KC mock, Hierarchy Actions panel, Copy as new action, 7/9/09................23
Figure 7: Coeus 4.3.2 Award Hierarchy window with Details selected ........................23
Figure 8: KC mock, Hierarchy Actions panel, Copy as child action, 7/9/09 ..............24
Figure 9: Coeus 4.3.2 Award Copy window ............................................................................24
Figure 10: KC mock, Hierarchy Actions panel, New child based on new action, 7/9/09
...........................................................................................................................................................24
Figure 11: KC mock, Hierarchy Actions panel, New child based on copy from parent
action, 7/9/09 ..............................................................................................................................25
Figure 12: Coeus 4.3.2 Create Child Award window ...........................................................25
Figure 13: KC mock, Hierarchy Actions panel, New child based on selected award
action, 7/9/09 ..............................................................................................................................25
Figure 14: Coeus 4.3.2 Create Child Award window based on Select Award (w/in
current hierarchy) ......................................................................................................................26
Figure 15: UCSD Modified Hierarchy screen...........................................................................27
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 4 of 37
Figure 16: Examples of Eclipse Icon Decorators ..................................................................29
Figure 17...............................................................................................................................................29
Figure 18...............................................................................................................................................29
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 5 of 37
1.
Introduction
1.1.
Purpose
Educational institutions receive sponsored research funding (Awards) through a wide variety of instruments with
widely varying terms and degrees of complexity. Funding arrangements may span decades, and changes may
occur frequently over time. Institutions need efficient and effective systems to manage these arrangements.
1.2.
Review
The following people have read and agreed to the contents of this document:
Table 1 Document Reviewers
Name, Title (or Role)
Organization
Signoff, Date
Susan Mundt/Renee Dolan, Lead SME, on behalf of SME
UofA/MSU
7/9/09
Kenton Hensley, Lead Business Analyst
Cornell University
Terry Durkin, Development Manager
Indiana University
Scott Heise, QA Manager
Indiana University
1.3.
Document Revision History
The following table lists major revisions of this document following table. Please see the Document Change Log
on page 30 for a detailed list of changes.
Table 2 Document Revision History
1.4.
Document
Version
Revision Name - Description
Revision Date
Author(s)
1.0
First Draft - LBA Review
Postponed
Neil Maxwell
1.0
Second Draft – SME Review
3/11/09
Neil Maxwell
1.0
SME-Final
References
Documents that have information relating to the information discussed in this document.
Table 3 Relevant Documents
Document Title
Description
Location
Structuring Awards
MIT Wiki document describing Berkeley,
Dartmouth, & MIT Hierarchy models
Document describing Rutgers’ Hierarchy model
http://www.coeus.org/coeuscons/document/secure/outline/docs/8.10.html
http://orsp.rutgers.edu/coeus/Rutgers_COEUS_Awards.pdf
Rutgers Coeus Awards
1.5.
Terms and Definitions
The following table lists the terms used in this document. The KRA Glossary on the Confluence Wiki is used to
centrally maintain the definitions of these words. It is strongly recommended that you review the definitions
before continuing. Please see: https://test.kuali.org/confluence/display/KRACOEUS/KRA+Glossary.
Table 4 Terms and Definitions
Term
Term
Account
Obligation Start Date*
Administrator
Obligated Total (or Amount)*
Anticipated Total (or Amount)
Parent
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 6 of 37
2.
Term
Term
Award
Project End Date*
Award Hierarchy
Project Start Date*
Award ID
Award
Child
Root Award
Obligation End Date*
Unit of Organization
Business Requirements and Objectives
A. Ensure Best Practice Management of Sponsored Funds: The proposed system must support the institution’s
ability to track and monitor money transactions in accordance with regulatory requirements, industry best
practices, the terms and conditions of sponsored agreements, and the general requirements of sponsors.
B. Reduce Contract and Grant Management Overhead: The proposed improvements to the system must reduce
the effort and cost required to manage complex funding arrangements over time.
C. Reduce Risk: The proposed system must ensure that the business risk due to incorrect, inconsistent, unstructured,
or incomplete records is minimized.
D. Improve Integration Capabilities: The proposed system must enhance the institution’s ability to integrate
enterprise contract and grant data with financial and compliance systems.
E. Improve Business Intelligence Capabilities: The proposed system must enhance the institution’s ability to
conduct robust operational and decision support reporting capabilities.
3.
Business Rules
Hierarchy implementation will be driven locally by combinations of customer (PI/department) needs and
reporting, financial system, compliance, or other business rules. Institutions may choose not to use the hierarchy
at all.
4.
User Requirements
4.1.
Narrative – User Story
4.1.1.
Introduction
Educational institutions receive sponsored research funding (Awards) through a wide variety of instruments with
widely varying terms and degrees of complexity. Funding arrangements may span decades, and changes may
occur frequently over time. Institutions need efficient and effective systems to manage these arrangements.
When thinking about how to organize and manage funds received from a sponsor, there are several key questions
that must be taken into consideration:





What mechanism is used to award and reimburse the funding? How will the authority to spend money be
communicated and recorded?
Is future funding anticipated? How is it described in the instrument?
Is future funding contingent on anything, such as reporting satisfactory progress or spending rate?
How many separate financial accounts are needed? Who needs to manage the funds? Are separate accounts
needed to manage their funds?
What are the business intelligence needs of the institution? Does the money management structure support
reporting?
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 7 of 37

How does the institution need to budget its money?
It is natural after some analysis to see these categories as falling into a Hierarchy of Awards, with money flowing
from the highest level Award into Units of Organization defined by the institution. Some examples of Units of
Organization are:






Time periods
Tasks or projects
Departments
PIs
Functions (fabrication, administration, etc.)
Accounts/funds recognized by a financial system
In addition to the ability to divide an Award into Units of Organization or Child Awards based on widely varying
institutional business rules, institutions need




The ability to move money from one Unit of Organization to another
The ability to navigate to a specific Unit of Organization within any Award Hierarchy
The ability to extract structured information on funding for operational needs, decision support, system
interfaces
The option not to use these features
The specific data elements supporting this functionality are:
Field
Description
Anticipated Amount
The total commitment of funds from the sponsor for
performance of the full scope of work
Obligated Amount
The amount authorized by the sponsor for spending
Anticipated Change
A change to the sponsor’s total commitment
Obligated Change
A change to the amount authorized by the sponsor for
spending
Effective Date
The begin date for spending authority
Obligation Expiration Date
The end date for spending authority
Final Expiration Date
The end of the Project Period
Title
The title or name of the project or Unit of Organization
Status
The status of the node (active, pending, expired, etc.)
Purpose*
The purpose of the Award (see 7.2 item 6) from the
account_type table
*See Issues List. Not current Coeus functionality
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 8 of 37
4.2.
Important Concepts and Background
4.2.1.
Examples of How the Hierarchy is Used in Coeus
The Hierarchy environment is a structured, graphical representation of a sponsored project in a tree-view format,
and allows for navigation to detailed Award data for both entry and viewing purposes. This document describes
several approaches to using the Award Hierarchy.
There are many different ways to implement the Award Hierarchy, including not implementing a Hierarchy at all.
UC Berkeley has developed business rules, described below, that define Templates for constructing a Hierarchy.
MIT, Rutgers, and Berkeley approaches to structuring Award hierarchies will be presented here.
4.2.1.1.
Berkeley Method
(Note: variants of this are in use at UC Irvine, UC Merced, UC San Diego, Dartmouth, UMCP)
Once a Root Award is created, all data entry for awards is initiated from the Hierarchy.
Under UC Berkeley rules, the Units of Organization are defined as periods of time associated with the authority to
spend funds. Each Hierarchy has three levels, and each level within a Hierarchy has a specific meaning relative to
time and money. All Awards are entered in the three-tiered hierarchical format shown below, regardless of the
length of the project and budget periods; a one year Award will also have three levels (project history, project
period, and budget period, with dates and dollars the same at each level).The levels are defined as
Level
Position
Name
Level 1
Root Award (ID ending in ‘-001’)
Project History
Parent of entire Hierarchy
Level 2
Child of Root Award
Project Period
Level 3
Child of Project Period
Budget Period
Figure 1: UC Berkeley Model, Project, History, Project Period and Budget Period Levels
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 9 of 37
The Project History level, shown in Figure 1 above by Award No. 021941-001, will represent all periods and
funding for an Award regardless of competing and/or noncompeting periods and/or funding increments within it.
This is a placeholder for the project and budget period records and is not used in any reporting or system feeds.
The End-Of-Month (EOM) Process, when used, summarizes all transactions at the Root Award level and stores
the results in a database table for reporting or system interface needs. The EOM process is not in use at UC
Berkeley. NOTE: some implementations of the Hierarchy generally follow this model but record Project Period
data at the Root Award level and Budget Period data at the second level. That usage would not allow for multiple
competing segments to be recorded in the same Hierarchy.
The Project Period level, shown in Figure 1 as Award No. 021941-002, represents the full period of performance
and total funding anticipated to complete the scope of work for the project as proposed by the institution. As
such, it represents the Sponsor’s overall commitment to support the project, and may include funding for which
there is no current authority to spend. Critical project-related data (such as subcontracts and cost sharing) are
entered at this level. Current & Pending Support reports for investigators as well as Project Period funding
summary reports are taken from this level. Project Period records feed directly to the financial system to open an
Account (“Fund” at Berkeley) and set the period of performance and Anticipated Total funding for the project.
The Budget Period level, shown in Figure 1 as Award Nos. 021941-003 through -005, represents current and
future authority to spend. All current and anticipated future funding years or option periods (if explicitly stated by
the sponsor in the Award instrument) are entered on initial receipt of the Award. Records at this level with status
Active represent current authority to spend and are fed to the financial system as such; future budget periods are
entered with status Pending (no obligated amount is entered until the funding is received and the record’s status is
changed to Active).
This allows for level-specific searches.
Figure 2: UC Berkeley Customized Coeus Interface showing Hierarchy Tier selection on search screen
Figure 3: UC Berkeley QuickSearch interface showing “Narrow by Tier” feature
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 10 of 37
UC Berkeley uses two classes of Hierarchy model, Grant Model and Contract Model, to serve as the structure
for capturing Award information. Each class is subdivided into two subclasses, Basic and
Continuing/Incremental.
Figure 4: UC Berkeley Hierarchy Model Classes
Model
Used for
Basic Contract/Grant
Contract/Grant Awards where the full period and full authority to spend are Awarded
at one time (i.e. no anticipated future funding, either by budget period or increment).
Initial data entered will be the same at all three levels.
Continuing Grant
Grant Awards where authority to spend is based on periods of time within an overall
Project Period, and where Awarding of subsequent authority to spend is based on
satisfactory progress of the project. These Awards generally have future periods and
funding explicitly stated in the instrument.
Incremental Contract
Contract Awards where funding is Awarded incrementally and the future increments
are not explicitly stated in the instrument
In general, Assistance Awards (grants) Grants are entered using one of the two Grant Models and Contracts are
entered using one of the two Contract Models, although the instrument’s behavior (rather than its label) is the
determining factor in making the choice.
4.2.1.2.
MIT Method
MIT enters all applicable Award information at the Root Award level. Business rules for the Time and Money
fields allow for usage of Anticipated Amount to record the sponsor’s total commitment, while Obligated Amount
records authority to spend. Child Records may be created to separate obligations into
 Competing segments
 Accounts to be used for specific purposes (equipment fabrication, administration, etc.)
 Allocating funds to different departments involved in the project
 Tasks
Most Award data is fed to a financial system. Some awards (i.e. Coeus Consortium Membership agreements) are
not part of financial feeds. Hierarchies may be unlimited in depth and there is no specific meaning ascribed to a
Hierarchy level.
1. Obligation Effective Date: The effective date of the current funding period should be entered. The date must
be equal to or later than the Award “Effective Date”. If the Award does not include a discrete effective date for
the current funding period, the Award “Effective Date” should be entered.
2. Obligation Expiration Date: End date of the current funding period. The date must be equal to or earlier than
the “Final Expiration Date”. If the Award is incrementally funded, but no obligation expiration date is included in
the Award, an estimated expiration date should be input in COEUS based on the proposed budget.
3. Final Expiration Date: Enter the projected end of the period of performance-- expiration of currently funded
period plus anticipated but currently unfunded periods, including possible option years. (Expiration date of
current competing segment.)
4. Amount Obligated to Date: Sponsor funding provided to date under the Award should be entered. The amount
must be equal to or less than the “Anticipated Total Award Amount”.
4.2.1.3.
Rutgers Method
(Source: http://orsp.rutgers.edu/coeus/Rutgers_COEUS_Awards.pdf)
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 11 of 37
Award Structure
There are two types of Awards in Coeus – Parent Awards and Child Awards. The Parent Award is linked to the
Main SPAN Account No. and may or may not be associated with a Child Award. However, every Child Award
must be associated with one Parent Award. Any Award that needs to be associated with multiple account
numbers will require the set up of Child Award(s). A separate Child Award will be created for each sub account
needed.
Each Award has a 6-digit Award number and a 3-digit extension (format: xxxxxx-xxx) as well as an associated
sequence number. This Award number is different from the SPAN account number(s) and sponsor Award number
that are associated with an Award. If an Award is broken up into several accounts (parent/children), the 6-digit
Award number remains the same, and the 3-digit extension acts as a counter for the Child Awards.
Parent Award Only (Award with Main Account Only)
For example, a grant of $50,000 for astronomy research is received. The Award number assigned by Coeus is
007473-001 sequence: 1.
Awards with Incremental Funding
The above model works well with an Award where there is no continuation of funding. However, for
incrementally funded or supplemental Awards sequence numbers must be used.
An Award sequence number marks time or is used to keep track of specific Awards changes. Totals from previous
sequences roll over to the next sequence. Below is a simple example of a non-competing continuation to be
distributed over two years in $50,000 chunks for a total of $100,000. The first Award is sequence 1. When the
continuation funding is received sequence 2 is created. Sequence 1 is no longer accessible, except for historical
tracking (found under the |Money and End Dates| tab).
Parent / Child Awards (Award with Sub Account(s))
In those cases where portions of an Award need to be distributed a “parent” Award with one or more children
needs to be created. As an example, a program project grant would involve the set up of a simple Award
Hierarchy. The Hierarchy might include the “parent” Award and two “children” – one for the Astronomy
department and another for the Physics department. First the parent Award is created. Then the first child account
for the Astronomy department is created and funds distributed from the parent Award. As funds are distributed
from the parent Award to the child, the distributable amount of the parent Award is reduced.
Lastly, the Physics department child Award is created. All three of these Awards will have the same 6-digit
number, but the 3-digit extension will be incremented as each child is added. Note that the distributed amount
plus the distributable amount for parent (extension 001) should always equal the amount of the Award.
Complex Awards
Below is an example of a more complex incrementally-funded Award. The Award is structured using parent/child
relationships as well as sequence numbers. This example involves 3 child Awards descended from the parent
Award and incrementally funded for Year 2. As in the simple fully-funded Hierarchy model, first the parent
Award is created, and then the children.
When the second year funding is added, the 6-digit Award numbers and 3-digit extensions will remain the same,
but the sequence numbers will increment for both the main Award and the children when the incremental monies
are received. Additionally, in this example there will be “anticipated” amounts that will be reached once the
Award is fully funded.
If this model were extended to a third year, and an additional $50,000 were added to the Award for the
participation of the Engineering department in the third year of the project, the sequence numbers for the parent
Award and previous children would increment, but the new Engineering Department child would start with
sequence 1, since this would be the first sequence for this child component.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 12 of 37
Task Orders
Task orders can be handled similarly to program project grants utilizing the parent/child relationships maintained
by Coeus. For example, a sponsor funds two tasks to be funded incrementally. Initially a parent Award will be
created with two dependent children with the current funds for the two tasks.
In the next funding installment the sponsor fully funds the second task, but doesn’t fund the first task for whatever
reason (perhaps a milestone has not been met). The parent Award and task 2 sequence numbers increment, but not
task 1. Note that even though the sequence number for Task 1 hasn’t incremented, it is still associated with
Sequence 2 of the parent Award.
4.3.
User Classes and Roles
The following table lists the groups of people that are expected interact with the system. Each user class role are
considered when documenting the procedures that users will follow when interacting with the system. In the use
cases, these are called “Actors.” The latest complete copy of this table is kept on the Kulai Coeus Wiki at:
http://test.kuali.org/
This version was last updated from the central version on: <date>
Table 5 User Roles and Classes
User Class
Role
Description: the group and how they are expected to use the system.
OSP Admin
Maintainer
OSP Admin is responsible for high level maintenance of Hierarchy
Templates and Awards. The user should have access to view all data.
User must be able to change data based on sponsor Award modifications
and internally approved change requests
Unit/Dept Admin
Viewer
Unit/Dept Admin should have access to view the Award Hierarchy only;
changes should be requested through the appropriate mechanism and
routed to the OSP Admin and/or sponsor as appropriate
PI/Co-PI/Key Personnel
Viewer
PI/Co-PI/Key Personnel should have access to view the Award Hierarchy
only; changes should be requested through the appropriate mechanism and
routed to the OSP Admin and/or sponsor as appropriate
4.4.
#
User Requirements
New
funct?
ID(s)
User Requirement
1
1) Search for a Hierarchy Award: The user shall be able to search for an Award in a
Hierarchy.
2
2) Navigate to a Hierarchy Award: The user shall be able to use the Award Hierarchy
to navigate to a specific Award within a Hierarchy.
3
3) View Key Award Details: The user shall be able to view key details about the
Award, and to access more detailed information if needed.
4
4) Create and Maintain an Award Hierarchy: The user shall be able to create a
hierarchical Parent Award/Child Award structure for an Award.
5
5) Copy a Hierarchy Award: the user shall be able to copy an Award in a Hierarchy.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 13 of 37
4.5.
Index to Use Cases
The following table lists the use cases
Use
Case ID
UC1
New
?
Use Case Name
Use Case Description
1)
Maintain an Award Hierarchy
User selects an Award and creates, modifies, or copies Awards in the
Hierarchy.
a)
Create a New Child Award
User selects an Award and Creates a New Child in the selected Hierarchy
for that Award
i)
As New
User chooses NOT to copy data from another Award in the Current
Hierarchy
(1) Blank
User chooses to enter all data manually (see KC_AWD-Create an Award)
(2) Data from Inst Prop
User selects an Institutional Proposal to populate the new Award (see
KC_AWD-Create an Award).
Copy from Parent Award
User chooses to copy data for the new Award from the selected parent
Award in the current Hierarchy.
UC1
UC1 N
UC1 A1
ii)
UC1 A2
iii) Copied from another Award in
current Hierarchy
User chooses to copy data for the new Award from another Award in the
current Hierarchy.
Copy an Award Hierarchy
User copies an Award Hierarchy
i)
Copy an Award to create a new
Award Hierarchy
User navigates to the Hierarchy Panel and chooses to copy the Award as a
new Award Parent/Root.
(1) Copy Descendant Awards
User chooses whether to include all Child Awards of the copied Award in
the copy action.
Copy an Award to create Child
Award in current Hierarchy
User navigates to the Hierarchy Panel and chooses an Award to copy as a
new Child Award within the current Hierarchy.
UC2 A3
(1) Copy Descendant Awards
User chooses whether to include all Child Awards of the copied Award in
the copy action.
UC2 A4
iii) Copy an Award to create Child
Award in another Hierarchy
User navigates to the Hierarchy Panel and chooses an Award to copy as a
new Child Award another selected Hierarchy.
UC2 A5
(1) Copy Descendant Awards
User chooses whether to include all Child Awards of the copied Award in
the copy action.
b)
UC2
UC2 N
UC2 A1
ii)
UC2 A2
See
DRs
2)
Open an Award
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
User shall be able to take action to open an Award for display or edit from
the screen to maintain the Award Hierarchy.
Page 14 of 37
4.6.
Use Cases
4.6.1.
UC1 – Maintain an Award Hierarchy
1
Use Case ID:
2
Use Case Name
3
Priority:
4
UC1
Maintain an Award Hierarchy
Must Have
OSP Admin
Actor(s):
Description:
User wishes to modify the structure of an Award Hierarchy, to maintain
individual Units of Organization, or to redistribute funds from one Unit
of Organization to another.
5
6
Precondition(s):
7
8
9
Normal Course:
PR1
User has a valid user account and has logged in to the system
PR2
User must have rights to view and create an award
PR3
User has created an Award (the ‘root’ or top level of the hierarchy) See KC_AWD-Create
an Award
PR4
User has selected an Award in the Hierarchy they wish to maintain
N
Create a Child Award
1) User chooses to maintain the Hierarchy
2) System presents user with a display of the current Hierarchy
3) User selects an Award in the current hierarchy as the parent Award for the new
Award (selects location for new node within the hierarchy)
4) User chooses to create a new child Award
5) System provides the following create options:
a) New Award
b) New child Award with data copied from the Parent Award
c) New child Award with data copied from another Award in the current Hierarchy
6) User chooses New Award [A1] [A2]
7) See KC_AWD-Create an Award for steps to create a new award (with or without data
from a Funding Proposal)
8) User chooses to save the new Award in the current Hierarchy. [A3]
9) System saves the new Award in the current Hierarchy. [PO1]
A1
Create New Award based on Parent Award
1) User chooses to populate the new Award with data from the Parent Award
2) System populates new Award with data from the Parent Award (see FR 5)
3) System displays new Award
4) User continues to edit new Award
5) User chooses to save the new Award [A3] [E1]
6) System saves the new Award in the current Hierarchy [PO1]
A2
Create New Award based on another Award in the Hierarchy
1) User chooses to populate the new Award with data from another Award in the
Hierarchy
2) System displays the Hierarchy
3) User selects an Award as source data for the new Award
4) System populates new Award with data from selected Award. (see FR 5)
5) User chooses to save the new Award [A3]
6) System saves the new Award in the current Hierarchy. [PO1]
A3
Don’t Save New Award
1) User chooses not to save the modified Hierarchy.
2) System discards the changes. [PO2] See Issue 9:
10
Alternative Course(s):
11
12
13
Cancel or Abandon a
Copy
Exceptions:
14
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
E1
Data Validation
1) System returns appropriate error messages.
2) User acknowledges messages.
3) System returns user to appropriate field to make corrections as needed.
4) Repeat E1 steps 1-3 until all errors are corrected.
5) Return to use case at point Data Validation was called.
Page 15 of 37
15
Post-conditions:
16
17
Special Requirements:
18
Assumptions:
19
Notes and Issues:
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
PO1
Changes saved
PO2
No changes saved
SR1
Page 16 of 37
4.6.2.
UC2 – Copy an Award
1
Use Case ID:
2
Use Case Name
UC2
Copy an Award
3
Priority:
Must Have
4
Actor(s):
OSP Admin
5
6
Description:
Precondition(s):
7
8
9
Normal Course:
User copies an Award and, optionally, its descendant Awards to another
location.
PR1
User has a valid user account and has logged in to the system.
PR2
User must have rights to view and create an award
PR3
User has created an Award (the ‘root’ or top level of the hierarchy) See KC_AWD-Create
an Award
PR4
User has selected an Award in the Hierarchy they wish to maintain
N
Copy an Award in a Hierarchy
1) User chooses to maintain the Hierarchy
2) System presents user with a display of the current Hierarchy, indicating the selected
Award
3) User selects an Award to copy
4) User chooses to copy the selected Award
5) System provides the following copy options:
a) Copy as new Hierarchy
b) Copy as a child Award in an existing Hierarchy
6) User chooses to Copy the Award as a new Hierarchy [A2] [A4]
7) System presents user with the option to include descendent Awards of the selected
Award in the copy action (if the selected Award has descendents in the Hierarchy)
8) User chooses NOT to include descendents in the copy action [A1]
9) User chooses to execute the copy action [A6]
10) System copies selected Award to create new root Award and Hierarchy
a) System assigns a new unique identifier to the single node Award and Hierarchy
b) System saves the new Award and Hierarchy [PO1]
c) System exits the previous Hierarchy display
11) System displays the new Hierarchy with options to display or edit an Award in the
new Hierarchy, or maintain the new hierarchy (as in UC1 or UC2)
A1
Copy Award and All Descendents as new Hierarchy
1) User chooses to include descendant Awards in the copy action.
2) User chooses to execute the copy action [A6]
3) System copies selected Award and all descendents to create Hierarchy
a) System assigns a new unique identifier to each Award in the new Hierarchy
b) System saves the all Awards and the Hierarchy [PO1]
c) System exits the previous Hierarchy display
4) System displays the new Hierarchy with options to display or edit an Award in the
new Hierarchy, or maintain the new hierarchy (as in UC1 or UC2)
A2
Copy Award as Child of an Award in the Current Hierarchy
1) User chooses to Copy the Award as a child Award in an existing Hierarchy
2) System presents user with the option to include descendant Awards of the selected
Award in the copy action
3) User chooses NOT to include descendant Awards in the copy action [A3]
4) User selects an Award in the current Hierarchy as the parent of the Award (selects
location for new node within the current Hierarchy) [A4]
5) User chooses to execute the copy action [A6]
5) System copies selected Award in the selected location of the Hierarchy
a) System assigns a new unique identifier to the new Award in the Hierarchy
b) System saves the Hierarchy and new Award [PO1]
6) System displays the updated Hierarchy with options to display or edit an Award in
the displayed Hierarchy or maintain the Hierarchy (as in UC1 or UC2)
10
Alternative Course(s):
11
12
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 17 of 37
A3
Copy Award and all Descendents as Child of an Award in the Current Hierarchy
1) User chooses to Copy the Award as a new Award in an existing Hierarchy
2) System presents user with the option to include descendant Awards of the selected
Award in the copy action
3) User chooses to include descendant Awards in the copy action
4) User selects an Award in the current Hierarchy as the parent of the Award and
descendents (selects location for new nodes within the Hierarchy)
5) User chooses to execute the copy action [A6]
6) System copies Award and descendents in the selected location of the Hierarchy
a) System assigns a new unique identifier to the new Awards in the Hierarchy
b) System saves the Hierarchy and new Awards [PO1]
7) System displays the updated Hierarchy with options to display or edit an Award in
the displayed Hierarchy or maintain the Hierarchy (as in UC1 or UC2)
A4
Copy Award as Child of an Award in another Hierarchy
1) User chooses to Copy the Award as a child Award in an existing Hierarchy
2) System presents user with the option to include descendant Awards of the selected
Award in the copy action
3) User chooses NOT to include descendant Awards in the copy action [A5]
4) User chooses to search for an Award (Hierarchy) outside the current Hierarchy as the
parent of the Award (selects location in another destination Hierarchy)
5) System displays Award lookup
6) User searches for an Award using standard KC lookup functionality and selects an
Award
7) System displays the Hierarchy for target Award
8) User may repeat A4 steps 4-7 until correct Award and Hierarchy target is selected
9) User selects an Award in the displayed target Hierarchy as the parent of the Award
(selects target location for new Awards within the displayed Hierarchy)
10) User chooses to execute the copy action [A6]
11) System copies Award in the selected target location of the Hierarchy
a) System assigns a new unique identifier to the new Award in the target Hierarchy
b) System saves the target Hierarchy and new Award [PO1]
12) System displays the updated target Hierarchy with options to display or edit an
Award in the target Hierarchy or maintain the Hierarchy (as in UC1 or UC2)
A5
Copy Award and all Descendents as child of an Award in another Hierarchy
1) User chooses to search for an Award (Hierarchy) outside the current Hierarchy as the
parent of the Award (selects location in another destination Hierarchy)
2) System displays Award lookup
3) User searches for an Award using standard KC lookup functionality and selects an
Award
4) System displays the Hierarchy for target Award
5) User may repeat A5 steps 1-4 until correct Award and Hierarchy target is selected
6) User selects an Award in the displayed target Hierarchy as the parent of the Award
(selects target location for new Awards within the displayed Hierarchy)
7) User chooses to execute the copy action [A6]
8) System copies Award and descendents in the selected target location of the Hierarchy
a) System assigns a new unique identifier to all new Awards in the target
Hierarchy
b) System saves the target Hierarchy and new Awards [PO1]
9) System displays the updated target Hierarchy with options to display or edit an
Award in the target Hierarchy or maintain the Hierarchy (as in UC1 or UC2)
A6
Copy Abandoned
1) User chooses not to execute the copy action
2) System discards the changes and returns user to Award lookup [PO2]
13
14
15
16
17
Exceptions:
18
Post-conditions:
19
20
Special Requirements:
21
Assumptions:
22
Notes and Issues:
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
E1
PO1
Changes saved
PO2
No changes saved
SR1
Page 18 of 37
5.
Functional Requirements
Table 6 Functional Requirements
#
New
funct?
ID
Requirement
1
1) View an Award Hierarchy: The system shall allow users to view an Award Hierarchy to depict
the parent/child relationships between all Awards in the Hierarchy.
2
2) Award Hierarchy Indicators: System shall provide visual indicators for each Award listed in
the Hierarchy tree to indicate the status of the Award to help the user understand the relationship
between Awards. Additional text may be displayed to the right of Hierarchy icons.
3
3) Maintain Award Hierarchy - System shall allow the user to maintain the Award Hierarchy
structure as follows:
4
a)
New Child Award - System shall allow the user to create child Awards in the current
Hierarchy with a variety of options for the source data.
5
i)
6
ii) New Child Based on Parent - System shall allow the user to create the new child award
by copying award data (excluding Time & Money and Budget) from the parent award.
7
iii) New Child Based on an Award in the Current Hierarchy - System shall allow the
user to create the new child award by copying award data (excluding Time & Money and
Budget) from any award selected from the current Award Hierarchy.
8
b) Copy an Award Hierarchy - System shall allow the user to copy Hierarchy Award(s) with a
variety of source and target options for the copy action.
9
i)
10
New Blank Award - System shall allow the user to populate data in the new child award
using functionality detailed in KC_AWD-Create an Award.
Copy as New Hierarchy - System shall allow the user to copy a Hierarchy Award to
create a new Award Hierarchy.
(1) Copy Descendents in New Hierarchy - System shall allow the user to include a
copy of all descendant Awards of the copied Award in the new Award Hierarchy.
11
ii) Copy as Child in Current Hierarchy - System shall allow the user to insert a copy of
an Award as a child to any Award in the current Award Hierarchy.
12
(1) Copy Descendents in Current Hierarchy - System shall allow the user to insert a
copy of an Award and all its descendants as children of any Award in the current
Award Hierarchy.
13
iii) Copy as Child in Another Hierarchy - System shall allow the user to insert a copy of
an Award as a child of any Award in any existing Award Hierarchy.
14
(1) Copy Descendents in Another Hierarchy - System shall allow the user to insert a
copy of an Award and all its descendents as children of any Award in any existing
Award Hierarchy.
15
4) Copy Descendents Option Availability – System shall allow user to copy descendents only
when there are descendents available to copy.
16
5) Fields in New Awards Created by Copy Functions – System shall create new Awards as a
result of Award Hierarchy copy functions (new child or copy) as follow:
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 19 of 37
#
New
funct?
ID
Requirement
Default Data in Copied Award – System shall automatically populate the following fields
of an Award created with the Maintain Award Hierarchy copy actions associated with New
Child or Copy actions:
Transaction Type = New,
Notice Date = null,
Comments = Copied Award
17
a)
18
b) Award Copy Function Fields – System shall populate the following new Award fields as a
result of the Copy or New Child actions that copy an existing Award: Award Status, Sponsor
Award ID, Account ID, Modification ID, NSF Science Code, Project Start Date, Project End
Date, Obligation Start Date, Obligation End Date, Execution Date, Sponsor, Activity Type,
Award Type, Account Type, CFDA Number, Document Funding ID, Small Business
Subcontracting Plan, Procurement Priority Code, Sponsor Authorization information
(Authorized Amount, Effective Date and Comments), Title, Sponsor Template, Prime
Sponsor, Payment Basis, Payment Method, Final Invoice due within # days, Invoice Copies,
Invoice Instructions, Sponsor Contacts, all Reports information (including Proposals Due),
all Terms, all Special Reviews with related comments, all Key personnel and Credit Split
information, Unit Contacts, Central Administration Contacts, all Comments, all Cost Sharing
information and Comments, F&A Rates information that is not system-generated, Keywords,
Benefits Rates and related Comments, all Closeout information,
19
c)
20
d) Unknown Effect of Copy Functions on Attachments - Whether or not Attachments are
copied when a new Award is created based on an existing Award from the new child or copy
actions is unknown because Coeus Award Attachments functionality is inactive as of
6/16/09.
21
6) Open Awards from Maintain Award Hierarchy Screen– System shall allow user to open any
Award in the currently displayed Award Hierarchy to view or edit the document according to the
user’s permissions.
22
3) Permissions – System shall allow users with the following permissions to access functionality to
maintain an Award Hierarchy.
23
a)
Exclusions from Award Copy Functions - System shall exclude the following Award data
from actions that create new Awards by copying an existing Award (new child or copy
actions): all Time & Money amounts, all Budget information, all Subawards information
(Approved AND Funded), Payment Schedule information, Sponsor Funding Transferred
information, Approved Equipment, Approved Foreign Travel information, Funding
Proposals, Notes.
Create Award – System shall require that a user have the Create Award permission to
perform any of the actions to maintain an Award Hierarchy as described in this document.
24
7) Maintain Award Hierarchy Availability - System shall make the Maintain Award Hierarchy
screens and actions available ONLY to users with the Create Award permission. All others
should not even be able to view the action buttons or Maintain Award Hierarchy panel.
25
8) Return to open document from Maintain Award Hierarchy: System shall return user to
screen that was already open when user navigates from Hierarchy to a document previously open
(to avoid problems that could be caused by having duplicate copies of the same document open
by the same user in various stages of editing). See Issue 10: Complex Navigation & Multiple
Docs Open
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 20 of 37
6.
Data Dictionary
6.1.
6.2.
Data Dictionary Items
Data Item Name
Data Item Name
Obligation Start Date
Obligated Amount
Obligation End Date
Anticipated Amount
Project End Date
Title
Document ID
Account
Status
Current
Pending
Distributed View
Distributable Amount
Go To
Grouping and Sort Order
Group in following order:
7.
Group Name
Sort Order
Document IDs
As Hierarchy is rendered, documents are displayed
in ascending ID order
User Interface Design
7.1.
User Interface Workflow
7.1.1.
Tab Order of Fields
Tab order should be left to right in each row, then move through rows from top to bottom.
7.1.2.
Hierarchy Icons
Numbered Award statuses already exist in Award Status code table. Status is displayed to the user with colored flags. For
accessibility, it is proposed to add an alphabetic identifier to colored flag (1-3 letters in length). Additional Proposed
Indicators are included in Coeus Perfect Tracker Case 2380 (marked for Coeus development, and therefore, in scope for KC).
Suggestions for flags were not included in Coeus enhancement request; suggestions for a starting point see 10.2.3 Icon
Decorators.
7.2.
#
Design Requirements
New?
1
2
ID
Requirement
1) Open a Hierarchy Award: System shall allow user to navigate to a specific Award within a
Hierarchy to view or edit the Award.
New
2) Award Identification in Hierarchy – System shall allow users to select and order award
identification information (like Award ID, Account ID, PI Name, Lead Unit Name…) in the Award
Hierarchy screen to assist users in identifying awards related in a common award hierarchy.
See UCSD Modified Hierarchy Screen
3
New
3) Open window for Award Hierarchy – System shall allow user to open a window to provide fullscreen view of the Award Hierarchy.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 21 of 37
#
New?
Requirement
4
9) Expand/Collapse Hierarchy – System shall provide common KC UI actions to expand or collapse
a branch of the Award Hierarchy to view or hide Awards.
5
10) Expand All/Collapse All – System shall provide common KC UI actions to expand all and collapse
all branches of the Award Hierarchy to view or hide Awards.
4) Maintain Award Hierarchy – System shall allow user
6
7
ID
New,
See
Issue 1
5) STILL UNDER DISCUSSION Award Hierarchy Indicators – See 7.1.2. System shall provide visual
indicators of the status and/or purpose of the Award Hierarchy node to help the user understand the
relationship between Award Hierarchy documents.
Award Status Code Table Description
Active
Inactive
Pending
Terminated
Closed
Hold
Award Hierarchy Flag Color
Green ‘A’
Red ‘I’
Yellow ‘P’
Red ‘T’
Red ‘C’
Blue ‘H’
Additional Proposed Indicators
Fabricated Equipment
Cost Sharing
Purple FE (KC SME suggestion)
Orange CS (KC SME suggestion)
Indicator format is new. See Issue 1: AW-24 Configurable Award Hierarchy Icons (originally
raised in KC_SHARED-Medusa)
7.3.
User Interface Mock-up
Figure 5: KC mock, Hierarchy Actions panel, showing details7/9/09
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 22 of 37
Figure 6: KC mock, Hierarchy Actions panel, Copy as new action, 7/9/09
Figure 7: Coeus 4.3.2 Award Hierarchy window with Details selected
This action is available from the Award search, NOT from within an open Award.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 23 of 37
Figure 8: KC mock, Hierarchy Actions panel, Copy as child action, 7/9/09
Figure 9: Coeus 4.3.2 Award Copy window
This window is displayed when user chooses ‘copy’ action from Award Hierarchy window
Figure 10: KC mock, Hierarchy Actions panel, New child based on new action, 7/9/09
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 24 of 37
Figure 11: KC mock, Hierarchy Actions panel, New child based on copy from parent action, 7/9/09
Figure 12: Coeus 4.3.2 Create Child Award window
This window is displayed when user chooses ‘new child’ action from Award Hierarchy window
Figure 13: KC mock, Hierarchy Actions panel, New child based on selected award action, 7/9/09
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 25 of 37
Figure 14: Coeus 4.3.2 Create Child Award window based on Select Award (w/in current hierarchy)
8.
User Documentation Notes
9.
Differences From Coeus

Expand/Collapse All Awards: “The system shall provide functionality that allows the user to expand or
collapse all Awards within a Hierarchy.” This is a Kauli common UI action.

Normal Course “Create an Award Hierarchy,” N-11, N-12; Propose an enhancement that would not
require users to search for awards they just created, but would leave them at the Hierarchy screen. This will
require that Hierarchy controls (create child, copy Award) be available to the user upon creation of any Root
or child Award.

Label Changes:

Coeus Label
Kuali Coeus Label
Oblig Exp Date
Obligation End Date
Final Exp Date
Project End Date
Eff Date
Obligation Start Date
Anticipated Amt
Anticipated
Obligated Amt
Obligated
MIT Award Number
Document ID
Display shall allow institution to select identification data displayed to the left of Award Hierarchy.
Propose an enhancement request to allow users to add Award data elements to the Hierarchy display (See
10.2.1 “UCSD Modified Hierarchy Screen” for an example).
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 26 of 37
10. Design and Implementation Notes
10.1.
10.2.
Constraints and Issues

Decisions about how to implement Hierarchy dramatically affect reporting, feeds & interfaces, and future KC
module integration. Several implementation models exist within the Coeus Consortium; hierarchies can be
fixed at a certain number of levels, with each level having specific meaning, or they can be of indeterminate
depth with no specific meaning attached to a particular level.

The Hierarchy need not be used at all. Institutions may choose to record everything at the Root Award level.

End-of-month (EOM) process, if run, will be impacted by the choice of Hierarchy implementation. EOM
reports transactions at the Root level only. Kuali Coeus does not require an ‘End of Month Process’ be run to
report on Award activity for a given period of time.
Other Technical
10.2.1.
UCSD Modified Hierarchy Screen
Figure 15: UCSD Modified Hierarchy screen
Note “Details” box is checked by default (Berkeley also customized this). Eight additional data elements from
Award details are displayed here. “Overwrite Typos” is also a UCSD customization.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 27 of 37
10.2.2.
Technical Implementation of UC Berkeley Hierarchy
This implementation of the hierarchy requires that the end user (client application, web client, reporting tool, etc.)
be able to extract tier-specific information. Selection of a tier is accomplished by the use of a view in REPORTS’
schema that applies the DECODE function to the column PARENT_MIT_AWARD_NUMBER in table
OSP$AWARD_HIERARCHY.
Table:
ROOT_MIT_AWARD_NUMBER
NOT NULL CHAR(10)
HIERARCHY_SEQUENCE_NUMBER NOT NULL NUMBER(4)
MIT_AWARD_NUMBER
NOT NULL CHAR(10)
SEQUENCE_NUMBER
NOT NULL NUMBER(4)
PARENT_MIT_AWARD_NUMBER NOT NULL CHAR(10)
View DDL:
CREATE OR REPLACE VIEW report$award_hierarchy AS
SELECT
root_mit_award_number,
mit_award_number,
parent_mit_award_number,
DECODE(parent_mit_award_number,
'000000-000', 1,
root_mit_award_number, 2, 3) tier
FROM
coeus.osp$award_hierarchy outer
WHERE
hierarchy_sequence_number =
(SELECT
MAX(hierarchy_sequence_number)
FROM
coeus.osp$award_hierarchy inner
WHERE
inner.root_mit_award_number =
SUBSTR(outer.mit_award_number, 1, 6) || '-001'
AND
inner.mit_award_number = outer.mit_award_number)
View:
Name
----------------------------------------ROOT_MIT_AWARD_NUMBER
MIT_AWARD_NUMBER
PARENT_MIT_AWARD_NUMBER
TIER
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Null?
-------NOT NULL
NOT NULL
NOT NULL
Type
-------CHAR(10)
CHAR(10)
CHAR(10)
NUMBER
Page 28 of 37
10.2.3.
Icon Decorators
Eclipse icon decorators are one way to add indicators in a tree-view hierarchy and are offered here as examples
(ref. http://www.eclipse.org/articles/Article-Decorators/decorators.html)
Figure 16: Examples of Eclipse Icon Decorators
Figure 17
Figure 18
In Fig. 12, a lock icon is superimposed on the Java icon image (
) of the file ImageDecoration.java. A prefix
and a suffix label are added for the file TextDecoration.java (
). The file NoDecoration.java does not have any
custom decoration (
).
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 29 of 37
11. Appendix
11.1.
Document Change Log
Important changes and additions since the last published version are noted in the list below.
11.1.1.
[2/16/09, Susan Mundt input from UofA]
Neil, initial comments from UofA are included in Track Changes view: final showing markup. We didn’t
bother to restate changes discussed in last Thursday’s spec meeting to User Requirements and Use Case
Index. Functional Requirements aren’t added yet, so we didn’t review. The primary focus of our comments
are on Use Cases. I did document maintenance items like captioning screenshots and updating Table of
Contents, Inserting File Name in Footer too.
11.1.2.
[2/19/09, Marcus Fricke input from ISU]
Changes incorporated into document.
11.1.3.
[2/20/09, Rosemary Hanlon input from MIT]
Changes incorporated into document.
11.1.4.
[2/27/09, Neil Maxwell]
Updates to User Requirements, Use Case Index, Use Cases, Functional Requirements.
11.1.5.
[3/4/09, Neil Maxwell]
Updates to Functional Requirements, Data Dictionary, UI Design/Mock, Differences from Coeus. Need to
address Glossary items (start/end dates, amounts) for consistency (see KC_SHARED-Medusa).
11.1.6.
[3/20/09, Renee Dolan input from MSU]
Updates to UC1, Differences from Coeus, minor corrections and clarifications.
11.1.7.
[3/20/09, Neil Maxwell]
Added Issues List, Data Dictionary Items, User Interface Workflow.
11.1.8.
[3/24/09, Neil Maxwell
Revised 7.1.2, inserted 10.2.3, added Renee Dolan as contributor.
11.1.9.
[3/31/09, Susan Mundt]
I updated issues because I had to review for FC report anyway. I also captioned figures as I would do in Lead
SME finalization.
11.1.10. [4/8/09, Neil Maxwell]
Updated with revised mock from Bart 4/8/09.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 30 of 37
11.1.11. [5/19/09, Neil Maxwell]
Removed (proposed) “Search/Filtered Search” and “Navigate To” Use Cases and FRs. Reordered Use Case
Index and FRs. Use cases are now “create” and “maintain”; FRs are “create,” “maintain,” and “view.”
11.1.12. [6/9/09, Neil Maxwell]
Minor change to FRs.
11.1.13. [6/12/09, Neil Maxwell]
Revised use cases to reflect LBA/SME discussion on the concept of Hierarchy editor controls to support the
creation and maintenance of Hierarchies. Updated screen mocks, differences from Coeus. Left changes
showing for SME discussion.
11.1.14. [6/12/09-06/14/09, Susan Mundt]
Formatting has been cleaned up for spec finalization. Remaining issues were updated. Use Case Index, Use
Cases, Functional Requirements and Design Requirements were reworked in conjunction with updates to
related spec: KC_AWD-TimeMoney.
11.1.15. [7/9/09, Susan Mundt]
Updated spec with comments and discussions from Terry Durkin, Development Manager. Added Issues 9
and 10. KC mock screens have been updated.
11.2.
Issues List
11.2.1.
Open/In Progress
Issue ID:
Status:
Subject/Title:
Description:
Owner(s):
1
Open/In Progress/Closed
Reporter:
Create Date:
NM
Jira #:
KRAFUNC-169
3/20/09
AW-24 Configurable Award Hierarchy Icons
Progress on issue will be documented in KC_AWD-Medusa spec, Issue 3: Configurable Award Hierarchy Icons
More detail needed on Hierarchy screen. MIT is proposing an enhancement to Coeus that would add a descriptor for
the purpose of the Award (see 7.2 item 6). This data would come from the account_type table. UCSD has customized
the Hierarchy screen (see 10.2.1) for a similar purpose; to provide more detail so that users do not need to take the
additional step of displaying Award details.
Further SME discussion around proposing a KC enhancement that would allow institutions to display selected Award
data elements of their choosing in the space adjacent to Hierarchy icons. It was felt that this would be preferable (for
accessibility and configuration reasons) to combining status and purpose in a single combined color/character-based
icon display.
Next Step(s):
Susan Mundt
Write Enhancement Request.
Terry Durkin
Awaiting DM review and approval process.
Due: Date:
Close Date:
03/15/09
03/17/09
When possible
Resolution:
Issue ID:
Status:
Subject/Title:
Description:
2
Open/In Progress/Closed/Deferred
Reporter:
Create Date:
NM
3/20/09
Jira #:
PT #:
COEUSQA-1578
2796
Sync To Parent Function
This Coeus “MIT Just Do IT” enhancement is scheduled for Coeus release 4.4. Estimated effort is 3 weeks, 1 hour.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 31 of 37
Description : We here at MIT would like a function in the award module that would apply any change(s) made to level
1 parent to any (all) levels (children) below.
We would like this function to work for:
Terms
Contacts
Reports
Indirect Cost (excluding Fabricated Equipment Child Accounts)
Comments
Cost Sharing (limiting syncing to Cost Sharing Child Accounts)
Status Changes (usually pending to active)
Principal Investigator/Lead Unit/Co-PI
Prime Sponsor
So if you changed one or more of these in the level 1 parent we would like to be able to also apply these changes to all
lower levels without going into each individual lower level to make change. This would also reduce human error.
Another idea along with this would be to have a pop-up or something with check boxes asking which lower levels you
would like to update.
Example of Pop-Up Check List:
Apply Changes to:
All including Closed
All Active/Pending
Exclude Fabricated Equipment (for Indirect Cost Change)
Apply only to Cost Sharing Child (for cost sharing changes on a one-to-one match)
We could then select through this pop-up exactly which lower levels to update as some changes may not apply to all
lower levels.
snair-31-DEC-08:Changed status from [Marked for Devlpmt] to [In Development].
jenflach-30-APR-09:Changed status from [In Development] to [In QA].
Owner(s):
Neil Maxwell
Resolution:
Issue ID:
Status:
Subject/Title:
Description:
Next Step(s):
Due:
Close Date:
Dat
03/25/09
03/25/09
e:
This is scheduled for development for Coeus 4.4 and will be deferred to KC 3.0. This may belong in KC_AWDTimeMoney.
Locate a working instance of Coeus 4.4 and test functionality.
3
Open/In Progress/Closed/Deferred
Reporter:
Create Date:
NM
Jira #:
3/20/09
Proposed enhancement for filtered search capability
In Coeus there is currently no filtering of search results as criteria are added. SME discussion around providing users
with search functionality that would allow for filtered searching of Award Hierarchies.
See Appendix 2: Potential Future Enhancements
Owner(s):
Next Step(s):
Due:
Date:
Close Date:
Resolution:
Issue ID:
Status:
Subject/Title:
Description:
4
Open/In Progress/Closed
Reporter:
Create Date:
NM
Jira #:
3/20/09
AW-29 Increase Award Node Extension Digits
Coeus three-digit numeric suffix limits the number of Child Awards within a Hierarchy to 999, unless alternative
characters are introduced (MIT uses alpha characters in the format A##, B##, AA#, BB#, etc. to support Hierarchies
with >999 Awards). An enhancement request is under consideration to reexamine the numbering scheme. Data
migration may be an issue.
From: Terry Durkin , Sent: Tuesday, March 31, 2009 2:03 PM
To: Susan Mundt, Cc: 'Neil Maxwell', Subject: Re: Question about KC Data Dictionary
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 32 of 37
The data dictionary can change what the system allows, but a change there wouldn't have a way to say "ok, go up to
9999 now instead of 999". I think we definitely want to make this change, but the question is for data migration, how
do we want to handle it? Ideally we make a choice on how it should behave and handle the difference during data
conversion, rather than coding in logic for handling either 3 or 4 chars.
We could convert the A## and AA# (does anyone go up to AAA?) to 0001-9999 during data conversion... 26^3 =
17,576 :)
I'd be curious to hear how Coeus would handle this. It's possible that they'd just ignore the A## Awards and just start
w/ 1000 if they expand. That'd certainly be easy-enough for us to do as well. Either that or convert the A## Awards to
numbers. Dealing with these as numbers certainly simplifies the technical implementation.
But either way it's an enhancement...
Date: Wed, 1 Apr 2009 13:27:04 , From: Rosemary Hanlon
Hi Susan, I reviewed this issue with Sabari Nair.
We concur that resolving the 3-digit suffix limitation for award node numbers is appropriate. Though it may be worth
preparing the functionality to support the database to accommodate 5 digit Awards. (Back in the day, we thought 3
would be suffice, so let's not put ourselves in the same work-around situation)
We currently believe that MIT would be the only Coeus school that would incur this data migration challenge for
converting data for award hierarchies with existing Awards with alpha characters higher than 999. We don't think we
need to worry about other schools with hierarchies with more than 999 Awards. We will manage the data conversion
issue for MIT.
Rosemary Hanlon, Business Intelligence Liaison, Coeus Consortium, 617-253-3529
Owner(s):
Next Step(s):
Due:
Date:
03/25/09
Close Date:
Neil Maxwell
SME discussion
Terry Durkin
EM to DM asking about KC Data Dictionary dated 3/31/09
03/31/09
03/31/09
EM regarding Terry’s ‘what would Coeus do’ question
04/02/09
06/12/09
Write Enhancement Request
06/17/09
R. Hanlon
Susan Mundt
03/25/09
Resolution:
Issue ID:
Status:
Subject/Title:
Description:
9
Reporter:
Open/In Progress/Closed/Deferred
Create Date:
Susan Mundt
Jira #:
07/09/09
Cancel or Abandon a Copy
Don’t Save New Award
1) User chooses not to save the modified Hierarchy.
2) System discards the changes. [PO2
T. Durkin: UC1.A3 - No way to cancel or abandon a copy. Once it exists it's there... Same as Coeus. (since an entire
hierarchy can be copied at once, all nodes must be saved)
S. Mundt 6/22/09: UC1 handles the Award Hierarchy Create Child action. I tested again, and Coeus allows the user to
discard the new child prior to the first save. I know what you’re saying; that since KC creates the Award as it’s opened
and there are implied saves, then Awards can’t be “uncreated.” However, this IS a difference from Coeus. Does KC
have to save the new Award as part of the Hierarchy if a new child is cancelled? Or can the Award still exist,
but be inactive and not linked to the Hierarchy? I want it just to be a lost orphan wandering aimlessly in the big
wide world! How’s that for a glimpse at my dark side?!
T. Durkin: UC2.A1 - We can discuss options on this. I have one of my leads doing analysis on what the options are for
copying all nodes in a hierarchy. This may be a place where we have to break out 1 Document/Award/Version
paradigm. Copying large hierarchies may be problematic if we need to create a document for each node. I will followup with options and pros/cons later in the week.
S. Mundt 6/22/09: Really, we don’t want any fancy selection of Version/Doc combos. Coeus just copies the current
active version and that’s fine. Perhaps I’m not getting your point here, but I’ll wait to discuss later this week.
T. Durkin: Technical Analysis is in progress regarding copying hierarchies. System performance is also an issue. May
need to copy hierarchies as 1 document. More to come…
Owner(s):
Next Step(s):
Terry Durkin
Suggest solution following completion of technical analysis
Due:
Date:
Close Date:
Resolution:
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 33 of 37
Issue ID:
Status:
Subject/Title:
Description:
Owner(s):
10
Reporter:
Open/In Progress/Closed/Deferred
Create Date:
Susan Mundt
Jira #:
07/09/09
Complex Navigation & Multiple Docs Open
Return to open document from Maintain Award Hierarchy: System shall return user to screen that was already
open when user navigates from Hierarchy to a document previously open (to avoid problems that could be caused by
having duplicate copies of the same document open by the same user in various stages of editing)
T. Durkin: Don't think this is possible using our current technology if this is supposed to be in a pop-up window.
S. Mundt 6/22/09: OK, so the point I was trying to make with this one was that, like Coeus, the user should be able to
close documents and retrace the path they took to get where they were as well as jump around that path (multiple
windows open). Is there something you can suggest to move in that direction?
Next Step(s):
Terry Durkin
Suggest solution following completion of technical analysis
Due:
Date:
Close Date:
Resolution:
11.2.1.
Resolved
Issue ID:
Status:
Subject/Title:
Description:
Owner(s):
5
Open/In Progress/Closed
Reporter:
Create Date:
Issue ID:
Status:
Subject/Title:
Description:
Owner(s):
Jira #:
3/20/09
Expand/Collapse All actions
“Expand all” and “collapse all” functionality do not currently exist in Coeus but are part of Time & Money mock
KRAFUNC-124.
Next Step(s):
Neil Maxwell
Resolution:
NM
SME Discussion
Issue ID:
Status:
Subject/Title:
Description:
Close Date:
03/25/09
03/25/09
Just list in Differences from Coeus – This is just a UI difference.
6
Open/In Progress/Closed
Reporter:
Create Date:
Jira #:
3/20/09
User should not need to search for an award they just created
UC3 Normal Course step 11: user shouldn’t have to search for the award they just created. Current Coeus functionality
requires create/save and then search/retrieve steps for an award where the user is building the Hierarchy.
Next Step(s):
Neil Maxwell
Resolution:
Due: Date:
SME discussion
Due:
Date:
03/25/09
Close Date:
03/25/09
In KC DEV for PD/B 1.1, system returns user to the open doc following save action. The close action returns
user to Main Menu after asking if user wants to save document. Issue can be listed as a Difference from Coeus.
7
Open/In Progress/Closed
Reporter:
Create Date:
Neil Maxwell
Jira #:
KRAFUNC-124
3/20/09
Expanded View for Award Hierarchy
From: Susan Mundt [mailto:mundts@email.arizona.edu] , Sent: Tuesday, March 31, 2009 12:30 PM, To: 'Terry
Durkin', Subject: UI issues or enhancements? (AWD Hierarchy)
Hi (again) Terry, Do we need to write functional enhancement requests for either of these things? I think they’re UI
issues, not functional enhancements, but wanted your confirmation before we move on to other things.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 34 of 37
Comments from Jira for Time & Money mock development KRAFUNC-124:
*Issue for input from Terry/Bart/Tom: Regarding scrolling within the Award Hierarchy subelement - SME group
would like the number of rows in the Award Hierarchy window to equal the number of rows in the hierarchy up to
about 15 rows. THEN, the window could scroll in proportion to the overall hierarchy size. Is that possible? Further,
what rules govern that proportionally sized scrolling window? If that isn't possible, perhaps we need to discuss how this
technology works again cuz we SME's don't 'get it.' We functional folks think the Award Hierarchy window should be
bigger and accommodate a hierarchy up to approximately 10-15 rows without having to scroll.
*I forgot one more thing... Can we have an expanded view icon for the Award Hierarchy that would open a separate
window for just the Award Hierarchy (like the pencil icon for expanded text window)?
Description of KC_AWD-Create an Award Hierarchy spec Issue 7: “Open Hierarchy in new window/tab” functionality
is derived from Medusa spec: “Open Hierarchy in new window/tab” functionality is not currently in Coeus, but similar
functionality has been proposed in the Medusa spec.
From: Terry Durkin [mailto:tdurkin@indiana.edu] , Sent: Tuesday, March 31, 2009 1:53 PM, To: Susan Mundt, Cc:
'Neil Maxwell'; dolan@ais.msu.edu, Subject: Re: UI issues or enhancements? (AWD Hierarchy)
Scrolling w/in the hierarchy is certainly doable w/o an enhancement. We can modify it in the mock do display more
and either display more by default in the code or make it scale to a reasonable amount.
Not sure I completely understand #2 - Is that just to pop the hierarchy out and into its own window? If so, I don't think
that will be an issue, either. T
[2:18:04 PM] Susan Mundt: Terry answered my question. I DID mean just pop the hierarchy out into it's own window.
Owner(s):
Next Step(s):
SME discussion
Due:
Date:
03/25/09
Close Date:
Neil Maxwell
Terry Durkin
EM to DM 3/31/09 to ask if we need to write enhancement requests
03/31/09
03/31/09
Resolution:
Issue ID:
Expanded view icon (to pop AWD Hierarchy into a separate window) will be added to UI mock.
8
Status:
Open/In Progress/Closed
Subject/Title:
Task-based interface
Description:
Reporter:
Create Date:
Neil Maxwell
Jira #:
3/20/09
SME discussion about categorizing the ‘views’ of time & money data (Summary, History, Anticipated Funding, etc)
and ‘actions’ (Correct/New Entry/New Child/Display) separately to create more of a task-based interface. This relates
more directly to the Time & Money spec than Hierarchy but the environments are similar in many ways. Progress of
this issue will be updated in Time & Money spec.
Owner(s):
Next Step(s):
Neil Maxwell
Further SME UI discussion
Resolution:
03/25/09
Due:
Date:
04/08/09
Close Date:
06/11/09
This issue is no longer valid given UI progress with Time & Money screens including Award Hierarchy.
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
Page 35 of 37
12. Appendix 2: Potential Future Enhancements
New
funct?
#
ID(s)
User Requirement
6
1) Search for a Hierarchy Award: The user shall be able to search for an Award in a
Hierarchy.
7
2) Navigate to a Hierarchy Award: The user shall be able to use the Award Hierarchy
to navigate to a specific Award within a Hierarchy.
8
3) View Key Award Details: The user shall be able to view key details about the
Award, and to access more detailed information if needed.
4.4
9
4) Apply Changes to Descendant Awards: The user shall be able to apply changes
made to an Award to all descendant Awards in the Hierarchy
Use
Case
ID
New
?
Use Case Name
Use Case Description
1)
Search for a Hierarchy
The user searches for an award Hierarchy.
a)
Enter search criteria
The user enters search criteria for the Award.
i)
The user shall be able to view a result set that narrows as additional
criteria are entered.
Yes
Yes
b)
2)
#
26
New
funct?
4.4 – this is
not fully
understood
ID
Filter results
View results
The user shall be presented with a result set containing hierarchies
matching the criteria upon completing search criteria.
Apply Changes to Descendent Awards
User shall be able to apply changes made to an Award to descendant
Awards in the Hierarchy.
Requirement
11) Sync To Parent Function: The system shall provide functionality to apply a change made to an
Award to its descendant/parent Awards.
Search functionality needs discussion with LBA/DM. Review document search capability currently in KC and determine
appropriate course.
Table 7: UC? Filtered Search for a Hierarchy
1
Use Case ID:
2
Use Case Name
3
Priority:
4
Actor(s):
5
Description:
6
Precondition(s):
7
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
UC?
Filtered Search for a Hierarchy
Essential
OSP Admin
User wishes to search for a Hierarchy to view or maintain the Hierarchy.
PR1
User has a valid user account and has logged in to the system.
User must have rights to view an award
Page 36 of 37
Normal Course:
N
5)
User navigates to Award Search function.
System presents user with field to enter search terms.
User enters search criteria. [A1]
System filters results as user types; result set is ‘final’ when user stops typing.
[E1][E2]
User retrieves desired Award Hierarchy.
A1
1)
2)
3)
User changes search criteria.
System filters results as user types; result set is ‘final’ when user stops typing.
User retrieves desired Award Hierarchy.
E1
Result set too large to display, display matching record count until reaching threshold.
E2
No matching results, display message “No matching records found.”
8
9
10
Exceptions:
11
12
Post-conditions:
13
PO1
PO2
14
Special Requirements:
15
Assumptions:
16
1)
2)
3)
4)
SR1
Although a query grid exists in Coeus, filtered search described here is beyond current
Coeus capability.
Notes and Issues:
Table 8: UC? Navigate to an Award
This was removed because navigation does not appear to work this way in Kuali Coeus
17
Use Case ID:
18
Use Case Name
19
Priority:
Essential
20
Actor(s):
OSP Admin
21
Description:
22
Precondition(s):
UC?
Navigate to an Award
User wishes to navigate to an Award to view or maintain Award details.
PR1
23
User must have rights to view and create an award
Normal Course:
N
3)
4)
5)
User retrieves desired Award Hierarchy from search results.
System displays selected Award Hierarchy. Default display shows Root Award
expanded, second tier collapsed.
User expands desired Hierarchy branch. [A1]
System displays descendant Awards of expanded Hierarchy branch. [A2][A3]
User selects desired Hierarchy Award.
A1
1)
2)
User chooses to expand all branches of the Hierarchy
System displays entire Award Hierarchy.
A2
1)
2)
3)
4)
5)
User chooses to collapse expanded Hierarchy branch.
System collapses expanded Hierarchy Awards.
User chooses to expand a different Hierarchy branch.
System displays descendant Awards of expanded Hierarchy branch.
User selects desired Hierarchy Award.
A3
1)
2)
User chooses to collapse all branches of the Hierarchy.
System collapses all Hierarchy Awards to display only the Root Award.
E1
No child records of selected Hierarchy Award. System displays indicator that user is at the
leaf level of the Hierarchy.
24
25
26
27
28
29
Exceptions:
Post-conditions:
30
1)
2)
PO1
PO2
31
Special Requirements:
32
Assumptions:
33
User has a valid user account and has logged in to the system.
Notes and Issues:
Document1 – Revision 1.0
Last Save: 2/8/2016 5:12:00 PM
SR1
“Expand all” and “collapse all” functionality do not currently exist in Coeus but are part
of Time & Money mock KRAFUNC-124.
Page 37 of 37