Building a New Feature

Submitting a Feature Request
Please visit How to Request a New Feature for an overview of submitting a feature request.

Writing the Functional Specification

The steps below will outline additional details to include to expand your feature request into full functional specification.

You will then add these details into a functional specification template that you can then submit for discussion to the mifos-users mailing list.

The following can be copied over from your initial feature request.

Feature Request Name:

Name of feature. Describe the feature in 5 - 7 words. For example: "Declining balance interest calculation" or "Displaying previously saved attendance values in Bulk-Entry".

Status:

Once the feature is posted to Development Project Pages, it is good to update this field so that developers know how current the requirements are.

Contact details of person who last updated document:

Again, this field is required once you post it to Mifos.org.

Feature Summary:

Brief 2-3 sentences summarizing the feature. Some of this may be explained in the background section. An example for "declining balance" would be: This feature would allow MFIs to create loan repayment schedules with equal installments and interest based on the declining balance formula.

Background:

The section provides information describing the issue for folks who might not be familiar with Microfinance methodology or how Mifos handles the current use case. For example, background information for the "Declining Balance" feature would explain that Mifos currently only supports flat interest calculation, would explain what flat interest calculation is (since this is an unfarmiliar concept for people in the US), and explain how declining balance works. Background information for the "Displaying attendance in Bulk Entry" would give a brief summary of the bulk-entry feature and explain that when a user returns to the same bulk-entry screen, previously saved attedance values aren't displayed.

Business Need for feature: Optional

Brief 2-3 sentences explaining why this feature is important/necessary. This is your opportunity to convince a volunteer how important your feature request is and make him/her excited to work on it! An example for "Displaying attendance values in bulk-entry" would be: For many MFIs, there will be the scenario of a user needing to return to the bulk-entry screen to finish inputting all transactions that were collected at the center meeting. We need the previously entered attendance data to be displayed in order to reduce data errors.

FEATURE DESCRIPTION

In this section provide as much detail as possible about the business processes or products and services the new feature would support as well as step-by-step instructions for how it would be used. When writing the step-by-step instructions you should consider all the different scenarios a user might encounter in working with the new feature. Typically these scenarios are broken down into two types.

The first is called the "Primary Flow." This is the most common way a user would interact with the feature. The "Primary Flow" assumes the user encounters no errors and completes the task they were working on. Other scenarios are called "Alternate Flows." These explain how errors are handled, what happens if the user decides to click on the cancel button, etc. Refer to the Feature Request topic in the Mifos Wiki for more details on writing the Primary Flow and Alternate Flow(s). If at all possible it is also useful to provide mock ups of how the user interface for the new feature would look. You can attach images of the UI when you enter extra information in the next step.

In this section, you walk through a detailed step-by-step process of how users interact with the feature or enhancement. The Primary Flow explains the most common way a user would interact with the feature. This typically means that the user encounters no errors and completes the task they were doing. After that, you also need to specify Alternate Flows. These typically explain how errors are handled or how what happens if the user decides to click the cancel button, etc.

Primary Flow:

Walk through step by step or page by page (if appropriate) how a user will access the feature and interact with the feature. Be as specific as possible, including details around:

• WHERE FEATURE IS LOCATED INSIDE OF MIFOS AND HOW IS IT ACCESSED: _ Would the enhancement require a new page or is it embedded in an existing page? _ If feature creates new pages: How do users access the page? If via a link, what places does the link appear in the product (include specific pages and location within the page)? What should the link be called? * If it is embedded, which pages is it embedded in - and where on the page should it appear?
• IF FEATURE IS "ATTACHED" TO A MIFOS ENTITY THAT HAS STATES (ie, centers, groups, clients, accounts, etc): _ Does the feature require any logic around the state-flow diagram? (ie, does the feature only (ie, does the feature only work on clients/accounts in active state? What about on hold states? Does the display or user interaction with the feature change based on the entity state? If yes, how?) _ Does the feature itself require creating a state flow diagram (ie, creating an insurance product offering)? If so, what are the states? _ For each page/step of accessing the feature, explain exactly and in as much detail as possible as what the user should see on the page: _ Are the pages part of a pipeline (ie, "Create a new client" or "Create a loan account") where the left nav disappears? If the page is not a pipeline and is located inside the navigation, does it display a breadcrumb trail across the top of the page? If so, what should the breadcrumb say? * What is the title of the page (which appears in orange text). What subheads (in bolded black text) appear on the page?
• If data is collected, specify exactly what data is collected. For example, if the feature you're defining is the ability to define an insurance product-specify exactly all data fields and parameters to create an insurance product. For each data field, specify: _ Name of data field _ Whether/not display of field can be configured by the MFI in the configuration screen _ Whether/not the field optional, mandatory and/or whether this can be configurable by the MFI in the configuration screens _ Data type for each field (text box, checkbox, single select radio button, multi-select text boxes) * Defaults values or are fields left blank
• Required validations (ie, making sure a date field is a real date; making sure a phone number is a valid input, defining the acceptable range for a numeric input, are negative numbers accepted, etc) and specific error messages to be displayed (ie, "invalid date" or "Invalid number. Please enter a number less than 1,000"). _ What actions are allowed from the page (ie, submit and cancel). _ (If feature involves submitting data) upon submission, is a confirmation page displayed or is user returned to another page? What is displayed on the confirmation page?
• If Mifos is doing a calculation on data: How does the system's rounding rules impact the feature? What is the exact algorithm to use.

Alternate Flows:

Examples of alternate flows may include editing, deleting, error cases, etc. Each of these separate flows should have their own "alternate flow" section.

• If there is a "cancel" button, what page is the user taken to when clicking "cancel"?
• What is the edit flow for the feature, if any?
• What is the delete flow for the feature, if any?

UI Screens:

If at all possible, include UI mock-ups of the feature. A picture is worth a thousand words.

Additional information:

• Should access to this feature be restricted by permissions? Do new permissions need to be added into the system?
• Does the feature require a change log to track changes? If it is a new field to an existing entity that has a change log (ie, clients/groups/accounts, etc)-does the change log need to capture edits to the enhancement?
  If you're an MFI, I recommend that you generate a document describing the feature and circulate it internally prior to posting it. Once you have agreement on how the feature should work, submit the feature to the mifos-functional mailing list. Once you've collected feedback from the mailing-list, you can post the feature here on Mifos.org on the Development Project Pages wiki page. If you have any questions-- don't hesitate to ask!