There are two approaches to functional specifications, one is to list all of the functionality that could be needed and the other is to start with a few key use cases. We prefer a bit of a hybrid in that we want to know "where we are going" in terms of functionality, but also we want to only specify that which we can build immediately.
For an initial build, we should reference both of these:
However, when the functional requirements conflict with rapid development with sufficient testing, then we should push functional requirements to the next release.
Minimal Viable Product
The initial release should consist of these microservices:
- supporting libraries
See Fineract CN Project Structure for references to these microservices.
The target deploy is a minimal payment app backend system with minimal UI. It should be deployed on a VM or cloud service (dockerized) and have a short guide to address questions about how to secure.
Perhaps it has the following functional characteristics:
- Use case orientation - that specific end-user roles and the steps that the end-user takes in interaction with Fineract-CN front end are written in a style that allows for both "tests" and communication of the requirements. For example:
- The User:BankStaff is able to login to see a recent history of all transactions by specific accounts, according to the permissions that they have that mask certain transaction details.
- The User:Customer is able to login to a see current balances and recent activity on both debit and credit accounts with a total showing for all of their accounts.
- The User:FieldAgent is able to login and see a list of payments by individuals for whom they are assigned to.
- and so on...
- That security and configuration guides be included in the thinking from the beginning. An open source project often faces the false criticism that it is less secure so it is important to have ways of analyzing and addressing security holes from the beginning. This may also take the form of jira tickets that relate to ensuring that the logs are inviolable and that early detection mechanisms send alerts to the proper humans defined in the configuration file - which may require thinking that through more. There are guides to how to secure infrastructure and I am sure other Apache projects have had to deal with this - we should look to them for advice.
- That the surface area of the release includes:
- Open an Account with at least two KYC levels
- Open a second account for the same person or entity
- Make a deposit
- Make a withdrawal
- Transfer funds within accounts held by the same person
- Enforce rules related to transfer amounts (subject to KYC limits)
- Have a simple approval process for a loan application (an agent can approve)
- Configure a loan product with min and max amounts and two methods of interest calc
- Transfer funds from a "lending department" to a customer
- Generate an expected payments schedule based on the product definition
- Write off the loan
- Close the account (put into one of several different states)
- That there is sufficient test coverage for the release.
There is a good discussion concerning a minimal viable product here – > https://lists.apache.org/thread.html/f658ccf0d9b0c350be901d58aad07c66fc40637f46d480b164793320@%3Cdev.fineract.apache.org%3E