A Mobile Based Auctioning Platform for Auctioneering Firms Student No: 101331 Group A An Information Systems Project documentation submitted to the Faculty of Information Technology in partial fulfilment of the requirements for the award of a Degree in Business Information Technology Date of Submission: January 2021 ii Declaration I declare that this work has not been previously submitted and approved for the award of a degree by this or any other University. To the best of my knowledge and belief, the research proposal contains no material previously published or written by another person except where due reference is made in the research proposal itself. Student’s signature: _____________________ Date: ___________________ Supervisor’s signature:___________________ Date:__________________ iii Abstract The auctioning industry in the country is in a predicament. There is an increased demand for their services due to the increased number of loan defaults on assets. This was caused by a reduction in business activities due to the measures taken by the government to help slow down the transmission rate of the corona virus. The measures being limiting of public interaction has had an impact on auctioneers' activities as most auctions are held in public places. Despite demand being present foe their services, the auctioneers cannot fully serve this demand with the current auctioning systems leading to lost business for them and lost asset value for those wishing to put their assets on auction. Auctioneers can regain their previous demand and maybe surpass it by adopting an auctioneering system that is mobile based. Such a platform will also provide better services to the bidders as they can now access markets anywhere in Kenya. The android operating system is be the best mobile platform as it has a large market share of users in the Kenyan market. Firebase database will be used because of its easy integration with android apps. Agile development methodology will be used with deliverables to determine the progress of the project. Once completed, the system hopes to improves the business activities of auctioneers and provide bidders access to market they previously didn’t 1 Table of Contents Declaration...................................................................................................................ii Abstract.......................................................................................................................iii Chapter 1: Introduction................................................................................................2 1.1: Background............................................................................................................3 1.2: Problem statement..................................................................................................3 1.3: Aim.........................................................................................................................3 1.4: Specific objectives.................................................................................................3 1.5: Justification............................................................................................................4 1.6: Scope and limitations.............................................................................................4 Chapter 2: Literature Review …...............................................................................................5 2.1: Introduction............................................................................................................5 2.2: Description of current systems...............................................................................5 2.3: Challenges of the current system...........................................................................6 2.4: Review of existing solutions and technology........................................................7 2.4.1 Mobile based platforms............................................................................7 2.4.2 Cloud database.........................................................................................7 Chapter 3: Methodology...........................................................................................................9 3.1: Introduction............................................................................................................9 3.2: System Analysis.....................................................................................................9 3.2.1: Functional requirements..........................................................................9 3.2.2: Non-functional requirements................................................................10 3.3: System design......................................................................................................10 3.4: Development tools and techniques......................................................................10 3.5: Deliverables.........................................................................................................11 3.5.1 Development of user module…………………..……………...........…11 3.5.2 Development of bidding module…………..……………….….............11 3.5.3 Development of authentication module……...........…………………..12 3.5.4 Development of admin module…………..………...........…………….12 3.5.5 Testing of the system……………………..………………...........…....12 3.5.6 Deployment……………………………………………...........…….…12 2 Chapter 4: System Design ......................................................................................................16 4.1: Introduction ….....................................................................................................16 4.2: Requirements Gathering ….................................................................................16 4.3: System Requirements …......................................................................................16 4.4: System Architecture ............................................................................................17 4.5: Use Case ..............................................................................................................18 4.6 Database schema …............…..............................................................................19 4.7 Entity Relationship Diagram …...................….....................................................20 Chapter 5: …...........................................................................................................................21 5.1: Introduction .........................................................................................................21 5.2: System interfaces ................................................................................................21 5.2.1: Log in and Sign-up interfaces ..............................................................21 5.2.2: Assets on auction interface ..................................................................23 5.2.3: User data interface ...............................................................................24 5.2.4 Bid for asset interface ...........................................................................25 5.2.5 Upload asset for auction .......................................................................26 5.3: System testing .....................................................................................................27 Chapter 6: …...........................................................................................................................29 6.1: Introduction .....................................................................................................................29 6.2: Discussion........................................................................................................................29 6.3: Recommendation.............................................................................................................29 6.4: Future work .....................................................................................................................30 References: .............................................................................................................................31 Appendix: …..........................................................................................................................32 3 Chapter 1: Introduction 1.1 Background In addition to the serious implications for people's health and the healthcare services, coronavirus (COVID-19) is having a significant impact on businesses and the economy (PwC, 2020). This is mainly due to the measures that have been put in place by the government to handle the pandemic. Almost all businesses in all industries have been affected either directly or indirectly. As business activities reduce, companies are forced to lay off some workers due to reduced demand for their goods or services. This in turn reduces the spending capacity of other businesses customers and the vicious cycle continues (Quartz, 2019). One consequence of this is the reduced demand for high value assets such as homes and cars for both businesses and people thus reducing the demand for financing services as they are uncertain of their economic future. On the other end, there is an increased number of defaults on loan repayments as people lose their incomes and businesses lose their customers reducing their ability to service their debts. This situation has left the financing companies with an increasing asset portfolio that continues to lose value as there is no demand for them, and a reducing customer base for their financial products. The procedure followed by most financing companies to recoup back their rewards on risk is to put the assets up on public auction. Once on auction, people and companies interested in the asset place bids over a given period of time and the asset is sold to the highest bidder. This auctioneering activity usually takes place in a physical location where all parties are present. The government's directives of social distancing requiring people to stay at least one meter apart (Ministry of Health, 2020) limits the number of participants who can take part in the bidding process. This hinders the abilities of the auctioneering companies to recoup back their returns on risks thus, other ways to conduct the auctioneering need to be developed. The 4 existing technologies can allow for an online auctioneering to take place. The financing companies can also leverage the technology to reach potential clients in far geographical locations who might be interested in the assets potentially increasing their profits. 1.2 Problem Statement As it stands, the current auctioneering process is limiting the number of customers that can participate in the auctions as they have to adhere to Kenyan Government directives to cope with the covid-19 pandemic. If the auctioneers decide to continue with business as usual, it will put all participants at risk of contracting the virus which might lead to legal action taken against the auctioneers by either the Kenyan Government or any of the participants. This leads to less profits and potentially losses realised by the financing companies. This may lead to even more layoffs thus continuing the vicious cycle. 1.3 Aim The aim of this project is to develop a mobile based platform that allows the auctioneering companies to carry out their auction online. The platform will help solve the problem of reduced participants and potentially increase them as any interested party can participate from anywhere. 1.4 Specific objectives (i)To investigate the considerations in the auctioneering process. (ii)To analyse existing approaches and techniques used for auctioneering. (iii)To develop a mobile based auctioneering platform. (iv)To test the developed platform. 5 1.5 Justification Online auctioning seems to be the best solution to the problem as it provides value to both the interested investors by providing them with an opportunity to bid from anywhere and to the auctioneers by ensuring their normal business activities can continue taking place without any of the participants risking their health or legal action taken against them. 1.6 Scope and limitations The project is intended to solve the specific problem creating an alternative market for auctions to take place. It will look at what is needed for such transactions to take place and try to implement the same on an online platform. The project will be limited to providing a solution for the local market (Kenya) due regulatory constraints. The platform will not handle cash transfer but instead offer a platform where contracts of future transfer of assets are made between the auctioneer and the investor. 6 Chapter 2: Literature Review 2.1 Introduction This chapter reviews the current literature on the auctioning process in Kenya, the trends in mobile technology, implementation of mobile technology in other areas or markets of the industry. It first explores the challenges that exist in the current auctioning process 2.2 Description of Current Auctioning Process Most auctions that take place are auctions of assets repossessed by institutional investors such as Saccos, insurance companies and banks like Equity Bank, Cooperative Bank and Kenya Commercial Bank (KCB) on loans that have defaulted. Others are done by large organisations trying to get rid of their old inventory. Some of these organisations and companies contract companies specialized in the auctioning industry for a variety of services (Lolwe auctioneers, 2020), while others carry out their own auctioning processes such as NIC bank (NIC Bank, 2020). In both cases, the auctioning process is similar. The auctioning begins with the asset or collateral in question being repossessed (Garam Investments Auctioneers, 2020), then it is listed in a public announcement declaring the intentions of putting the asset up on public auction. This announcement is done through various means but most commonly the back of daily newspapers such as the Daily Nation and the Standard Newspaper with detailed description of the asset. Other ways of announcing the auctions are through the auctioning companies own website or the financial institutions website. 7 The details of the auctioning and terms of sale are stated in the announcement. These terms of sale are more often specific to the auctioneer or the financer as they each detail their own terms of sale (Keysian, 2020). The auctioneers also provide details of the location of the assets so as to allow the potential buyer to assess the asset. The auctioneer also declares the date at which the auction will take place and the location of the auctioning. The location is usually a physical location such as storage areas for the repossessed assets or the branch offices of the auctioning company. The assets are then lined up and each auctioned out to the potential buyers. Some auctions involve many different assets being sold in one location, while others involve the sale of one big asset such as a building 2.3 Challenges with Current Auctioning Process With auctions accounting for a third of all asset sales in Kenya (Standard, 2020), there are various challenges that plague the current auctioning processes that are followed by the auctioning firms. One of these problems is that most of the auctions are held in physical locations. This usually limits the number of potential customers that can participate in the auctions to those that are geographical nearer. This loss of market participants might lead to loss in the real value of the asset as the maximum demand is not realised. This loss of value is only realised when the asset is sold to an artificially low market, thus eating into the margins of the auctioneers and the financier. This lower price of the asset then puts downward pressure on similar assets in the market forcing their valuations to go down as well. This then increases the default rates as those who were barely floating on the previous market prices. A vicious cycle of lower market prices is then formed leading to greater losses. With the on-going pandemic and directives given by the Kenyan Government for social distancing to be maintained and the lock-down measures of the country’s biggest asset markets of Nairobi and Mombasa (The Star, 2020), the number of potential customers to participate in the auctions is further reduced. This is because investors that are located in different areas but would travel to take part in the auctions can no longer access the Mombasa 8 market nor the Nairobi market. This has increased the downward pressure of price that the assets were already experiencing leading to further losses. The current system may also pose health threats to those that participate. This is because the bidding of the asset is often done in a congregation where auctions are done in public spaces. These spaces can turn out to be areas of transmission of the virus if proper hygiene is not maintained and the social distancing directives not adhered to by even just a single participant. 2.4 Review of Existing Technology and Solutions There are existing technologies that can be employed to help solve the problems being faced by the auctioning industry. The internet has allowed a lot of transactions that previously needed physical locations to take place to now take place online. An example of these transactions is the paying of taxes through the i-tax platform that allows the citizens of Kenya to conduct all tax related transactions online (iTax Online Services, 2020). Another example is the purchase of insurance plans. Some insurance companies have adopted mobile technology to allow them to reach customers without the need of a physical interaction. This is done by selling their insurance premiums on mobile online platforms such as websites and mobile applications. The insured pays for the premium through M-pesa or online banking and is issued a soft copy of their cover by the insurer guaranteeing that the transaction has taken place (Insure Afrika, 2020). Some auctioneers have shown interest in having an online auctioning process but none seem to have been successfully deployed (Business Today, 2012). They only use the websites for announcing the auction details such as location and date but they are not used for the actual auctioning. 9 2.4.1 Mobile Applications Mobile applications can be grouped into web app, native apps and hybrid apps depending on the platform they run on (Think Mobile, n.d). These platforms have allowed entrepreneurs to find and create solutions to problems such as those mentioned previously. We are going to use android apps as they have a low barrier of entry to their development tools and their app store. Android also boasts of large share of mobile OS in the Kenyan market (Statista, 2020). 2.4.2 Cloud Database This is a database that is provided as a service which run on cloud computing (IBM, 2020). Examples of these solutions databases are Google’s Firebase, Microsoft’s Azure and Amazon’s AWS. These databases provide the highest industry standards on all aspects of data storage from security to mobility, latency, and software integration. We will be using Firebase as it is the best suited for development of an android app. Firebase is also the best solution because it provides data storage services for other mobile applications platforms such as web apps and iOS apps. 10 Chapter 3: Methodology 3.1 Introduction A system development methodology refers to the framework that is used to structure, plan and control the development process of an information system that satisfies the system requirements (Kabir Pulami, 2019). There are various development methodologies each with their own strengths. The decision on which methodology to use largely depends on the context of the problem in question and the solution used to solve the said problem. Some of these development methodologies are waterfall, agile, rapid application development, spiral model, extreme programming and lean development. We will be using the agile development methodology for the development of the mobile based auctioning platform. We chose agile development methodology because of its high priority on individuals and interactions. This is important because the system is intended to be used by a wide variety of people thus making simplicity of use a key criterion for success. Another reason for using 11 agile development is because of customer collaboration. This is important as each auctioneer might want to implement their own unique terms of trade. 3.2 System Analysis This is an analysis of the system and its objectives so as to come up with requirements that have to be met for the solution to be optimal (Study.com n.d). This entails looking at the system as it is, forming abstractions for simplifications, and finding out what is important and what isn’t taking into consideration the users of the system. From this process, functional and non-functional requirements are determined. Being such a powerful tool in development, it will also be employed in the software development process. 3.2.1 Functional Requirements These are requirements that define how the system will work. One of these functional requirements is authentication. The system should allow one to create user accounts. The system will be used to form contracts of exchange of assets between people thus a need for identification and authentication of a user is important. Another functional requirement is allowing third party individuals who might want to put their assets on auction can use the platform for a fee. This implies a system that allows a user to upload photo(s) and perform CRUD functions. While participating in an auction a bidder might want to know if some another bidder has placed a higher bid than theirs, this makes a notification system necessary. Due to the type of contracts being made on the platform, there needs to be a backup for all transactions that have taken place on the platform 3.2.2 Non-Functional Requirements These are requirements that are not important to the system but offer better experience while using the system (Scaled Agile, n.d). The system should be able to handle large traffic of activities. This is to cater for the event that an asset gets many bids being 12 placed on it. The system needs to be secure so as to guard the authenticity of the contracts. The system needs to easy to maintain so as to increase the amount of time the service can be used. 3.3 System Design This involves the design of elements of a system such as the architecture, data schema and interfaces. There are many different design patterns that can be applied in system design. These models can be defined as behavioural, creational structural and functional. The Model view controller model which is an architectural design pattern will be used in the development of the software. The model can be understood to be the database schema which holds all the data that the system will use. The view is the point of interaction with the user, how the data in the model is presented to the user. The controller acts as intermediary between the view and the controller, allowing the users to input data into the model and get data to the view from the model. Database schema will be developed in to aid in design of the model. Unified modelling language (UML) diagrams such as activity diagrams to show the flow of activities in the system and class diagrams to show relationships between objects will be used in the development of the system. 3.4 System Development Tools and Techniques Android Studio is an integrated development environment that is used in the development of android applications. It is the most popular tool with a lot of industry support which helps in debugging of any errors that might occur in the development process. In it, it has the java development kit which is used to write java code that runs the android operating system. It also has an xml editor that is used for the development of the interfaces that will be used for interaction between the users and the system. Another tool that will be used for development is the firebase cloud database provided by Google. It is a database management system that is cloud based and hosted by Google. It has 13 a simple and robust integration with the android apps which is the mobile platform that we will be using. 3.5 Deliverables There are various milestones that have to be achieved before project can be completed. These milestones will be used to determine the progress of the system development and to know if the project is within the. The whole process of the project from inception to completion follows as system development life cycle. From this, some measurable deliverables can be determined. The deliverables for the project are: 3.5.1 Development of user module This module will be the point of interaction between the user and the system. 3.5.2 Development of bidding module This module will allow for live bidding and notification system for bidders. 3.5.3 Development of authentication module This includes sign-up and sign-in system and will also allow for easy identification of users. 3.5.4 Development of admin module This is for administration purposes and management purposes of the system for the auctioneer. 3.5.5 Test the system To make sure all modules work as they should and the system works as intended. 3.5.6 Deployment The system should be deployed once a customer if found. 14 Chapter 4: Analysis and Design 4.1 Introduction In this chapter we focused on system requirements and how we arrived at them. We also looked at the designs of the various components that make the system function as intended and how such components interact with each other. 4.2 Requirements gathering 15 Requirements gathering was done to identify the functional and non-functional requirements that satisfied the users' needs and the system's needs. It involved observing and analysing the normal auctioning process of various auctioneers. Interviewing the auctioneers and the bidders also proved to provide useful insight on the system requirements. 4.3 System requirement These are conditions that had to be met before the system could be said to remedy the problem. The requirements were divided into functional and non-functional requirements. Functional Requirements FR1 A user can sign-up to a unique account. FR2 A user should be able to login into their accounts. FR3 A user should be able to post an asset for auction. FR4 A user should be able to view assets put on auction. FR5 A user should be able to place bids on assets still on auction. FR6 The system to periodically notify a user when another user has placed a higher bid than theirs. FR7 A user should be able to view assest that they have successfully won. FR8 A user should be able to log out of their accounts. FR9 The system should keep a record of all ongoing and past auctions. FR10 The system should be able to retire the assets to the rightful owners after expiration of auction period. Non-functional requirements NFR1 The system should be intuitive. NFR2 The system should have a low downtime. NFR3 The system should be able to auto scale on demand. 4.4 System Architecture The system architecture that was used was the model view controller architecture. The model and the controller was hosted on a cloud service provider (Google Firebase) while the view is an android app. 16 4.5 Use case 17 The above diagram is an abstraction of the interactions that might have taken place between the different users and the system. 18 4.6 Database Schema The above image is a simplified version of the schema of the implemented database schema. Because of the iterative nature of the development process, this schema is always changing and no final verion have been arrived at as system requirements are implemented. 19 4.7 Entity relationship diagram The image above shows how the various entities of the system interact with each other. 20 Chapter 5: System Implementation and Testing 5.1 Introduction This chapter focuses on how the system was developed from its various components. This chapter will also focus on the testing of the different components and whether the system satisfies the system requirements and remedy the problem. 5.2 System Interfaces Below are the interfaces that the user will interact with while using the system. 5.2.1 Log-in and Sign-up interfaces The image above is the interface a user will see when the first get the app or when the log out of the app. This interface is meant for authentication of the user before they can view the assets on auction or bid on them. The user sees the following; 21 1) Input area where they insert their emails. 2) Input area where they provide their passwords. 3) Button that when clicked tries to log in the user based on the data provided. 4) Sign Up text that is a button to the Sign up interface. The image above is the interface the user will see when they click on the Sign-Up text in the log in interface. This is the interface the user will use to create a new account. The user will see the following; 1) Input area where they provide their names. 2) Input area where they provide their emails. 3) Input area where they provide their phone numbers. 4) Input area where they provide the password they will use to log into their accounts. 22 5) Button that when clicked will attempt to make an account with the data provided by the user. 5.2.2 Assets on auction interface The image above shows the interface the user will see once they create an account or log into an existing one. The view shows the assets that are currently on auction. The user only needs to click on the asset they want to bid on. The view is made possible by a recycler view that holds the individual asset data. From the view the user can see the following; 1) The asset with the most bids placed on it at the top of the view. 2) Button that has the name of the current user. 3) List of the assets up for auction. 3.1) Image of the asset on auction. 3.2) The name of the asset. 23 3.3) The current highest bid. 3.4) A snippet of the description of the asset. 5.2.3 User data interface The image above shows the interface of the user data. This is shown after the user clicks on the button that has their name in the assets on auction interface. This view shows the user the details of the user who is currently signed in. The details that can be seen are; 1) Name of the user. 2) Phone number of the user. 3) Email of the user. From this view the user can also sign out by clicking on the log out button. 24 5.2.4 Bid for asset interface The image below is a screenshot of the interface that a user will see when he clicks on an asset on the assets on auction interface. In this interface the user will be see the following; 1) Asset image. 2) Current bid. 3) Asset name. 4) Input area where the user will input how much he wants to increase the bid by. 5) Button for the user to submit their bid. 6) Who currently has the highest bid. 7) The date the auction on the asset will end. 8) A description of the asset as provided by the auctioneer. 25 5.2.5 Upload asset for auction interface The image above shows the interface the user will see when they click on the plus floating button. This is the interface that will be used by the user to upload an asset for auction. In this view the user can see the following; 1) Image button that will prompt the user to pick an asset image. 2) Input area where the user will provide the asset name. 3) Input area where the user will provide the reserve price (starting bid). 4) Input area where the user will provide a description of the asset they are putting on auction. 5) Calendar where the user provides a date when the auction for the asset will end. 6) Button that once clicked will attempt to post the asset and make it available for auction 26 5.3 System testing Tests had to be conducted to guarantee that the system works as expected. The tests were conducted multiple times with the same and different data to make sure the system behaves in a reliable predictable way. Test Id Related Requirem ent Inspection check Pre-condition Test data Success or Failure T1 FR1 Does the system allow a new user to create an account. The user should be able to create a new account Email: cheche.oloo@gm ail.com Phone: 0796142444 Name: Dickson Password: ************ Success T2 FR2 Does the system allow and existing user to sign into an existing account. The user should log into their account. Email: cheche.oloo@gm ail.com Password: ******** Success T3 FR3 Does the system allow a user to post an asset for auction. The user should be able to post an asset for auction. Name: BMW 3201 Reserve price: 600000, Date: 2/11/2021 Description: Cool car for sale. Success T4 FR4 The system should show assets put on auction The user should be able to see the new assets put on auction Name: BMW 3201Reserve price: 600000, Date: 2/11/2021 Description: Cool car for sale. Success T5 FR5 The system should accept bids on assets on auction The user should be able to place bids on auction. Bid price: 200000 Success T6 FR6 The system should The user cheche.oloo Success mailto:cheche.oloo@gmail.com mailto:cheche.oloo@gmail.com mailto:cheche.oloo@gmail.com mailto:cheche.oloo@gmail.com 27 notify bidders of higher bids than theirs. should get periodic notification of a higher bid than theirs currently has the highest bid on BMW 320i T7 FR7 The system should show the user assets that they have won. The user should get to see assets they own. Name: BMW 3201Reserve price: 600000, Date: 2/11/2021 Description: Cool car for sale. Success T8 FR8 The system should allow the user to sign out. The user should be able sign out of the system. N/A Success 28 Chapter 6: Discussion conclusion and recommendation 6.1 Introduction This chapter we will talk about the system and what was achieved at its completion. This chapter will also cover what the system was not able to achieve and recommendations on how to remedy what was not achievable. 6.2 Discussion The project set out to solve the problem auctioneers are facing with the restrictions of public gathering due to the Covid-19 safety regulations. The solution settled on was a mobile auctioning system. To solve the problem, the system had to abstract the auctioning process to an information system. The system needed to satisfy some minimal requirements for it to adequately remedy the problem. Some of the requirements achieved are; the system was able to create new unique accounts, the system was able to receive new assets for auction from users, the system accepted user bids for assets that were on auction, the system displayed to the user the assets that were on auction, the system was able to notify the users when another user placed a higher bid than theirs, the system was also able to retire assets whose auctioning dates had lapsed to their new owners. Despite being able to conduct actual auctions, some requirements that were not previously obvious arose while the system was being used. Problem of the auctioneer and winner of the auction being aware of each other after the expiry of the auction date is a problem that wasn’t considered. This is key for the system to fully satisfy the problem and bring value to both the auctioneer and the bidders. 6.3 Recommendation The system does allow for basic auctioning to take place but there are still some gaps left in the auctioning process particularly closing the auction on an asset. This is because of the regulatory restraints of exchanging the assets and missing functionality in the system. With the insights provided by the tests, it is recommended that the system has a functionality that 29 allows the bidder and the auctioneer to communicate on how they are eventually going to exchange the asset for the cash. 6.4 Future work Future work on the project will focus on implementing the communication module between the auctioneer and the bidder. Implementing this will fully satisfy the problem. Collecting data for business analysis for insights into the markets will provide another value proposition to the auctioneers and the bidders to allow them to participate int the market more efficiently. Getting regulatory certificates allow the system to be able to settle transactions will provide more value the users of the system and fully satisfy the problem. 30 References Macharia Kamau. (2020, January 27). Tears as auctions account for a third of properties on sale. Standard. https://www.standardmedia.co.ke/article/2001358045/kenya-is-now-an- auction-market Scaled Agile. (n.d). Non-functional Requirements. Scaled Agile. https://www.scaledagileframework.com/nonfunctional-requirements/ Study.com (n.d). Systems Analysis: Definition & Example. Study.com https://study.com/academy/lesson/systems-analysis-definition-example.html KRA (n.d) KRA Mobile Services. Kenya Revenue Authority. https://www.kra.go.ke/en/online-services/m-services Kabir Pulami. (2019, April 13). System Development Methodology. Quora. https://www.quora.com/What-is-system-development-methodology?share=1 IBM. (n.d). What is a cloud database? IBM. https://www.ibm.com/cloud/learn/what-is-cloud- database S.O’Dea. (2020, February 28). Statista. https://www.statista.com/statistics/1063958/market- share-held-by-mobile-operating-systems-in-kenya/ https://www.standardmedia.co.ke/article/2001358045/kenya-is-now-an-auction-market https://www.standardmedia.co.ke/article/2001358045/kenya-is-now-an-auction-market https://www.scaledagileframework.com/nonfunctional-requirements/ https://study.com/academy/lesson/systems-analysis-definition-example.html https://www.kra.go.ke/en/online-services/m-services https://www.quora.com/What-is-system-development-methodology?share=1 https://www.ibm.com/cloud/learn/what-is-cloud-database https://www.ibm.com/cloud/learn/what-is-cloud-database https://www.statista.com/statistics/1063958/market-share-held-by-mobile-operating-systems-in-kenya/ https://www.statista.com/statistics/1063958/market-share-held-by-mobile-operating-systems-in-kenya/ 31 Daniella Rosul. (nd). ThinkMobiles. https://thinkmobiles.com/blog/popular-types-of-apps/ Pwc. (n.d). COVID-19: Impacts to business. PWC. https://www.pwc.com/gx/en/issues/crisis- solutions/covid-19.html Appendix: A Sample scripts https://thinkmobiles.com/blog/popular-types-of-apps/ https://www.pwc.com/gx/en/issues/crisis-solutions/covid-19.html https://www.pwc.com/gx/en/issues/crisis-solutions/covid-19.html 32 A.1 A.2 A.3 33 A.4