PURPOSE
To explain how CS Lucas handle and prioritize feature request from its customers.
WHY IS THIS IMPORTANT?
We depend on feature requests from our clients to enhance CS Lucas functionality and make our solution more user friendly. Equally important is our desire to make these new features available in existing modules at no additional cost. Given the large number of requests we received and the reality of limited resources and time, we must categorize requests and then prioritize them in a systematic and transparent manner. This document explains how we currently do this and our rationale.
GENERAL GUIDELINES
A feature request from client will be queued according to its priority compared other requests. This queue is reviewed monthly.
All things being equal, a feature will receive higher priority over others when (in order of importance)
– it enhances system security or visibility of security
– it adversely affects CS Lucas ability to render ongoing support
– it coincides with CS Lucas’ development roadmap
– more clients have made similar requests
– it will result in greater efficiency and productivity for users
– its code change is closely related to another feature that is higher up in a priority queue
All things being equal, a feature will be assigned a lower priority over others if
– existing feature can be used to achieve the same results.
– effect of change is to perform a one-off edit or amendment data set up which is not complex or risky to perform.
OUT-OF-SCOPE ITEM
CS Lucas may at its discretion determine that a feature request is out of scope. Out of scope changes will not be place in an enhancement queue.
As a general guideline, an out-of-scope feature request arises when the request
– is specific to customer’s bespoke needs and would not be relevant for other clients. (Such request can be dealt with through the CS Lucas Extension Store. Please contact CS Lucas for more information.)
– not generally within the purview of corporate treasury management system.
– generally is available within the purview of another enterprise system (e.g. ERP, HRM. CRM etc…) and that most client would normally use the feature in such other systems to avoid integration and duplication efforts.
CLASSIFICATION PROCEDURE
User will submit their request via the Qliko Issue Tracking System.
An issue will be classified as a feature request if it is not a clarification of usage or a system bug (see FAQ below on bugs). These matters will be dealt with under our standard SLA which is resolution within 48 hours.
For feature request, we may sometimes ask the client for more information regarding usage so that we may classify the item on a queue; high or normal priority. Once we have made the classification, we will inform of the corresponding ID that we have created in the queue. This is to protect the confidentiality of a client request and to centralize all feature requests into a common queue for prioritization.
The request issue initiated by the client will then be closed for housekeeping purposes. Client may continue to track these by filtering for closed items that are feature requests or enhancements.
ESTIMATED TURNAROUND TIME
IMPORTANT: Feature request will be undertaken on a best effort basis.
Feature request in our queue will be classified as either High or Normal priority. We have an informal target to turnaround a High priority request within 12 weeks.
FREQUENTLY ASKED QUESTIONS
FAQ01. What is the difference between a bug and a feature request?
Any feature that we develop will be based on a written and defined specification. To determine whether an issue is a bug or a feature request, we adopt an objective assessment with reference to specification.
If a feature is not working as documented in the specifications, this will be classified as a bug. This is deficiency and shall be resolved within 48 hours.
If a feature is not document in the original specification, it is a feature request.
FAQ02. Will new feature fully comply with the documentation submitted by the client making the change?
We will strive to ensure that the new feature will meet or exceed what a client has requested for. There are certain limitations as we do this:
– We may solicit feedback from other clients prior to undertaking changes to make sure the new feature has the most general appeal. This may add or remove characteristics requested for by a client.
– We may be limited by technology and resources to meet all the clients’ requests. In this case, we will reduce feature scope and not all characteristics of the feature request may be available.
RELATED INFORMATION
CHANGE HISTORY
0 Comments