1
Kuali Rice
System Requirements Specification
Business Rules
Module - <Module Name>
Abstract:
Author(s):
Contributor(s):
Current Owner:
Revision:
Version 1.0
Create Date:
5/6/2008 3:42:00 PM
Last Save Date:
5/5/2008 9:53:00 pm by KHensley
© Kuali Foundation 2008
Contents
CONTENTS .........................................................................................................................................................2
TABLES ...............................................................................................................................................................3
FIGURES ............................................................................................................................................................3
1. INTRODUCTION ...........................................................................................................................................4
1.1.
Purpose ................................................................................................................................................... 4
1.2.
Review ..................................................................................................................................................... 4
1.3.
Document Revision History ......................................................................................................... 4
1.4.
References ............................................................................................................................................ 4
1.5.
Terms and Definitions .................................................................................................................... 5
2. BUSINESS REQUIREMENTS AND OBJECTIVES.....................................................................................7
3. BUSINESS RULES ................................................................................. ERROR! BOOKMARK NOT DEFINED.
4. USER REQUIREMENTS ...............................................................................................................................7
4.1.
Narrative – User Story ................................................................................................................... 7
4.2.
Important Concepts and Background ................................................................................... 8
4.3.
User Classes and Roles .................................................................................................................. 8
4.4.
User Requirements .......................................................................................................................... 8
4.5.
Index to Use Cases .......................................................................................................................... 9
4.6.
Use Cases............................................................................................................................................. 11
5. FUNCTIONAL REQUIREMENTS ...............................................................................................................15
6. DATA DICTIONARY ..................................................................................................................................23
6.1.
Data Dictionary Items .................................................................................................................. 27
6.2.
Grouping and Sort Order ............................................................................................................ 30
7. USER INTERFACE DESIGN ......................................................................................................................31
7.1.
User Interface Workflow .................................................................Error! Bookmark not defined.
7.1.1. Tab Order of Fields ......................................................................Error! Bookmark not defined.
7.2.
Design Requirements ................................................................................................................... 31
7.3.
User Interface Mock-up .............................................................................................................. 31
8. USER DOCUMENTATION NOTES ............................................................................................................31
9. DIFFERENCES FROM COEUS...................................................................................................................31
10. DESIGN AND IMPLEMENTATION NOTES ........................................................................................31
10.1. Constraints and Issues ................................................................................................................ 32
10.2. Other Technical ................................................................................................................................ 32
11. APPENDIX ..............................................................................................................................................32
11.1. Document Change Log ................................................................................................................. 32
11.1.1. [Date] ............................................................................................................................................ 32
11.2. Issues List ........................................................................................................................................... 32
11.2.1. Open/In Progress ...................................................................................................................... 32
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 2 of 38
11.2.2. Resolved ....................................................................................................................................... 34
11.3. Document Parts ............................................................................................................................... 36
11.3.1. Standard Document Table ..................................................................................................... 36
11.3.2. Use Case Template ................................................................................................................... 36
11.3.3. Requirements Table ................................................................................................................. 37
11.3.4. Issue Template .......................................................................................................................... 37
11.3.5. Callouts ......................................................................................................................................... 38
Tables
Table 2 Document Reviewers .........................................................................................................4
Table 3 Document Revision History .............................................................................................4
Table 4 Relevant Documents ..........................................................................................................4
Table 5 Terms and Definitions .......................................................................................................5
Table 6 User Roles and Classes .....................................................................................................8
Table 7 KRA Locking Requirements ...........................................................................................15
Table 9 Issues and questions ....................................................... Error! Bookmark not defined.
Figures
No table of figures entries found.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 3 of 38
1.
Introduction
1.1. Purpose
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
<name>, Lead SME, on behalf of SME
<name>, Lead Business Analyst
<name>, Development Manager
<name>, QA Manager
1.3. Document Revision History
The following table lists major revisions of this document following table. Please see the Document Change Log
on page 32 for a detailed list of changes.
Table 2 Document Revision History
Document
Version
Revision Name - Description
1.0
First Draft - LBA Review
1.0
Second Draft – SME Review
1.0
Final –
Revision Date
Author(s)
1.4. References
Documents that have information relating to the information discussed in this document.
Table 3 Relevant Documents
Document Title
Description
Location
Defining Business Rules –
What are they Really?
Systems analysts have long been able to describe enterprises in
terms of the structure of the data those enterprises use and the
organization of the functions they perform, but have tended to
neglect the constraints under which the enterprise operates.
Frequently these are not articulated until it is time to convert
them into program code. While rules which are represented by
the structure and functions of an enterprise have been
documented to a degree, others have not been articulated as
well, if at all.
The GUIDE Business Rules Project was organized in
November 1993 to carry out that articulation. This paper, the
original report of the GUIDE Business Rules Project (now the
Business Rules Group), describes a scheme for understanding
the nature of business rules and the categories into which they
fall. It presents a formal approach for identifying and
articulating the rules that define the structure and control the
operation of an enterprise.
http://www.businessrulesgroup.org/
first_paper/br01c0.htm
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 4 of 38
1.5. Terms and Definitions
The following table lists and defines the terminology used in this document. It is organized to read in an
approximately logical order.
Table 4 Terms and Definitions
Term
Definition
Kuali Rules
Management System
(KRMS)
A module for creating and managing business rules built into Kuali Foundations Rice
middleware.
(In speech, KRMS has come to be referred to as “crumbs”)
context
The area of business where a rule applies and where the terms used to create the rule are
defined and relevant. Rules only make sense in a particular Business Domain and when
evaluated against the information in that domain. For example, rules that are specifically
authored and that are meaningful in application on a Research Proposal would be most
unlikely to make sense or be relevant in the context of a Student Record.
context qualifier
One or more criteria defined by an application that is using KRMS to refine the context
for agenda and rules. For instance, a rule and agenda may only be valid for a particular
unit in the organizational hierarchy.
rule
A rule is a construct to evaluates when a particular condition or state exists and then
optionally execute an action to be taken
From the information systems perspective a rule is a construct used to enforce or help
with enforcement of a business policy. It describes and enforces a constraint, behavior, or
structure for some aspect of the business.
From the business perspective, a rule is guidance that there is an obligation concerning
conduct, action, practice, or procedure within a particular activity or sphere or area of the
business. Two important characteristics of a business rule are:

There ought to be an explicit motivation for it.

It should have an enforcement regime stating what the consequences would be
if the rule were broken.
condition
The part of a rule, made of up of one or more propositions (also called comparison
statements) that evaluates the information to determine if a specific state or condition
exists. Multiple propositions can be combined using the logical operators AND and OR. .
If the condition exists the, the condition evaluates to “True” and if the condition does not
exist it evaluates to “False.”
decision
The result returned by a rule after its condition is evaluated by being applied to a set of
facts. The condition off the rule is evaluated through logical execution of the propositions
and the result returned as a “True” or a “False.”
action
One or more procedure(s) executed if the condition of a rule returns a positive result (a
Boolean TRUE).
proposition
A proposition compares two values and “supposes” it to be true. Propositions consist of
two operands and one of the comparison operators. Each proposition returns a Boolean
(True or False) as the result. For instance: X > Y is True only when the actual value for
X is greater than the actual value for Y. The True or False result of a proposition can be
combined with the result of another proposition using one of the Boolean logical
operators AND and OR. Propositions are for a rule are collectively called a condition.
term
A defined item of business information that evaluates to a specific value called a fact For
example: Student’s First Name, Proposal Total Cost, Student Transcript, Protocol ID - are
all business terms or information that are valid in their relevant contexts. Terms are
inserted as operands in propositions.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 5 of 38
comparison operator
One of several symbols representing how two values will be compared with each other: =
(equal to), > (greater than) , < (less than), >= (greater than or equal to), <= (less than or
equal to).
logical operator
An AND or OR function in Boolean algebra that determines how each of the TRUE or
FALSE results from two propositions are combined to evaluate to a final Boolean result.
custom term
A custom function that evaluates to any value type except a Boolean True or False.
Custom terms can be used to perform complex logic not possible in the simple proposition
format provided by KRMS and are specified as an operand in a proposition.
custom propositions
A custom function that encapsulates complex logic that cannot be easily expressed in
simple Boolean expressions and that stands alone as a proposition. Custom functions may
be have parameters and accept arguments from the terms defined in its Context. The name
of custom propositions generally imply a Boolean answer, for example: IsNASAProposal
, ProposalNarrativesExist, ProposalHasBudgetMarkedFinal.
operand
One of two expressions that are compared to each other as specified by one of the
comparison operators.
order of evaluation
The order in which pairs of logically combined propositions (using AND and OR) are
organized in nested groups such that they are evaluated beginning with the inner-most
group first.
agenda
A plan of execution for a set of rules. An agenda specifies both ordered and conditional
execution for rules. Rules are run conditionally based on the Boolean return result of a
previous rule.
event
Some defined and detectable “happening.’ An event can be used to start the processing of
an agenda which then causes the rules in the agenda to be evaluated and any actions run
depending on the decision result returned by the rules. Events serve as the “trigger” for
rule processing.
variable operand
An expression such in the form of a term or custom term (a function that returns a nonBoolean value) that is specified as an operand in a proposition and is evaluated to an
actual value from the relevant data record at the time the proposition is evaluated.
constant operand
An unchanging value that is specified as one of the operands in a proposition .
expression
A symbolic representation of an operation such as one or more logically evaluated
propositions.
maps
A construct in Coeus that defines a set of sequential stops for approval workflow with the
capability to have multiple responsible approvers at each stop.
“Request chain” has been suggested for the Rice Equivalent. Other suggestions?
Simple Approval Workflow Definjition (SAWD).
notification
An action that can be specified as part of a rule definition that sends out a pre-defined
communication.
validations
An action which can be specified in a rule that validates the content in a document.
meta rule
In Coeus, a Meta Rule defines the order of execution for a rule. For KRMS this has been
renamed agenda.
comparison
statement
See proposition.
organizational unit
(OU)
Defines a part of an organizational structure and is usually arranged hierarchically.
unit hierarchy
In Coeus and Kuali Coeus, the structure that defines the organizational hierarchy.
Business rules can be defines at the department level.
fact
When a proposition is evaluated with actual data, the Proposition with its True or False
result is called a fact. For instance, the proposition FirstName = “Bill” is a proposition
that asserts that the First Name of an actual person is the name Bill. The evaluation of
“Marge” = “Bill” is False
function
A pre-defined, custom procedure for evaluating data that returns a value that can be
selected for us in a proposition. There are two categories of function based on their return
type: custom propositions which return the a Boolean value and custom Terms which
return are used as an operand
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 6 of 38
variable
A representation of a data item that is replaced with an actual value when evaluating a
proposition.
active rule
A rule that operation because it is associated with a published agenda (an agenda that is
associated with at least one event so that when that event “happens” the rules in the
agenda are evaluated and actions are run for the rules that return true).
term group
A collection of terms that make sense to group logically together.
standard operations
The set of operations and their associated behavior for items in the system such as Save
and Delete.
2.
Business Requirements and Objectives
3.
User Requirements
3.1. Narrative – User Story
There are many rules that have to be followed in business systems. In Higher Education in the area of Research
Administration, to take an example, it must ensure that documents such as Proposals, Awards and Protocols are
managed properly. For example, “Proposals over $250,000 require the Dean’s review.” There are a number of
observations about rules that are important:

These rules are not static. They may change when regulations or institutional policy change are due to a reorganization.

Rules are different based on the department or unit. Units have needs that are particular to how they operate
and consequently they have their own rules.

Rules can be used and re-used to make decisions involving several different tasks. For instance, it may be
used to make a workflow decision or it might also be used in validations.
3.1.1.
Routing Rules: Approval of Development Proposals
After an investigator has approved a development proposal, it must be routed for internal approvals before
submission to the sponsor. Generally the central office that manages sponsored research (OSP – Office of
Sponsored Research) communicates with campus administration in the approving units such as a Dean’s
office or the Vice President for Research’s (VPR) office as well as individual Departments, Labs, and
Centers, to establish each office’s approval criteria. The information conveyed regarding which proposals
should be reviewed at that office and by whom, are then added to logical statements that evaluate business
data. These logical statements are combined into business rules. An example of the types of information that
are included in the
Who: Principal Investigator (PI) and Co-Investigators (Co-Is)
Where: Units maintained for the PI and Co-Is
What:
1) Proposal type (e.g., Fellowship or Instruction)
2) Sponsors
3) Answers to Questions such as:
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 7 of 38
a)
b)
c)
d)
e)
Are special reviews required?
Is Cost Sharing incurred?
Is Under-recovery incurred
Was a Funding amount proposed?
Other specialized functions to meet campus needs
When managing approvals, an administrator often has to deal with the following items:
1. Having to ad-hoc add additional people to the approval route, for instance because a resource that has
been added that belongs to a different department or the use of a restricted material.
2. Questions often arise concerning what happened during approval routing, and so the routing history
needs be maintained with the proposal.
3. Also, the administrator must manage and track with the proposal documents related to approval that
are added during the approval process.
3.1.2.
Other Business Rules functionality: Validations
Proposals often have to be checked for data that is required for certain submissions, but may also be specific
to the institution. Remembering to do this requires checklist and awareness on the part of Administrators as
they proof a proposal prior to submission. These checks are a significant help the process by preventing
Grants.gov sponsor errors or warnings that will reject the submission. Having an automated way to ensure
these rules are applied would increase quality of submissions and ensure that, whatever the knowledge of the
administrator concerning the requirements for a particular sponsor and/or submission, that the proposal has
been validated.
3.2. Important Concepts and Background
3.3. User Classes and Roles
The following table lists the groups of people that are expected interact with the system.
Table 5 User Roles and Classes
User Class
Role
Description: the group and how they are expected to use the system.
System Administrator
3.4. User Requirements
Table 6 User Requirements
#
1
ID(s)
User Requirement
UR-1
1) Business Rules: The user must have the ability to create and define one or more logical
statements that evaluate whether a specific state or conditions exists in business data and
then can execute some action based on the outcome.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Scope
Page 8 of 38
#
Scope
ID(s)
User Requirement
2
UR-2
2) Data For Use in Business Rules: The user must be able to define which data will be
valid for use in the propositions of a business rule. This will include the capability to
reference a complex function in a proposition, that could be authored with the appropriate
programmer-level technical skill.
3
UR-3
3) Business Rules Actions: The user must be able associate the result or outcome of a rule,
the decision, with an action such that the action is carried out if the decision is positive.
In particular, the user must be able to execute the following actions:
a) Workflow: Initiate an automated approval workflow,
b) Validation: Activate a data validation that either serves to warn the user or require
valid data in order to continue.
c) Notification: Execute a pre-configured notification, such as an email.
d) Custom Action: Provide a development and publishing mechanism for actions such
that a user may request custom actions to be created and published for their use. An
example of this would be an action that includes a Questionnaire on a document.
An “Include Questionnaire” action is functionality specific to KC and is required for
functional equivalence with Coeus, but would not be included in Rice. However, as stated
above, a mechanism for the KC team to create the custom action is necessary.
4
5
4) Permissions: Creating, modifying and activating rules must be controlled by permissions.
UR-5
5) Context and Constraints for Rules: The author of a rule should be able to define the
context for a rule. The context is the logical data area where that rule applies. For
instance, authors must be able to define rules on a per unit basis so that they are specific
to a particular unit.
6
6) Execution: The user must be able to specify which rules are active, the order in which
they will be executed and be able to conditionally run the rules based on the result of a
previous result. .
7
7) Error Management: The user must be informed when rules fail to execute and why the
failed to execute in such manner
8
UR-6
8) Versioning of Rules: The user shall be able to see when a new version of a rule has been
created and be able to control when the new version of the rule is placed in service.
Not in Coeus
Out of Scope
9
UR-7
9) Approval of Rules: The user must have the option to be able to define an approval
process for rules if desire
Not in Coeus
3.5. Index to Use Cases
The following table lists the use cases
Use
Case
ID
Use Case Name
Use Case Description
Term Groups
1)
Create a Term Group
a.
Modify a Term Group
b.
Delete a Term Group
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
A group name is created that describes a logical collection of terms.
Page 9 of 38
Terms
1)
Create a Term
a.
Define term with source as single value
b.
Define term with source as multiple
value list
c.
Define single value term
Terms (something that can stand for an item of data
Custom Functions
A list of available actions must be created and defined in the system
before they can be used in a rule. There will be some default actions
provided by the middleware. An application administrator must be
able to add actions to the list of available actions.
Actions
1)
Add New Action
a.
Modify an Action
b.
Delete an Action
c.
Create an Action
Namespace View
2)
Create a New Namespace
a.
Find a Namespace
Search for and find a namespace
b.
Modify a Namespace
A Namespace is retrieved and modified by changing its attributes or
the terms and term groups that have been added.
c.
Delete a Namespace
A Namespace is deleted
d.
Add a Term
e.
Add a Custom Function
f.
Add a Term Group
Business rules are created from propositions that are active for a
particular namespace.
Business Rule
3)
Create New Business Rule (BR)
a.
Modify BR
b.
Delete BR
c.
Copy a BR
d.
Inactivate a BR
Condition: Proposition Editor
4)
A Namespace is defined that serves as a container for holding terms
organized in groups that will be used as operands in propositions.
This is a maintenance function that must be completed before rules
can be used.
The data is queried using propositions to determine if a certain
condition exists.
Edit a Condition
a.
Add a Proposition
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 10 of 38
b.
Modify a Proposition
c.
Delete a Proposition
d.
Add a Logical Operator
e.
Modify a Logical Operator
f.
Delete a Logical Operator
g.
Create a Group
h.
Remove a Group
i.
Move a Group
An Agenda is created to determine which rules will executed and in
what order. Agendas can be included in other agendas.
Agenda
5)
4.
Create an Agenda
a.
Modify an Agenda
b.
Delete an Agenda
c.
Add a Rule to An Agenda
d.
Delete a Rule from An Agenda
e.
Insert An Agenda as a Sub-Agenda
Use Cases
Table 7 Use Case Sample
1
Use Case ID:
2
Use Case Name
3
Priority:
4
Actor(s):
5
Description:
6
Precondition(s):
PR1
7
Normal Course:
N
1)
8
Alternative Course(s):
A1
2)
9
A2
3)
10
A3
<Alternate Course Name>
1)
2)
11
A?
Delete BR (rule in use)
1) System determines that the business rule is in use
2) System restarts the business
12
Exceptions:
13
Post-conditions:
14
E1
PO1
PO2
15
Special Requirements:
16
Assumptions:
17
Notes and Issues:
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
SR1

Page 11 of 38
4.1. Business Rule – High Level
18
Use Case ID:
19
Use Case Name
20
Priority:
21
Actor(s):
Business Rule Process High Level
Application Administrator (application using KRMS), Rule Author
22
Description:
23
Precondition(s):
PR1
This use case describes the basic steps that are required to use KRMS in an application.
24
Normal Course:
N
25
Alternative Course(s):
1)
Configuration Environment: Using the configuration environment, an Application
Developer defines the following items that will be later used by a Rule Author to
create rules:
a. Context: Creates the one or more Contexts that define functional areas of
the consuming application where the rules will be used.
b. For each Context the user must at least one of each the following
i. Terms – the business information that will be using in
identifying a particular condition exists in the data. Terms are
used as operands in propositions. Terms can be collected
together. logically as needed using Term Groups. Custom,
complex term can also be created and published using a
function.
ii. Custom Propositions: A proposition can be custom
programmed and published in the context.
iii. Actions – Each context has valid Actions that are specified for a
rule. The action is taken on a positive result developed from the
rule. An Application using KRMS must define the actions it
wants to provide. Some default actions will be provided by Rice
including a validation, sending a notification and starting a
simple workflow definition.
iv. Events – Events are defined for the application and are what
trigger the running of an Agenda.
2) The KRMS system is now configured for use by the Rules Authoring Environment
which will reference everything defined in that Context when creating Rules and
adding them to Agenda.
3) The Rule Author navigates to the Rule Authoring Environment and opens the
Rules Editor.
4) KRMS displays the UI for editing Rules
5) The Rules Author creates one or more rules by creating a proposition and specifying
an action to execute if the rule returns True.
6) The Rules Author opens the Rule Agenda
7) KRMS displays the editor for authoring Agenda.
8) The Rule Author adds rules to the agenda specifying:
a.
the order in which a rule should be run and/or
b. whether the rule should be run conditionally based on the result of a
previous rule.
c. They also specify the Event that will trigger the agenda to be evaluated.
9) The Application fires an event.
10) In response to the event, KRMS:
a. detects the event
b. finds the agenda associated with the event
c. evaluates the rules in the agenda
d. executes any actions from the agenda
A1
26
A2
3)
27
A3
<Alternate Course Name>
4)
5)
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 12 of 38
28
A?
29
Exceptions:
30
Post-conditions:
31
Delete BR (rule in use)
6) System determines that the business rule is in use
7) System restarts the business
E1
PO1
PO2
32
Special Requirements:
33
Assumptions:
34
Notes and Issues:
SR1

4.2. Business Rule
Table 8 Use Case Sample
35
Use Case ID:
36
Use Case Name
37
Priority:
38
Actor(s):
39
Description:
Create a Business Rule (BR)
Application Administrator, Business Unit Administrator
The user creates a new Business Rule using the business rules editor
40
Precondition(s):
PR1
41
Normal Course:
N
Create a New Routing Business Rule
8) Search/Lookup: User navigates to search facility for or more business rules
9) System displays search facility with appropriate criteria [Lookup Req]
10) Search Criteria: User enters search criteria and
11) User navigates to the Business Rules editor
12) System displays the Business Rules editor and presents the following actions for
business rules (BR): Create, Modify, Delete
13) User selects a Unit from the Unit Hierarchy where they wish create the rule.
14) System displays the Unit Name so that it can be seen for the duration of the edit
15) User edits the setup information for creating a rule as follows
a. Selects the default value for Rule Type which is “Routing”
16) User executes the “Create Business Rule” action [A1-Modify BR; A2-Delete BR]
17) User fills in the following information about the Business Rule:
a. Selects the Type from list of valid types (Notification, Questionnaire,
Routing, Validation)
b. Selects the Module where the rule will applied
c. Selects the Sub-module the rule will be applied
18) User fills in the following information about the Business Rule
19)
42
Alternative Course(s):
A1
Modify BR
1) User executes the “Modify Business Rule” action
2)
43
A2
Delete BR (rule not in use)
1) User executes the delete business rule action
2) System confirms that the business rule is not in use [A?]
3) System displays message asking the user to confirm the deletion
4) User confirms deletion
5) System deletes the business rule
44
A3
<Alternate Course Name>
6)
7)
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 13 of 38
45
A?
46
Exceptions:
47
Post-conditions:
48
Delete BR (rule in use)
8) System determines that the business rule is in use
9) System restarts the business
E1
PO1
PO2
49
Special Requirements:
50
Assumptions:
51
Notes and Issues:
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
SR1

What happens if you delete a unit that is already in use
Page 14 of 38
5.
Functional Requirements
Note: Only key data
Table 9 Functional Requirements
#
1
2
Trace
Requirements
Scope
1) Standard Operations: The behavior of the following operations, as follows:
a)
Inactivate: Unless otherwise specified, items (for example Terms and Rules that
require an inactivate operation shall use the date range defined by the Active and
Inactive dates to determine if an item is active or inactive, as follows:
Not in Coeus
The use of Active/Inactive dating as a way is the standard method in Rice used to
inactivate an item in the system.
3
i)
Active Items: An active item is one where the start date of the range is older than
the end date of the range and the end date is either not specified or it is the same or
later than the current date.
The effect of this
4
ii) Inactive Items: An item is treated as inactive if
(1) the start date of the range is latter than the current date OR
(2) the start date of the range is earlier or equal to the current date and the end date
of the range is earlier than the current date.
5
iii) Effect on Existing Dependent Items: When an item is inactivated, it shall have no
effect on the existing items that currently depend on the item such that the
dependency must be specifically removed from the definition of that item.
For example, if a term is inactivated, it will not affect existing rules and
propositions that depend on that term immediately. A Rule Author must edit the rule
and remove the dependency on that term render it inactive.
Need to validate this behavior
6
iv) Effect on Creating New Items: When an item is inactivated it shall no longer be
made available in the list of items needed for the creation of dependent items.
For example, if a term is inactivated, it must no longer be available for when
creating the condition in new rules.
7
b) Delete:
8
i)
9
ii) Delete Permission: A Rule Author must have the delete permission in or der to
delete a role.
See table for default Roles and Permissions at the end of the functional
requirements.
10
iii) Delete Validation: The system shall prevent the deletion of any rule that is
currently active and in use on an agenda (see e.
Dependency Check
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 15 of 38
#
Trace
Requirements
11
Scope
iv) Delete Confirmation: The system shall provide a message that asks the user to
confirm deletion.
Need full list of system messages
12
13
14
2) CONTEXT
In Coeus, the idea of Context was not explicitly defined but the equivalent was effected by
Module, Sub-Module and Type (type being the same as a KRMS “Action”). In KC, this list
of criteria will be dynamic and would likely include the type of Document.
15
a)
Context: The system shall provide a means to collect together items valid for a
particular business area including terms, custom functions (custom terms and custom
terms) events, actions, rules and agenda.
Another way of saying this is that Context is the set of all items
16
b) At Least One Context: The Application Developer must create at least one and may
create multiple contexts for use in the consuming application.
17
c)
Default Context: The KRMS system shall define a default context for the KRMS
system that defines the default, terms and other functions that may be used in the
creation of rules.
Validate: Based on a comment by KS on the need to reflect on data in the system (?).
Should we provide this?
18
d) Context Attributes (see Table 11 Entity Data for full list)
19
i)
20
ii) Context Criteria: A list of criteria that define the context.
Standard Attributes: Context shall be described and defined by the following
attributes: Name, Description, Context Criteria (see table)
In practical terms, in Rice, a Document Type will determine the primary boundary
of a context is the Document (or Document Type).
21
22
23
iii) Lists of valid items for creating rules and agenda: A context shall maintain lists
of the following items that define what are valid for use in creating Rules and
Agenda in the context:
(1) Terms
(2) Actions
(3) Events
(4) Custom Terms
(5) Custom Propositions
e)
Effect and Behavior of Context: Contexts have the following effect and use in the
system:
i)
All KRMS Entities Have a Context: When Terms, Custom Terms, Custom
Propositions, Events, Actions, Rules and Agenda are created they must be assigned
to a context.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 16 of 38
#
Trace
Requirements
Scope
24
ii) Lists are filtered by Context: When displaying lists of terms, events, actions,
custom functions and custom terms to the Rule Author while creating Agenda or
Rules, only entities defined within the same context assigned to the Agenda must be
displayed in the list (in other words, lists are restricted and filtered by the context
that is defined for the Rule and the Agenda that is being worked on).
25
iii) Searching and Lookup: When searching for rules, agenda and various other items
that are defined for a particular Context, the Context Name or ID may be specified
as search criteria.
26
iv) Default Search Criteria: When working within a context, that context shall be
included in the default search criteria.
27
3) TERMS
A term is the definition for any piece of information that a user may need to evaluate in a
rule. The collection of data that is valid “makes sense” in a Namespace
28
a)
29
Terms: The system shall provide a mechanism to define and publish a list of data items
that are valid in the context for authoring the proposition in a rule.
i)
Term Attributes: A Term shall be defined and described by the following
attributes Name, Description, Data Type, Valid Value List, Context(s) ( see Table
11 Entity Data for full list)
a.
ii) Term Operations: The system shall provide the following list of operations that
act on a Term: Create New, Edit, Copy, Delete, Inactivate (see Table 10 Entity
Operations for a list of standard operations)
b.
iii) Delete: An operation that allows an existing Term to be removed from the system
under the following conditions:
c.
(1) Not in use in a proposition: A term may only be deleted from the context
when it is no longer used in any proposition in that Context.
d.
(2) Determining Use: They system shall provide a mechanism for a Rule Author
to see a list Rules where a Term is used.
Not in Coeus
In or out of scope?
30
4) ACTION
Different From
Coeus
Actions are how a rule is “enforced.” When a rule returns a positive (Boolean True) result, the
action that is defined for that rule is executed. In Coeus, actions are not implied by the “type” of
the rule you define – you define a rule as a “Notification Rule” for instance. “Send
Notifications” is the implied action.
31
Actions: They system shall provide a mechanism to define and manage a list of actions for the
specification as part of the rule definition.
32
5) Action Data: The system shall include the following data for Action: Name
33
i)
34
ii) Description: A text value for providing additional information about an action.
35
iii) Context: The Context or Contexts (see above) to which this Term belongs.
Name: A text value that identifies an action.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 17 of 38
#
Trace
Requirements
36
iv) Action Parameter(s): The system shall provide a mechanism to define zero or
more parameters that can pass information from the current context to the action
before it executes :
Scope
Not in Coeus
This is not in Coeus, but was considered necessary to allow an action to operate
generically enough for most applications.
(1) Action ParameterAttributes: An action’s parameter(s), if provided, shall be
describe by the following attribute: Name, Description, Data Type, Default
Value (see Table 11 Entity Data for a complete list)
37
38
b) Action Operations: The system shall provide the following list of operations for
working with on an Action: Create New, Edit, Copy, Delete (see Table 4 Terms and
DefinitionsTable 10 Entity Operations for a complete list)
39
c)
40
Action Execution: If the condition specified and defined for the rule returns the value
True, they system shall initiate a process to perform the Action associated with the rule.
i)
Standard Actions: They rules system shall provide the following standard actions
that may be selected for a rule:
41
(1) No Operation: An action that essentially does nothing, the “no operation”
action when it is selected initiates no procedures and no steps are taken even if
the rule’s condition evaluates to “True”.
42
(2) Execute Workflow: Select a Sequential Workflow Definition based on the
rules and execute
43
(3) Send Notfication(s): A predefined action system that shall initiate a process to
send notifications that are defined and valid for the context.
44
(4) Validate Document: They system shall prevent a document from being
submitted if the condition for the rule returns the value “False.”
45
6) EVENTS:
The system shall provide a mechanism to define and identify what steps in a process shall
intiate (trigger) the evaluation of rules.
Not Explicitly in
Coeus
Events are not explicitly defined in Coeus, but of course they exist as a concept. For instance
when a Proposal is submitted for approval this is the event that triggers the selection and
execution of a workflow. In KRMS we have made this explicit and some additional
functionality has been added.
46
a)
47
b) Event Operations: The system shall provide one
48
c)
49
d) Default Events: The KRMS shall provide the following standard events
i) Document Close Action Executed
Event Details: Attributes shall be shall be provided to define and describe an Event
including the following: Name, Description, Context (see Table 11 Entity Data for a
complete list)
Events: Event shall be defined by the each software application implementing the
KRMS system
50
ii) Document Submitted
51
iii) Others (?)
What are the other default events that need to be provided with in KRMS?
52
e)
Events and Context: Events may be associated with more than one context.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 18 of 38
#
Trace
Requirements
53
f)
54
g) List of Agenda: The system shall maintain and be able to display a list of agenda that
are associated with each event.
55
h)
56
Scope
Events and Agenda: An event may be associated with exactly one agenda.
7) RULES: They system shall provide functionality to create and manage one or more rules.
This section discusses requirements for the structure and management of rules, particularly
the three main parts of rules: action, condition and action.
57
58
59
a)
Rule Operations: The system shall include the following operations that act on
business rules: Create New, Edit, Inactivate, Delete. (see Table 10 Entity Operations for
a complete list and the requirements for Standard Operations )
8) Rule Structure: A rule definition shall be constructed of three parts: Descriptive Details, the
Condition and the Action. These are as follows:
a)
Attributes: A rule shall include the following information, Name
60
i)
61
ii) Description: A text value that optionally provided extended descriptive
information.
62
iii) Version: The version number of the rule (see requirements for versioning of rules)
Name: A mandatory text value that identifies the rule.
Not In Coeus
Coeus does not version rules but this may be something that we consider in Rice.
Modifying rules that are in service directly could have a large impact on the
modification of the rules.
63
b) Condition: The system shall provide mechanism for the creation and management of
an expression that evaluates data in a namespace. (see Heading for Conditions &
Propositions below).
Example: To evaluate whether a person is a Key Person, the Key Personnel list must
queried. The rule author must create a statement that can establish that a person is a
member of the Key Personnel list. That statement can be stated in natural language as:
Execute a custom function that accepts a Person ID as a parameter, checks all IDs
assigned to the Key Personnel list on a proposal, and returns true if that list
64
c)
Action: The system shall provide a mechanism for associating an action with a rule such
that when the result of the evaluation of the Conditions defined for a rule results in a
Boolean value of TRUE, the action is executed.
Not in Coeus
An action might also be called the “Enforcement,” or “Consequence,” of that rule. In
Coeus, the “Type” of the rule, indicated what Routing, Validation, Notification or
Include Questionnaire. Actions should be stated as a active verb.
65
i)
Standard Actions: They system shall provide the following actions as standard
These actions are listed here because they likely belong in the middleware (Rice)
since they interact with core functionality provided by Rice. The behavior of the
rules has yet to be determined. Requirements require further discussion.
66
(1) Notify: The positive evaluation of the rule shall cause any defined notifications
to be sent.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 19 of 38
#
Trace
Requirements
Scope
67
(2) Validate: When the rule returns a negative result in a validation procedures is
applied to the to the data context.
68
(3) Select & Execute Approval Workflow: The rule(s) shall select and execute an
approval workflow (map)
69
ii) Actions: They system shall provide a mechanism for Rule Author to select valid
rules that are associated with
70
Not in Coeus
(1) Custom Action Parameters:
Presumably a rule needs to pass the context to an action? Anything else?
71
72
(2) Return Value:
d) Versions: The system shall track the changes made to a rule such that: ???
73
i)
74
75
Changes Create Versions: If change is made to any aspect of a rule, a new version
of the rule is created.
Need to complete
9) Results of Evaluation: When a rule is evaluated (or executed) the system shall track the
result for the following scenarios:
There are multiple questions here: What happens if a rule fails in one way or another.
76
a)
77
b) Rules: Rules may include other rules ??? more a Rule Set
78
c)
79
Not In Coeus
Result of Successful Rule Evaluation: If condition statement for a rule returns the
value TRUE and also the action executes successfully, then the rule shall return the
Boolean result of TRUE
Rules: If some aspect of a rule
10) Modifying a Rules: That are In Use: When an active rule is modified, the system shall
documents that have a dependency on that rule as follows:
80
How do we want this to work?
81
CONDITION & PROPOSITIONS
This section defines requirements for a “Condition Editor” that allows the user to define what
must true( the condition) in the data domain in order for the rule to execute its action.
82
11) Propositions: The system shall provide a mechanism for creating and editing comparison
statements that compare terms (data) defined in the namespace to a specific value for that
item.
Example: ([AGE] >= 18 AND SPONSOR_CODE=”NIH”) OR [NAME]=”Charles”
83
a)
Structure: A proposition shall consist of the following:
84
i)
85
ii) Logical Operators: Optionally, multiple comparison statements may be joined by
either of the binary logical operators, AND or OR.
86
iii) Order of Evaluation: Propositions may be to indicate the order in which the
Boolean logical expressions should be evaluated.
Comparison Statement(s): One or more propositions that compare two values
using a comparison operator, for example: =, <, >, <=, >=, ≠ (see table ?? for all
operators)
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 20 of 38
Trace
#
Requirements
87
b) Default Order of Evaluation: The logical AND operator shall be evaluated before the
logical OR operator.
88
c)
Scope
Operands: When authoring an expression the operands may be defined as any one of
the following:
In Coeus, the left hand operand of a comparison statement is the variable value (such as
a column name from a database). The right hand operand is the literal or constant
value.
89
(1) Literals: Any numbers or text typed in.
90
(2) Data Item Name: A data item name from taken from the data context.
91
(3) Function: A pre-defined function that returns a
92
ii) Comparison Operators:
93
iii) Logical Operators:
94
iv) Fixed-Value (right-hand) Operand:
95
d) Structure of Conditional Statements:
96
12) Custom Functions: They system must provide a mechanism to define custom functions that
can be used in the data evaluation statements.
97
13) System Data: The system shall provide a mechanism to define which facts may be used the
following data in the system for use in the left operand of the condition:
14)
In Coeus 4.4 YNQ questions are still included, but have been deprecated.
Design Note: 1) when adding questions from the questionnaire, only the ID of the question is
displayed in the condition making it difficult to see what the condition is testing. 2) There is no
type checking in the interface for valid types for the left operand
98
i)
99
ii) Questionnaire Questions: The answers give to a particular question from
particular questionnaire
100
iii) Functions: Custom, user defined, functions that can accept arguments
101
System Data: Pre-specified columnar data items from the data store
b) Operators: The system must provide the following operators for use in building a
logical expression depending on the type of data
102
i)
System Columnar Data: equal to, not equal to, greater than or equal to, less than or
equal to
ii)
103
c)
Natural Language Expression: The comparison and logical statements expressed in
natural language (in English).
104
15)
105
16) Agenda: The system shall provide a mechanism for ordering and conditionally executing
rules called an Agenda.
Not In Coeus
From Kuali Student
In Coeus, this is handled by the“Meta Rule”
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 21 of 38
Trace
#
Requirements
106
a)
107
b) Agenda Operations: The system shall provide the following procedures for operating
on an agenda: Create New, Modify, Delete, Activate/Inactivate (see Table 10 Entity
Operations for a complete list).
108
c)
Agenda Attribute: An agenda shall include the following data attributes: Name,
Description, Event, Condition (see Table Table 11 Entity Data for a complete list)
Events are associated with agenda and when an event occurs it causes any agenda
associated with it to be evaluated.
109
(1) Multiple Event Triggers: An agenda may be associated with one or more
events (see events defined above), such that when the event occurs the rules in
the agenda are evaluated (conditions evaluated, action executed if required)
according the agenda’s rule execution logic.
110
(2) One Agenda Per Event: The system shall allow one, and only one, agenda to
be associated with an event.
111
112
Scope
ii)
d) Sub Agenda(s): The system shall allow one or more sub-agenda(s) to be specified
instead of a rule in the agenda’s rule execution logic.
Not in Coeus
Are we eliminating this for version 1? Can we just allow the naming of a branch in
113
e)
Agenda Execution Logic: They system shall provide a mechanism for defining the
order and conditional execution of rules as follows:
114
i)
115
ii) “Always” Operator: The first rule added to an agenda is always executed and shall
be prefixed with the agenda action “Always.”
116
iii) Ordered, Unconditional Execution “Next” Operator: When a rule is prefixed
with the Next action, the rule is run without consideration for the Boolean value
returned by the evaluation of the condition in the most recently executed rule.
117
iv) “If” Operators: An agenda shall provide for conditional execution of rules by
providing the conditional operations “If True” and “If False” that evaluate the
result returned from the condition in the rule that executed immediately previous.
Order of Execution: Rules shall be executed in the order presented in the agenda.
118
(1) “If True Evaluate <Rule>” operation: When a rule is added to the agenda
prefixed with the “If True” action, the rule is run only if the result of the
condition in rule executed immediately prior is the Boolean value “True”
119
(2) “If False Evaluate <Rule>” operation: When a rule is added to the agenda
prefixed with the “If False” action, the rule is run only if the result of the
condition from the rule executed immediately prior is the Boolean value
“False”
120
(3) “If True” and “If False” are mutually exclusive: If both “If True” and “If
False” actions are specified the logic shall execute only one or the other and
not both.
121
(4) “Branching Behavior”
122
f)
123
g) Agenda Authoring Behavior and Constraints: When adding rules to an agenda the
following constraints apply:
124
i)
First Rule: The first rule inserted in the agenda must have the execution action of
always.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 22 of 38
Trace
#
Requirements
125
ii) Second Rule Inserted: The second rule may be prefixed by anyone of the standard
execution actions: Next, If True, If False
126
iii) If operation: After an If operation is added, so that the execution is branched,
rules may only be added below the if operation. The second rule must be added
127
iv) When the Second Rule is an If True then the following can be added:
128
(1) An If False at the same level
129
(2) c
130
v) Any Execution Action Can Follow a Next: The execution action Next can be
followed by any other action including another Next.
131
vi) Next Action: Can be added at any time beneath an
132
133
h) Execution Logging: The system shall optionally record the details of how an agenda
was executed, as follows:
i)
Scope
Not In Coeus
Required by KS
Record Rule Decision: The system
Example: A policy may exist at an institution that states: “All Key Personnel on a proposal must file a Conflict of
Interest Report.” It should The implementation of this policy in the system implements requires, first, an answer to the
question: Is the person a member of the Key Personnel list on the proposal? Second, it requires enforcement of an
action “must file a Conflict of Interest (COI) report.” The action is named “Notify and Require a COI Report”
implemented in the system as a set of flags in the Proposal and COI system that notify the person until they file a
report and flag proposals that do not have a completed report.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 23 of 38
Agenda: Rule Execution Logic and Authoring Constraints
Level 5
Level 4
Level 3
Level 2
Level 1
1. An [Always] execution operation must be first.
2. Multiple [NEXT] operations can be inserted at
any level until a branch is encountered.
(1) [Always] Rule the first
3. During authoring, rules can only be added
under the current, highest level. For instance,
once 4.1 is added, you can only add rules at Level
3 (4.1.x) and not after (4), that is inserting Rule
(5) is not allowed.
(3) [NEXT] Another Rule
(2) [NEXT] Rule
(4) [NEXT] Rule X ...
(4.1) [IF (4) Rule X = TRUE] My True Branch Rule
(4.1.1) [NEXT] Another Rule
4. During execution, when a branch is followed, all
other branches are ignored and never followed
(4.2) [IF (4) Rule X = FALSE] My False Branch Rule
(4.2.1) [IF (4.2)My False Branch Rule = TRUE] Branch Again Please Rule
(4.2.1.1) [NEXT] Yet Another Rule
(4.2.1) [IF 4.2- My False Branch Rule = FALSE] Another True Branch Rule
(5) [NEXT]
5.1. Entity Operations
Table 10 Entity Operations
#
Entity
Action
Entity
Permission
1
Context
Create New
Context
Create New
2
Save
3
Modify
4
Delete
5
6
Rule
7
Create New
Modify
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
The system shall allow the user to create
a new business rule.
Page 24 of 38
Action
Entity
8
Delete
The system shall allow A Rule Author to
modify the descriptive attributes of a
rule.
9
Save
10
Copy
11
Inactivate
An action that
15
Create New
Term
16
Edit
17
Copy
18
Delete
19
Inactivate
#
Entity
Permission
12
13
14
Term
20
21
Proposition
22
Create New
23
Edit
24
Modify
25
Copy
26
Inactivate
Proposition
27
28
Create New
They system shall provide an operation
that creates a new Action
29
Edit
The system shall provide operation that
allows and existing Action to be
modified.
30
Copy
An operation that duplicates the
action.
(Add design requirement for how
copies this will
31
Delete
Action
32
33
Event
(none)
34
Agenda
Create New
35
Modify
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 25 of 38
#
Entity
Action
36
Delete
37
Inactivate/Activate
Entity
Permission
5.2. System Messages
Operator
Message
Delete
Delete Confirmation
5.3. Logical Operators
Operator
Meaning
ALL
TRUE if all of a set of comparisons are TRUE.
AND
TRUE if both Boolean expressions are TRUE.
ANY
TRUE if any one of a set of comparisons are TRUE.
BETWEEN
TRUE if the operand is within a range.
EXISTS
TRUE if a subquery contains any rows.
IN
TRUE if the operand is equal to one of a list of expressions.
LIKE
TRUE if the operand matches a pattern.
NOT
Reverses the value of any other Boolean operator.
OR
TRUE if either Boolean expression is TRUE.
SOME
TRUE if some of a set of comparisons are TRUE.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 26 of 38
5.4. Comparison Operators
Operator
Meaning
= (Equals)
Equal to
> (Greater Than)
Greater than
< (Less Than)
Less than
>= (Greater Than or Equal To)
Greater than or equal to
<= (Less Than or Equal To)
Less than or equal to
<> (Not Equal To)
Not equal to
!= (Not Equal To)
Not equal to (not ISO standard)
!< (Not Less Than)
Not less than (not ISO standard)
!> (Not Greater Than)
Not greater than (not ISO standard)
6.
Data
Table 11 Entity Data
#
Entity
Name
Description
Scope
38
39
The logical set of all information
needed by the rules and agenda.
Context
40
Name
41
Description
42
Context Criteria
A list of criteria that define the
context.
1
List of Terms
A list containing one or more terms
valid for creating propositions.
2
List of Actions
A list containing one or more actions
that are valid for creating rules.
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Context
Create New
Page 27 of 38
Name
Description
3
List of Custom Functions
A list of pre-defined functions
(created by the application developer)
for use in creating the rule
proposition.
4
List of Rules
The list of rules created for use in the
rules.
5
List of Agenda
The list of agenda that that have been
created for use in the context.
6
Version (?)
#
Entity
Scope
7
8
A construct that is used to make a
decision and run an action of the
decision is positive.
Rule
9
Name
A text value to identify the rule.
10
Description
A text value to provide des
11
List of Actions
A list containing one or more actions
that will be executed if this rule
returns True.
12
Context
The context where this rule is a
member, to which it applies and is
vais a member.
13
Condition
One or more propositions created to
evaluate the data in the context.
14
Version (?)
Not in Coeus
15
16
An item for information used in
creating propostions.
Term
17
Name
Term
18
Description
A text value for providing additional
information about a term.
19
Data Type
The type of data the Term references,
for example: text, integer, decimal
number, currency.
20
Valid Value List
When applicable the system shall
allow a user to specify an existing list
of values to be used for selecting a
valid value for this term when
creating a proposition.
21
List of Contexts
The list of contexts where this term is
valid.
22
Version (?)
23
24
Term Group
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Allows a logical set of terms to be
grouped and displayed together in the
user interface.
Page 28 of 38
#
Entity
Name
25
Name
26
List of Terms
27
Description
Scope
A comparison statement consisting of
two operands that are compared using
a default set of operators.
Proposition
28
Left-Side Operand
29
Right-Side Operand
30
Comparison Operator
31
Term Group
32
Logical Operator
33
34
A way to name larger expression
consisting of one or more
propositions linked by logical
operators.
Proposition Group
35
Name
A name that identifies a proposition
group.
36
37
A procedure is associated with a Rule
and is executed when that Rule
returns “True”
Action
38
Name
A text value that identifies the name
of the action
39
Description
A text value that provides and
extended area for describing the
40
List of Action Parameters
A list of parameters to get things
done
41
42
Defined information that may be
passed to an action when a rule
executes.
Action Parameters
43
Name
A mandatory text value to identify
the Action Parameter.
44
Description
An optional text value for providing
additional descriptive information
about the parameter
45
Data Type
A mandatory value that specifies the
type of data for this parameter.
46
Default Value
An optional value that will be passed
if no specific value is provided at run
time.
47
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 29 of 38
#
Entity
48
Event
Name
Description
Scope
(or Event Trigger) An identified step
in the procedure that is used to
initiate additional steps in the
procedure.
49
Name
50
Description
51
Context Criteria
52
53
54
Agenda
55
Name
Text value to identify rule.
56
Description
Text value for providing extensive
descriptive information
57
Context
The name of the context that the
agenda is associated with.
58
Event List
59
Active Date
60
Inactive Date
61
Rule
0 or more events can will cause this
agenda to be evaluated
62
63
6.1. Grouping and Sort Order
Group in following order:
Group Name
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Sort Order
Page 30 of 38
7.
User Interface Design
7.1. Coeus User Interface
7.2. Design Requirements
7.3. User Interface Mock-up
8.
User Documentation Notes
#
ID
Requirement
1
1) Rule Evaluation and Action Execution: To avoid having to deal with the situation where a
rules’ action(s) might update the fact base thus affecting rules evaluated after it, there is it is
recommended that the decision is returned from all rules in the agenda and then the actions
run in the appropriate order.
User documentation should include an explanation of this behavior.
2
2)
3
a)
4
b)
5
c)
9.
Differences From Coeus
10. Design and Implementation Notes
#
ID
Requirement
6
3) Rule Evaluation and Action Execution: To avoid having to deal with the situation where a
rules’ action(s) might update the fact base thus affecting rules evaluated after it, there is it is
recommended that the decision is returned from all rules in the agenda and then the actions
run in the appropriate order.
User documentation should include an explanation of this behavior.
7
4)
8
a)
9
b)
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 31 of 38
#
ID
Requirement
10
c)


In Agenda, display the action that goes with the rule? Or just rely on the user to name it carefully.
10.1.
10.2.
Constraints and Issues
Other Technical
11. Appendix
11.1.
Document Change Log
Important changes and additions since the last published version are noted in the list below and in the document
by an orange star.
11.1.1.
[Date]
Description of Change
11.2.
Issues List
11.2.1.
Open/In Progress
Issue ID:
Status:
Reporter:
Open/Closed/In Progress
Jira #:
Create Date:
Subject/Title:
Description:
Owner(s):
Next Step(s):
Due:
Date:
Close Date:
Resolution:
Issue ID:
Status:
Reporter:
Open/Closed/In Progress
Jira #:
Create Date:
Subject/Title:
Description:
Owner(s):
Next Step(s):
Due:
Date:
Close Date:
Resolution:
Issue ID:
CustomPropositions
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Reporter:
Jira #:
Page 32 of 38
Status:
Subject/Title:
Description:
Open/Closed/In Progress
Create Date:
2011-02-04 Fri
Do we need a distinction between Custom Propositions and Custom Terms?
Do we want to make a distinction in Custom functions between those that return a Boolean (call them Custom
Propositions?) and everything else (call them Custome Terms?)? The main effect of this would be how they are treated
in the interface.
Owner(s):
Next Step(s):
Larry
Will check with Kamal and get back
Due:
Date:
Close Date:
Resolution:
Issue ID:
Status:
Subject/Title:
Description:
RuleTypeName
Open/Closed/In Progress
Reporter:
Jira #:
Create Date:
Business Rule Type in KRMS?
In Coeus, a Type of business rule is defined by what we are calling the “Action.” This is presumably because rules
have different functionality based on their type. Since our Rule/Action definition is more generic, do we need a type?
Discussion:
This was discussed at the F2F but not completely decided.
Owner(s):
Next Step(s):
Kenton
Examine as the requirements develop and evaluate if it is still warranted.
Due:
Date:
Close Date:
Resolution:
Issue ID:
RuleManagementVersion
Reporter:
Status:
Open/Closed/In Progress
Create Date:
Subject/Title:
Description:
Jira #:
Versioning of Rules - Discussion
Coeus does not version rules, but this has been suggested on the KRMS side? If we are going to version rules, what
functionality is contemplated and if this is necessary, is necessary for the first release of KRMS?
Owner(s):
Next Step(s):
Kenton
Explore Versioning in the requirements to see what the scope of this would look
like.
Due:
Date:
Close Date:
Resolution:
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 33 of 38
11.2.2.
Resolved
Issue ID:
Status:
Subject/Title:
Description:
Owner(s):
Resolution:
Issue ID:
Status:
Subject/Title:
Description:
ExecutionFeedback
Open/Closed/In Progress
Reporter:
Create Date:
Kenton
Jira #:
Jan 26 20011
Do we need excecution feedback and logging?
Two motivations for this
1) Providing feedback to the user so they can see why a rule decision was made
2) Student was thinking of using rules for “best fit.” kind of analysis” by providing information that could be
evaluated as part of the ongoing rule evaluation.
Next Step(s):
Due:
Date:
Close Date:
2011-02-07 Mon: Agreed that we would only address 1) above. Item 2) would have to addressed in custom functions
used as terms or propositions.
SubAccountCase
Open/Closed/In Progress
Reporter:
Create Date:
Kenton
Jira #:
Jan 26 20011
Routing document to correct person’s for large numbers of sub-accounts
A solution for the following case was raised by Eric Westfall: at IU in KFS, users have a simple mapping to route based
on sub-account. There are nearly 3000 sub-accounts. If a user wanted to create rules to identify the person and then
route to them, how would they do that. If you had to create 3000 rules and then add all 3000 to an agenda it seems a bit
heavy. What are the options for this? At Indiana they create and edit large numbers of these rules.
Eric: Is this a use case for dynamic agenda?
Can this solved by custom function?
Owner(s):
Next Step(s):
Due:
Date:
Kenton
Resolution:
Issue ID:
Status:
Subject/Title:
Description:
Close Date:
2011-02-07 Mon: Recommend that this be handled as a custom function.
ConditionReuse
Open/Closed/In Progress
Reporter:
Jira #:
Create Date:
Should there be functionality to allow conditions to be reused in some way? (Not In Coeus)?
Should we allow conditions to be re-used in some way?
1) For rules that have a complex set of propositions and expressions, it may be useful to save some portion of it as a
condition and then use the results of that expression in other conditions. In this
2) Where multiple rules depend on the same condition, it
Owner(s):
Next Step(s):
Kenton
Add the copy requirements to the specification
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Due: Date:
Close Date:
Page 34 of 38
Resolution:
Issue ID:
Status:
Subject/Title:
Description:
Jan 7: Agreed that:

There will be no referential reuse. In other words, a condition cannot be saved with a unique ID that would allow
more than one rule to use that condition. This would create a dependency that would be hard to manage on a large
scale.

Providing the ability to copy a rule and other items will be the extent of the reuse.
FactsChangeDuringRuleEval
Open/Closed/In Progress
Reporter:
Create Date:
What happens if an action updates the facts in the context in which the rules are running?
Should the rule complete against the outdate information?
If not and the facts are cached how do we detect an out of date cache?
Do we need to track that these changes have occurred?
Next Step(s):
Kenton
Update design requirements to reflect resolution
Issue ID:
Status:
Subject/Title:
Description:
2011-02-04 Fri Fri Fri
Fri
What to do about Actions that may change facts in the rule base?
Owner(s):
Resolution:
Jira #:
Due:
Date:
Close Date:
As a matter of design it was settled that all the conditions in the rules will be evaluated and then based on the
decision(s), a list of actions would be created and executed in the order in which they were determined. This would
avoid unpredictable behavior from occurring if the data changing actions were executed while the rule were being
evaluated
ConditionActions
Open/Closed/In Progress
Reporter:
Create Date:
Kenton
Jira #:
Jan 4, 2011
Can a condition have actions?
In Coeus, a Routing Rule can have multiple conditions (as can all rules). Each condition can have the action “use Map”
associated with it. Each condition is evaluated within a conditional IF <condition> ELSEIF statement. The net result
that is that the Routing Rule returns just one Routing Map (workflow definition). This same functionality is true for
Question type rules which essentially execute the action in
Two points:
1) For KRMS, we have defined the Rule as the entity that has an action associated with it. Do we need/want
conditions being able to execute actions as well? Another possible option is allow rules to include other rules.
2)
Owner(s):
The Coeus Routing Rules are essentially have Agenda type (rule execution logic) in the Rule. This puts this logic
in two places.
Next Step(s):
Discuss at Jan 7 Meeting
Resolution:
Due:
Date:
Close Date:
Recommendation:
a) All rule execution logic resides in the Agenda and will be removed from the rule (where it is in Coeus)
b) Agendas shall be allowed to include other agenda (sub-agendas).
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 35 of 38
Issue ID:
Status:
Subject/Title:
Description:
Owner(s):
ActiveInactive
Reporter:
Open/Closed/In Progress
Create Date:
Jira #:
2011-01-09 Sun
Acitivating and Inactivating Rules
There is no way to inactivate a rule in Coeus. In one sense, a rule is not actively used unless it is added to an agenda.
Do we need a way to “archive” or “inactivate” rule. If we are versioning rules how does this impact this requirement?
Also, that data model currently contains active/inactive dating.
Next Step(s):
Add Activate, Inactivate functional requirement to functional specification
Resolution:
11.3.
Due:
Date:
Close Date:
2011-02-08: Rice provides this out of the box.
Document Parts
11.3.1.
Standard Document Table
Use following table to ensure you have the formatting and styles for tables in this document. Using Word’s
create table feature will not setup the standard formatting as in the following table.
To Use: Copy and paste into your document then add, remove and adjust columns and rows as necessary.
Table Heading
11.3.2.
Use Case Template
When you copy this table, the numbering in the # column may change. To reset it so it starts at “1”, rightclick the first numb and select “Restart at 1” from the menu (Windows, Word 2007).
Table 12 Use Case Sample
52
Use Case ID:
53
Use Case Name
54
Priority:
55
Actor(s):
56
Description:
57
Precondition(s):
PR1
Normal Course:
N
<Normal Course Name>
10)
11)
A1
<Alternate Course Name>
12)
13)
58
Alternative Course(s):
59
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 36 of 38
A2
<Alternate Course Name>
14)
15)
A3
<Alternate Course Name>
16)
17)
60
61
62
Exceptions:
63
Post-conditions:
64
E1
PO1
PO2
65
Special Requirements:
66
Assumptions:
67
Notes and Issues:
11.3.3.
SR1
Requirements Table
When you copy this table, the numbering in the # column may change. To reset it so it starts at “1”, rightclick the first numb and select “Restart at 1” from the menu (Windows, Word 2007).
Table 13 Requirements List Template
#
ID
Requirement
1
1)
2
a)
3
b)
4
c)
5
2)
6
a)
7
b)
8
c)
11.3.4.
Issue Template
Issue ID:
Status:
Reporter:
Open/Closed/In Progress
Jira #:
Create Date:
Subject/Title:
Description:
Owner(s):
Next Step(s):
Due:
Date:
Close Date:
Resolution:
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 37 of 38
11.3.5.
Callouts
The following callouts can be used to highlight important points for the user. The layout for each callout is
inside a Word text box. Text boxess will not display in Normal or Draft View - you must be in Print Layout
view to see them.
To Use: Click on a text box below, copy and paste it into your document, then type a short heading in the
bold text and an explanatory text below.
<Note Heading>
A general note
<Process Note>
A process explanation
<A warning!>
A caution and explanation
<A Question?>
An answer
Kuali Rice Rules Management System
Last Save: 7/29/2017 1:53:00 AM
Page 38 of 38