|
|
Views
Feature Request
When submitting a feature or enhancement request, it is important to provide as much specific and detailed information as possible. Mifos will have a lot of volunteers and contributors working on this project, so your feature may be built by someone who has a limited understanding of Microfinance operations. Your feature request must clearly explain how the feature should be implemented into Mifos and how the user will interact with the feature. Remember that what may seem obvious to you, probably won't seem obvious to someone else. Below is a template to help!
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!
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".
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.
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.
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.
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.
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 doinig. 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.
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.
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?
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?
|
