KAW SAMPLE Feature Overview--License Control and Compliance v1

Kathleen Walsh
SAMPLE OVERVIEW DOCUMENT
KAW SAMPLE Feature Overview--License Control and Compliance v1.docx Page 1 of 12
Last Modified: 2-Aug-15 7:17 PM (Version: 164)
Company, LLC
Feature Overview:
License Control & Compliance
(trackid)
Review Version 1
(Last Modified: 2-Aug-15 7:17 PM)
(Version: 159)
Revision History
Date Version Author Comments
150801 1 Kathleen First review

Kathleen Walsh
Table of Contents
Revision History ......................................................................................................................................................................1
Contacts ..................................................................................................................................................................................3
Review Notes ..........................................................................................................................................................................3
Outstanding Issues (2).............................................................................................................................................................3
Feature Details........................................................................................................................................................................3
Summary.............................................................................................................................................................................3
Product Licensing................................................................................................................................................................3
License Types ..................................................................................................................................................................4
License Key..........................................................................................................................................................................4
Key Generator.................................................................................................................................................................4
Changing Licenses ...........................................................................................................................................................4
System Startup....................................................................................................................................................................5
Login....................................................................................................................................................................................5
Exit Application / Logout.....................................................................................................................................................5
Licensing Email Notifications ..............................................................................................................................................5
User Profiles and Management ..........................................................................................................................................6
New User Properties.......................................................................................................................................................6
Other Inactive User Checks.............................................................................................................................................6
Licensing Checks..............................................................................................................................................................6
Inactive Flag and Role Assignments................................................................................................................................7
Impacted Objects................................................................................................................................................................7
Object Properties That Must be Current Active Users ...................................................................................................7
Subscriptions and Email Notifications ................................................................................................................................8
Administrator License Page ................................................................................................................................................8
Analytics..............................................................................................................................................................................9
Installation and Upgrade...................................................................................................................................................10
Upgrade for This Release ..............................................................................................................................................10
Future Upgrades ...........................................................................................................................................................10
Appendix B: Future Features ................................................................................................................................................10
Appendix: Conventions.........................................................................................................................................................10

Kathleen Walsh
Contacts
Position/Responsibility Person
Business Analyst Kathleen Walsh
Product Manager John Smith
Review Notes
• Track Changes is used to indicate changes from previous review version.
• Screen shots in this document may only be visible in Page view mode, not Normal/Draft mode.
Outstanding Issues (2)
1. Upgrade if Named users exceeds Licensed value (see TBD under Upgrade).
2. Prevent direct DB updates which would violate license allowances (see TBD under User Profiles and
Management).
Feature Details
Company needs to audit customers and ensure they are in compliance with their licenses. To make this
easier, on both the Customers and Company, some features need to be added to the product.
SUMMARY
1. Changes to the User Profile allow better auditing of license types and Named vs. Concurrent licenses.
a. Users can now be Active or Inactive allowing customers to ‘turn off users’ without deleting them
completely so as not to consume Named seat licenses (also has other benefits for customers).
See the following for more details:
User Profiles and Management
Other Impacted Objects
Object Properties that must be Active Users
Subscription and Email Notifications
2. Enforcement of Named and Concurrent licenses through User Management and Login.
3. Real-time statistics on current system use.
4. Analytics on historical use of system and licenses.
5. Some related bugs and minor enhancement requests will also be dealt with as part of this feature; list
is in Track as children of Feature.
PRODUCT LICENSING
Product is licensed as follows:
• Administrator is not license-controlled
• Employee
◊ Concurrent

Kathleen Walsh
◊ Named
• Customer
◊ Concurrent
License Types
• Named Seats licensing controls the number of Users with a Role of the application’s type that can be
created. It also limits each user to logging in only once.
• Concurrent license controls the number of user sessions that can exist at the same time.
LICENSE KEY
In order to be able to decide if the system is in license-compliance, Product needs to store the customer's
license information (encrypted).
DESIGN NOTE: The design of licensing should account for possible expansion and change in the future. In
particular, we may add or change license types. My best guess as to a design element is the ability to re-
purpose parts of the key or include parts that are not currently used but are there for future use (e.g.,
extra characters or ‘bytes’).
• The key shall be unique for each customer and tied to a specific installation of the software/database.
For example, on installation, setup shall assign the system an ID that is used to generate the key.
• The key shall include the product(s) licensed and for each, the type and number of licenses.
Application License Type Number
Employee Concurrent Number of allowed users
Employee Named Number of allowed users
Customer Concurrent Number of allowed users
• The key shall be encrypted.
• The license key shall include an “apply by” date; if not applied to the system by that date, it is invalid
and a new key must be obtained.
Key Generator
• A single license generator tool shall be provided for internal use so that Services/Support can provide
all the license codes for customers.
◊ This tool shall be a self-contained executable that requires only the operating system (no other
pre-requisites).
• For security purposes, the License Generator shall be valid for 6 months. After 6 months, the
application will display an error that it has expired.
Important: This means Engineering will need to issue a new generator every 6 months; support must
have the new one before the old one expires.
Changing Licenses
• The license key may be changed at any time through Administrator. The system does not need to be
re-installed to increase or decrease available licenses.
• This function shall be available through the Administrator application and be controlled by a new
permission.

Kathleen Walsh
SYSTEM STARTUP
When system is started, the System shall verify there is a valid license key. If not, system shall log error
and email configured user. Administrator and command line utilities shall still function but the following
will not function:
◊ API
◊ Customer App
◊ Employee App
LOGIN
• For named licensing:
◊ Named users are allowed to log in multiple times from the same machine.
◊ If named licensing is in effect, when a user logs in, the system shall ensure they are not already
logged in on another machine.
◊ Once a user is successfully logged in, the System shall record the login date and time.
• For concurrent licensing:
◊ The system shall verify a license is available.
If a license is not available, the system shall display an error, log the issue, and send an email per
configuration. To, CC, BCC, Priority, Subject, and Message shall all be configurable.
◊ Once a user is successfully logged in:
∗ System shall record the login date and time.
∗ System shall decrement the number of available licenses.
EXIT APPLICATION / LOGOUT
If concurrent licensing is in use, when a user session ends, the system shall release all system resources
(including the license) held by the session(s).
A session may end when:
• User logs out.
• User exits application.
• Session times out.
LICENSING EMAIL NOTIFICATIONS
The system shall provide configuration and a session function that emails administrators when certain
license conditions occur.
1) New Configuration Manager settings for Licensing (new category):
a. Email addresses
b. Conditions under which email should be sent, such as:
i. concurrent users = max
ii. concurrent users = max – n
iii. concurrent users = max – n%

Kathleen Walsh
iv. named = max
v. named = max – n
vi. named = max – n%
2) System Startup: if license key is invalid, system sends email to configured users.
3) Login: if concurrent notification limit is reached or exceeded, system sends email to configured
users.
4) Save User: if named notification limit is reached or exceeded, system sends email to configured
users.
5) Daily: If at any time the number of searches per hour was exceeded, the system shall an email
with the details.
USER PROFILES AND MANAGEMENT
• These apply to all ways a User can be managed: Administrator, API, or transfer data.
New User Properties
• Active: Indicates if the user is Active or not.
◊ Inactive users are not allowed to login.
◊ Inactive users do not count against Named license limit.
• Last Login Date
The system shall store the user's last login date (optional; nulls allowed). (Note: This field will not be
filled in during upgrade. If a customer wishes to do this, they will need to create a custom utility to
pull the dates from the log files and populate the database themselves.)
• Customer License Type Concurrent or Named
If both Customer Named and Concurrent licenses are available (per license code), a new property of
the user shall be available for the Admin to assign one type to the User. Each user can be Named or
Concurrent, not both.
Other Inactive User Checks
• Inactive users are not allowed to be set for certain object properties. When an Inactive User is saved
the system shall verify that the user is not currently assigned to any of these. See Object Properties
That Must be Current Active Users for a list. (NOTE: This list is similar to checks when deleting a
user.)
Licensing Checks
If named licensing is in use, when a user is saved AND the user has at least one Role of Type = Employee:
• If this is a new Active user:
◊ System shall verify that an Employee Named license is available.
◊ If there is no available license, system displays error and lets admin edit User. (User can still be
saved as Inactive or with different Roles.)
• If the user was Inactive and is now Active, the System shall behave the same as above.
• If the user was Active and is now Inactive, the System shall reduce the number of Employee Named
licenses in use.
• If a user is deleted, the System shall reduce the number of Employee Named licenses in use.

Kathleen Walsh
• If all Roles of Type = Employee are removed from the User Profile, the System shall reduce the
number of Employee Named licenses in use.
Inactive Flag and Role Assignments
◊ TBA (Dev): we need a way to ensure that a customer does not make direct-db updates to change
users from inactive to active and by-pass licensing.
∗ One option is a stored procedure or utility that runs periodically to verify license; however, that
must also be tamper-proof. It cannot be tied only to system startup as our goal is to not have
them restart frequently.
∗ Is there some way to ‘code’ the record to know that it was updated by Product vs. direct-db
method? If the code is invalid, then the user is considered inactive.
∗ We have currently added a check in 2 places: Service start and User session creation upon login,
but are open to other (additional, instead of) suggestions.
∗ Other ideas?
IMPACTED OBJECTS
Several objects have properties that are required to be current system users.
• For a list of these objects and properties, please see Object Properties That Must be Current Active
Users.
• These conditions shall also be enforced for any method of updating the data: GUI, API, import/export,
and transfer data.
• For these object properties, the system shall not allow inactive users to be assigned. (Displayed lists
(excluding User Manager) shall not include any Inactive Users.)
• System shall check on Save/Submit of these objects that assigned users are valid and active. (These
objects save/submit functions currently have a check to make sure assigned users aren’t exist, we just
need to add “active” check.)
Object Properties That Must be Current Active Users
• These following object properties must be current, active system users:
◊ Customer Anonymous User Name
◊ Task Owner
◊ Groups
∗ Supervisor
∗ Owner
• Things that are not affected by user being made inactive:
◊ Analytics
◊ All objects:
∗ Creator
∗ Last Modified By
∗ Users in:
− History
− Notes

Kathleen Walsh
◊ Group Members
Not removing inactive users from groups allows for a user to be re-activated and the admin not to
have to go back and add them to the Groups.
This does mean it is possible for a Group to be assigned to something and all its users to be
inactive so no one can perform the function. We are not going to check or code for that scenario.
We will, however, include a warning in the documentation about it.
SUBSCRIPTIONS AND EMAIL NOTIFICATIONS
When a user is made inactive, their Subscriptions and Notification settings are not deleted; however,
emails are not sent to inactive users.
ADMINISTRATOR LICENSE PAGE
Access to this page shall be controlled by a new permission.
GUI: (to be updated with new desired fields)

Kathleen Walsh
• Displays License Key
◊ Allows it to be edited; access to this function shall be controlled by a new permission (separate
from the one required to access the page).
• Displays the number and type of licenses for each product
◊ Employee Named
∗ % Used
∗ Allowed
∗ Used
◊ Employee Concurrent
∗ Maximum in past <tbd time frame>
∗ Average over past <tbd time frame>
∗ Number of times users denied access in past <tbd time frame>
◊ Customer Concurrent
∗ Maximum Concurrent in past <tbd time frame>
∗ Average Concurrent over past <tbd time frame>
∗ Number of times users denied access in past <tbd time frame>
◊ Provides ability to view full list of users currently logged in
∗ Displays all the currently logged in users
∗ Provides filtering/searching
∗ Allows admin to kill session (useful if one has hung)
• Includes Email Notification Settings
◊ Send To, CC, and BCC fields
◊ Send conditions
∗ Concurrent users at maximum
∗ Concurrent users available below set number or percent of allowed
∗ Named users at maximum
∗ Named users available below set number or percent of allowed
ANALYTICS
• Quick Statistics
◊ % Named used
◊ Max % Employee concurrent used
◊ Max % customer concurrent used
◊ # Named users not logged in x months
• Track use of the system over time (line chart)
◊ X = months
◊ Y=
∗ Concurrent Customer users

Kathleen Walsh
∗ Employee sessions
INSTALLATION AND UPGRADE
Upgrade for This Release
• Existing users shall have the new properties set as follows:
◊ If user has at least one Employee role AND
∗ License Key allows Concurrent, License Type = Concurrent
∗ License Key does not allow Concurrent, License Type = Named
− TBD: Behavior for situation in which number of users exceeds allowed Named Licenses.
◊ Active = True
• New permissions shall be added.
Future Upgrades
• The license code does not need to be re-entered when the system is upgraded without changing
servers (e.g., applying a Service Pack or performing an in-place upgrade from one version to another).
Handling server changes and allowing multiple servers to exist at the same time will be a process call
and Product Management will work out with Services and Support how to handle the licensing of co-
existing systems.
Appendix A: Future Features
The following features are candidates for a future release. They are included here for information and to
ensure the design does not make implementing these later difficult.
• Cascade Replace/Delete considers Inactive Users
When a user is made inactive, they are not allowed to be used as certain things (e.g., Group Owner).
In the future, the system should allow the admin to 'cascade replace' the user if they are found to be
one of these.
• More flexible notification
◊ Other methods of notification (e.g., text message, IM)
Appendix: Conventions
• GUI Terminology
The GWT Style Guide contains more details; however, definitions also apply to non-GWT technology.
◊ Inline Page (or Page): An inline page is one that is in the framework of the main application
window.
◊ Non-Modal Screen (or Screen): A non-modal screen is separate from the main application window
page, but is still part of the application and is not opened in a new full browser or browser tab.
◊ Modal Dialog (or Dialog): A modal dialog is displayed on top of the current screen or page.
• GUI Elements (Labels, Fields and Functions):
All GUI Elements are not always included and enabled. The individual requirements indicate when a
specific element is include and enabled.
◊ Included: An element that is included is present on the screen.
∗ "Always included" means it is always present.

Kathleen Walsh
∗ "Included only if…" indicates conditions under which it is included. GUI tables may have
separate columns where the column itself is the condition (e.g., if the screen has different
modes (read-only; edit; manage)).
If the condition is not true, the element is not present.
◊ Enabled: A field that is enabled is available for the user to type into or select from; a function that
is enabled is available for the user to select. Labels are always read-only.
∗ "Always enabled": means the element is always enabled.
∗ "Enabled only if…" indicates the conditions under which the element is enabled. GUI tables may
have separate columns where the column itself is the condition (e.g., if the screen has different
modes (read-only; edit; manage)).
If a field or function is enabled only under certain conditions, it is disabled if those conditions
are not true.
∗ "Read-only": Used for fields that are present but always read-only (e.g., a screen label, create
date). In some cases, the values can be changed, but through a function, which is listed
separately with its own enabled/disabled conditions.
◊ In some cases, a field may be "blank"; this refers to the field value, not the field label. It is used in
cases where we want to include the label, but indicate that no value is assigned (for example, in
Product, a Object ID is not assigned until the document is saved, but we do not want to hide the
Object ID field itself—that is considered bad design for localization).
◊ How functions are implemented (buttons, links, menus) is part of GUI design and based on internal
and industry standards.
◊ Fields types (single-line text boxes, multi-line text boxes, radio buttons, DDL) are included in the
requirements.
• Formatting
◊ Angle brackets ( < > ) are used to indicate variables. The brackets and words inside the brackets
should be replaced with the appropriate variable value at runtime. For example:
Message: <property> cannot contain spaces
Example: Password cannot contain spaces.
◊ Italics: References to other documents and sections (or headings) are in italics.
◊ Strikeout: Struck out requirements or parts of requirements have been removed; the strikeout is
used to explicitly show that something that was implemented at one time needs to be removed.
Strikeout is used only for features and functionality that was implemented in a previous release or
sprint. It is not used during document reviews before implementation (track changes is used for
that purpose to indicate changes from one review version to another).
◊ Underline is used for:
∗ Requirement labels so they stand out in the text of the requirement.
∗ References to a specific requirement that include the label. For example: Functions per the
General Save requirement (KM-A1000) in the 1A-General and Shared PRD.
◊ Grey text enclosed in {} are notes for the document owner about similar requirements so when
changes are made they are made consistently.
• Highlighting
◊ The following highlight colors are used to indicate different types of requirements:
Color Purpose Reviewer Responsibility

Kathleen Walsh
Yellow New functionality for the release. Review and plan release based on these
requirements.
Light Blue Newly included or updated
requirements for existing
functionality.
Review and indicates any disagreement
about how functionality is described in
requirements vs. how you think it does or
should work.
No highlight Existing requirements; previously
included and reviewed.
None
◊ In addition, the following highlight colors may be used to indicate open questions or action items.
Color Purpose Reviewer Responsibility
Green Questions for reviewers to answer Answer!
Purple Author’s questions/to do list; goal is to NOT have
any of these when a document is posted for
review.
None
Grey Author’s notes for future changes, things to do
later (like enter bugs).
None

KAW SAMPLE Feature Overview--License Control and Compliance v1

Recommended

Recommended

More Related Content

Similar to KAW SAMPLE Feature Overview--License Control and Compliance v1

Similar to KAW SAMPLE Feature Overview--License Control and Compliance v1 (20)

KAW SAMPLE Feature Overview--License Control and Compliance v1