Recently I had a chat with the CEO of a microfinance institute in Nicaragua. We exchanged thoughts on the problems faced in microfinance and the types of solutions that requirements engineering can provide. I was very happy when the conversation culminated in a job offer in a research position for when I finish my doctoral thesis, which I gladly accepted. So, what exactly can RE do for microfinance?
Microfinance is a movement aimed at providing financial services to those in developing countries who would not otherwise receive them. Management of loans and other financial services has a cost that remains constant regardless of the amount of money involved. There is therefore little incentive for commercial banks to provide these services to poorer sections of society where it becomes difficult to break even. The microfinance movement aims to set up self- sufficient financial service providers that enable small businesses to manage their risk in developing countries – thereby stimulating economic growth.
There are many challenges in setting up and maintaining microfinance projects that remain largely unsolved since the movement’s inception in the 70’s. Many of these challenges are underpinned by the problem of providing services to the developing world that have been created and evolved in developed countries. From a software engineering perspective a parallel can be drawn with the migration of a legacy software system into a new business environment. The requirements that were valid for commercial banking simply do not fit those of the microfinance world – and a lot of redesign needs to be done at all levels of the software lifecycle.
The mismatch includes many examples. In the developed world a business owner can easily calculate their wage costs and report them to a lender, while in a predominantly agricultural economy where family members are employed for free and supported though school, clothing and food this becomes more difficult. Capital assets can be hard to calculate when they consist of a herd of cows. Little recourse is possible against defaulting borrowers.
Solutions have been implemented in a similar fashion to many legacy systems – hack the current architecture until it plays nice. An example that has had some success involves lending to groups of borrowers in a community to reduce management costs and encourage members of the group to protect against their neighbours defaulting. For the majority of developing countries, however, microfinance systems are still in need of redesign if they are to stand a chance of providing meaningful support the vast majority of those who do not have access to financial services.
So, taking an RE perspective, what techniques could be used to help?
Goal oriented analysis could provide a start. Constructing goal models for aspects of commercial banking may reveal areas of the model where there are mismatches with the goals for microfinance. Do goals need to be added or removed? Have conflicts or obstacles been introduced into the model as a result? Given a set of goals and requirements aspects of the ‘implementation’ of microfinancial systems could be traced back to the goals they satisfy. Are all the goals satisfied? Do we have redundancies?
Quantitate goal satisfaction analysis may also be applicable. Data on existing transactions in microfinancial systems could tell us the degree to which certain goals are satisfied, and alternative goals could be constrained or relaxed to order to maximise the satisfaction of higher level goals. For example, decreasing the level to which borrowers need to be accountable for their business when the risk of defaulting is lower. This approach may also introduce a feedback loop into the requirements thereby encouraging microfinancial systems to take on a ‘self- adaptive’ nature.
The self-adaptive paradigm could also be taken a step further by viewing alternative implementations as ‘components’ in a microfinancial ‘architecture’, which can be interchanged to maximise the satisfaction of higher-level goals with respect to a specific operating environment. A simple example of this approach would be to increase the number loans made to groups where borrowers are defaulting.
Advances in social requirements engineering could also be put to use. Feature request management systems, for example, could be used to source requirements directly from borrowers or get microfinance institutions across to the globe to collaborate on defining and evolving microfinance requirements. Social stakeholder discovery using a tool such as Stakesource might reveal previously unknown stakeholders in new microfinance projects.
An agile approach to developing new services could be employed, where lightweight ‘throw away prototype’ trial projects are run to explore and evolve requirements.
The microfinance context is a prime example of where RE techniques designed for software systems development could be applied to address issues in other complex large-scale systems. Should RE not have a higher profile?
The ideas here are presented at a high level, but I would be interested in discussing any further thoughts or comments on the topic: There is a discussion page I’ve opened up on the RESG LinkedIn Group.