| MAKERERE UNIVERSITY [CONSULTANT] REGIONAL UNIVERSITIES FORUM FOR CAPACITY BUILDING IN AGRICULTURE (RUFORUM) (CLIENT) | | --- | | **System Requirements Specification (SRS)** **For the** ** Integrated Information, Learning, and Management Platform (IILMP)** **Draft 1** | | | | | | **Project Technical Team** | | **March, 2026** | | | | --- | # REVISION HISTORY | **Date** | **Description** | **Authors** | **Comments** | | --- | --- | --- | --- | | 24th March 2026 | Version 1 | | First version of requirements-based on data collected, validation from the validation process | # TEAM COMPOSITION | **Name ** | **Role ** | | --- | --- | | Dr. Mary Nsabagwa | Project Manager and Lead Systems Analyst | | Dr. Julianne Sansa-Otim | Co- Project Manager | | Mr. Joshua Muhumuza | Lead programmer | | Mr. Wamozo Cosmas | Programmer | | Mr. Mbonye Isaac | Systems Analyst | | Mr. David Gamuwa | Infrastructure | | Mr. Juma Katongole | QA | | Mr. George Lukanya | Intern (Systems analyst) | | Ms. Babirye Catherine | Systems analyst | | Mr. Newton Kambugu | Intern (Systems analyst) | | | | # DOCUMENT APPROVAL The following requirements specifications have been accepted and approved by the following **RUFORUM (CLIENT)** **Name: ___________________________** Signature: ____________________________ Date: _____________________________ **TECHNICAL TEAM** **Name: _____________________________** Signature: ____________________________ Date: _____________________________ # TABLE OF CONTENTS **REVISION HISTORY** **ii** **TEAM COMPOSITION** **iii** **DOCUMENT APPROVAL** **iv** **TABLE OF CONTENTS** **v** **LIST OF TABLES** **ix** **LIST OF FIGURES** **xi** **ABBREVIATIONS** **xii** **1** **INTRODUCTION** **1** 1.1. Background 1 1.2. Objectives and Key Deliverables 2 1.2.1 Main Objective 2 1.2.2 Specific Objectives 2 1.3. Scope 2 1.4. Purpose and Structure of SRS Document 3 1.4.1. Reader-Specific Sections 3 **2.** **SYSTEM STUDY** **5** 2.1. Methodology 5 2.1.1. Stakeholder Interviews 5 2.1.2. System Assessment 5 2.1.3. System development and Upgrade planning 6 3.1.5. Data Analysis 7 3.2. Existing Systems 7 3.2.1 RUFORUM Information Management System (RIMS) 7 3.2.2. Regional e-learning platform (REP) 10 3.2.3. Repository 14 3.2.4. M&E and Feedback System 15 3.2.5. Alumni 16 3.2.6. SME-hub 17 3.3. The Integrated RUFORUM Digital Ecosystem 21 3.3. Problems Faced with RUFORUM Systems 24 3.3.1 Challenges in RIMS 24 3.3.2. Challenges faced by REP 28 3.3.3. Challenges faced by the Repository 30 3.3.4. M&EL Challenges 31 3.3.5. Alumni Challenges 32 3.3.6. SME-hub Challenges 33 3.4. Risks and mitigation of Integrating the Systems 1 3.5. Data structure 1 3.5.1. Data domain 1 3.5.1. Data domains and Entities 2 The data domain mappings provide the following Key Integration Insights 4 **4. Project execution** **6** 4.1. System Update roadmap 6 4.2. Stakeholder analysis 6 4.3. Proposed system features 9 4.3.1. Grand Administration (Formerly RIMS) 9 4.3.2. Regional E-learning platform 17 4.4.3. Repository 18 4.3.4. M&E and Feedback System 18 4.3.5. Alumni proposed features 19 4.3.6. SME-Hub 20 4.4. Security Roadmap 24 **5. SYSTEM REQUIREMENTS AND SPECIFICATIONS** **28** 5.1. RIMS/ Fund Administration (FA) 28 5.1.1: Description 28 5.1.1. Subprocess Descriptions 29 5.1.2. Functional Requirements and System Specifications for Fund Administration 69 5.1.3. Non-Functional Requirements 129 **5.2. Repository (REPO)** **129** 5.2.1 Module Description 129 5.2.2 Sub-Process Descriptions 131 REPO-SP1: Document Capture and Ingestion 131 REPO-SP2: Metadata, Classification, and Author Management 139 REPO-SP3: Search and Retrieval 147 REPO-SP4: Access Control and Permissions Management 153 REPO-SP5: Document Versioning and Lifecycle Management 159 REPO-SP6: Content Review and Quality Assurance 166 REPO-SP7: Document Collaboration 174 REPO-SP8: Integration and Ecosystem Linkage 179 REPO-SP9: Repository Analytics, Reporting, and AI-Powered Insights 187 5.3. M&E and feedback (MFL) 266 5.3.1. Module Description 266 5.3.2. Use-case narratives 266 5.3.3. Functional requirements 282 5.3.4. Non-functional requirements 285 5.4. Finance Management (FM) 286 5.4.1 Finance Management Module Description 286 5.4.2 Finance Management sub-process descriptions 286 1. Define Objectives and Scope 287 2. Identify Budget Line Items 287 3. Estimate Costs 287 4. Define Fiscal Year Structure 287 5. Plan Multi-Year Allocations (if applicable) 287 6. Assign Funding Sources 287 7. Set Budget Controls and Limits 288 8. Input Budget into Financial System 288 9. Review and Validate 288 10. Approval and Finalization 288 11. Monitoring and Adjustments 288 1. Confirm Approved Budget and Commitments 289 2. Identify Payable Items 290 3. Define Payment Details 290 4. Set Payment Dates 290 5. Select Payment Methods 290 6. Assign Funding Source and Accounts 290 7. Cash Flow Validation 290 8. Set Approval Workflow 291 9. Enter into Financial System 291 10. Notification and Reminders 291 11. Execute Payments 291 12. Reconciliation and Tracking 291 13. Adjust and Reschedule (if needed) 291 1. Initiate Disbursement Request 292 2. Enter Request Details 292 3. Attach Supporting Documentation 292 4. Budget Availability Check 292 5. Compliance and Policy Validation 292 6. Submission for Approval 292 7. Multi-Level Review and Approval 292 8. Revision (if required) 293 9. Final Approval and Authorization 293 10. System Recording and Audit Trail 293 11. Forward to Payment Processing 293 12. Status Tracking and Notifications 293 1. Retrieve Approved Payment Instructions 293 2. Prepare Payment Batch 294 3. Validate Payment Details 294 4. Execute Payments 294 5. Record Payment in the System 294 6. Update Payment Status 294 7. Generate Payment Documentation 295 8. Notify Stakeholders 295 9. Bank and Cash Reconciliation 295 10. Resolve Discrepancies 295 11. Update General Ledger 295 12. Audit Trail and Reporting 295 13. Ongoing Tracking and Monitoring 295 5.4.3. Functional requirements for financial management 298 5.4.3 Non-functional requirements for financial management 300 5.5. Regional E-Learning Platform (REP) 302 5.5.1 Module Description 302 5.5.2 Sub-Process Descriptions 303 REP-SP1: User Registration and Profile Management 303 REP-SP2: Course and Programme Management 310 REP-SP3: Enrolment and Access Management 317 REP-SP4: Learning Delivery and Engagement 324 REP-SP5: Assessment and Grading Management 331 REP-SP6: Certification and Credential Management 339 REP-SP7: Learner Networking and Community Management 346 REP-SP8: Transition Support and Career Services 351 REP-SP9: Personalisation and Adaptive Learning 356 REP-SP10: Learning Analytics and Reporting 360 5.5. General system features 366 **6.** **Integration Requirements** **366** 6.1. Objectives and outcomes of integration 366 6.2. API and Interface Requirements 367 6.3. Data Integration Requirements 370 6.3.1 Data Formats 370 6.3.2. Data Mapping Rules Between Systems 370 6.3.3 Master Data Definition (Source of Truth) 371 6.4. Error Handling & Monitoring 372 7.1 Data Domains and Data Structures 375 **7.** **Reports Generated by the System for Decision-Making** **375** **8.** **General Functional Requirements** **378** 8.3. General Non-Functional Requirements 378 8.4. General Data Requirements 378 8.5. General Quality Requirements 379 8.5.1. Reliability 379 8.5.2. User Interface Requirements 380 8.5.3. Performance 381 8.5.4. Maintainability 381 8.5.5. Flexibility 382 **References** **382** **APPENDIX A: Interview Guide** **383** **APPENDIX B: Requirements Elicitation Guide** **384** # LIST OF TABLES Table 1: System-specific reader sections 4 Table 3: Roles of the different stakeholders 20 Table 4: Strategic relationship summary of the systems 24 Table 5: Current Application Landscape 24 Table 6: Risks and mitigation mechanisms of integrating systems 1 Table 7: Systems business application mapping across systems 1 Table 8: Data Domains and Data Entities 2 Table 9: Stakeholder interests (** shows primary system for the stakeholder) 7 Table 10: RIMS Action Plan Summary 12 Table 11: Security Roadmap for RUFORUM Systems Integration 25 Table 12: Grant planning and setup use case narrative 29 Table 13: Functional specifications for Fund administration 34 Table 14: Funding Type Configuration Rules Grant Planning and Setup (5.1.1.1) 42 Table 15: Call setup use case narrative 45 Table 16: Functional Requirements and System Specifications Call Setup (5.1.1.2) 50 Table 17: Application Management use case narrative 62 Table 18: Functional Requirements and System Specifications Application Management (5.1.1.3) 70 Table 19: Award and Agreement Management use case narrative 83 Table 20: Requirements specification for fund management 92 Table 21: Requirements specifications for fund administration 116 Table 22: Document Capture and Ingestion Use-Case Narrative 131 Table 23: Functional Requirements Document Capture and Ingestion 134 Table 24: Metadata, Classification, and Author Management Use Case Narrative 139 Table 25: Functional Requirements Metadata, Classification, and Author Management 142 Table 26: Search and Retrieval use case narrative 147 Table 27: Functional Requirements Search and Retrieval 149 Table 28: Functional Requirements Access Control and Permissions Management 155 Table 29: Document Versioning and Lifecycle Management use case narrative 159 Table 30: Functional Requirements Document Versioning and Lifecycle Management 162 Table 31: Content Review and Quality Assurance use case narrative 166 Table 32: Functional Requirements Content Review and Quality Assurance 169 Table 33: Document Collaboration use case narrative 174 Table 34: Integration and Ecosystem Linkage Use Case Narrative 179 Table 35: Use case narrative for Onboarding and Business Registration 196 Table 36: Broad View of Data Requirements SP1: Onboarding & Business Registration 200 Table 37: Use case narrative for incubation Programme Management 210 Table 38: Requirements specifications for Fund Management 215 Table 39: Use case narrative for Market and Partner Linkage 227 Table 40: Requirements specifications for Market and Partner Linkage 231 Table 41: SP4 Innovation Showcasing & Deal Management 236 Table 42: Innovation Showcasing and Deal Management use case narrative 240 Table 43: SP5 Investment & Funding Access 246 Table 44: SP5 Investment & Funding Access 250 Table 45: SP6 Monitoring, Learning & Impact 255 Table 46: Use Case for result hierarchy management 266 Table 47: Use case narrative for indicator management 277 Table 48: Use case narrative for Reporting and Compliance 279 Table 49: Use case narrative for finance management 286 Table 50: Use case narrative for disbursement and Payment 289 Table 51: Use case narrative for financial reporting 296 Table 52: requirements specifications for budget and financial management 298 Table 53: User Registration and Profile Management use case narrative 303 Table 54: Functional Requirements User Registration and Profile Management 306 Table 55: Course and Programme Management use case narrative 310 Table 56: Functional Requirements Course and Programme Management 313 Table 57: Enrolment and Access Management use case narrative 317 Table 58: Functional Requirements Enrolment and Access Management 320 Table 59: Learning Delivery and Engagement Use Case Narrative 324 Table 60: Functional Requirements Learning Delivery and Engagement 327 Table 61: Functional Requirements Assessment and Grading Management 334 Table 62: Certification and Credential Management use case narrative 339 Table 63: Learning Analytics and Reporting Use Case Narrative 360 Table 64: Functional Requirements Learning Analytics and Reporting 362 Table 65: Rate Limits and Usage Constraints 369 Table 66: Error-Handling Integration Requirements for RUFORUM Systems 373 Table 67: High-level System reports 375 # LIST OF FIGURES Figure 3. 1: User dashboard 8 Figure 3. 2: Sample notification of progress of the application 9 Figure 3. 3: Simple text search interface 15 Figure 3. 4: High-level stakeholders 19 Figure 3. 5: Roles available in SME-HUB during self-registration 20 Figure 3. 6: Current registration form for businesses 22 Figure 3. 7: RUFORUM System relationships and Purpose 24 Figure 3. 8: Registration form for users 27 # ABBREVIATIONS | ACE | Africa Higher Education Centres of Excellence | | --- | --- | | AI | Artificial Intelligence | | AICC | Aviation Industry Computer-Based Training Committee | | AIHs | Agri-Enterprise Innovation Hubs | | API | Application Program Interface | | BTVET | Business, technical, and vocational education and training Institutions | | COI | Conflict Of Interest | | CSV | Comma-Separated Values | | CV | Curriculum vitae | | DR | Data Requirements | | FA | Fund Administration | | FM | Finance Management | | FR | Functional Requirements | | H5P | HTML5 Package | | HTML | Hypertext Markup Language | | ID | Identification | | IILMP | | | IMSCP | | | IP | Intellectual Property | | IT | Information technology | | JPEG | Joint Photographic Experts Group | | KPIs | Key Performance Indicators | | LMS | Learning Management System | | LTI | Learning Tools Interoperability | | M&E | Monitoring and Evaluation | | M&EL | | | MoU | Memorandum of Understanding | | MySQL | My Structured Query Language | | NFR | Non-Functional Requirements | | NGO | Non-Governmental organisations | | OER | Open Educational Resources | | ORCID | Open Researcher and Contributor ID | | PDF | Portable Document Format | | PNG | Portable Network Graphics | | QA | Quality Assurance | | QR | Quality Requirements | | QR CODE | Quick Response Code | | REP | Regional E-learning Platform | | REPO | Repository | | RIMS | RUFORUM Information Management System | | RUFORUM | The Regional Universities Forum for Capacity Building in Agriculture | | SCORM | Sharable Content Object Reference Model | | SMART | Specific, Measurable, Achievable, Relevant, and Time-bound | | SME-hub | Small and Medium Enterprise Hub | | SMS | Short Message Service | | | | | SRS | Software Requirements Specification | | T-VETs | | | URL | Uniform Resource Locator | # INTRODUCTION ## Background The Regional Universities Forum for Capacity Building in Agriculture (RUFORUM) has grown into a significant network of 175 universities across 40 African countries. RUFORUM is registered as an International NGO (FORR78950) in Uganda and coordinated by a Secretariat hosted at Makerere University, Kampala. The large number of partners and their operations is being supported by a system with functions including management, grants, learning, project and alumni management, among others. These systems generate massive amounts of data, with varying formats, and are distributed across different places. This hinders decision-making as a result of the lack of a holistic view of the performance of RUFORUM and its member institutions. Challenges faced include:- - Lack of an accurate picture of the performance: Accessing data is hard, which impedes and delays decision-making. - Inaccurate and incomplete reporting: Data extraction, consolidation, and analysis are time-consuming and error-prone. Moreover, the resulting reports may be inaccurate or incomplete, which hampers decision-making. Hence, the inability to identify trends, track performance, and seize opportunities. - Operational inefficiencies: In case integrated reports are required, these are manually generated through the manual transfer of data between systems. - Data duplication: Data is duplicated across systems. This may include user information and other project data, which is required for use across different systems. - Data incompatibility: Each system has different data representations and formats, which make it hard to combine for efficient reporting. System integration can solve the challenges, improving process efficiency, improving data accuracy, and enhancing decision-making, among others. ## Objectives and Key Deliverables ### 1.2.1 Main Objective . ### 1.2.2 Specific Objectives To investigate baseline/current and target/future information for developing an Enterprise Architecture for the IILMP. This will be achieved through the following activities: - Review of documents regarding RUFORUM processes - Study existing paper-based and IT Systems that are to be integrated - Determine RUFORUM and related business process stakeholders that will provide data to the consultant - Conduct interviews and collaborative group sessions with stakeholders identified above to study, appreciate, and/or understand, and identify the management practices and workflows that are being undertaken. - Design system models, which will guide the implementation phase to deliver a working system - To deploy the system such that it can be accessed over the network. - To test and validate the system with the users **Key Deliverables** In line with the above specific objective, the major deliverables of this project include - Requirements document - M&E framework - Design document - Integrated system - User manuals - Technical Report ## Scope The project seeks to provide an IILMP to support sub-processes within the following divisions, as well as data migration of existing data therein. The inception report covers the following components of the IILMP upgrade: - - To ***develop*** ***an upgraded RIMS*** with enhanced functionality, including but not limited to Grants and projects management, scholarship administration, administrative operations, and M&E modules - ***Create an advanced REP*** with Interactive learning environments, integrated SME-Hub, enhanced user engagement tools, and mobile learning support - ***Implement comprehensive tracking*** and reporting system modules through the use of ***artificial Intelligence ***features. - Establish robust security and data protection measures - To deploy IILMP and support users in transitioning through training and user support The above will be achieved following a user-centered methodology in which users will be involved through requirements gathering processes, documentation, and validation at each stage. Additionally, user training and maintenance of the system will be done to ensure a smooth transition to the new system. Geographically, the RUFORUM Secretariat, all its partners across Africa, and other stakeholders will contribute to the evaluation of the integrated system ## Purpose and Structure of SRS Document ### Reader-Specific Sections It is expected that this document will be used by people with different skill sets. This section explains which parts of this document should be reviewed by various types of readers. - **End Users (Client) and Project managers**: must read functional and non-functional requirements to clarify if all the requirements have been captured. They may not the section on quality requirements, since it mainly contains technical aspects that may be difficult to understand due to the technical jargon. - **Systems analysts** are expected to read all sections of the document as they are expected to know everything about the document. - **Programmers** are expected to read sections that contain use-case narratives to understand the human resources management sub-processes. They should also read and understand the functional requirements that arise from the various tasks. Programmers should also read the non-functional requirements to understand under what constraints the system they implement operates. - **Testers**: are recommended to read functional and non-functional requirements to understand what aspects of the system they should test for as a means of validating system requirements. **Table 1: System-specific reader sections ** | **Module** | **Section** | **Description** | | --- | --- | --- | | M&E Module (MFL) | 3.2.4 (Pg 15–16) | Overview of the current M&E system and its functions | | | 3.3.4 (Pg 31–33) | Key challenges affecting monitoring and evaluation processes | | | 4.3.4 (Pg 18–19) | Proposed improvements and system features | | | 5.3 (Pg 266–293) 5.3.1–5.3.4 | Full system requirements and specifications Module description, use cases, functional and non-functional requirements | | RIMS (Fund Administration) | 3.2.1 (Pg 7–10) | Overview of the grants, scholarships, and funding system | | | 3.3.1 (Pg 25–29) | Issues affecting system performance and usability | | | 4.3.1 (Pg 9) | Proposed system enhancements | | | 5.1 (Pg 28-129) | Detailed system requirements and workflows | | Regional E-Learning Platform (REP) | 3.2.2 (Pg 10–14) | Overview of the online learning and training system | | | 3.3.2 (Pg 29–31) | Issues affecting usability and integration | | | 4.3.2 (Pg 17) | Proposed improvements | | | 5.5 (Pg 302 - 360) | Detailed learning system requirements and processes | | Repository (REPO) | 3.2.3 (Pg 14–15) | Overview of the knowledge storage and sharing system | | | 3.3.3 (Pg 31) | Issues related to search, organization, and access | | | 4.4.3 (Pg 18) | Proposed repository improvements | | | 5.2 (Pg 129 - 187) | Detailed requirements for document management and access | | Alumni Module | 3.2.5 (Pg 17) | Overview of the alumni tracking and engagement system | | | 3.3.5 (Pg 33) | Challenges in alumni data, engagement, and tracking | | | 4.3.5 (Pg 19) | Proposed improvements for the alumni system | | SME-Hub Module | 3.2.6 (Pg 18–22) | Overview of the entrepreneurship and innovation support system | | | 3.3.6 (Pg 34) | Challenges affecting SME support and platform functionality | | | 4.3.6 (Pg 20) | Proposed SME-Hub features and enhancements | | Finance Management (FM) | 5.4 (Pg 286 - 300) 5.4.1–5.4.3 | Financial planning, budgeting, disbursement, and reporting system Sub-processes, workflows, and system requirements | # SYSTEM STUDY ## Methodology ### Stakeholder Interviews Semi-structured interviews were conducted with various stakeholders, at the secretariat, specifically targeting system users. A requirements elicitation guide is provided in Appendix B. The purpose of the interviews was to explore the experiences, views, sources of information, and attitudes with respect to what happens during the different sub-processes in the directorate. The Interview guide was used to explore activities and procedures, documents, and stakeholders involved so as to develop an interoperable, integrated, and coordinated functional system that gives up-to-date and timely information. A joint stakeholder meeting/workshop was held at the start of the data collection process, which provided a general understanding of RUFORUM activities and led to division-centered interviews with division heads or representatives. The sampling frame and selection criteria for the different interviews were as follows: A purposive sampling approach was used to actively select a middle manager in the organisation based on their role in managing the RUFORUM functions. ### System Assessment - **Confirming functional Compatibility**: This included checking if the systems support the required business, confirming if the features aligned, and if data formats and workflows are compatible - **Data Integration and Data Quality checks:** This involved identifying the most appropriate data formats to be used, data mapping between systems, performing data accuracy, completeness, and consistency checks, and handling duplicates and conflicts - **Interface and API Design**: This involved checking if there were APIs and integration interfaces, and if any, checking if they are compatible, checking the request/response formats, and error handling - **Security and privacy**: This involved checking existing authentication and authorization methods, data encryption (in transit and at rest), compliance with privacy rules, access control, and audit logs ### System development and Upgrade planning The module upgrade will follow the following steps: - - **Improvement Planning**: We drafted a process improvement plan, which stipulates the description of processes to be improved and the justifications for improving them. The plan includes but is not limited to, team responsibility assignment; identification of resources to be allocated to the different modules, and identifying Key performance indicators for the process Improvement to help in monitoring progress. - **Identification of issues with the current modules**: through reviewing the system module implementations and documentation, identify issues that affect their quality and performance in terms of: - **User interface design issues**, including but not limited to system navigation flows, ease of use, consistency, - **Performance issues**: including identification of which features are slowing down the system. - **Features that limit productivity,** such as manual processes that need to be automated; Adherence to regulatory standards; How dispersed is the data? Providing decision-making analytics; Identifying duplications - Devising means of improving the modules through documenting solutions to each of the identified issues **2.1.4. System Integration planning** Integration followed the following steps: - - **Integration planning**, including defining integration points, data exchange mechanisms, and integration workflows. These workflows include extracting data from existing databases, data transformation to map with the available form fields, and validating the integrity of the imported data ### Data Analysis Requirements from the data collected from the literature were first combined with those identified from the field. These were then categorized into one or more classifications of requirement, i.e., Functional (FR), Non-Functional (NFR), Data (DR), and Quality (QR) requirements. Each requirement was then reviewed to identify the sub-process to which it belonged. System specifications were then identified for each functional requirement. ## Existing Systems ### 3.2.1 RUFORUM Information Management System (RIMS) The RUFORUM Information Management System (RIMS) serves as the primary platform for managing academic and research opportunities within the RUFORUM network. It is designed to streamline the lifecycle of various organisational activities, facilitating global visibility and access for the scientific community. The system is structured to manage four primary types of “***Calls***” including: - - **Grants**: Research funding, including doctoral research and policy abstract grants. - **Scholarships**: Sponsored academic programs (e.g., Mastercard Foundation) for undergraduate and postgraduate students. Hence, scholarships are forms of financial support for students to pursue formal education. - **Fellowships**: A fellowship supports professional growth and expertise development, often beyond formal coursework. This is used to build leadership, research excellence, or specialized expertise. - **Challenges**: This is a competitive call for innovative ideas or solutions meant to solve a specific problem **Figure 3. 1**: User dashboard The system supports the following functions: - - **Call preparation**: This is where the call manager uses a template to prepare a call by adding the instructions. When the call is ready for publication, the call manager shares it with the systems administrator for uploading into RIMS. - **Call Upload**: This is when the systems administrator uploads the call to RIMS for all to see. - Sharing call link: The systems administrator shares the link for the call with the communications team for dissemination purposes. - **Communication/ information dissemination**: The communications team adds the call to the newsletter and disseminates it using platforms such as social media. - **Application process:** the system utilises a multi-stage process for handling applications through four (4) major stages. These include: - - **Registration:** Users create accounts if they are not yet registered. Only registered users can start the application and view calls in RIMS. Email addresses are used as unique identifiers for users within the system - **Application**: The applicant fills out and submits the application form for the call of interest. - **Validation:** A two-level validation process exists. First, the application is subjected to a manual check for required documents (such as CVs and academic documents). If the applicant has all the requirements, they are then assessed for eligibility (e.g., degree level or nationality). - **Review Process:** Applications are assigned to external reviewers who use system-integrated templates to provide comments and scores. Each application is assigned multiple reviewers. These scores, once assigned to the applicant, are entered into the system. A review recommendation/result is in any of the categories, including Reject, Minor, Accept, and Major. Applicants are notified by email about the progress of their application, as in Figure 3.2. The reviewer visits the system and uploads the reports of the applications they were assigned to. **Figure 3. 2: **Sample notification of progress of the application - **Scoring:** The system calculates an average score when all reviewers have uploaded the results to determine the ranking of applicants. - **Selection**: The system provides an interface for displaying all applications, where results are arranged in descending order, and the top applicants are considered successful at that stage. The follow-up process on the successful candidates is made off the system. - **Interviews**: if interviews are required, the interview is organised, and the applicant is notified via email. - **Follow-up of candidates** ### 3.2.2. Regional e-learning platform (REP) The REP was developed to provide a platform for RUFORUM member universities to deliver online courses and training programs. The system encompasses - Project Cycle Management - Scholarships Portal - Alumni Portal and - Features that allow the general administration at the Secretariat, including travel, leave, and procurement The e-learning platform is designed in Moodle. Being an open source Learning Management system (LMS) provides an opportunity to easily add the required plugins, while accessing data for processing is possible through the use of a Web Service framework feature provided by Moodle. An external API can then be used to extract the required data, while API endpoints can also be created using the core Moodle functions or by creating custom APIs using the available local plugins. The system has the following core plugins: - **Bigbluebuttonbn**: This enables instructors to create, manage, and deliver live, interactive online classes directly within a course. Key functions include real-time video conferencing, screen sharing, breakout rooms, multi-user whiteboards, and recording. - **customcert**: This is designed to allow teachers and administrators to create, customize, and issue dynamic PDF certificates directly within a Moodle course. The plugin enables full visual customization of the certificate’s layout through a drag-and-drop web browser interface. Core functions include - dynamic PDF Generation, which automatically generates a personalized PDF certificate for each student, incorporating user-specific data. - Drag-and-Drop Editor, which allows users to add, remove, and reposition elements (text, images, signatures) on the certificate. - Customizable Elements, which include student name, grade, course name, date, teacher names, images, QR codes, and custom text. - Template Management, which enables administrators to create site-wide templates, allows teachers to easily load a standard design and avoid re-creating certificates. - Certificate Verification, which assigns each certificate a unique code, allows employers or other parties to verify its authenticity through a specific link. - Automatic Emailing, which can be configured to automatically email a copy of the PDF certificate to the user once they meet the specified course completion conditions. - "*My Certificates*" Access, which enables users to view all certificates they have received in one place, usually under their profile or a specific block. - Teacher Control, which enables teachers to view a list of all issued certificates, download them, or revoke them if necessary.  - **folder**: - **h5pactivity**: The H5P activity plugin in Moodle enables instructors to create, upload, and embed interactive HTML5 content directly into courses, such as quizzes, interactive videos, presentations, and games. It supports interactive learning, tracks student attempts, and allows for grading within the Moodle gradebook.  - **Label**: allows teachers to embed text, images, multimedia, or code directly onto the main course page, helping in organizing course content, creating headers, breaking up sections, and improving layout, without requiring students to open a separate resource.  - **Page**: Allows teachers to create a web page resource using the HTML editor, offering ways of presenting text, images, sound, or embedded video within a course, compared to adding files directly. It supports multimedia integration, conforms to usability standards, and keeps content organized.  - **Resource**: The module allows instructors to add static learning materials to a course, such as files, documents, text, or links to external websites. They are generally not interactive. These resources include files, pages, books, folders, URL and labels, among others. - **Workshop**: the module allows students to submit their own work and evaluate their classmates’ submissions based on instructor-defined criteria. It manages the submission, peer review, and grading process, providing two distinct grades: one for the student’s own submission and one for their assessment of others.  - Book: Creates a multi-page, structured, and book-like resource, allowing instructors to organize long-form content into chapters and subchapters. It also reduces course page clutter by housing extensive text, images, and multimedia in one place, featuring a navigation table of contents and printable options.            -  **Data**: This module is a tool for building and managing shared information records. It does all this in a way that lets teachers and students collect, organize, share, and search information in a structured online database. In addition, it works like a custom online record book inside a course that is being attended by a student.    - **Forum**: It is an essential asynchronous communication tool that enables students and teachers to exchange ideas, hold discussions, and build online communities through features like threaded discussions, subscription options, post limits, tracking, etc.   - **IMSCP**:   IMS Content Package (IMSCP) module allows instructors to upload and display standardized, pre-packaged, static educational content (e.g., interactive tutorials, HTML pages) created in external authoring tools. - **Lesson**: The lesson module is an interactive, adaptive teaching tool that presents content in a series of HTML pages, allowing students to navigate through material at their own pace. It also delivers information, asks questions based on that content, and adjusts the learning path based on student answers. -  **Qbank**: The Question bank central system used to create, store, organize, manage, and reuse exam and quiz questions. In other words, it acts as a digital library for past exams and quiz questions for students. Not only is this Qbank module useful to students, but also to teachers in such a way that it helps them to create many types of questions, store them in one place, reuse questions in different quizzes, organize questions by topic, maintain quality and consistency, and randomize tests for fairness. - **SCORM**: This enables instructors to upload, manage, and deliver standardized, interactive e-learning packages (SCORM/AICC compliant) directly within a course. It is used for tracking learner progress, completion status, time spent, and detailed quizzes. The module tracks question responses and final scores and sends completion status and grades to the gradebook. - **url**: This allows teachers to add external websites, documents, or online videos directly into a course page as a clickable link. It enables sharing resources like YouTube videos, articles, or images, with options to display them embedded, in a new window, or via pop-up - assign - **choice**: This is an interactive module, which allows teachers to ask a single question and offer multiple radio-button responses for students to select. It acts as a quick poll, voting tool, or for sign-ups, helping gauge student understanding. It is used to gather feedback or vote on course topics - Feedback: This allows teachers to create and conduct custom, non-graded surveys to collect feedback from students. It is ideal for course evaluations or gathering opinions. It is designed for qualitative and quantitative feedback, and allows custom questions, including multiple-choice, essay, and checkbox, with options for anonymity, such as on teaching, course content, or specific activities. - **Glossary**: This is for enabling instructors and students to create, maintain, and search a collaborative, dictionary-like list of definitions, key terms, or resources. It supports auto-linking, which highlights defined terms throughout the course, for instance, context-sensitive access to information - **Lti**: The Learning Tools Interoperability module enables seamless integration with external web-based tools and applications, acting as both a consumer (using external tools) and a provider (sharing content). It enables single sign-on, secure user data exchange, and grade synchronization between Moodle and third-party platforms - **Quiz**: enables instructors to design, create, and manage online assessments, ranging from simple reading checks to complex, high-stakes exams. It supports various question types, including multiple choice, true-false, short answer, and drag-and-drop. These are stored in a reusable Question bank. Quizzes can be randomized, timed, and configured for immediate or delayed feedback - **Subsection**: allows instructors to create nested, collapsible sub-headings within course topics or weeks, significantly reducing page scrolling and organizing content. It enables grouping related activities, applying restrictions to specific subsections, and enhances navigation via improved breadcrumbs, creating a cleaner, more hierarchical structure - **Wiki**: enables collaborative content creation by allowing users to collectively create, edit, and link web pages within a course. It acts as a shared, browser-based document repository for group projects, note-taking, or brainstorming. It supports both collaborative (class-wide) and individual wiki creation. ### 3.2.3. Repository The Repository System, hosted on ([http://repository.ruforum.org/](http://repository.ruforum.org/) ), is used as a central digital library to store, preserve, and share knowledge products generated through RUFORUM-supported activities. The system serves the following functions - **Storage and preservation of research and administrative outputs:** These include theses and dissertations, journal articles, conference papers, policy briefs, technical and project reports, and others, from research and other network activities. The shared resources MUST be Open Access or Open Educational Resources (OER). - **Knowledge sharing**: This helps to increase the visibility of the network and shares knowledge of RUFORUM-supported research amongst member universities, researchers and students, policymakers, development partners, and the public, among other stakeholders. - **Show impact and accountability**: This is in terms of showing evidence of outputs, especially projects that are funded The system provides the following functions: - **Upload of collections**: Here, resources are uploaded, and descriptions of the resources are provided to ease searching through the resources - **Searching through the resources:** This is to help end users find the required resources. This is done through 3 ways, including 1) using simple text/ keywords, 2) by browsing through the collections, which consist of categories, and 3) using advanced searches, which allows the use of multiple keywords to refine their search. **Figure 3. 3:** Simple text search interface **Figure 5:** Advanced text search (Top form) and using collections (bottom right with “browse”) ### 3.2.4. M&E and Feedback System The module is charged with the following functions - Monitoring framework routine - Evaluation of RUFORUM projects - Planning, scheduling activities, tracking expenditure on operations - Monitoring raw data - Integration with partner systems If a progress report for a specific project is required, - The project team provides the report - Provide data supporting the outputs - Consolidate the report into the RUFORUM secretariat report **Sources of the information ** - May be from a survey, e.g., Welfare change. These are conducted by consultants - If external, will require a study, e.g., for baseline - Universities Analysis is conducted to establish the current to the past performance. The deadlines may vary according to Universities or the secretariat's schedule. The metrics of success depend on the project objectives. ### 3.2.5. Alumni The alumni system/module in RUFORUM’s digital ecosystem refers to the part of the RIMS used to record, track, and engage graduates of RUFORUM programmes, enabling networking, career tracking, and ongoing communication with former students. The feature supports the following functions: - - **Tracking Graduates and Former Participants**: This involves capturing and storing contact details for graduates (alumni) of RUFORUM-supported programmes so the Secretariat can track where alumni are *working* and how they *contribute* to the sector. After graduation, informally arrange for paid graduate training and volunteer work. - **Alumni Engagement and Networking**: This supports alumni networking, connecting past students, sharing opportunities, events, jobs, or professional development. Many large alumni networks have online directories or forums for this purpose. - **Integration with Other Data**: Alumni data links with scholarship outcomes, tracer studies, and impact assessment to help RUFORUM understand how its training investments translate into careers and contributions – a key part of monitoring and evaluation. - **Communication**: The feature supports administrators to send emails, updates, and opportunities to alumni, maintain career profiles, and share sector news, strengthening engagement between RUFORUM and its former scholars. While specific details depend on implementation, this is a common purpose of alumni systems in organisational information systems - **Industry engagement and sharing feedback with Universities**: RUFORUM engages industry for alumni feedback through collaborative research,** **internships/attachments, innovation hubs, and tracer studies, ensuring graduates’ skills align with industry needs by involving companies in training, providing direct feedback channels, and assessing graduate performance in the workplace for continuous curriculum improvement and relevant skill development in agricultural value chains. RUFORUM also identifies employers to host students for internships and ensure graduates are market-ready. - **Curriculum development support**: Through engaging with employers to support the development of the curriculum. - **Tracer Studies**: RUFORUM conducts studies to track graduates' experiences in the labor market, gathering feedback from both graduates and potentially their employers on the relevance of their qualifications. - **Direct University-Industry Partnerships**: Universities are encouraged to package areas for support (e.g., Research for Development) and market themselves to industry, creating win-win scenarios that build feedback into the relationship ### 3.2.6. SME-hub The **SME-Hub** is an initiative hosted in the business development services unit that aims to support entrepreneurs and small businesses, particularly those emerging from or connected to the RUFORUM partner university innovation environment. RUFORUM designs and rolls out programs by leveraging its university network to build Agri-Enterprise Innovation Hubs (AIHs) that offer ***incubation***, ***training***, ***mentorship***, and ***funding***, focusing on research-driven solutions for local challenges, digital skills, and connecting youth to practical business opportunities in agriculture and beyond, fostering innovation, jobs, and economic growth through partnerships and blended learning. The key functions of the business development services are as summarised below: - - **Develop and Implement Strategies**: Design and roll out programs for business incubation, investment promotion, and digital economic growth. - **Partnership Building**: Forge strategic links with universities, businesses, and development partners. - **Capacity Building**: Enhance business skills, innovation, and entrepreneurship among students and faculty. - **Project Coordination**: Oversee projects related to job creation and market linkages - **Supporting business growth** **and development**: This is mainly through funding and business mentorship. The above functions are achieved through the following: - - **Business Incubation**: RUFORUM establishes AIHs within member universities to host the incubation centres. Through this, RUFORUM provides technical assistance, business and financial training, mentorship, and space for students to design, validate, and test business models. The aim is to nurture student-led ventures and turn research into viable, local solutions, creating jobs and addressing community needs. - **Investment Promotion and Funding**: Funding is offered from small proof-of-concept grants to seed funding for prototypes and connections to investors for growth. Entrepreneurs are connected to the private sector, government, and other funding agencies to bridge funding gaps. **Figure 3. 4: **High-level stakeholders At the time of the interview, the SME-Hub system was not in use, and all processes were run manually. The current SME-hub supports the following - **User registration**: During self-registration, one can choose user roles, including entrepreneur, mentor, or investor. **Figure 3. 5: Roles available in SME-HUB during self-registration** - **Calls**: The administrator to draft a call for application, which, if published, can be viewed by potential applicants. A draft call is not visible to the public or on the website. The calls may include SME funding opportunities, training, or other offers available for qualifying SMEs. The top section provides a filter to enable you narrow down your search by call status. Calls can be filtered further by clicking the header titles of the Calls table, i.e., Title (Alphabetical order or reverse), Status (Published and Drafts), and Expired (Valid vs. expired). Call records can be exported to Excel (xlsx format) using the Export link on the calls list page. Against the calls, the following are done - Edit call - Adding a guide for the judges, intended to set the sections under which the calls will be assessed, the marks, and instructions. However, the feature that is not yet operational - Selection of judges for the call from the available judges - View applications made on a call – once a call is submitted, it may be one of the statuses, including submitted, reviewed, accepted, or rejected. Certificates for specific business applicants can also be created - Deleting - **Business**: This enables admins to view/filter applications for business registrations, but also allows for manual registration of businesses from the backend. Only verified entrepreneurs can register their businesses. Entrepreneurs are provided an interface to register their businesses. The business details are received on the administrator dashboard. Once the administrator receives the new business details, they can view, edit, verify, and revoke the business - Request meeting: This provides a form for setting the meeting agenda, date, and time. Once scheduled, the entrepreneur can see the message on their dashboard, under the meetings link **Table 3: **Roles of the different stakeholders | **Administrator** | **Entrepreneur** | **Mentor** | **Investor** | | --- | --- | --- | --- | | Manage calls Receive applications Set the roles of users | Business registration Receives and sends messages regarding the meetings with the secretariat Participates in a mentor’s forum | Provides information on competencies and background information | Providing Financial Capital Supporting Business Development Facilitating Market Access | - **Mentor’s dashboard**: Mentors are professionals who build relationships with businesses and help them by imparting knowledge, expertise, and wisdom in specific areas of mutual interest The processes and systems face the following challenges: Usability challenges **Figure 3. 6: **Current registration form for businesses New entrepreneurs may be required to enter their details before receiving a verification email, after which the details are not saved. Hence, frustrating to the user. ## 3.3. The Integrated RUFORUM Digital Ecosystem The set of systems, combined, creates a fully integrated innovation ecosystem for RUFORUM. RIMS (M&El), the Regional E-Learning Platform, the Repository, and the SME Hub, when viewed in an ecosystem context, contribute to the overall RUFORUM objective of strengthening higher education, research, innovation, and enterprise development across Africa. Each system performs a distinct function, but together they form a seamless value chain that transforms funding into measurable impact. At the foundation of this ecosystem is the RIMS, which serves as the operational backbone of RUFORUM’s programs. It manages scholarships, grants, fellowships, and innovation challenges by registering beneficiaries. Whereas the RIMS contains features such as tracking project implementation, monitoring budgets, and capturing outputs, these are better placed in M&El. Every funded activity, whether a PhD research project, a postdoctoral fellowship, or an innovation grant, is recorded and monitored through RIMS. To impose modularity, monitoring of these may be moved to M&E. As projects are implemented, knowledge and intellectual outputs are generated. These outputs—including theses, publications, datasets, policy briefs, and innovation technical documents are stored and disseminated through the RUFORUM Repository. The Repository serves as the network's institutional memory and knowledge archive. It preserves research outputs, enhances visibility, and ensures that knowledge generated through RUFORUM investments remains accessible to universities, policymakers, innovators, and development partners. Parallel to research implementation, the Regional E-Learning Platform strengthens human capital development. It delivers structured training programs, professional development courses, entrepreneurship modules, and blended learning support for scholars and innovators. Beneficiaries tracked in RIMS access courses through the E-Learning Platform, building competencies that enhance research quality, leadership capacity, and enterprise readiness. Learning data and completion records can inform M&E processes. The SME Hub extends the ecosystem from knowledge generation to commercialization and societal impact. Innovations emerging from RUFORUM-supported research, Universities and innovation hubs, or captured in the Repository, are identified for incubation, mentorship, and market linkage within the SME Hub. The Hub connects entrepreneurs, researchers, investors, and industry partners, facilitating startup development, technology transfer, and enterprise growth. In this way, research does not remain confined to academia; it evolves into viable businesses and scalable solutions addressing agricultural and development challenges. Overarching all these systems is the M&E framework. M&E synthesizes data from RIMS, the Repository, the E-Learning Platform, and the SME Hub to measure outcomes and long-term impact. It tracks indicators such as graduation rates, research outputs, policy influence, the number of enterprises and jobs created, and community benefits, among others. This evidence supports donor reporting, strategic planning, and continuous improvement. Additionally, insights from M&E inform future program design, funding priorities, and system enhancements, hence completing the feedback loop. **Figure 3. 7: **RUFORUM System relationships and Purpose Figure 3.7 shows the RUFORUM systems interconnection in which the regional innovation and learning ecosystem follows a connected, yet currently fragmented, pathway. Funding and program design are managed through the RIMS, ensuring that initiatives are strategically planned. The knowledge generated from these programs is captured and preserved in the institutional Repository, making it accessible for research and reference. Learners and stakeholders then strengthen their capacity through the regional E-Learning Platform, applying insights gained to practical challenges. Innovations emerging from this process are commercialized via the SME-Hub, fostering entrepreneurship and regional development. Finally, the impact of these efforts is measured through Monitoring and Evaluation, with lessons learned feeding back into new investments and program designs, creating a continuous cycle of improvement and knowledge-driven impact. Rather than functioning as isolated platforms, these systems collectively enable RUFORUM to move from capacity building to knowledge creation, from innovation to enterprise development, and from activity tracking to measurable developmental impact. The integrated architecture ensures that every investment in scholarships, research, and innovation contributes to sustainable transformation in African higher education and agricultural systems **Table 4: **Strategic relationship summary of the systems | **System** | **Core Function** | **Source of data** | **Feeds Into** | | --- | --- | --- | --- | | RIMS | Fund management | Program data | M&E, Repository | | M&E | Impact measurement | RIMS, SME Hub, E-learning, repository | Strategy & donors | | E-learning | Training & capacity building | RUFORUM programs | SME Hub, M&E | | Repository | Knowledge storage | Research projects and RIMS, SME Hub, E-learning, repository | SME Hub, M&E | | SME-Hub | Commercialization | Repository, E-learning | M&E | **Table 5: **Current Application Landscape | **System** | **Purpose** | **Integration Level** | | --- | --- | --- | | RIMS | Research & grants | Low | | SME-Hub | SME incubation | Standalone | | E-Learning | Online training | Partial | | Repository | Publications | Manual linkage | | Alumni | Tracking | Disconnected | ## Problems Faced with RUFORUM Systems The problems/challenges cited by the processes include; ### 3.3.1 Challenges in RIMS The system is faced with the following challenges: - - **Lack of Documentation:** System upgrades are currently performed without formal technical documentation, relying instead on verbal or ad-hoc user requirements. Critical system knowledge resides with a few key individuals, who maintain the system. If these employees leave, the knowledge is lost, leading to disruptions and making it difficult for others to assume their responsibilities. Additionally, training new hires is a time-consuming and inefficient process without structured, step-by-step guides. The dashboard lacks a quick guide on what each of the terms means, which may cause confusion to new system users. - **Poor user interface designs:** During registration, a user is required to enter the institution by typing in the name. This results in data inconsistencies that result from diverse formats fed into the system, making backend processing complex. Users who are not part of the partner institutions may also register and proceed with the application process, only to later be told they are ineligible. This causes frustration to applicants in that category. Implementing robust validation rules and error messages adds significant development time and cost. - **Mandatory registration**: The extra step to register before even seeing the value from the system deters users, causing them to leave for sites with immediate access. - **Registration Form:** The registration form uses emails to uniquely identify applicants. This poses a challenge, especially for unsuccessful applicants who use it to register as different individuals using different email addresses. Fields such as a high level of qualification may be entered much later, when one wishes to apply for the available opportunities. - **Provision for multiple institution affiliation:** While users can belong to more than one institution, the system lacks a standardised dropdown mechanism to manage multiple institutional affiliations, requiring manual entry. **Figure 3. 8: **Registration form for users - **Multilingual Support**: Although the interface shows options for French, Arabic, and Portuguese, these functions are not yet supported. - The call management Call Management and Distribution feature has the following challenges: - **Notification Gaps:** The module lacks an automated notification feature when new calls are added. This may cause delayed information access when individuals fail to immediately manually communicate the new information.  Users must manually check the system for updates, leading to delays in accessing critical new information. Additionally, users might resort to alternative, less efficient communication channels (e.g., emails, phone calls) to confirm whether new information has been uploaded, adding redundant communication layers  - **Manual Call Coordination Workflows**: Call managers from different departments prepare calls, but the distribution process relies on manual coordination between the call manager, the secretariat communication officers, and the partner Universities. This results in misinterpreted digital messages, a lack of spontaneous interaction, and difficulty building rapport. - **Inconsistent Interview Requirements Across Call Types**: Different call types have different interview requirements. Some grants require interviews, while others do not. Some grants have budgets attached upfront, while others only receive budgets after presentations are reviewed. The system does not clearly differentiate or manage these variations. - **Inadequate Grant Progress Tracking and Reporting**: The system lacks comprehensive monitoring and evaluation (M&E) functionality for tracking grant progress. While grantees are required to submit reports at 3, 6, and 9-month intervals, the system does not provide administrators with summaries showing the number of beneficiaries, how many have completed their grants, how many have submitted reports, and who has not submitted. Additionally, there is no visibility into delayed reports or budget utilisation metrics. Hence, it is difficult to assess risk profiles and maintain fund integrity, potentially resulting in significant losses. The absence of automated analytics may result in reliance on manual processes and spreadsheets for data management and reporting, which are time-consuming, prone to human error, and hinder scalability as data volumes increase. Secretariat also struggles to gain a holistic and real-time view of its programme performance. - The review and evaluation process are faced with the following challenges: - - **Manual Two-Level Validation:** The system relies entirely on manual validation processes at two levels: first-level document verification (CV, letter) and second-level eligibility checks (degree level, nationality), with no automated system support. - **Lack of an automated Conflict Resolution:** When multiple reviewers provide conflicting recommendations (e.g., one reviewer recommends “***reject***” while another recommends “minor review”), the system lacks an automated mechanism to handle these discrepancies. The decision-making process remains manual. - **Inconsistent Evaluation Workflo**w: Different call types (scholarships, grants, fellowships, and challenges) follow varying evaluation processes, but there is no standardized protocol for how evaluations should be entered and tracked across call types. - **Manual Review Template Distribution:** Review templates and evaluation requests are often sent via email or external communication channels rather than being fully integrated within the system's workflow. System users spend significant time on repetitive, low-value tasks like data entry, which wastes time that could have been used for more productive tasks. - **Lack of Automated Eligibility Filtering: **Ineligible applicants are manually identified and set aside rather than being automatically filtered by the system based on predefined eligibility criteria. - **Manual Reviewer Workload Distribution:** With large application volumes, reviewer assignments are split manually (e.g., 50/50 distribution) without system-level support for equitable workload management. - **Absence of Anonymisation Features: **The review process lacks built-in functionality to anonymise applicant identities during evaluation, which may introduce reviewer bias. The Interview Scheduling and Verification is faced with the following challenges: - - **Manual Interview Scheduling:** The call manager is responsible for manually scheduling interviews after the review process, with no system-integrated scheduling functionality. - **Failure of the system to close out projects**: The system is unable to close out projects, which causes students to claim funds much later after project time expiry, and when funds are no longer available ### 3.3.2. Challenges faced by REP The regional E-learning platform is faced with the following challenges Because the system is not integrated with other institutional platforms, data is fragmented across multiple systems, making it difficult to generate comprehensive and accurate reports. This fragmentation limits the platform’s ability to effectively track learner progress across different universities at a regional level, measure the overall impact of its programs, and support informed, data-driven decision-making. As a result, stakeholders may lack a clear, consolidated view of performance and outcomes, which weakens strategic planning and reduces the overall effectiveness of the e-learning initiative. The lack of integration results in fragmented data and isolated workflows, making it difficult to share learner information, track research outputs, or leverage alumni engagement effectively. Users must manually transfer information between platforms, increasing administrative workload and the risk of errors. Furthermore, the absence of seamless connectivity limits opportunities for cross-platform analytics, consolidated reporting, and coordinated program management, thereby reducing the overall efficiency, effectiveness, and impact of RUFORUM’s regional e-learning initiatives. **It’s difficult to accurately track how long learners spend engaging with course content**. Due to limited system capabilities and a lack of integration with advanced learning analytics tools, the platform cannot reliably capture detailed user engagement metrics such as time spent reading materials or interacting with resources. This makes it difficult for instructors and administrators to assess actual learner participation, distinguish between active and passive engagement, and evaluate the effectiveness of course content. Consequently, the absence of precise engagement data weakens monitoring, reduces the quality of learner performance analysis, and limits the ability to improve content delivery based on real user behaviour. **Poor content navigation**: This is caused by limitations in the authoring tools used to develop learning materials. The tools do not provide a well-structured or intuitive way to organize content, resulting in cluttered and inconsistent navigation elements. Learners often encounter multiple or repeated buttons such as “Next” and “Previous,” which can be confusing and disrupt the learning flow. This lack of clear and streamlined navigation makes it difficult for users to move through course content efficiently, leading to frustration, reduced engagement, and a less effective overall learning experience. **Requirement for enrollment keys in closed courses on Moodle:** While intended to control access, this extra step can create a barrier for learners who may not readily have the key or do not understand how to obtain it. As a result, interested users may abandon the enrollment process altogether, leading to reduced participation and missed learning opportunities. This friction in the onboarding experience can negatively affect course uptake, particularly for new or less technically experienced learners, ultimately limiting the platform’s reach and effectiveness. ### 3.3.3. Challenges faced by the Repository The repository is faced with the following challenges - **Lack of an ordering criterion**: This leads to difficulty in finding specific items, which increases the time it takes to return results, especially as the number of documents grows. Users have no way to sort or filter the repository by relevance, date, name, or any other metadata, increasing the time it takes to locate the desired information. Identification of duplicates is also hard to achieve. Moreover, the lack of organization leads to user frustration and leads to a steep decline in the adoption and effective use of the repository system. Recently added articles are displayed first under the “*materials/resources*” list. - **Lack of a unique identifier for authors**:  It is nearly impossible to distinguish authors who share common names, and hence, their contributions, without additional identifying information like affiliations, ORCID, or email addresses may be missed. Additionally, authors who change their names may not be mapped to their works. Hence, the challenges result in reduced discovery and impact of the respective researchers. - **Limited Statistics**: The system gives only the number of reads of a particular document, leaving out essential document *performance*, *usage*, and *compliance. *These may include visit Frequency, download counts, search frequency, activity logs, etc - **Inconsistencies in feature naming**: e.g., “*private area*”, which contains categories of documents such as published, unpublished, documents created by specific users, etc. - **Lack of interface with other systems**: The repository is not connected to other systems such as RIMS and M&EL, and hence several outputs are missed. - Limited advanced insights: Advanced impacts, which may be achieved through machine learning, are not yet possible with the current version of the system. These show impact by automating document classification (e.g., sorting research papers by discipline, country, etc.), intelligent information extraction (such as pulling key dates), summarization and synthesis of lengthy articles or reports, and predictive analytics such as forecasting research trends or identifying risks. - **Cluttered interface**: There is a lot of unnecessary information, which negatively affects the user experience - **Notifications on uploading documents:** The administrator cannot configure or determine the recipients of the notifications sent each time new documents are uploaded - **Currently, no quality assurance **guidelines are available to guide the process of filtering documents** ** ### 3.3.4. M&EL Challenges The M&E is faced with the following challenges **Manual processes**: A significant challenge faced by RUFORUM and similar regional initiatives is the reliance on manual Monitoring and Evaluation (M&E) processes. When M&E is conducted manually, data collection, entry, and analysis become time-consuming, error-prone, and inconsistent. This limits the ability to quickly track program performance, measure impact, or generate accurate reports for decision-making. Additionally, manual processes make it difficult to consolidate information from multiple projects, universities, or platforms, reducing the timeliness and reliability of insights. As a result, program managers may struggle to identify gaps, respond to emerging issues, or make data-driven adjustments, ultimately weakening the effectiveness and strategic oversight of capacity-building and innovation initiatives. **Absence of a formal Monitoring and Evaluation (M****&****E) framework to guide M****&****E processes**. Without a standardized framework, there is no clear structure for defining indicators, setting targets, or determining the methods for data collection and analysis. This leads to inconsistent practices across projects and universities, making it difficult to measure performance, assess impact, or compare results over time. The lack of guidance also increases the risk of missing critical data, misinterpreting outcomes, and producing reports that are incomplete or unreliable. Consequently, decision-making, strategic planning, and accountability are weakened, and opportunities to learn from past experiences and inform future investments are significantly limited. **Absence of integration **between the M&E and other systems being monitored, such as RIMS, the Repository, and the SME Hub. This lack of connectivity leads to fragmented and siloed data, making it difficult to track key indicators across the entire program lifecycle. M&E teams are forced to manually collect, consolidate, and reconcile information from multiple sources, which is time-consuming and increases the risk of errors or inconsistencies. As a result, the quality, timeliness, and reliability of M&E reports are compromised, limiting the ability of program managers to make evidence-based decisions, measure impact accurately, and inform future investments effectively. **Failure to consistently reach out to data sources over time**: When data collection is irregular or delayed, there are gaps in the information needed to monitor programme performance, track learner progress, or evaluate innovation outcomes. This discontinuity prevents timely identification of trends, emerging issues, or areas requiring intervention, undermining the accuracy and usefulness of M&E reports. Consequently, program managers and stakeholders are unable to make fully informed, evidence-based decisions, and the ability to measure impact or adjust strategies for improved effectiveness is severely constrained ### 3.3.5. Alumni Challenges Management of the above functions is done manually using Excel sheets, and faces the following challenges: - - **Incomplete and Outdated Alumni Data**: Alumni information is collected while at the university, and when students are mostly using institutional email addresses. Once the students leave the Universities and lose their email addresses, their contacts are lost. Other reasons include low registration and profile completion rates, outdated contact information due to alumni mobility, and a lack of standardized data fields across cohorts and universities. These challenges make it difficult to track alumni impact, engagement, and career progression. - **Limited Digital Functionality**: The alumni platform lacks advanced networking features, poor integration with social media and professional platforms, and limited analytics and reporting capabilities, leading to reduced user engagement and weak data-driven decision-making. - **Low Alumni Engagement and Participation**: There is limited perceived value of the alumni feature, and irregular communication and updates. - **Poor Integration with RUFORUM Core Programs:** The Alumni feature is not fully embedded in research, innovation, and policy programs, and lacks alumni involvement in mentorship, proposal review, or policy dialogues, which leads to missed opportunities to leverage alumni knowledge and networks. - **Monitoring and Impact Measurement Gaps**: There are no clear KPIs for alumni engagement and impact, and weak feedback and reporting mechanisms, leading to difficulty in demonstrating alumni value to stakeholders and donors. - **Manual engagements**: Manual engagement through virtual and physical, in-person meetings often faces inefficiency, logistical hurdles, and limited scalability. Key obstacles include high costs and time consumption, difficulties with scheduling, limited documentation, and lower flexibility compared to modern digital alternatives. These often rely on manual, manual note-takers, which often results in incomplete records or missed action items - **Lack of a structured, systematic way of engaging partners: **This can lead to inefficiencies, strained relationships, and project failures. When partnerships are managed haphazardly, they frequently suffer from communication breakdowns, misaligned goals, and unclear roles.  Poor collaboration discourages partners from sharing, brainstorming, or challenging the status quo. ### 3.3.6. SME-hub Challenges The SME-Hub is faced with the following challenges A key challenge facing the SME-Hub is that **the system lacks the intelligence to generate tailored funding opportunities and personalized course recommendations** for users. Without this capability, entrepreneurs and innovators receive generic information that may not align with their specific needs, stage of business development, or sector focus. This limits the platform’s ability to connect users with the most relevant grants, investment options, or skill-building programs, reducing engagement and slowing the commercialization of innovations. As a result, the SME-Hub cannot fully optimize support for regional enterprises, and users may miss critical opportunities that could enhance growth, competitiveness, and impact. **Most user profiles remain incomplete: **Missing or inconsistent information, such as business details, funding preferences, or skill sets, hampers the platform’s ability to match users effectively with relevant opportunities, resources, or collaborations. This lack of complete profiles reduces the efficiency of networking, slows the identification of suitable investors or partners, and limits the platform’s capacity to provide personalized recommendations. Consequently, the SME-Hub’s effectiveness in supporting innovation, facilitating funding, and driving enterprise growth across the region is significantly constrained. The platform **does not provide a clear or easily trackable follow-up pathway**: This makes it difficult to monitor ongoing interactions, assess progress on mentorship guidance, or track the status of funding negotiations. Without a structured follow-up mechanism, important opportunities may be delayed or lost, accountability is weakened, and both innovators and supporters may struggle to maintain engagement. As a result, the platform’s ability to facilitate sustained support, measure outcomes, and ensure that connections translate into tangible business growth is significantly limited. SME-Hub is that it is not integrated with the Go to market Studio (GTM) platform, where onboarding and initial training of new innovators is done. This lack of connectivity forces the secretariat to enter the same data separately into both platforms, resulting in duplicated records and increased administrative workload. The redundancy not only wastes time but also raises the risk of inconsistencies and errors in user profiles, training records, and progress tracking. Consequently, the platform’s efficiency is reduced, data quality suffers, and the ability to generate accurate reports or provide seamless support to innovators is significantly constrained. **Absence of clear, standardized guidelines for assessing the credibility of both entrepreneurs and funders** on the platform. Without well-defined criteria or verification processes, it becomes difficult to distinguish trustworthy participants from potentially unreliable or fraudulent ones. This uncertainty can discourage genuine entrepreneurs from seeking funding and make investors hesitant to commit their resources, ultimately undermining confidence in the ecosystem. Additionally, the lack of transparency and consistent evaluation metrics increases the risk of poor decision-making, mismatched partnerships, and financial losses, which can slow the growth and effectiveness of the SME-HUB as a reliable marketplace for business development. ## Risks and mitigation of Integrating the Systems Integrating the digital platforms presents significant opportunities for improving efficiency, data-driven decision-making, and regional collaboration. However, this integration also introduces a range of technical, operational, and governance-related risks, particularly given RUFORUM’s distributed network of member universities across multiple countries with varying capacities and infrastructure. Key challenges such as data inconsistency, system interoperability, user management, and cybersecurity must be carefully managed to ensure a seamless and sustainable integration process. Table 5 outlines the major risks associated with system integration and proposes practical mitigation mechanisms to enhance reliability, strengthen institutional trust, and support the long-term success of RUFORUM’s digital ecosystem. **Table 6: Risks and mitigation mechanisms of integrating systems ** | **Risk** | **RUFORUM-Specific Context** | **Mitigation Strategy** | **Severity** | **Likelihood** | | --- | --- | --- | --- | --- | | Fragmented data across member universities | Data is generated and stored across multiple universities in different countries with varying standards and systems | Develop a RUFORUM-wide data governance framework; enforce standard data templates and metadata across institutions | High | High | | Inconsistent data quality from nodes | Member universities have different capacities for data entry, validation, and management | Build capacity through training; introduce automated validation rules and periodic data quality audits | High | High | | Limited interoperability between existing platforms | Systems like e-learning, RIMS, SME-Hub, and repository may have been developed independently with limited integration readiness | Implement middleware/API layer; adopt interoperable standards and phased integration approach | High | Medium | | Weak identity and access management across systems | Users (students, alumni, researchers, entrepreneurs) may have multiple accounts across platforms | Introduce centralized identity management (Single Sign-On) with role-based access across all RUFORUM systems | High | Medium | | Connectivity and infrastructure variability | Some member universities face unreliable internet and limited IT infrastructure | Use cloud-based, low-bandwidth-optimized solutions; enable offline capabilities where possible | High | High | | Data security and cross-border compliance risks | Data flows across multiple countries with different data protection regulations | Develop a unified data protection policy aligned with international standards; implement encryption and access controls | High | Medium | | Lack of standardized guidelines in SME-Hub and alumni systems | Weak or absent frameworks for verifying entrepreneurs, alumni credentials, and funders reduces trust in the ecosystem | Develop clear verification protocols, accreditation links with universities, and rating/reputation systems | High | High | | Institutional resistance and change management challenges | Universities operate autonomously and may resist centralized systems or new workflows | Engage stakeholders early; create incentives; implement structured change management and communication plans | Medium | Medium | | Misalignment of M&E indicators across programs | Different RUFORUM programs and grants use varying indicators, making integration difficult | Harmonize M&E frameworks; define core indicators and integrate dashboards across systems | Medium | Medium | | Sustainability and funding constraints | Integration requires ongoing funding for development, hosting, and support beyond project cycles | Develop a sustainability model (member contributions, donor alignment, cost-sharing mechanisms) | High | Medium | | Skills gaps in system administration and use | Limited technical expertise at some nodes affects adoption and maintenance | Provide continuous training, certification programs, and centralized technical support | Medium | High | | Dependency on external vendors/consultants | Some systems may rely on third-party developers, limiting internal control and flexibility | Ensure knowledge transfer, proper documentation, and gradual internalization of technical capacity | Medium | Medium | ## Data structure ### Data domain Business functionality/domain mapping is a critical step in system integration because it provides a clear, structured view of **which system supports which business processes**, enabling informed decisions about how the integrated ecosystem should operate. By identifying overlaps, gaps, and unique strengths across systems, this mapping helps avoid duplication of functionalities, ensures that each business process is anchored in the most appropriate “system of record,” and supports the definition of efficient data flows between systems. It also enhances interoperability by clarifying dependencies and integration points, making it easier to design APIs, data exchange mechanisms, and workflows. Furthermore, such mapping strengthens governance and accountability by assigning ownership of specific functions to particular systems, while guiding harmonization of processes across the enterprise. Ultimately, it ensures that the integrated system delivers a cohesive user experience, improves operational efficiency, and enables accurate, consolidated reporting and decision-making. **Table 7: **Systems business application mapping across systems | **Business Functionality / Domain** | **E-Learning Platform** | **Alumni System** | **SME-Hub** | **Funding System (RIMS)** | **M****&****E System** | **Repository** | | --- | --- | --- | --- | --- | --- | --- | | User Registration and Profile Management | Yes | Yes | Yes | Yes | Yes | Yes | | Authentication and Access Control | Yes | Yes | Yes | Yes | Yes | Yes | | Training and Capacity Building | Yes | Limited | Yes | Yes | Limited | No | | Knowledge Sharing and Content Access | Yes | Yes | Yes | Limited | Yes | Yes | | Research Output Management | No | Limited | No | Yes | Yes | Yes | | Project/Grant Management | No | No | Limited | Yes | Yes | No | | Monitoring and Reporting | Limited | Limited | Limited | Yes | Yes | No | | Networking and Collaboration | Yes | Yes | Yes | Limited | Limited | No | | Innovation and Enterprise Support | No | Limited | Yes | Limited | No | No | | Funding and Investment Management | No | No | Yes | Yes | No | No | | Data Collection and Surveys | Limited | No | Yes | Yes | Yes | No | | Performance Tracking and Analytics | Yes | Yes | Yes | Yes | Yes | Limited | | Document and Resource Repository | Yes | Limited | Limited | Yes | Yes | Yes | | Verification and Accreditation | Yes | Yes | Yes | Yes | Limited | No | | Communication and Notifications | Yes | Yes | Yes | Yes | Yes | Limited | ### 3.5.1. Data domains and Entities Providing clearly defined data domains and data entities across the systems of RUFORUM systems is a critical foundation for successful systems integration. By establishing a shared understanding of what data exists (such as users, projects, grants, courses, SMEs, and research outputs) and how these entities are structured, RUFORUM can ensure consistency, interoperability, and data quality across its distributed platforms. This common data framework reduces duplication, enables seamless data exchange, and supports unified reporting and analytics across programs and institutions. Moreover, it provides a basis for designing integration mechanisms such as APIs, and master data management systems, ultimately improving coordination, decision-making, and the overall efficiency of RUFORUM’s digital ecosystem **Table 8: **Data Domains and Data Entities | **Key Entities** | **Systems Where a Relationship Exists** | **Relationship Type** | **How to Connect the Entities (Integration Approach)** | | --- | --- | --- | --- | | User ↔ Course | E-Learning, Alumni, M&E | A user enrolls in / completes a course | Use a **unique User ID** across systems; sync course enrollment and completion via APIs | | User ↔ Alumni | Alumni, E-Learning, SME-Hub, RIMS | A user becomes an alumnus after program completion | Maintain lifecycle status field in user profile; trigger updates upon graduation | | User ↔ SME | SME-Hub, Alumni, M&E | A user owns or participates in an SME | Link via **User ID as SME owner/participant**; maintain SME membership table | | User ↔ Grant/Application | RIMS, M&E, Alumni | A user applies for or manages grants | Use **User ID mapped to application records**; integrate application tracking APIs | | Project ↔ Grant | RIMS, M&E | A grant funds a project | Assign **Grant ID to Project ID**; synchronize project lifecycle data | | Project ↔ SME | SME-Hub, M&E, RIMS | Projects may be implemented through SMEs | Link **SME ID to Project ID**; track implementation roles | | Course ↔ Research Output | E-Learning, Repository | Courses may produce or reference research outputs | Use **Course ID linked to Repository Item ID** via metadata tagging | | Research Output ↔ Project | Repository, RIMS, M&E | Research outputs are generated from projects | Tag outputs with **Project ID**; enforce metadata standards | | Alumni ↔ SME | Alumni, SME-Hub | Alumni create or support SMEs | Link **Alumni ID to SME ID**; track entrepreneurial activity | | Alumni ↔ Project | Alumni, RIMS, M&E | Alumni participate in funded projects | Map **Alumni (User) ID to Project roles** | | SME ↔ Funding/Investment | SME-Hub, RIMS | SMEs receive funding or investment | Integrate **SME profiles with funding records** using SME ID | | Indicator ↔ Project | M&E, RIMS | Projects are measured using indicators | Link **Indicator IDs to Project IDs**; standardize indicators | | Indicator ↔ Course/Training | M&E, E-Learning | Training effectiveness is measured | Map **training outcomes to indicators** via reporting layer | | Document/Resource ↔ User | Repository, E-Learning, Alumni | Users upload or access documents | Use **User ID for ownership and access control** | | Document ↔ Project/Grant | Repository, RIMS, M&E | Documents support grants/projects | Tag documents with **Project/Grant IDs** | | Institution ↔ User | All Systems | Users belong to member universities | Use **Institution ID linked to User profiles** | | Institution ↔ Project/Grant | RIMS, M&E | Institutions implement projects/grants | Map **Institution ID to Project/Grant records** | ### The data domain mappings provides the following **Key Integration Insights** - User ID is the central anchor entity** **across all systems** ** - Project and Grant entities form the backbone** **of RIMS and M&E integration** ** - SME and Alumni linkage is critical** **for innovation tracking and impact measurement** ** - Repository acts as a shared knowledge layer**, **linking research, courses, and projects** ** - Standardized metadata (IDs, tags, indicators)** **is essential for seamless interoperability # 4. Project execution ## 4.1. System Update roadmap The overall objective is to transition from partially connected platforms to a** **secure, interoperable, scalable digital ecosystem that supports capacity building, research management, commercialization, and impact tracking. ## 4.2. Stakeholder analysis RUFORUM member ***universities*** and ***TVETs*** prepare students and develop their skills for the graduate labour market through work-integrated learning schemes. Through research and innovation, Universities advance knowledge through the discovery, dissemination, and application of gender responsive research within and across disciplines. Through community engagement, Universities in liaison with RUFORUM engage society to enhance economic, social, and cultural well-being by facilitating knowledge transfer to practice. Table xxx provides the stakeholder interests from the systems. **Table 9****: **Stakeholder interests (** shows primary system for the stakeholder) | | **RIMS** | **M****&****E** | **Repository** | **SME-Hub** | **REP** | | --- | --- | --- | --- | --- | --- | | RUFORUM Secretariat | Beneficiary management, funding support processing, and beneficiary onboarding | Consolidated impact reporting and KPI dashboards, Core project tracking, and financial monitoring | Visibility of research outputs | Enterprise management | Training participation management | | Donors and development partners | | Impact metrics and aggregated reports, financial tracking, milestone reporting, and start-up or job creation metrics | Evidence of research outputs | | | | Member University Leadership | Funding opportunities | Institutional performance indicators | Showcases university research outputs | | Staff and student training opportunities | | Researchers and Faculty | Grant, fellowship, and challenge opportunities | Grant application and reporting | Publication storage and visibility | Innovation and commercialization support | Skills development and training opportunities | | Students (Scholarship Beneficiaries) | Scholarship opportunities | | Thesis submission and visibility | Entrepreneurship support | Course access and certification | | Entrepreneurs and Innovators | | enterprise performance | Source of innovations | Start-up incubation and investor matching | Entrepreneurship training | | Investors and the Private Sector | | Performance metrics | ******Technology background evidence | Start-up profiles and matchmaking | | | Governments and Regulators | | **Aggregated indicators, Graduate and project data | **Research publications | | | ## 4.3. Proposed system features ### 4.3.1. Grand Administration (Formerly RIMS) **Action Plan and Recommendations** To address the identified technical challenges and ensure the RIMS system meets the needs of the RUFORUM network, the following actions are recommended: - - **System Administration and Documentation**: Establish Formal Documentation Protocol: Implement a comprehensive documentation framework for all system upgrades, feature changes, and modifications. This should include technical specifications, user requirements, implementation steps, and testing procedures. All upgrades should be documented before deployment to ensure consistency and enable knowledge transfer. - **Registration**: Implement Institution Dropdown with Custom Entry Option: Create a standardised dropdown menu for institutional selection that includes all RUFORUM partner universities and T-VETs. Include an option to add institutions not in the predefined list, with a validation process to ensure data consistency while allowing flexibility for non-consortium institutions. - **Introduce Guest View or Preview Mode**: Develop a guest preview functionality that allows potential applicants to view available calls and system features without requiring account creation. This will reduce barriers to entry and improve user engagement. - **Streamline Registration Form**: Review and reduce the length of the registration form by consolidating related fields, making non-essential fields optional, and implementing progressive disclosure (showing additional fields only when relevant). Prioritise essential information collection. - **Establish Automated Notification System**: Develop an automated notification mechanism to alert registered users about new calls matching their interests. This should include email notifications, in-system alerts, and optional SMS notifications to reduce reliance on informal networks. - **Standardise Call Preparation and Distribution Workflow**: Create a standardised, documented process for call managers to prepare and upload calls. Implement a centralised call management interface where all call types (grants, scholarships, fellowships, challenges) follow consistent workflows, reducing manual coordination. - **Clarify Call Type Definitions and Requirements:** Develop and document clear definitions for each call type (grants, scholarships, fellowships, challenges) with explicit guidance on interview requirements, budget submission timing, and evaluation processes. Implement system-level indicators to communicate these differences to applicants. - **Implement Standardised Call Type Configurations**: Create predefined call type templates in the system that automatically configure interview requirements, budget submission options, and evaluation workflows based on the selected call type, reducing manual coordination and inconsistencies. - **Multilingual Support: **Activate Multilingual Interface Modules: Prioritise the activation and testing of French, Arabic, and Portuguese language modules. Ensure all system interfaces, notifications, and documentation are available in these languages to support the multilingual nature of the RUFORUM consortium. - **Review and Evaluation: **Automate First-Level Document Validation: Transition the first-level manual validation of required documents (CV, letter) to an automated system check. Implement file type and size validation, and automated notifications to applicants about missing documents. - **Implement Automated Eligibility Filtering**: Develop system-level eligibility checks based on predefined criteria (e.g., degree level, nationality, institutional affiliation). Automatically filter ineligible applicants at the validation stage and provide clear feedback on rejection reasons. - **Establish Conflict Resolution Protocol for Reviewer Disagreements**: Define and implement a clear, automated protocol for resolving conflicting reviewer recommendations. Options include: majority voting, average score thresholds, escalation to a senior reviewer, or weighted scoring based on reviewer expertise. Document the protocol and make it transparent to all stakeholders. - **Standardise Evaluation Workflow Across Call Types**: Create a unified evaluation framework that accommodates different call types while maintaining consistent data capture and tracking. Implement standardised review templates with required and optional fields, ensuring all evaluations are entered directly into the system. - **Integrate Review Template Distribution Within System**: Move review template distribution from email to an integrated system workflow. Automatically assign reviewers, send review requests through the system, and track submission status within the platform. - **Implement Equitable Reviewer Workload Distribution**: Develop a system-level mechanism to automatically distribute applications among reviewers based on availability and expertise. Track workload in real-time and provide administrators with visibility into reviewer assignments and progress. - **Add Anonymisation Features to Review Process**: Implement built-in functionality to anonymise applicant names and identifying information during the review process. Allow reviewers to evaluate applications based on merit without knowing the applicant's identity, reducing potential bias. - **Interview Scheduling and Verification: **Develop a system-integrated interview scheduling module that allows call managers to schedule interviews, send automated invitations to applicants, manage calendar availability, and track interview status. This should include integration with calendar systems where possible. - **Standardise External Verification Processes**: For call types requiring phone verification or in-person meetings (e.g., scholarships), create standardised verification templates and workflows within the system. Ensure all verification results and findings are recorded in the system rather than maintained externally. - **Automate Verification Result Entry**: Develop a structured form or template for recording verification results (phone checks, parent meetings, etc.) directly into the system. This ensures consistent data capture and maintains audit trails. - **Automate selection process**: Implement automated selection functionality that ranks applicants based on average reviewer scores and applies predefined selection criteria. Allow administrators to set target numbers and automatically generate shortlists, reducing manual data downloads and external processing. Define and document clear selection criteria for each call type, including target numbers, minimum score thresholds, and tie-breaking rules. Implement these criteria in the system to ensure consistent and transparent applicant selection. - **Grant Budget Tracking**: For grants with upfront budgets, implement budget tracking functionality that monitors expenditures against approved budgets. For grants with deferred budgets, create a workflow to assign budgets after technical review and track their utilisation. - **Data Management and Reporting: **Improve Template-Based Data Capture: Enhance the system to not only capture which data fields are required but also preserve and display the actual content submitted by applicants. Ensure all submitted documents and information are accessible within the system for review and analysis. - **Standardise Template Structure**: Develop a standardised template structure for all call types and evaluation processes. This should include consistent field definitions, data types, and validation rules to ensure uniform data capture and reporting. - **Establish Data Retention and Archival Policies**: Implement clear policies for data retention, archival, and deletion. Ensure historical call data and evaluation records are preserved for audit and learning purposes while maintaining system performance. - Linking the system to professional pages **Table 10**: RIMS Action Plan Summary | **NO.** | **Item** | **Sub Item** | **Challenge** | **Action to Move Forward** | | --- | --- | --- | --- | --- | | 1 | System Administration and Documentation | 1. Formal Documentation Protocol | System upgrades are performed without formal technical documentation, relying on verbal or ad-hoc user requirements | Document all system upgrades and changes thoroughly, detailing technical specs, user needs, implementation, and testing. | | 2 | Registration | 1. Institution Entry Restrictions | During registration, users can enter any institution, even those not supported by the system | Standardize institutional selection with a dropdown menu covering all RUFORUM partners (universities and T-VETs), plus an option for non-consortium institutions. | | | | 2. Mandatory Registration | There is no guest view, creating barriers for potential applicants to explore the system | Develop a guest preview functionality | | | | 3. Form Length | The registration form is very long, potentially discouraging user engagement | Review and reduce the length of the registration form by consolidating related fields | | | | 4. Mandatory Photo and Address Requirements | Mandatory fields may create barriers or raise privacy concerns | Evaluate the necessity of these fields and consider making them optional or conditional based on call type, with the implementation of privacy safeguards | | | | 5. Multiple Institution Affiliation Handling | Users can belong to more than one institution | Enhance the institution dropdown to support multiple institutional affiliations | | 3 | Call Management and Distribution | 1. Notification Gaps | most users learn about opportunities through "friends" rather than system-led communication | Develop an automated notification mechanism to alert registered users about new calls | | | | Manual Call Coordination Workflow | Call managers from different departments prepare calls, but the distribution process relies on manual coordination between multiple channels | Create a standardised, documented process for call managers to prepare and upload calls with a centralised call management interface | | | | Inconsistent Interview Requirements Across Call Types | Different grant types have different interview requirements and budget submission timing, with no clear system differentiation | Develop explicit guidance on interview requirements, budget submission timing, and evaluation processes | | | | Grants Without Upfront Budgets | Some grant calls do not require applicants to submit budgets initially | Implement standardised call type configurations | | | | Inadequate Grant Progress Tracking and Reporting | The system lacks comprehensive M&E functionality | Develop comprehensive M&E functionality with real-time dashboards | | 4 | Multilingual Support | Non-Operational Language Modules | Language functions are not yet operational | Prioritise the activation and testing of French, Arabic, and Portuguese language modules | | 5 | Review and Evaluation | Manual Two-Level Validation Without Automation | The system relies entirely on manual validation processes | Transition first-level manual validation of required documents to an automated system check | | | | Lack of Automated Eligibility Filtering | Ineligible applicants are manually identified | Develop system-level eligibility checks based on predefined criteria | | | | No Automated Conflict Resolution | The system lacks an automated mechanism to handle discrepancies | Define and implement a clear, automated protocol for resolving conflicting reviewer recommendations | | | | Inconsistent Evaluation Workflow | Different call types follow different evaluation processes | Create a unified evaluation framework that accommodates different call types | | | | Manual Review Template Distribution | Review templates and evaluation requests are often sent via email or external communication channels | Transfer review template distribution from email to an integrated system workflow with automatic reviewer assignment and tracking of submission status | | | | Manual Reviewer Workload Distribution | With large application volumes, reviewer assignments are split manually without system-level support for equitable workload management | Develop a system-level mechanism to automatically distribute applications among reviewers based on availability and expertise, with real-time workload tracking | | | | Absence of Anonymisation Features | The review process does not include built-in functionality to anonymise applicant identities during evaluation, which may introduce reviewer bias | Implement built-in functionality to anonymise applicant names and identifying information during the review process to reduce potential bias | | 6 | Interview Scheduling and Verification | Manual Interview Scheduling | The call manager is responsible for manually scheduling interviews with no system-integrated scheduling functionality | Develop a system-integrated interview scheduling module that allows automatic invitations, calendar management, and status tracking | | | | Non-System-Based Verification Process | For certain call types, the evaluation process involves phone verification and in-person parent meetings conducted outside the system, with results manually entered afterward | Create standardised verification templates and workflows within the system to ensure all verification results are recorded in the platform | | 7 | Data Management and Reporting | Template-Based Data Capture Issues | The system uses templates to capture which data fields are required, but the actual content submitted by applicants is not always properly preserved or displayed | Enhance the system to preserve and display the actual content submitted by applicants, ensuring all submitted documents and information are accessible within the system | | | | Manual Final Selection Process | After reviewers submit scores, administrators must download data externally and manually "chop" (select) top candidates based on average scores | Implement automated selection functionality that ranks applicants based on average reviewer scores and applies predefined selection criteria | | | | Lack of Standardised Selection Criteria | There is no clear, automated protocol for how many applicants should be selected, relying on manual decisions for each call | Establish and document clear selection criteria for each call type, including target numbers, minimum score thresholds, and tie-breaking rules | | | | Grant Budget Tracking | For grants with upfront budgets, there is no system functionality to monitor expenditures; for deferred budgets, there is no workflow to assign budgets after technical review | Implement budget tracking functionality that monitors expenditures against approved budgets and creates workflows for deferred budget assignment | ### 4.3.2. Regional E-learning platform ### 4.4.3. Repository The repository should be designed to automate the processes **Figure 5. 1: **Phases of data management from which the process will be derived ### 4.3.4. M&E and Feedback System Below are the proposed features of the M&E system. The major proposed features of the M&E system include the following - **M****&****E Results framework and indicator management**: This helps to measure outcomes and impacts. For each objective, specify which activities will be conducted to achieve the objective, what impact, and what outputs will be achieved. The indicators that track long-term benefits can also be captured (e.g., changes in income, health, or behaviour). - **M****&****E Data collection and management**: Features for incorporating data collection tools or data import tools from external offline tools into the system. Photo, video, and document uploads to support the narratives. A mobile application for field officers - **Real-time dashboards and visualization: **These include interactive dashboards, charts, and graphs, drill-down analysis, and performance against targets, among other - **Reporting and analytics**: these include predictive analytics, trend analysis, and export facilities for automated reports - **Project and activity tracking**: These include work plan tracking, activity scheduling, budget vs. expenditure tracking, and milestone monitoring - **Beneficiary and stakeholder management**: Keeping details of project beneficiaries, demographic profiling, and attendance tracking through QR code scanning and registration, and enabling feedback mechanisms from beneficiaries. - **Project performance scoring**: **Budget Monitoring**: Integrate with finance to monitor the budget **Recognition**: Encouraging users to update RUFORUM with information. This may be through recognition, providing offers that would attract such persons to update their profiles - **Performance notifications**: Alert for persons not reporting or performing - Post-project Monitoring: ### 4.3.5. Alumni proposed features The following can be used to lessen the challenges listed above - **APF Profile management**: This is for capturing student data from when they join the RUFORUM programmes as students. This includes personal contact information, duration of the program, and any other information that describes the person. After leaving the University, profile information such as skills, employer, project engaged in, publications, description, and other professional achievements attained by alumni. - Streamlining and structuring engagement activities amongst partners: By fostering ***two-way*** communication, clear goal alignment, and personalized interactions tailored to different partner types. This can be achieved through the following: - - **Non-Monetary Recognition:** Publicly recognize high-performing partners through, for example, “*Partner of the Year*” awards, spotlights in newsletters, or exclusive access to new, unreleased products, etc - Implement system features to automate, manage, and measure interactions. - **Define Objectives and KPIs:** Establish clear goals, and especially emphasize alignment of each partner’s goals to ensure mutual benefit - **Regularizing communication: **This is through** **establishing consistent routines. - **Creating features to match mentors to mentees:** this will be used to pair individuals based on skills, goals, and interests to create compatible, effective mentoring relationships that support professional growth, boost engagement, and save administrative time. - **Supporting networking: **This includes making connections based on common interests, geographical location, sector of employment, and area of employment, among others. Supporting the selection of participants by groups of interest, such as chapters/countries. - **Integration with social media:** This can be through embedding live social feeds to display real-time posts from LinkedIn, Twitter, or Instagram directly. This shows active engagement and keeps content fresh. Additionally, share buttons can be embedded on posts and articles to encourage visitors to share your content with their networks and automatically convert social media leads, followers, or event attendees into contacts. The social media profiles can also be enriched with Social Data by syncing profiles with public information from LinkedIn or other platforms, such as job titles and company information. - **Enhance access to jobs through **job postings and manual job searches, and linking to jobs and syncing job postings from related websites. - **Events calendar: **This includes creating an events calendar for conferences, workshops, training, etc., and enabling members to see events that are relevant to them. Integration with tools such as Zoom and Teams for online events, and provision of detailed reports on event views and engagement. - **Linking to knowledge repository:** This will enable linking to the relevant publications and projects, and hence automatically enhancing profiles. - **Search functionality:** Features to support exact keyword matches as well as semantic searches that understand the intent behind queries rather than just exact phrases, Boolean search to support for operators (AND, OR, NOT) to narrow or broaden search queries for precise results and real-time and incremental search, which provides instantaneous, predictive results as the user types, improving efficiency and user experience. Advanced filtering and AI-based searches (such as those that use natural language processing) are also necessary to improve the user experience. ### 4.3.6. SME-Hub To ensure a successful connection to partners and markets, an SME-Hub system must include the following: - - **Innovation and Business onboarding**: The onboarding process shall involve innovators and businesses submitting information that captures key information about their solution, business model, team capacity, market focus, and supporting documentation. Once submitted, the vetting shall be conducted, including eligibility screening, technical and commercial assessment, and, where necessary, regulatory and compliance verification to ensure credibility and readiness. This review may involve expert evaluators or sector specialists who assess innovation quality, feasibility, scalability potential, and alignment with platform standards. Applicants may receive feedback and be guided to refine their submissions before final approval. Upon successful vetting, the innovation or business profile is formally onboarded, categorized appropriately, and published to registered users through the platform’s directory and marketplace features, making it visible to potential partners, buyers, investors, and service providers. - **Ecosystem and Partner Linkage**: This will serve as a comprehensive ecosystem designed to foster collaboration across sectors. At its core is a dynamic partner directory that brings together government agencies, corporate organizations, NGOs, and universities, creating a centralized space for connection and visibility. Through intelligent partnership matchmaking, aligned by sector focus, specific needs, and geographic priorities, the feature will enable stakeholders to identify and engage with the most relevant partners. The platform will further streamline collaboration by facilitating Memorandums of Understanding (MoUs) and formal partnership agreements, reducing administrative friction and accelerating engagement. Beyond introductions, it will actively support initiatives and co-development opportunities, empowering partners to test ideas, innovate jointly, and scale an impactful solution - **Market Access and Commercialization**: The features will establish a vibrant marketplace that connects innovators with demand through a structured buyer and off-taker registry, ensuring that credible purchasers are visible and accessible to innovators. A robust product listing and catalogue system that allows businesses to showcase their offerings in a clear, organized, and searchable format will also be provided. To strengthen commercial viability, the platform will also integrate market validation and customer discovery tools, equipping users with insights, feedback mechanisms, and data-driven analysis to refine their solutions and confidently align with market needs - **Service Provider and Business Support:** This feature will be designed to connect innovators with the technical and professional expertise they need to grow. It will serve as a centralized gateway to essential support services, featuring a registry of vetted service providers spanning legal advisory, financial services, certification, packaging, quality assurance, and intellectual property support. Innovators will seamlessly access on-demand advisory bookings, enabling timely and targeted guidance tailored to their stage of development. In addition, the platform offers standardized service packages such as certification pathways, branding solutions, and regulatory compliance support, hence streamlining access to critical services and reducing the complexity, cost, and time typically associated with securing professional assistance. - **Mentorship and Industry Advisory**: To prepare innovators to engage confidently and effectively with partners and markets, this feature shall provide structured capacity-building support tailored to real-world demands. It will connect innovators with industry-specific mentors who offer practical insights, sector knowledge, and strategic direction aligned with market realities. Through comprehensive readiness assessments, covering market positioning, technical robustness, and regulatory compliance, the platform will help identify gaps and areas for improvement. Building on these insights, innovators will receive targeted product refinement support and go-to-market guidance, ensuring their solutions are not only technically sound but also commercially viable and positioned for successful market entry. - **Innovation Showcasing and Deal-support**: To create meaningful interaction opportunities between innovators, partners, and markets, this feature will curate dynamic engagement spaces that drive visibility and deal flow. It will organize demo days and pitch events where innovators can present their solutions directly to investors, buyers, and strategic partners. Through targeted innovation challenges and open calls, it will stimulate problem-solving aligned with real industry needs, attracting high-potential solutions. It will also host both virtual and physical showcases to broaden its reach and ensure continuous exposure across geographies. To convert interest into action, dedicated deal rooms provide structured environments for negotiations, due diligence, and partnership finalization, helping transform connections into concrete agreements and market traction. - **Investment and Finance Linkage: **To enable scaling and long-term sustainability, this feature will provide innovators with structured access to capital and investment readiness support. It will maintain a comprehensive investor-funder database, connecting start-ups and SMEs to venture capitalists, impact investors, development finance institutions, and other funding partners. Through regularly updated grant and funding call listings, innovators will be able to identify and pursue relevant financial opportunities aligned with their growth stage and sector. Complementing these tools, targeted investor–innovator matchmaking ensures that high-potential ventures are strategically connected with funders whose mandates and interests align, accelerating pathways to scale - **Regulatory and Policy Navigation**: To enable market entry and foster strong public-sector partnerships, this feature shall provide innovators with structured guidance to navigate regulatory and institutional landscapes effectively. It will offer regulatory guidance covering applicable standards, approvals, and compliance requirements, helping businesses and innovations reduce uncertainty and accelerate time to market. Additionally, streamlined certification and licensing pathways will be outlined, ensuring that products and services meet required legal and quality benchmarks while positioning innovators for credible and sustainable participation in public-sector opportunities. - **Monitoring, Learning, and Impact (*****Implemented in M******&******E*****L and accessible in SME-hub): **To ensure products succeed beyond initial connection, the feature shall provide structured post-engagement support that strengthens long-term outcomes and impact. It shall incorporate partner engagement tracking to monitor interactions, commitments, and collaboration progress, ensuring accountability and sustained momentum. Through market uptake and sales monitoring, innovators will gain visibility into performance trends and commercial traction. Built-in feedback loops from buyers and partners shall generate actionable insights to refine products, improve service delivery, and respond to evolving market needs. Together, these mechanisms will generate credible evidence for scale-up and replication, positioning successful solutions for broader adoption and sustainable growth **Figure 4. 1: **Support features for the Innovation and business lifecycle** ** ## 4.4. Security Roadmap A security roadmap is a strategic plan that outlines how this project will strengthen and manage RUFORUM’s information security during system implementation and integration. It defines current security gaps, desired future state, key initiatives (such as implementing access controls, data protection measures, monitoring systems, and compliance frameworks), timelines, responsibilities, and required resources. It is a phased and prioritized guide that aligns security improvements with organizational goals, risks, and available capacity. The security roadmap has the ability to bring structure and direction to what is a complex and reactive area. It helps to proactively identify vulnerabilities, prioritize high-risk areas, and allocate resources efficiently instead of responding only after incidents occur. The security roadmap ensures consistent protection across all systems, safeguards sensitive data, and builds trust among users and stakeholders. Additionally, it supports compliance with regulatory requirements, improves incident preparedness, and provides a clear framework for continuous improvement as technologies and threats evolve. The roadmap focuses on securing: - Data exchange across systems - User access and identity - Infrastructure and APIs - Cross-system governance and compliance **Table 11: **Security Roadmap for RUFORUM Systems Integration | **Objective** | **Phase** | **Actions** | **Tasks** | **Expected Outcomes** | | --- | --- | --- | --- | --- | | Establish baseline security posture | Phase 1: Security Assessment & Planning (0–3 Months) | Conduct security assessment and planning | Perform security audit for RIMS, REP, SME-Hub, M&E, Repository, Alumni- Identify vulnerabilities and risks- Classify data (sensitive, internal, public)- Define security requirements | Clear understanding of risks- Data classification framework- Security baseline established | | Implement unified identity management | Phase 2: Identity & Access Management (3–6 Months) | Deploy centralized authentication and access control | Implement Single Sign-On (SSO)- Configure Identity Provider (IdP)- Define Role-Based Access Control (RBAC)- Enable Multi-Factor Authentication (MFA) | - Single user identity across systems- Reduced unauthorized access- Improved user accountability | | Secure system interoperability | Phase 3: Secure Data Integration & APIs (6–9 Months) | Protect data exchange across systems | Implement API Gateway- Enforce HTTPS/TLS encryption- Apply OAuth2/JWT authentication- Set API rate limiting and monitoring | - Secure data exchange- Reduced risk of interception- Controlled integration environment | | Ensure data integrity and governance | Phase 4: Data Governance & Protection (6–12 Months) | Establish data governance and protection mechanisms | Define data ownership and stewardship- Implement data validation rules- Introduce Data Loss Prevention (DLP)- Apply data anonymization where needed | - Improved data quality and consistency- Reduced duplication- Enhanced data trust | | Protect infrastructure and applications | Phase 5: Infrastructure & Application Security (9–15 Months) | Strengthen system and hosting security | Deploy firewalls and IDS/IPS- Conduct penetration testing- Perform vulnerability scans- Implement secure software development practices (Secure SDLC)- Apply patch management | - Reduced exposure to cyber threats- Improved system resilience- Secure application environment | | Enable monitoring and incident response | Phase 6: Monitoring, Logging & Incident Response (12–18 Months) | Implement monitoring and response systems | Deploy SIEM system- Enable centralized logging- Configure real-time alerts- Develop incident response plan- Establish response team/process | - Faster detection of threats- Effective incident handling- Full audit trail of activities | | Ensure compliance and continuous improvement | Phase 7: Compliance, Training & Continuous Improvement (Ongoing) | Maintain long-term security and compliance | - Align with data protection regulations- Conduct user security training- Perform periodic audits- Review and update security policies | - Sustained security posture- Improved user awareness- Compliance with regulations | | Address system-specific risks | Cross-Cutting (All Phases) | Apply tailored security controls per system | - Secure financial data in RIMS- Protect learner data in REP- Verify users in SME-Hub- Secure analytics in M&E- Control repository access- Protect alumni personal data | - System-specific vulnerabilities mitigated- Balanced and context-aware security implementation | # 5. SYSTEM REQUIREMENTS AND SPECIFICATIONS The system requirements are derived from the system study, i.e., from the literature and interviews conducted at RUFORUM. These were categorized and have been presented as functional, non-functional, data, and quality requirements. ## RIMS/ Fund Administration (FA) ### 5.1.1: Description This is a module that digitizes and centralizes the entire lifecycle of grants—from application, review, and approval to fund disbursement, reporting, and compliance monitoring. It replaces manual, paper-based processes and spreadsheets with automated workflows, improving efficiency, transparency, and reporting for non-profits, government agencies, and grant-making foundations.  **Figure 5. 2: **Phases of the fund administration process They include the following submodules **Grant planning and setup**: This is where an authorized user creates, configures, and initializes a new grant. The process includes defining grant details, budget structure, reporting schedules, and assigning responsible personnel. This is where grant records are created, showing the funding amount and duration, and assigning a grant manager, defining the reporting schedule, linking the grant to the program or strategic objective, and budget creation (line-item level) ** Call set-up**: This includes publishing funding calls, defining eligibility criteria, uploading guidelines and templates, and managing deadlines. **Application management**: This includes application intake and tracking, document uploads, proposal review workflow, reviewer scoring and evaluation, approval/rejection notifications, and application status tracking **Award and agreement management**: For the approved grants, generating award letters, uploading signed agreements, tracking contract terms, managing amendments, defining grant milestones, and configuring payment tranches **Grant Close-Out**: this includes final narrative reporting, asset verification, a close-out checklist, and archiving of grants ### Subprocess Descriptions This sub-process involves the following steps, and the typical flow of events is summarized in Table xxx, in which the various main and alternative steps, where applicable, are specified. **Table 12**: Grant planning and setup use case narrative | **Use case name** | **Grant planning and set up** | | --- | --- | | **Actor** | Grants Manager (primary), Finance Officer, Program Manager, Program Director / Finance Director (approvers), System Administrator | | **Description ** | This use case describes how an authorized user creates, configures, and initializes a new grant, including defining grant details, linking to a donor profile, building a budget structure at the line-item level, configuring reporting schedules and milestones, assigning responsible personnel, and submitting the grant for approval. The use case also covers saving as a draft, editing an existing grant, and the approval and rejection outcomes. | | **Pre-condition** | The user is authenticated and has been assigned the Grants Manager role. At least one funding type/program and one strategic objective are configured in the system. If a donor profile is to be linked, the donor either already exists in the system, or the user has permission to create a new donor profile. | | **Main success scenario** | The user clicks “*New Grant*” to initiate a new grant record. The system displays the grant setup form, organized into sections: General Information, Donor Profile, Budget Structure, Reporting Schedule, and Staff Assignment. The user completes the General Information section by entering the required information. The user selects the strategic objective(s) the grant aligns to from a dropdown list of configured objectives. The user proceeds to the Donor Profile section. If the donor already exists in the system, the user searches and selects the donor record. If the donor does not exist, the user selects “*Add New Donor*” and enters the required information. The system saves the new donor profile and links it to the grant record. The user proceeds to the Budget Structure section. The user creates budget categories and enters line-item allocations under each category, including the item description, unit, quantity, unit cost, and total. The system automatically calculates the total budget and displays it alongside the grant amount entered in step 3. The system validates that the total budget equals the grant amount. If they match, the user may proceed. If they do not match, the system displays an inline warning indicating the variance and prevents progression until the budget is reconciled. The user proceeds to the Reporting Schedule section. The user configures the financial reporting frequency (e.g., monthly, quarterly, semi-annual), the narrative reporting frequency, and defines specific milestone dates for the grant lifecycle. The system generates a reporting calendar based on the configured frequencies and start/end dates and displays it to the user for review. The user proceeds to the Staff Assignment section. The user assigns the Grant Manager (which may be themselves or another user), the Finance Officer, and the Program Lead. The system validates that, at a minimum, a Grant Manager has been assigned before allowing submission. The user can “*Preview*” to review all entered information across all sections in a summary view. The user clicks “*Submit for Approval*.” The system validates all mandatory fields across all sections. If validation passes, the system generates a unique Grant ID, sets the grant status to “*Pending Approval*,” logs the submission action in the audit trail, and sends a notification to the designated approver (Program Director or Finance Director) informing them that a grant record is awaiting their review. | | Alternative flow | A1: Save as Draft At any point during data entry, the user may click “*Save as Draft*” instead of submitting. The system saves all entered information in its current state without requiring all mandatory fields to be complete. The grant is assigned a system-generated Draft ID, and its status is set to “*Draft*.” The grant remains invisible to other users except those with grant management permissions. A2: Edit Existing Grant User selects existing grant. User modifies budget, dates, or reporting schedule. System logs changes and updates the version history. A3: Approval Workflow Required User submits a grant for approval. The designated approver (Programme Director or Finance Director) receives a system notification that a grant is pending their review. The approver logs in, navigates to the approval queue, and opens the grant record. The approver can either approve or reject. If Approved: The system changes the grant status to “*Approved*,” logs the changes, and sends a notification to the Grants Manager and assigned Finance Officer confirming the approval. The grant is now eligible for activation and for linking to a call or proceeding to award and agreement management. If rejected: The approver enters rejection comments specifying the reason and the changes required. The system changes the grant status back to “*Draft Revision Require*d,” logs the rejection with the approver's comments, user ID, and timestamp, and sends a notification to the Grants Manager with the rejection reason and required changes. The Grants Manager opens the grant, reviews the approver’s comments, makes the necessary revisions, and resubmits for approval The system creates a new version record for the revised submission and routes it back to the approver. | | **Post condition** | The grant record is created and stored in the system. Budget structure is configured. The reporting schedule and milestone calendar are defined and stored. The Grant Manager, Finance Officer, and Program Lead are assigned to the grant. The donor profile is linked to the grant record. The strategic objective alignment is recorded. A complete audit trail and version history of the creation and approval process is stored in the system. Relevant staff have been notified of the approval. | **Table 13**: Functional specifications for Fund administration | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | **Grant Record Initialisation** | **FRFA-GPS001:** The system shall allow authenticated users with the Grants Manager role to create a new grant record. | User credentials, role permissions | Blank grant setup form displayed | Grants Manager | | | **FRFA-GPS002:** The system shall generate a unique Grant ID upon successful submission of a grant record for approval. | Completed and validated the grant form | Unique Grant ID assigned; grant record stored in system | System (automated) | | | **FRFA-GPS003:** The system shall allow a grant record to be saved as a Draft at any point during data entry without requiring all mandatory fields to be complete. | Partially completed grant form data | Draft grant record saved with Draft ID; status set to Draft; audit log entry created | Grants Manager | | | **FRFA-GPS004:** The system shall automatically save grant form data at configurable intervals to prevent data loss during entry. | In-progress form data | Auto-saved draft record; no data loss on session interruption | Grants Manager | | **General Information** | **FRFA-GPS005:** The system shall provide a structured form for entering general grant information, including grant title, funding type, grant amount, start date, end date, description, and strategic objective alignment. | Grant title, funding type, amount, dates, description, strategic objective | The general information section is stored against the grant record | Grants Manager | | | **FRFA-GPS006:** The system shall allow the user to select a strategic objective from a configurable dropdown list of objectives defined in the system. | Existing strategic objectives in the system | Selected strategic objective linked to the grant record | Grants Manager, System Administrator | | **Donor Profile Management** | **FRFA-GPS007:** The system shall allow the user to search for and link an existing donor profile to a grant record. | Donor search query | Existing donor record linked to the grant | Grants Manager | | | **FRFA-GPS008:** The system shall allow the user to create a new donor profile during grant setup if no matching donor exists, capturing donor name, donor type, country, and contact details. | Donor name, donor type, country, contact details | New donor profile created and linked to the grant record | Grants Manager | | | **FRFA-GPS009:** The system shall detect potential duplicate donor profiles based on name and country matching, and alert the user before saving a new donor record. | New donor details, existing donor records | Duplicate warning displayed; user prompted to link existing or confirm new record; duplicate flag logged for administrator review | Grants Manager, System Administrator | | **Budget Structure** | **FRFA-GPS010:** The system shall allow the user to create a budget structure consisting of categories and line items, with each line item capturing description, unit of measure, quantity, unit cost, and calculated total. | Budget categories, line-item details | Budget structure stored against grant record; line-item totals calculated automatically | Grants Manager, Finance Officer | | | **FRFA-GPS011:** The system shall automatically calculate and display the total budget from all line-item entries and compare it against the grant amount entered in the general information. | Budget line-item totals, grant amount | Budget total calculated and displayed; variance highlighted if total does not match grant amount | System (automated), Grants Manager, Finance Officer | | | **FRFA-GPS012:** The system shall prevent submission of a grant record for approval if the total budget does not equal the grant amount, displaying a clear variance error message to the user. | Budget total, grant amount | Inline variance error message; submission blocked until reconciled | System (automated), Grants Manager, Finance Officer | | | **FRFA-GPS013:** The system shall support multi-currency budget entry, with a designated base currency configured per grant. | Currency selection, line-item amounts | Budget amounts stored in selected currency; base currency recorded on grant record | Grants Manager, Finance Officer | | **Reporting Schedule** | **FRFA-GPS014:** The system shall allow the user to configure the financial reporting frequency, narrative reporting frequency, and milestone dates for the grant. | Financial frequency, narrative frequency, milestone dates, grant start/end dates | Reporting schedule stored against the grant record | Grants Manager, Finance Officer | | | **FRFA-GPS015:** The system shall automatically generate a reporting calendar based on the configured frequencies and grant start and end dates, and display it to the user for review before submission. | Configured frequencies, start/end dates | Reporting calendar generated and displayed; stored against the grant record | System (automated), Grants Manager | | | **FRFA-GPS016:** The system shall prevent activation of a grant record if the reporting frequency has not been defined. *(Enforces NFRFA003)* | Grant record status check | Activation blocked with an explanatory message if the reporting frequency is absent | System (automated) | | **Staff Assignment** | **FRFA-GPS017:** The system shall allow the user to assign a Grant Manager, Finance Officer, and Program Lead to a grant record by selecting from registered system users. | User search, selected user records | Staff assignments are stored against the grant record | Grants Manager, System Administrator | | | **FRFA-GPS018:** The system shall prevent submission of a grant record for approval if no Grant Manager has been assigned. *(Enforces NFRFA004)* | Grant record staff assignment data | Submission blocked with explanatory message if the Grant Manager is absent | System (automated) | | | **FRFA-GPS019:** The system shall notify assigned staff members by email when they are added to a grant record. | Staff assignment action, user email addresses | Email notification sent to the newly assigned Finance Officer and Program Lead | System (automated) | | **Submission and Approval Routing** | **FRFA-GPS020:** The system shall validate all mandatory fields across all grant setup sections when the user selects “*Submit for Approval*,” highlighting incomplete fields and preventing submission until all are completed. | Completed grant form, mandatory field definitions | Validation pass or field-level error indicators; submission blocked if validation fails | System (automated), Grants Manager | | | **FRFA-GPS021:** The system shall route a submitted grant record to the designated approver (Program Director or Finance Director) and send an automated notification informing them that a grant is pending their review. | Submitted grant record, approver role configuration | Notification sent to approver; grant placed in approval queue | System (automated), Program Director / Finance Director | | | **FRFA-GPS022:** The system shall allow the designated approver to review all sections of a submitted grant record before making an approval decision. | Grant record in Pending Approval status | Grant record displayed in full to approver | Program Director / Finance Director | | | **FRFA-GPS023:** The system shall allow the designated approver to approve a grant record, triggering a status change to Approved and sending a notification to the Grants Manager and Finance Officer. | Approver approval action | Grant status set to Approved; audit log entry created; notification sent to Grants Manager and Finance Officer | Program Director / Finance Director, System (automated) | | | **FRFA-GPS024:** The system shall allow the designated approver to reject a grant record with mandatory written comments, triggering a status change to Draft Revision Required and sending the rejection comments to the Grants Manager. | Approver rejection action, written comments | Grant status set to Draft Revision Required; rejection comments stored against grant record; notification sent to Grants Manager | Program Director / Finance Director, System (automated) | | **Audit Trail and Version History** | **FRFA-GPS025:** The system shall log all create, edit, save, submit, approve, and reject actions against a grant record, capturing the user ID, timestamp, action type, and, where applicable, the previous and new values of changed fields. *(Enforces NFRFA011)* | All user actions on the grant record | Audit trail entries stored and accessible to authorised users | System (automated) | | | **FRFA-GPS026:** The system shall maintain a version history for grant records, creating a new version record each time the grant is resubmitted for approval following a rejection or edit. | Revised grant submission | Version record created; previous versions accessible for comparison | System (automated), Grants Manager | | **Budget Revision (Active Grants)** | **FRFA-GPS027:** The system shall allow authorised users to request a budget revision, date change, or reporting schedule change on an active or approved grant, routing the revision request through the same approval workflow as initial grant setup. *(Enforces NFRFA005)* | Proposed budget/date/schedule changes, active grant record | Revision request logged; current approved settings remain in force pending approval; approver notified | Grants Manager, Finance Officer, Program Director / Finance Director | **Table 14: **Funding Type Configuration Rules Grant Planning and Setup (5.1.1.1) | **Configuration Area** | **Grant** | **Scholarship** | **Fellowship** | **Challenge** | | --- | --- | --- | --- | --- | | **Primary purpose** | Research funding: doctoral research, policy grants, project funding | Academic support, mainly financial support for students in formal education programmes | Professional development for leadership, research excellence, specialised expertise beyond formal coursework | Competitive innovation prize-based call for innovative ideas or solutions to a specific problem | | **Budget entry at planning** | ***Required***. A full line-item budget must be entered and validated against the grant amount before approval | ***Required*** at programme level. Per-beneficiary award amount defined. | ***Required***. Stipend amount and duration are defined. | ***Required***. Prize amount(s) defined per award tier (e.g., 1st, 2nd, 3rd). | | **Budget upfront at call/application** | ***Required*** at application submission | ***Not required*** at application. The applicant submits a personal/academic profile only. Budget assigned at the award stage | ***Not required*** at application. The applicant submits a professional profile. Budget confirmed at the award stage | ***Not required*** at application. The applicant submits an innovation proposal only. No budget submitted by the applicant | | **Number of beneficiaries** | Defined per grant, one PI and research team | Defined at planning. The number of scholarship slots is configured as a hard cap | Defined at planning. The number of fellowship positions configured | Defined at planning. The number of prizes/awards configured | | **Reporting schedule type** | Milestone-based periodic reporting (e.g., month 6, 12, 18 through to final report) | Academic-cycle reporting per semester or academic year. Student reports linked to academic progress | Duration-based reporting, monthly or quarterly check-ins linked to fellowship activities | Single post-award report on the implementation of the innovation solution | | **Staff roles assigned** | Grant Manager, Finance Officer, Program Lead, Principal Investigator (PI) | Scholarship Manager, Finance Officer, Program Lead | Fellowship Manager, Finance Officer, Program Lead, Host Institution Coordinator | Challenge Manager, Finance Officer, Judging Panel Coordinator | | **Strategic objective linkage** | Linked to research programme objectives and result areas | Linked to capacity building objectives and partner university targets | Linked to leadership development and institutional strengthening objectives | Linked to innovation and enterprise development objectives | | **Downstream call type** | Grant Call | Scholarship Call | Fellowship Call | Challenge Call | | **Award output** | Grant Award research funding disbursed to the winner | Scholarship Award: tuition and/or stipend disbursed per academic period | Fellowship Award stipend disbursed monthly or quarterly | Challenge Prize lump sum or staged prize disbursement | | **Close-out requirements** | Final narrative report, financial report | Academic completion certificate, final student report, institutional confirmation | Fellowship completion report, outputs/deliverables verification | Innovation implementation report, impact evidence | **Table 15: **Call setup use case narrative | Use case name | Call set up | | --- | --- | | Actor | Funding Administrator / Program Officer | | **Description ** | This use case describes how an authorised Funding Administrator creates, configures, and publishes a Call against an approved funding record in the system. The call type must match the parent funding record type: Grant, Scholarship, Fellowship, or Challenge. The process covers linking the call to its parent record, configuring eligibility, uploading documents, setting submission parameters and deadline, and publishing the call for applicants. | | **Pre-condition** | The user is authenticated and holds the Funding Administrator or Program Officer role with permission to create and publish calls. An approved funding record of the relevant type (Grant, Scholarship, Fellowship, or Challenge) exists in the system and is available for linking. The funding record has an uncommitted balance available The document repository is available and accessible for file uploads. | | **Main success scenario** | The Funding Administrator selects “*Create Call*.” System displays approved funding records available for linking, showing funding type, committed balance, and remaining uncommitted balance. The Administrator selects the parent funding record. System links the call, sets the call type to match the funding record type, and pre-populates inherited fields, i.e., funding amount, strategic objectives, reporting schedule type, and responsible manager. The System loads the type-configured call setup form with the relevant sections, required fields, and evaluation workflow defaults for the call type. Administrator completes the General call Information call title, description, application start date, submission deadline, time zone, review period dates, and maximum number of awards. Administrator defines Eligibility Criteria using structured controls based on the type-specific eligibility fields on the call type. The System saves eligibility rules as enforceable criteria to be applied automatically at applicant submission. The** **Administrator uploads supporting documents as required by the call type. The Administrator configures Submission Settings based on the call type. The Administrator confirms the deadline and auto-close behaviour. The Administrator configures Notification Settings: publication notification, deadline reminders at configurable intervals, and submission acknowledgement. Administrator selects “*Preview*” to review all configured information in a read-only summary before publication. The Administrator clicks “*Publish*.” System runs pre-publication validation. On successful validation, the system generates a unique Call ID, sets the call status to “*Active*,” updates the committed balance on the parent funding record, makes the call visible on the public portal,** **and dispatches publication notifications. While active, the administrator may edit non-critical fields, upload revised documents (version tracked), post clarifications, or extend the deadline. At deadline, the system automatically closes the submission portal, sets the call status to “*Closed*,” locks all in-progress applications, notifies the administrator, and records the final submission count. | | **Alternative flow** | **A1 – No Eligible Parent Funding Record** System finds no approved funding records with available uncommitted balance. System displays a message informing the administrator that a call cannot be created without a parent funding record. The Administrator must first complete Grant Planning and Setup **(5.1.1.1)** before returning to this use case. **A2 – Save as Draft** Administrator selects "Save as Draft" at any point. System saves the current state without mandatory field validation. No balance committed on the parent funding record. Call assigned a Draft ID with status "Draft" not visible to applicants. Administrator may return to complete and publish at any time. **A3 Mandatory Field Validation Failure** Administrator clicks “*Publish*,” but pre-publication check identifies outstanding items. System displays a summary list of all outstanding items by section and field name. Call remains in Draft. No balance committed. Administrator resolves items and re-attempts. **A4 Funding Amount Exceeds Uncommitted Balance** The administrator enters a funding amount that exceeds the remaining uncommitted balance on the parent record. System displays an inline error showing the available balance and blocking progression. Administrator adjusts the call amount or selects a different parent funding record. **A5 Invalid Deadline** Administrator enters a deadline earlier than or equal to the start date, or a review period that begins before the deadline. System displays an inline validation error on the affected field. Administrator corrects dates before proceeding. **A6 Document Upload Failure** Uploaded file fails format, size, or malware validation. System rejects the file and displays a specific error message. The file is not stored. Administrator corrects and re-uploads. At least one valid guideline document is required before publication. **A7 Deadline Extension on Active Call** The administrator selects “*Extend Deadline*” and enters a new deadline. System validates new deadline is later than the current deadline, and review period dates remain consistent. System updates deadline, logs change with previous and new values, creates version record, and notifies all registered applicants and the review team. **A8 Withdraw Published Call** Administrator selects “*Withdraw Call*” and enters a mandatory withdrawal reason. System sets call status to “*Withdrawn*,” removes call from public portal, releases committed balance back to parent funding record, and notifies affected applicants with the withdrawal reason. Submitted applications are retained in a suspended state pending administrative decision. A withdrawn call cannot be republished. A new call must be created if the opportunity is to be reissued. | | **Post condition** | **Success Active** Call record stored with a unique Call ID and status “*Active*,” linked to the parent funding record. Committed balance updated on parent funding record. Eligibility criteria stored and enforceable at submission. Documents uploaded, validated, and accessible to applicants. Deadline is active and system-enforced. Publication notifications dispatched. Full audit trail recorded. **Draft** Draft call record saved with Draft ID. No balance committed. Not visible to applicants. Editable at any time. **Withdrawn** Call status “*Withdrawn*.” Not visible on the public portal. Committed balance released back to the parent funding record. Submitted applications retained in suspended state. **Closed** Call status “*Closed*.” Submission portal inactive. Applications available for progression to Application Management (5.1.1.3). Final submission count recorded on the call record. | **Table 16**: Functional Requirements and System Specifications Call Setup (5.1.1.2) | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | **Parent Funding Record Linking** | **FRFA-CS001:** The system shall display all approved funding records with an available uncommitted balance when a new call is initiated, grouped by funding type, showing Funding Record ID, title, approved amount, committed amount, and remaining uncommitted balance. | User requests to create a new call | List of linkable funding records displayed | Funding Administrator / Program Officer | | | **FRFA-CS002:** The system shall require the administrator to select and link a parent funding record before the call setup form is loaded. A call record cannot be created without a linked approved funding record. | Administrator funding record selection | Parent funding record linked to call; call type set to match funding record type; inherited fields pre-populated | System (automated), Funding Administrator | | | **FRFA-CS003:** The system shall pre-populate the call form with inherited fields from the selected funding record, available funding amount, strategic objectives, reporting schedule type, and responsible manager, all of which remain editable within permitted constraints. | Selected funding record data | Pre-populated call form fields | System (automated) | | | **FRFA-CS004:** The system shall prevent call creation and display an explanatory message when no approved funding records with an available uncommitted balance exist, directing the administrator to complete Grant Planning and Setup (5.1.1.1) first. | System check on available funding records | Explanatory block message displayed; call creation prevented | System (automated) | | **Call Type Configuration** | **FRFA-CS005:** The system shall load the call setup form pre-configured for the call type inherited from the parent funding record, applying type-specific template rules, required sections, mandatory fields, budget submission requirements, interview flags, and evaluation workflow defaults. *(See Call Type Configuration Table)* | Inherited call type, type template definitions | Type-configured form loaded with relevant sections and rules | System (automated) | | | **FRFA-CS006:** The system shall prevent the call type from being changed after publication. If the call type is found to be incorrect after publication, the administrator must withdraw the call and create a new one. | Post-publication call type change request | Change blocked; withdrawal prompt displayed | System (automated) | | **General Information** | **FRFA-CS007:** The system shall provide fields for the administrator to enter call title, description, application start date, submission deadline date and time, time zone, review period start and end dates, and maximum number of awards. | Call details entered by the administrator | The general information section is stored on call record | Funding Administrator / Program Officer | | | **FRFA-CS008:** The system shall validate that the submission deadline is later than the application start date, and that the review period start date is later than the submission deadline, displaying an inline error on the affected field and blocking progression if either condition is violated. *(Enforces NFRFA009)* | Date and time inputs | Validation pass or inline field-level error; progression blocked until corrected | System (automated) | | | **FRFA-CS009:** The system shall validate that the funding amount entered for the call does not exceed the remaining uncommitted balance on the parent funding record, displaying an inline error and blocking progression if it does. | Call funding amount, uncommitted balance on parent record | Validation pass or inline error showing available balance; progression blocked until corrected | System (automated) | | | **FRFA-CS010:** The system shall allow the administrator to save a call record as Draft at any point without mandatory field validation, without committing any balance against the parent funding record, assigning a Draft ID, and setting status to Draft. | Partial or complete call form data | Draft call record saved; Draft ID assigned; status set to Draft; no balance committed; audit log entry created | Funding Administrator / Program Officer | | | **FRFA-CS011:** The system shall automatically save call form data at configurable intervals during entry to prevent data loss. | In-progress form data | Auto-saved draft; session interruption does not result in data loss | System (automated) | | **Eligibility Criteria** | **FRFA-CS012:** The system shall provide structured input controls for defining base eligibility rules applicable to all call types, geographic restrictions, institutional affiliation, qualification level, sector or thematic area, age restrictions, and required documentation checklist. | Administrator-defined eligibility inputs | Base eligibility rules are stored as structured criteria on the call record | Funding Administrator / Program Officer | | | **FRFA-CS013:** The system shall present additional type-specific eligibility fields based on the call type. Scholarship calls include university and course selection; Fellowship calls include host institution and fellowship type; Challenge calls include innovation stage and sector focus; Grant calls include research area and institutional capacity requirements. | Call type, type-specific eligibility field definitions | Type-specific eligibility fields are displayed and stored | System (automated), Funding Administrator | | | **FRFA-CS014:** The system shall save all defined eligibility rules as enforceable criteria, applied automatically to screen applicant submissions at the point of submission, flagging or blocking ineligible submissions before they enter the review queue. | Stored eligibility rules, applicant submission data at submission time | Automated eligibility screening result; ineligible submissions flagged or blocked with reason shown to the applicant | System (automated) | | | **FRFA-CS015:** The system shall prevent publication of a call if no eligibility criteria have been defined. | Pre-publication validation check | Publication blocked with an explanatory message if the eligibility section is empty | System (automated) | | **Document and Template Management** | **FRFA-CS016:** The system shall allow the administrator to upload supporting documents for the call, with required document types varying by call type Grant calls require guidelines, proposal template, budget template, and terms and conditions; Scholarship calls require guidelines, application instructions, and terms and conditions; Fellowship calls require guidelines, fellowship terms, and host institution agreement templates; Challenge calls require guidelines, innovation brief, judging criteria document, and terms and conditions. | Document files uploaded by the administrator, call type | Documents validated, assigned document IDs, and linked to the call record | Funding Administrator / Program Officer | | | **FRFA-CS017:** The system shall validate each uploaded document for file format against the configured allowed list, file size against the configured maximum, and malware, rejecting files that fail any check and displaying a specific error message identifying the reason for rejection. | Uploaded file, validation rules | Validated document stored with a unique document ID, or rejection error with a specific reason displayed | System (automated) | | | **FRFA-CS018:** The system shall prevent publication of a call if no guideline document has been successfully uploaded and linked to the call record. | Pre-publication validation check, document upload status | Publication blocked with an explanatory message if no guideline document is present | System (automated) | | | **FRFA-CS019:** The system shall version-track all documents uploaded to an active call, retaining previous versions as accessible archived records while displaying the most recent version to applicants, with each version assigned a version number and timestamp. | Revised document upload on active call | New version stored; previous version archived and accessible; version number incremented; audit log entry created | System (automated) | | **Submission Settings** | **FRFA-CS020:** The system shall allow the administrator to configure the required applicant attachment list, maximum file size per attachment, and allowed file formats for applicant uploads. | Attachment list, size limits, format list | Submission configuration stored on the call record; applied at the applicant submission time | Funding Administrator / Program Officer | | | **FRFA-CS021:** The system shall automatically apply the budget attachment requirement based on the call type required for Grant calls at submission; not required at submission for Scholarship, Fellowship, and Challenge calls, where budget is deferred to the award stage | Call type, submission settings | Budget attachment requirement set correctly per call type; applied at applicant submission time | System (automated) | | | **FRFA-CS022:** The system shall allow the administrator to confirm the auto-close behaviour that the submission portal will be closed automatically at the exact configured deadline date and time, with no new submissions accepted after that point. | Deadline configuration, auto-close flag | Auto-close scheduled; confirmation displayed to administrator | System (automated), Funding Administrator | | **Notification Configuration** | **FRFA-CS023:** The system shall allow the administrator to configure automated notifications for call publication, deadline reminders at configurable intervals before the deadline, and submission acknowledgements to applicants upon receipt of their submission. | Notification toggle settings, reminder interval, notification template selection | Notification configuration stored on the call record; notification schedule created | Funding Administrator / Program Officer | | | **FRFA-CS024:** The system shall dispatch automated notifications to registered users when a call is published, using the configured notification template via email and in-system alert. | Call publication event, registered user email addresses, notification template | Notifications dispatched to registered users; dispatch log entry created | System (automated) | | | **FRFA-CS025:** The system shall send automated reminder notifications to applicants who have started but not yet submitted an application at the configured intervals before the deadline. | Reminder interval, in-progress application records, and applicant email addresses | Reminder notifications dispatched; dispatch log entries created | System (automated) | | **Pre-Publication Validation** | **FRFA-CS026:** The system shall perform a comprehensive pre-publication validation check on “*Publish*”, confirming: all mandatory fields complete, parent funding record link valid, call funding amount within uncommitted balance, at least one guideline document uploaded, eligibility criteria defined, and deadline valid, listing all outstanding items if any check fails and blocking publication until all are resolved. | Complete call form, publication action | Validation pass leading to publication, or a summary list of outstanding items with publication blocked | System (automated) | | **Publication and Activation** | **FRFA-CS027:** The system shall generate a unique Call ID, set the call status to Active, update the committed balance on the parent funding record by the call's funding amount, make the call visible on the public portal, enable the submission portal, log the publication action in the audit trail, and dispatch publication notifications upon successful publication. | Validated call record, administrator publishes action | Unique Call ID generated; call status set to Active; committed balance updated on parent funding record; call visible on public portal; submission portal enabled; audit log entry; notifications dispatched | System (automated) | | **Active Call Management** | **FRFA-CS028:** The system shall allow the administrator to edit non-critical fields on an active call description and FAQ content, logging all changes in the audit trail and notifying registered applicants where the change is applicant-visible. | Administrator edit action, updated field values | Updated call record; version record created; audit log entry; applicant notification dispatched if applicable | Funding Administrator / Program Officer, System (automated) | | | **FRFA-CS029:** The system shall allow an authorised administrator to extend the submission deadline of an active call, validating that the new deadline is later than the current deadline and review period dates remain consistent, logging the change with previous and new values, creating a version record, and notifying all registered applicants and the review team. | New deadline, current deadline, review period dates | Updated deadline; audit log entry recording previous and new deadline values; version record; applicant and review team notification dispatched | Funding Administrator / Program Officer, System (automated) | | | **FRFA-CS030:** The system shall allow an authorised administrator to withdraw a published call, requiring a mandatory written withdrawal reason, setting the call status to Withdrawn, removing the call from the public portal, releasing the committed balance back to the parent funding record's uncommitted balance, retaining submitted applications in a suspended state, and notifying affected applicants of the withdrawal reason. | Administrator withdrawal action, written withdrawal reason | Call status set to Withdrawn; call removed from public portal; committed balance released to parent funding record; applicant notifications dispatched; submitted applications retained in suspended state; audit log entry | Funding Administrator / Programme Officer, System (automated) | | **Automatic Closure** | **FRFA-CS031:** The system shall automatically close the submission portal at the exact configured deadline, set the call status to Closed, block new submissions, record the final submission count on the call record, lock all in-progress applications in draft state, notify applicants with in-progress applications that the deadline has passed, and notify the administrator of closure. | System clock, configured deadline | Call status set to Closed; submission portal closed; new submissions blocked; in-progress applications locked; applicant and administrator notifications sent; final submission count recorded; audit log entry with system timestamp | System (automated) | | **Audit Trail and Version History** | **FRFA-CS032:** The system shall log all create, edit, save, publish, withdraw, extend, and close actions on a call record, capturing the user ID or system event, timestamp, action type, and previous and new values of changed fields. | All user and system actions on the call record | Audit trail entries stored and accessible to authorised users | System (automated) | | | **FRFA-CS033:** The system shall maintain a version history for call records, creating a new version entry each time the call is modified during its active period, with all previous versions accessible for audit and reference. | Call record modification events | Version records stored with timestamps; all previous versions accessible | System (automated) | **Table 17: **Application Management use case narrative** ** | Use case name | Application Management | | --- | --- | | Actor | Applicant (primary), Program Officer (primary), Reviewer / Judge, System (automated), System Administrator | | **Description ** | This use case describes the end-to-end management of applications submitted in response to a Call for Proposals. The process includes application intake, document uploads, review workflow routing, reviewer scoring and evaluation, decision approval/rejection, notifications, and real-time status tracking | | Pre-condition | An active Call record exists with status “*Active*,” linked to an approved funding record. The submission portal is open, and the call deadline has not passed. Applicant is registered and authenticated in the system. Review workflow, scoring criteria, and weightings are configured on the call. Blind review setting is configured on the call. Program Officer has the application management role and permission to screen, assign, and decide. | | Main success scenario | ***Application Intake*** Applicant logs into the system and selects an active Call. Applicant clicks “*Start Application*.” The system creates a unique Application ID. Application status is set to ***Draft***. The applicant completes required fields, including organization details, project description, budget information, and contact details The system validates required fields System auto-saves progress. The applicant uploads the required documents The system validates file format and size, scans for malware, and assigns document IDs Uploaded documents are linked to the application record. The applicant reviews the completed application. The applicant clicks “*Submit*.” The system validates eligibility criteria, required attachments, and completion of mandatory fields If valid, the status changes to submitted, the timestamp is recorded, and a confirmation notification is sent to the applicant If the applicant fails any eligibility rule, the system sets the status to “*Rejected Ineligible*,” logs the specific rules failed, and notifies the applicant of the reasons. The application does not proceed to review. The application enters the intake queue. ***Screening*** The Programme Officer reviews the submission for completeness. If documents are complete and valid, the Programme Officer marks the application as “*Eligible Ready for Review*.” If documents are incomplete or invalid, the Programme Officer marks the application as “*Rejected Incomplete*,” and the system notifies the applicant with the specific reason. ***Reviewer Assignment and Workflow *** The Program Officer assigns one or more reviewers to each eligible application. System distributes assignments equitably based on reviewer availability and workload The system notifies reviewers, sets the review deadline, and grants secure access to application materials If blind review is enabled on the call, the system anonymises the applicant’s name and identifying information in the reviewer's view before granting access. The reviewer logs in and accesses the assigned application The reviewer evaluates based on predefined criteria. The reviewer enters the numeric score per criterion, comments, and recommendation (*Approve / Reject / Revise*) using the scoring criteria and weightings configured on the call. The System saves the evaluation, timestamps the action, and logs it in the audit trail. If blind review is enabled, the system prevents the reviewer from viewing any other reviewer’s scores or comments until all reviews for that application are complete. The system aggregates reviewer scores and displays the aggregated score, individual reviewer scores, comments, recommendations, and the application’s ranking among all applications in the call. The program Officer views the average score, individual reviewer feedback, and ranking The program Officer records the final decision The system updates the application status. **Interview / Verification (where applicable)** If the call type requires an interview or verification step, the Programme Officer proceeds to schedule it. The Program Officer schedules interviews through the system, which sends automated invitations to shortlisted applicants with date, time, and format details. For Scholarship calls where home or household verification is configured, the Programme Officer initiates the verification workflow. Verification results are recorded directly in the system using a structured form. The system records the Interview or verification outcomes against the application record, and these contribute to the final scoring and ranking. **Shortlisting and Decision ** The System generates a ranked shortlist of all applications based on aggregated scores, applying the minimum score threshold and maximum award number configured on the call. Tied applications are flagged for Program Officer review. The Program Officer reviews the ranked shortlist, individual scores, comments, and any flagged ties. The Program Officer records the final decision for each application as Approved or Rejected with mandatory written comments. The System updates application status to either “*Approved*” or “*Rejected*” and logs the decision with user ID, timestamp, and comments in the audit trail **Notification and Archiving ** The system automatically generates a decision notification and, depending on the result, may include a decision outcome, reviewer comments, and next steps The applicant can log in and see the status of their application at any stage Applicant receives email/system notification. Approved applications are flagged and made available for progression to Award and Agreement Management (5.1.1.4). Rejected applications are archived with full audit trail, scores, and decision records retained. | | **Alternative flow** | **A1 Application Saved as Draft** The Applicant completes part of the application and selects “*Save as* *Draft*.” The System saves the current state. Application status remains “*Draft*.” No eligibility screening or validation triggered. The Applicant may return and continue before the call deadline. After the deadline, draft applications are locked and cannot be submitted. **A2 Submission After Deadline** Applicant attempts to submit after the call deadline has passed. The system blocks submission and displays a message confirming the deadline has passed, and the portal is closed. Application remains locked in its current draft state. The applicant is notified. **A3 Automated Eligibility Rejection** On submission, the system checks the applicant data against call eligibility rules and finds one or more rules are not met. The System sets application status to “*Rejected Ineligible,”* records each specific eligibility rule that was not met, and notifies the applicant of the reasons. The Application does not enter the screening or review queue. Audit trail records the automated rejection with rules triggered. **A4 – Revision Request** The Programme Officer raises a revision request with written instructions. The System sets application status to “*Revision Requested”* and notifies the applicant with the instructions and a defined resubmission deadline. The Applicant resubmits before the defined deadline If the applicant does not resubmit before the revision deadline, the system sets the status to “*Withdrawn No Response*” and logs the outcome. **A5 Reviewer Conflict of Interest** The Reviewer identifies a conflict of interest with an assigned application and declares it through the system before accessing the application content. The System removes the reviewer from the assignment, logs the COI declaration with reviewer ID, application ID, and timestamp, and notifies the Program Officer. The Programme Officer assigns a replacement reviewer. System notifies the replacement and grants access. **A6 Missed Review Deadline** The Reviewer has not submitted their evaluation by the configured review deadline. The System sends an automated reminder notification to the reviewer. If the reviewer still does not submit within a further configurable grace period, the system flags the assignment as overdue and notifies the Programme Officer. The Program Officer may extend the review deadline for that reviewer or reassign the application to a different reviewer. All actions are audit logged. **A7 Conflicting Reviewer Recommendations** All reviewers have submitted evaluations, but their recommendations conflict; for example, one recommends Accept, and another recommends Reject. The System flags the conflict on the application record and alerts the Program Officer. The Program Officer reviews individual scores and comments and applies the configured conflict resolution, which could be majority recommendation, average score threshold, or escalation to a senior reviewer as defined in the call configuration. Conflict resolution outcome is recorded in the audit trail before the final decision is made. **A8 Applicant Withdraws Application** Before the call deadline, the applicant selects “*Withdraw Application*.” The System sets application status to “*Withdrawn Applicant Request*,” logs the withdrawal with a timestamp, and notifies the Program Officer. Withdrawn applications are removed from the active review queue but retained in the system for audit purposes. | | **Post condition** | **Success Approved** Application status set to “*Approved*.” Decision, scores, and reviewer comments were recorded and audit logged. Approved application available for progression to Award and Agreement Management (5.1.1.4). Decision notification dispatched to applicant. Total approved count validated against the maximum award number on the call. **Rejected** Application status set to “*Rejected*” with decision reason recorded. Decision notification dispatched to applicant with optional reviewer comments. Application archived with full scores, evaluations, and decision trail retained. **Rejected Ineligible** Application status set to “*Rejected Ineligible*.” Specific eligibility rules that failed are recorded. Applicant notified with reasons. The application does not enter the review queue. Application archived with automated screening result retained. **Withdrawn** Application status set to “*Withdrawn*.” Retained in the system for audit purposes. Program Officer notified. The application is removed from the active review queue. **Draft Not Submitted** Application remains in Draft status. Draft is not visible to Programme Officer or reviewers. The application is locked after the call deadline. Not counted in submission totals. | ### Functional Requirements and System Specifications for Fund Administration Table xxx presents the functional requirements and system specifications for the xxxx sub-processes. The functional requirements of the employment sub-processes were derived from the activities for each sub-process. Activities are broken into tasks, and these tasks were categorized into one of three categories depending on the expected mode of execution in RUFORUM processes. **Table 18: Functional Requirements and System Specifications Application Management (5.1.1.3)** | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | **Application Intake** | **FRFA-AM001:** The system shall allow an authenticated applicant to initiate a new application against an active call, generating a unique Application ID, linking the application to the call record and parent funding record, and setting the initial status to “*Draft*.” | Applicant credentials, active call selection | Application record created with a unique Application ID; status set to Draft; linked to call and funding record; audit log entry created | Applicant, System (automated) | | | **FRFA-AM002:** The system shall display the application form configured for the call type, presenting the required fields and attachment checklist as defined in the Call Type Configuration Table (5.1.1.2). | Call type, call form configuration | Type-configured application form displayed to the applicant | System (automated) | | | **FRFA-AM003:** The system shall allow applicants to save an application as Draft at any point before submission without triggering mandatory field validation or eligibility screening. | Partial or complete application form data | Draft application saved; status remains Draft; audit log entry created | Applicant | | | **FRFA-AM004:** The system shall automatically save application form data at configurable intervals during entry to prevent data loss. | In-progress application form data | Auto-saved draft; no data loss on session interruption | System (automated) | | | **FRFA-AM005:** The system shall validate all mandatory fields and confirm all required attachments are present when the applicant clicks “*Submit*,” highlighting missing items and blocking submission until all are resolved. | Completed application form, required attachment checklist | Validation pass or field and attachment-level error messages; submission blocked until resolved | System (automated), Applicant | | | **FRFA-AM006:** The system shall validate each applicant-uploaded document for file format, file size, and malware before accepting it, rejecting files that fail any check, and displaying a specific error message identifying the reason. | Uploaded document files, validation rules | Validated documents stored and linked to the application, or a rejection error with a specific reason displayed | System (automated) | | | **FRFA-AM007:** The system shall perform automated eligibility screening on submission, checking applicant data against all enforceable eligibility rules stored on the call record, and blocking or flagging the application if any rule is not met, recording each specific rule failed. | Submitted application data, call eligibility rules | Eligibility pass leading to Submitted status, or automated rejection with specific rules failed recorded; applicant notified | System (automated) | | | **FRFA-AM008:** The system shall set application status to “*Submitted*,” lock the application against further editing, timestamp the submission, log the action in the audit trail, and send the applicant a submission acknowledgement notification upon successful submission and eligibility pass. | Validated and eligible application | Application status set to Submitted; application locked; timestamp recorded; audit log entry; acknowledgement notification sent to applicant | System (automated) | | | **FRFA-AM009:** The system shall prevent submission after the call deadline has passed, displaying a message confirming the portal is closed, and locking any in-progress draft applications. | Submission attempt after deadline | Submission blocked; explanatory message displayed; draft application locked | System (automated) | | **Application Tracking** | **FRFA-AM010:** The system shall assign and automatically update application status at each stage of the process: Draft, Submitted, Under Review, Revision Requested, Approved, Rejected, Rejected Ineligible, Withdrawn, maintaining a chronological status history for each application. | System events and user actions across all process stages | Application status updated; chronological status history maintained on application record | System (automated) | | | **FRFA-AM011:** The system shall allow applicants to log in at any point and view the current status and full chronological status history of their own applications. | Applicant login, application record | Current status and status history are displayed to the applicant | System (automated), Applicant | | | **FRFA-AM012:** The system shall provide Program Officers with a real-time dashboard view of all applications for a call, filterable by status, call type, submission date, and eligibility outcome. | Application records for a call | Filtered application dashboard displayed | Program Officer, System (automated) | | **Screening** | **FRFA-AM013:** The system shall allow Program Officers to access all submitted and eligibility-passed applications for a call and review each for document completeness, confirming required documents are present and legible. | Submitted application records, required document checklist | Program Officer document completeness review interface | Program Officer | | | **FRFA-AM014:** The system shall allow Program Officers to mark an application as “*Eligible Ready for Review*” upon successful document completeness check, advancing it to the reviewer assignment queue. | Program Officer completeness decision | Application status updated to Eligible Ready for Review; application enters reviewer assignment queue; audit log entry | Program Officer, System (automated) | | | **FRFA-AM015:** The system shall allow Program Officers to mark an application as “*Rejected Incomplete*” with a mandatory written reason when documents are missing or invalid, triggering an applicant notification with the specific reason. | Programme Officer rejection decision, written reason | Application status set to Rejected Incomplete; reason recorded; applicant notification dispatched; audit log entry | Program Officer, System (automated) | | | **FRFA-AM016:** The system shall allow Program Officers to raise a revision request on an application with written instructions and a defined resubmission deadline, setting status to “*Revision Requested*” and notifying the applicant. | Program Officer revision request, written instructions, resubmission deadline | Application status set to Revision Requested; instructions and deadline stored; applicant notification dispatched; audit log entry | Program Officer, System (automated) | | | **FRFA-AM017:** The system shall allow an applicant to make requested changes and resubmit within the revision deadline, after which the application is locked again and returned to the screening queue. If the applicant does not resubmit before the revision deadline, the system shall set the status to “*Withdrawn No Response*” and log the outcome. | Revised application submission or deadline expiry | Application relocked and returned to screening queue on resubmission, or status set to Withdrawn No Response on deadline expiry; audit log entry in both cases | Applicant, System (automated) | | **Reviewer Assignment and Workflow** | **FRFA-AM018:** The system shall allow Program Officers to assign one or more reviewers to each eligible application, with the system distributing assignments equitably across available reviewers based on current workload, providing the Program Officer with real-time visibility of reviewer assignment counts. | Eligible application records, available reviewer list, and current workload data | Reviewer assignments stored; workload distribution displayed to Program Officer; audit log entry | Program Officer, System (automated) | | | **FRFA-AM019:** The system shall notify each assigned reviewer of their assignment through the system and by email, set the review deadline, and grant the reviewer secure access restricted to only their assigned applications. | Reviewer assignment, review deadline, reviewer contact details | Reviewer notification dispatched; review deadline set; reviewer access granted to assigned applications only | System (automated) | | | **FRFA-AM020:** The system shall anonymise applicant’s name and all identifying information in the reviewer's view when blind review is enabled on the call, before granting the reviewer access to the application. | Blind review flag on call, application record | Applicant identity hidden in reviewer view; anonymised application materials displayed to the reviewer | System (automated) | | | **FRFA-AM021:** The system shall allow a reviewer to declare a conflict of interest on an assigned application before accessing its content, removing the reviewer from the assignment, logging the COI declaration with reviewer ID, application ID, and timestamp, and notifying the Program Officer to assign a replacement. | Reviewer COI declaration | Reviewer removed from assignment; COI declaration logged; Program Officer notified; replacement assignment pending | Reviewer, System (automated), Program Officer | | | **FRFA-AM022:** The system shall send an automated reminder notification to a reviewer who has not submitted their evaluation by the configured review deadline, and flag the assignment as overdue to the Program Officer if no submission is received within a configurable grace period. | Review deadline, reviewer submission status | Reminder notification sent to reviewer; overdue flag raised on assignment; Program Officer notified | System (automated), Program Officer | | | **FRFA-AM023:** The system shall allow the Program Officer to extend the review deadline for a specific reviewer or to reassign an overdue application to a different reviewer, logging all actions in the audit trail. | Program Officer action, new deadline, or replacement reviewer | Review deadline updated or reassignment recorded; notifications sent; audit log entry | Program Officer, System (automated) | | **Reviewer Scoring and Evaluation** | **FRFA-AM024:** The system shall allow reviewers to enter a numeric score per criterion, written comments, and a recommendation, either Accept, Minor Revision, Major Revision, or Reject, using the scoring criteria and weightings configured on the call. | Reviewer scores, comments, and recommendations per criterion | Evaluation record stored against the application; scores, comments, and recommendations saved with the reviewer ID and timestamp | Reviewer | | | **FRFA-AM025:** The system shall prevent a reviewer from viewing any other reviewer's scores, comments, or recommendations on the same application until all assigned reviewers have submitted their evaluations, when blind review is enabled. | Blind review flag, reviewer submission status | Cross-reviewer score visibility is blocked until all reviews are submitted | System (automated) | | | **FRFA-AM026:** The system shall automatically calculate and display the aggregated score, individual reviewer scores, weighted averages, comments, recommendations, and application ranking among all applications in the call once all assigned reviews are complete. | All reviewer evaluation records for an application, scoring weightings | Aggregated score, weighted average, individual breakdown, and ranking displayed to Program Officer | System (automated), Program Officer | | | **FRFA-AM027:** The system shall detect and flag conflicting reviewer recommendations on an application where reviewers' recommendations diverge beyond a configurable threshold, alerting the Program Officer and recording the conflict in the audit trail. | All reviewer recommendations for an application, conflict threshold configuration | Conflict flag raised on application record; Program Officer notified; conflict recorded in audit trail | System (automated), Program Officer | | | **FRFA-AM028:** The system shall allow the Program Officer to apply the configured conflict resolution protocol majority recommendation, average score threshold, or escalation to a senior reviewer, recording the resolution outcome in the audit trail before the final decision is made. | Conflict flag, conflict resolution protocol configuration, Program Officer action | Conflict resolution outcome recorded; audit log entry; application advanced to decision stage | Program Officer, System (automated) | | **Interview and Verification** | **FRFA-AM029:** The system shall allow Program Officers to schedule interviews for shortlisted applicants where required by call type, sending automated interview invitations through the system with date, time, format, and location details, and tracking interview status for each applicant. | Shortlisted applicant list, interview schedule details, and call interview flag | Interview invitations dispatched; interview status tracked per applicant; audit log entry | Program Officer, System (automated) | | | **FRFA-AM030:** The system shall allow Program Officers to record interview outcomes directly in the system using a structured form, linking the outcome to the applicant's application record and including it in the overall scoring and ranking. | Interview outcome, structured recording form | Interview outcome stored on application record; included in aggregated score and ranking | Program Officer | | | **FRFA-AM031:** The system shall provide a structured verification recording form for Scholarship calls where home or household verification is configured, allowing verification results to be entered directly in the system and linked to the applicant's record. | Verification results, structured form, Scholarship call verification flag | Verification results stored on application record; linked to applicant; audit log entry | Program Officer | | **Shortlisting and Decision** | **FRFA-AM032:** The system shall automatically generate a ranked shortlist of all applications based on aggregated scores, applying the minimum score threshold and maximum award number configured on the call, and flagging tied applications for Program Officer review. | All application scores, minimum threshold, maximum award number, and call configuration | Ranked shortlist generated; applications meeting threshold displayed in descending order; tied applications flagged; shortlist available to Program Officer | System (automated), Program Officer | | | **FRFA-AM033:** The system shall allow the Program Officer to review the ranked shortlist, individual scores, reviewer comments, and flagged ties before recording the final decision. | Ranked shortlist, individual scores, reviewer comments, conflict flags | Shortlist and supporting detail displayed to the Programme Officer for review | Program Officer | | | **FRFA-AM034:** The system shall allow the Program Officer to record a final decision of Approved or Rejected for each application, requiring mandatory written decision comments before the decision can be saved. | Program Officer decision, written comments | Decision recorded against application; mandatory comments stored; audit log entry with user ID, timestamp, and decision | Program Officer | | | **FRFA-AM035:** The system shall automatically update the application status to “*Approved”* or “*Rejected”* upon decision recording, and validate that the total number of approved applications does not exceed the maximum award number configured on the call before confirming the status update. | Decision records, maximum award number from call configuration | Application status updated; award count validated against maximum; system blocks excess approvals with explanatory message | System (automated) | | | **FRFA-AM036:** The system shall allow applicants to withdraw their own application before the call deadline, setting status to “*Withdrawn Applicant Request*,” logging the withdrawal with a timestamp, and notifying the Program Officer. | Applicant withdrawal action | Application status set to Withdrawn Applicant Request; Program Officer notified; application removed from active review queue; audit log entry | Applicant, System (automated) | | **Notification and Archiving** | **FRFA-AM037:** The system shall automatically dispatch decision notifications to all applicants upon decision recording, approved applicants receive their outcome and next steps; rejected applicants receive their outcome and, optionally, reviewer comments as configured on the call. | Decision records, applicant contact details, notification template, reviewer comment inclusion flag | Decision notifications dispatched to all applicants; dispatch log entries created | System (automated) | | | **FRFA-AM038:** The system shall allow administrators to configure notification templates for decision communications, including the option to include or exclude reviewer comments in rejection notifications. | Notification template configuration, reviewer comment inclusion setting | Configured notification template stored; applied to all decision notifications for the call | System Administrator, Funding Administrator | | | **FRFA-AM039:** The system shall flag all approved applications and make them available for progression to Award and Agreement Management (5.1.1.4), carrying forward the application ID, applicant details, call reference, funding record reference, and decision record. | Approved application records | Approved applications flagged and available in the Award and Agreement Management queue; application record with full context passed forward | System (automated) | | | **FRFA-AM040:** The system shall archive all rejected, ineligible, and withdrawn applications with their full audit trail, scores, evaluations, reviewer comments, and decision records retained and accessible to authorised users for audit and reporting purposes. | Rejected, ineligible, and withdrawn application records | Applications archived with full audit trail, scores, and decision records retained; accessible to authorised users | System (automated) | | | **FRFA-AM041:** The system shall log all actions across all application management sub-processes, including all create, update, status change, assignment, evaluation, decision, notification, and archive actions, capturing user ID or system event, timestamp, action type, and previous and new values where applicable. | All user and system actions across all application management stages | Comprehensive audit trail entries stored across all sub-processes and accessible to authorised users | System (automated) | **Table 19**: Award and Agreement Management use case narrative | Use case name | Award and Agreement Management | | --- | --- | | Actor | Grants Manager (primary), Finance Officer (primary), Program Director / Finance Director (approver), Awardee / Principal Investigator (recipient), System (automated) | | **Description ** | This use case describes how an authorised Grants Manager formalises the outcome of the application process by generating award letters, uploading and tracking signed agreements, defining grant milestones, configuring payment tranches, monitoring expenditure against budget, managing contract amendments, and tracking active award performance. The process begins from an approved application and ends when all contractual obligations are fulfilled, and the award is ready for close-out. | | Pre-condition | One or more applications with status “*Approved*” exist in the system, flagged for progression from Application Management (5.1.1.3). The parent funding record has sufficient committed balance to cover the award amount. The Grants Manager and Finance Officer are assigned to the parent funding record. The Award letter template is configured in the system. The Finance Management module is available for disbursement scheduling and tracking. | | Main success scenario | **Award Letter Generation** The Grants Manager navigates to the Award and Agreement Management module and selects an approved application from the queue. The System displays the approved application with awardee details, call reference, funding record reference, approved award amount, and decision record carried forward from Application Management. The Grants Manager selects “*Generate Award Letter.”* System populates the award letter template with awardee details, award amount, funding type, funding record reference, award conditions, and reporting obligations drawn from the parent funding record. The Grants Manager reviews and confirms the content. The System generates the award letter as a PDF, assigns a unique Award ID, sets the award status to “*Award Letter Issued*,” stores the letter in the document repository linked to the award record, and dispatches the award letter to the awardee by email with a notification to acknowledge receipt. The System records the award amount against the parent funding record, updating the disbursed allocation balance. **Agreement Upload and Execution ** The Awardee receives the award letter, signs the agreement, and uploads the signed agreement document through the system portal. The System validates the uploaded agreement file for format and size, assigns a document ID, links it to the award record, and notifies the Grants Manager that the signed agreement has been received. The Grants Manager reviews the signed agreement, confirms it is complete and correctly executed, and marks the agreement as “*Accepted*.” System sets the award status to “*Agreement Signed Active*” and logs the action in the audit trail. If the Grants Manager finds the agreement is incorrectly executed or incomplete, the Grants Manager marks it as “*Returned Correction Required*” with written instructions. System notifies the awardee to resubmit a corrected agreement. **Milestone and Payment Configuration** The Grants Manager defines the milestone schedule for the award, entering each milestone title, description, due date, and the deliverable required to release payment for that milestone. Milestone due dates must fall within the award start and end dates. The Grants Manager configures payment schedules linked to milestones, entering the schedule amount, the milestone it is conditional on, and the expected disbursement date. The System validates that the total of all configured tranches equals the approved award amount and displays an error if a variance exists. The Finance Officer reviews and confirms the payment configuration. The System sets the schedule as active and generates a disbursement calendar visible to both the Grants Manager and Finance Officer. The System sends the awardee a notification confirming the award is active, with the milestone schedule and payment tranche plan attached. **Milestone Tracking and Payment Release** As each milestone due date approaches, the system sends automated reminder notifications to the awardee and Grants Manager at configurable intervals before the due date. The Awardee submits evidence of milestone completion through the system by uploading the required deliverable and a completion report. The System timestamps the submission, assigns a document ID, and notifies the Grants Manager. The Grants Manager reviews the milestone submission and deliverable. If the milestone is satisfactorily completed, the Grants Manager marks it as “Milestone Met” and initiates the associated payment release. The Finance Officer reviews the payment release request, confirms the milestone evidence, approves the disbursement, and records the payment details date, amount, and payment reference in the system. The System updates the status to “*Disbursed*,” updates the award's total disbursed amount, and notifies the awardee of the payment. The System continuously tracks total disbursed amount against approved award amount and displays a real-time expenditure dashboard for the award, showing disbursed amount, remaining balance, milestone completion status, and next tranche due date. **Contract Amendment ** Where a change to the award terms is required, extension of end date, budget reallocation between line items, change of Principal Investigator, or modification of milestones, the Grants Manager raises an amendment request, documenting the nature of the change, the justification, and the proposed new terms. The System routes the amendment request to the Program Director or Finance Director for approval, notifying them with the amendment details and the current award terms for comparison. The Approver reviews the amendment request. If approved, system updates the award record with the new terms, creates a version record preserving the previous terms, sets a new amendment number, logs the approval in the audit trail, and notifies the Grants Manager and awardee of the approved changes. If rejected, the system notifies the Grants Manager with the rejection reason and the award terms remain unchanged. All approved amendments are stored as a versioned amendment log on the award record, accessible for audit and reporting. **Award Performance Monitoring** The System monitors all active awards for overdue milestones whose due dates have passed without a completion submission. When an overdue milestone is detected, the system raises an overdue alert on the award record and notifies the Grants Manager. The* *Grants Manager reviews overdue alerts and takes action either granting a formal milestone extension through the amendment process or escalating to the Programme Director where the overdue poses a risk to fund integrity. The System provides the Grants Manager and Program Director with a real-time award performance dashboard across all active awards, showing milestone completion rates, disbursement status, overdue alerts, and remaining balances per award and in aggregate across the funding record. When all milestones are completed, all payments disbursed, and total disbursed amount equals the approved award amount, system flags the award as “*Ready for Close-Out*” and notifies the Grants Manager to initiate the Grant Close-Out process (5.1.1.5). | | **Alternative flow** | **A1 Awardee Does Not Acknowledge Award Letter** The System sends the award letter and automated acknowledgement request to the awardee. If no acknowledgement is received within a configurable period, the system sends an automated reminder. If still no acknowledgement after a further configurable grace period, the system raises an alert to the Grants Manager to follow up directly. The Award status remains “*Award Letter Issued*” until acknowledgement is confirmed. **A2 Awardee Does Not Return Signed Agreement** After the award letter is acknowledged, if the signed agreement is not uploaded within the configurable deadline, the system sends automated reminders to the awardee at configured intervals. If the agreement is not received by the final deadline, the system raises an escalation alert to the Grants Manager and Program Director. The Grants Manager may extend the agreement submission deadline through the system or initiate award cancellation. If cancelled, the system sets the award status to “C*ancelled Agreement Not Returned*,” releases the award amount back to the uncommitted balance on the parent funding record, and logs the cancellation with reason in the audit trail. **A3 Payment Total Does Not Equal Award Amount** When configuring payment amounts, the Grants Manager enters amounts whose total does not equal the approved award amount. The System displays an inline variance error showing the difference and blocks the configuration from being saved until the total is reconciled. Grants Manager adjusts the amounts until the total equals the award amount. **A4 Milestone Not Met** The Grants Manager reviews the awardee’s milestone submission and determines that the deliverable does not meet the required standard. The Grants Manager marks the milestone as “*Not Met Revision Required*” with written feedback. The system notifies the awardee of the feedback and a resubmission deadline. Payment amount linked to that milestone is held and not released until the milestone is marked as Met. If the awardee does not resubmit by the revision deadline, the system raises an overdue alert and notifies the Grants Manager to escalate or initiate an amendment. **A5 Budget Reallocation Request (Deferred Budget)** For call types where the awardee budget was deferred to the award stage Scholarship, Fellowship, and Challenge the Grants Manager initiates a budget assignment workflow after the technical review, entering the specific budget breakdown for the awardee. The System validates the budget against the award amount and stores it on the award record. The Finance Officer confirms the budget assignment before the first payment is released. **A6 Award Cancellation After Activation** After the award is active, circumstances require cancellation, for example, the awardee withdraws, the awardee becomes ineligible, or funding is withdrawn. The Grants Manager raises a cancellation request with a mandatory written reason. System routes the cancellation for approval by the Programme Director. On approval, the system sets the award status to “*Cancelled*,” stops any scheduled payment releases, releases any undisbursed balance back to the parent funding record's uncommitted balance, notifies the awardee of the cancellation reason, and logs all actions in the audit trail. Any payments already disbursed are flagged for recovery review by the Finance Officer. | | **Post condition** | **Active Award** The Award record stored with unique Award ID, status “*Agreement Signed Active*,” linked to approved application, call record, and parent funding record. The Milestone schedule and payment plan defined and active. The Disbursement calendar generated and visible to Grants Manager and Finance Officer. The Awardee notified of active status with milestone and payment plan. The Award amount recorded against parent funding record disbursed allocation. The Full audit trail recorded. **Milestone Completed and payment Disbursed** Milestone marked as Met with deliverable stored and linked to award record. Associated payment disbursed with payment reference recorded. Disbursed total updated on award record and parent funding record. Awardee notified of payment. **Ready for Close-Out** All milestones marked Met. All tranches disbursed. Total disbursed equals approved award amount. Award status set to “*Ready for Close-Out*.” Grants Manager notified to initiate Grant Close-Out (5.1.1.5). **Cancelled** The Award status is set to “*Cancelled*.” Undisbursed balance released to the parent funding record. Cancellation reason and approver recorded in audit trail. Disbursed amounts flagged for Finance Officer recovery review where applicable. | **Table 20**: Requirements specification for fund management | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | **Award Letter Generation** | **FRFA-AA001:** The system shall display approved applications flagged from Application Management (5.1.1.3), showing awardee details, call reference, funding record reference, approved award amount, and decision record. | Approved application records from 5.1.1.3 | Approved application queue displayed to the Grants Manager | Grants Manager | | | **FRFA-AA002:** The system shall generate an award letter by populating a configured template with awardee details, award amount, funding type, funding record reference, award conditions, and reporting obligations drawn from the parent funding record. | Award letter template, approved application data, parent funding record data | Populated award letter generated as PDF | Grants Manager, System (automated) | | | **FRFA-AA003:** The system shall assign a unique Award ID, set the award status to “*Award Letter Issued*,” store the generated award letter in the document repository linked to the award record, and dispatch the letter to the awardee by email with an acknowledgement request. | Generated award letter PDF, awardee contact details | Unique Award ID assigned; award letter stored and linked; email dispatched to awardee; audit log entry created | System (automated) | | | **FRFA-AA004:** The system shall record the award amount against the parent funding record, updating the disbursed allocation balance to reflect the new commitment. | Approved award amount, parent funding record balance | Disbursed allocation balance updated on parent funding record; audit log entry | System (automated) | | | **FRFA-AA005:** The system shall send automated reminder notifications to the awardee if acknowledgement of the award letter is not received within a configurable period, and raise an escalation alert to the Grants Manager if acknowledgement is still not received after a further configurable grace period. | Acknowledgement status, configurable reminder and escalation periods | Reminder notifications dispatched to awardee; escalation alert raised to Grants Manager if no response | System (automated), Grants Manager | | **Agreement Upload and Execution** | **FRFA-AA006:** The system shall allow the awardee to upload a signed agreement document through the system portal, validating the file for format and size, assigning a document ID, and linking it to the award record. | Signed agreement file uploaded by awardee, validation rules | Validated agreement stored with document ID and linked to award record; Grants Manager notified of receipt; audit log entry | Awardee, System (automated) | | | **FRFA-AA007:** The system shall allow the Grants Manager to mark a received signed agreement as “*Accepted*,” setting the award status to “*Agreement Signed Active”* and logging the action in the audit trail. | Grants Manager acceptance action | Award status set to Agreement Signed Active; audit log entry with user ID and timestamp | Grants Manager, System (automated) | | | **FRFA-AA008:** The system shall allow the Grants Manager to mark a received signed agreement as “*Returned Correction Required”* with mandatory written instructions, notifying the awardee to resubmit a corrected agreement. | Grants Manager rejection action, written instructions | Agreement status set to Returned Correction Required; instructions stored; awardee notification dispatched; audit log entry | Grants Manager, System (automated) | | | **FRFA-AA009:** The system shall send automated reminders to the awardee if the signed agreement is not uploaded within a configurable deadline, and raise an escalation alert to the Grants Manager and Program Director if the final deadline passes without receipt. | Agreement submission deadline, submission status | Reminder notifications dispatched; escalation alert raised to Grants Manager and Program Director on deadline expiry | System (automated) | | **Milestone and Payment Tranche Configuration** | **FRFA-AA010:** The system shall allow the Grants Manager to define a milestone schedule for each award, capturing milestone title, description, due date, and required deliverable for each milestone, and validating that all milestone due dates fall within the award start and end dates. | Grants Manager milestone inputs, award start and end dates | Milestone schedule stored on award record; date validation enforced; audit log entry | Grants Manager, System (automated) | | | **FRFA-AA011:** The system shall allow the Grants Manager to configure payment tranches linked to milestones, capturing tranche amount, linked milestone, and expected disbursement date, and validate that the total of all configured tranches equals the approved award amount displaying an inline error and blocking save if a variance exists. | Tranche amounts, linked milestones, approved award amount | Tranche schedule stored on award record; total validated against award amount; variance error displayed if mismatch; audit log entry | Grants Manager, System (automated) | | | **FRFA-AA012:** The system shall allow the Finance Officer to review and confirm the payment tranche configuration, after which the system activates the tranche schedule and generates a disbursement calendar visible to both the Grants Manager and Finance Officer. | Finance Officer confirmation action, tranche schedule | Tranche schedule activated; disbursement calendar generated and visible to Grants Manager and Finance Officer; audit log entry | Finance Officer, System (automated) | | | **FRFA-AA013:** The system shall notify the awardee when the award is activated, attaching the milestone schedule and payment tranche plan to the notification. | Activated award record, awardee contact details, milestone and tranche schedule | Activation notification with milestone and tranche plan dispatched to awardee | System (automated) | | **Milestone Tracking and Payment Release** | **FRFA-AA014:** The system shall send automated reminder notifications to the awardee and Grants Manager at configurable intervals before each milestone due date. *(Addresses as-is gap: no visibility into delayed reports)* | Milestone due dates, configurable reminder intervals, awardee and Grants Manager contact details | Reminder notifications dispatched at configured intervals before each milestone due date | System (automated) | | | **FRFA-AA015:** The system shall allow the awardee to submit milestone completion evidence through the system portal, uploading the required deliverable and a completion report, with the system timestamping the submission, assigning a document ID, and notifying the Grants Manager. | Awardee deliverable upload and completion report | Milestone submission stored with document ID and timestamp; Grants Manager notified; audit log entry | Awardee, System (automated) | | | **FRFA-AA016:** The system shall allow the Grants Manager to mark a milestone as “*Milestone Met”* upon satisfactory review of the completion evidence, and initiate the associated payment tranche release request to the Finance Officer. | Grants Manager milestone review decision | Milestone status set to Met; tranche release request raised to Finance Officer; audit log entry | Grants Manager | | | **FRFA-AA017:** The system shall allow the Grants Manager to mark a milestone as "Not Met Revision Required" with mandatory written feedback, holding the associated payment tranche, and notifying the awardee with the feedback and a resubmission deadline. | Grants Manager rejection decision, written feedback, resubmission deadline | Milestone status set to Not Met Revision Required; tranche held; awardee notified; audit log entry | Grants Manager, System (automated) | | | **FRFA-AA018:** The system shall allow the Finance Officer to approve a tranche release request by confirming milestone evidence, entering payment details date, amount, and payment reference and recording the disbursement, after which the system updates the tranche status to “*Disbursed*,” updates the award’s total disbursed amount, and notifies the awardee. | Finance Officer disbursement approval, payment details | Tranche status set to Disbursed; payment details recorded; total disbursed amount updated on award record and parent funding record; awardee notification dispatched; audit log entry | Finance Officer, System (automated) | | | **FRFA-AA019:** The system shall continuously track total disbursed amount against approved award amount for each active award and display a real-time expenditure dashboard showing disbursed amount, remaining balance, milestone completion status, and next tranche due date. *(Addresses as-is gap: no budget tracking or grant progress visibility)* | Award disbursement records, milestone completion records | Real-time expenditure dashboard displayed to the Grants Manager and the Finance Officer | System (automated) | | | **FRFA-AA020:** The system shall detect overdue milestones milestones whose due dates have passed without a completion submission raise an overdue alert on the award record, and notify the Grants Manager. | Milestone due dates, milestone submission status | Overdue alert raised on award record; Grants Manager notified; audit log entry | System (automated) | | **Contract Amendment** | **FRFA-AA021:** The system shall allow the Grants Manager to raise an amendment request documenting the nature of the change, justification, and proposed new terms, and route the request to the Program Director or Finance Director for approval with the current award terms displayed for comparison. | Grants Manager amendment request, written justification, proposed new terms, current award terms | Amendment request stored; approval notification dispatched to Program Director or Finance Director; audit log entry | Grants Manager, System (automated) | | | **FRFA-AA022:** The system shall allow the approver to approve or reject an amendment request on approval, updating the award record with the new terms, creating a version record preserving the previous terms, assigning a new amendment number, and notifying the Grants Manager and awardee; on rejection, notifying the Grants Manager with the rejection reason and leaving award terms unchanged. | Approver decision, rejection reason if applicable | Award record updated with new terms and amendment number on approval; version record created; notifications dispatched; or rejection reason recorded and Grants Manager notified; audit log entry in both cases | Program Director / Finance Director, System (automated) | | | **FRFA-AA023:** The system shall maintain a versioned amendment log on each award record, storing all approved amendments with amendment number, date, approver, previous terms, and new terms, accessible to authorised users for audit and reporting. | Approved amendment records | Versioned amendment log stored on award record; accessible to authorised users | System (automated) | | **Award Performance Monitoring** | **FRFA-AA024:** The system shall provide the Grants Manager and Program Director with a real-time award performance dashboard across all active awards, displaying milestone completion rates, disbursement status, overdue alerts, and remaining balances per award and in aggregate across the funding record. | All active award records, milestone and disbursement data | Aggregate performance dashboard displayed with per-award and portfolio-level metrics | System (automated) | | | **FRFA-AA025:** The system shall allow the Grants Manager to assign a deferred budget breakdown to an award for Scholarship, Fellowship, and Challenge call types after technical review, validating the budget against the award amount and requiring Finance Officer confirmation before the first tranche is released. | Grants Manager budget breakdown input, award amount, Finance Officer confirmation | Budget breakdown stored on award record; validated against award amount; Finance Officer confirmation required before first tranche release; audit log entry | Grants Manager, Finance Officer, System (automated) | | | **FRFA-AA026:** The system shall flag an award as “*Ready for Close-Out”* and notify the Grants Manager to initiate Grant Close-Out (5.1.1.5) when all milestones are completed, all tranches are disbursed, and the total disbursed amount equals the approved award amount. | Milestone completion status, tranche disbursement status, disbursed total vs award amount | Award status set to Ready for Close-Out; Grants Manager notified; award available in Grant Close-Out queue (5.1.1.5) | System (automated) | | **Award Cancellation** | **FRFA-AA027:** The system shall allow the Grants Manager to raise an award cancellation request with a mandatory written reason at any point after activation, routing the request to the Program Director for approval. | Grants Manager cancellation request, written reason | Cancellation request stored; approval notification dispatched to Program Director; audit log entry | Grants Manager, System (automated) | | | **FRFA-AA028:** The system shall, on cancellation approval, set award status to “*Cancelled*,” stop all scheduled tranche releases, release the undisbursed balance back to the parent funding record's uncommitted balance, notify the awardee with the cancellation reason, and flag any already-disbursed tranches for Finance Officer recovery review. | Cancellation approval, undisbursed balance, disbursed tranche records | Award status set to Cancelled; scheduled tranches stopped; undisbursed balance released to parent funding record; awardee notification dispatched; disbursed tranches flagged for recovery review; audit log entry | System (automated), Finance Officer | | **Audit Trail and Version History** | **FRFA-AA029:** The system shall log all actions across all Award and Agreement Management sub-processes including award generation, agreement upload and acceptance, milestone configuration, tranche configuration and disbursement, amendment requests and approvals, performance alerts, and cancellations capturing user ID or system event, timestamp, action type, and previous and new values where applicable. | All user and system actions across Award and Agreement Management | Comprehensive audit trail stored and accessible to authorised users | System (automated) | | | **FRFA-AA030:** The system shall maintain a version history for each award record, creating a new version entry each time the award terms, milestone schedule, or tranche configuration is modified, with all previous versions accessible for audit and reference. | Award record modification events | Version records stored with timestamps; all previous versions accessible to authorised users | System (automated) | | **Use case name** | Grant Close-Out | | --- | --- | | **Actor** | Grants Manager (primary), Finance Officer (primary), Program Director (approver), Awardee (submitter), System (automated) | | **Description ** | This use case describes how an authorised Grants Manager formally closes an award once all contractual obligations are fulfilled, and subsequently closes the parent funding record once all its awards are closed. The process covers close-out checklist enforcement, final narrative and financial report submission and approval, asset verification, outstanding balance resolution, formal award closure, archiving, and funding record closure. The process is the direct system response to the as-is gap of projects remaining open indefinitely past their end date, allowing fund claims after expiry. | | **Pre-condition** | An award record with status “*Ready for Close-Out*” exists, flagged from Award and Agreement Management (5.1.1.4), confirming all milestones are met, and all tranches are disbursed. The Grants Manager is assigned to the award record and has the close-out permission role. The close-out checklist template is configured in the system for the relevant funding type. The award end date has been reached, or the Grants Manager has manually triggered close-out following full milestone completion. | | **Main success scenario** | **Close-Out Initiation —** The system detects that an award has been flagged as “*Ready for Close-Out*” and automatically generates a close-out record linked to the award, sets the award status to “*Close-Out In Progress*,” and notifies the Grants Manager and Awardee that the formal close-out process has been initiated. System enforces the award end date from this point; no new disbursement requests, fund claims, or milestone submissions can be raised against the award. Any attempt to do so is blocked with an explanatory message. *(Directly addresses as-is gap: system unable to close out projects, causing late fund claims)* Grants Manager opens the close-out record and reviews the system-generated close-out checklist. The checklist is pre-configured for the funding type and contains all mandatory items that must be completed before formal closure is possible. **Final Reporting ** System notifies the Awardee of the close-out initiation and requests submission of the final narrative report and final financial report, providing the configured submission deadline for close-out documentation. Awardee submits the final narrative report through the system portal, uploading the report document and any required supporting outputs, publications, completion certificates, and implementation evidence as defined by the funding type. System validates file formats, assigns document IDs, timestamps the submission, and links all documents to the close-out record. Awardee submits the final financial report, providing a reconciliation of all disbursed tranches against actual line-item expenditure. The system stores the report and notifies the Grants Manager and Finance Officer. Finance Officer reviews the final financial report, verifying that total reported expenditure reconciles with total disbursed amount and that all line items are within approved budget limits. If the financial report reconciles cleanly, the Finance Officer marks it as "Financial Report Accepted." If discrepancies exist, the Finance Officer marks them as “*Financial Report Queries Raised*” with written queries, and the system notifies the Awardee to respond. Grants Manager reviews the final narrative report and supporting outputs. If satisfactory, the Grants Manager marks it as “*Narrative Report Accepted*.” If not satisfactory, the Grants Manager marks it as “*Narrative Report Revision Required*” with written feedback, and the system notifies the Awardee to resubmit before the close-out deadline. **Asset Verification** Where the award involved procurement of physical assets, the Grants Manager initiates the asset verification step. Grants Manager records the verification outcome for each declared asset confirmed present and accounted for, transferred to an approved party, or disposed of per award terms using the structured asset verification form in the system. System stores all asset verification records linked to the close-out record. If any asset is unaccounted for, the system flags it as an outstanding item on the close-out checklist and prevents progression until resolved. **Checklist Completion and Outstanding Balance Resolution ** Grants Manager works through the close-out checklist, marking each item as complete as the relevant evidence is received and verified. The system prevents any checklist item from being marked complete without the required supporting action or document being recorded. If the final financial report reveals an unspent balance total disbursed exceeds the total reported expenditure Finance Officer raises a recovery request for the unspent amount. System records the recovery amount on the close-out record and adds recovery confirmation as a mandatory checklist item. The award cannot be formally closed until recovery is confirmed, received, or formally waived by an authorised approver. Once all checklist items are marked complete, the system performs a final validation confirming every mandatory item is resolved, all required documents are linked, and no outstanding flags exist on the close-out record. **Formal Award Closure** Grants Manager submits the close-out record for approval. The system routes the close-out for final approval by the Programme Director, notifying them with a summary of the completed checklist, final reports, financial reconciliation, and asset verification outcomes. The Programme Director reviews the close-out summary and approves or rejects it. On approval, the system sets the award status to “*Closed*,” locks the award record against any further editing, records the closure date, logs the approval in the audit trail with the user ID and timestamp, and notifies the Grants Manager, Finance Officer, and Awardee that the award is formally closed. The system archives the complete award record, including the original application, award letter, signed agreement, all milestone submissions and evidence, all disbursement records, all amendments, final reports, asset verification records, and the close-out record in the document repository, applying the configured retention policy for the funding type. **Funding Record Close-Out —** System checks whether all awards linked to the parent funding record are now closed. If awards remain active or in progress, no further action is taken at the funding record level. When the last award under a funding record reaches “*Closed*” status, the system flags the funding record as “*Ready for Programme Close-Out*” and notifies the Grants Manager. Grants Manager reviews the funding record summary, total awarded, total disbursed, total recovered, remaining uncommitted balance, if any, and the status of all linked awards and confirms all obligations under the funding record are fulfilled. Grants Manager submits the funding record for programme-level closure. Program Director approves. The system sets funding record status to “*Closed*,” locks the funding record against further calls or amendments, finalises all balance figures, logs the closure in the audit trail, and notifies all assigned staff. System archives the complete funding record with all linked calls, awards, and close-out records in the document repository under the configured programme retention policy. | | Alternative flow | **A1 Award End Date Passes Without Close-Out Initiation** The configured award end date passes, but the award has not yet been flagged as “*Ready for Close-Out*” from Award and Agreement Management, for example, outstanding milestones exist. The system automatically blocks all new disbursement requests and fund claims against the award, raises an expiry alert on the award record, and notifies the Grants Manager and Program Director. The Grants Manager must either resolve outstanding milestones through Award and Agreement Management (5.1.1.4) to complete the normal lifecycle, or initiate a forced close-out with a mandatory written justification if the award is to be closed with outstanding items unresolved. Forced close-out requires Programme Director approval and is recorded as an exception in the audit trail. **A2 Final Report Not Submitted by Close-Out Deadline** The Awardee does not submit the final narrative or financial report by the configured close-out submission deadline. System sends automated reminder notifications to the Awardee at configurable intervals before and after the deadline. If reports are still not received after a further configurable grace period, the system escalates to the Grants Manager and Program Director. Grants Manager may extend the close-out deadline through a formal extension recorded in the system, or initiate a forced close-out under A1 procedures if the Awardee is unresponsive. **A3 Financial Report Discrepancy Unspent Balance** Finance Officer identifies that total reported expenditure is less than total disbursed amount an unspent balance exists. Finance Officer raises a recovery request for the unspent amount. System records the recovery amount and adds it as a mandatory outstanding item on the close-out checklist. Award cannot be formally closed until the recovery amount is confirmed received by the Finance Officer and recorded in the system, or until a formal waiver is approved by the Program Director with a written justification. **A4 Financial Report Discrepancy Overspend** Finance Officer identifies that total reported expenditure exceeds total disbursed amount an overspend exists. Finance Officer raises an overspend query. The system flags the discrepancy and notifies the Grants Manager and Programme Director. Grants Manager and Finance Officer investigate. If the overspend is validated and approved for coverage, an amendment is raised through Award and Agreement Management (5.1.1.4) to authorise the additional amount before close-out proceeds. If the overspend is not approved, the Awardee is required to submit a corrected financial report. **A5 Asset Unaccounted For** During asset verification, the Grants Manager records that one or more declared assets cannot be confirmed as present, transferred, or disposed of per the award terms. System flags the unverified asset as an outstanding close-out checklist item. The award cannot be formally closed until the asset is either verified or the discrepancy is formally resolved. The Grants Manager documents the investigation outcome. If the asset is confirmed lost or misappropriated, the matter is escalated to the Programme Director and recorded as an exception in the audit trail with the resolution action taken. **A6 Close-Out Rejected by Program Director** Program Director reviews the close-out submission and determines it is not complete or satisfactory, rejecting it with written reasons. System returns the close-out record to “*Close-Out In Progress*” status, notifies the Grants Manager of the rejection reasons, and identifies which checklist items or documents require further action. Grants Manager addresses the outstanding items and resubmits for approval. | | **Post condition** | **Award Closed** Award status set to “*Closed.*” The Award record locked against further editing. All close-out checklist items confirmed complete and recorded. Final narrative and financial reports accepted and stored. Asset verification records complete. Any recovery amounts confirmed received or formally waived. Complete award archive stored in document repository under configured retention policy. Full audit trail of the close-out process recorded. Awardee, Grants Manager, Finance Officer, and Program Director notified of formal closure. **Funding Record Closed** Funding record status set to “*Closed*.” No further calls, awards, or amendments can be raised against it. All balance figures finalised: total awarded, total disbursed, total recovered, and final uncommitted balance. Complete programme archive stored in document repository. Full audit trail of programme closure recorded. **Close-Out In Progress Incomplete** Award status remains “*Close-Out In Progress.”* Outstanding checklist items listed and visible to Grants Manager. All disbursements and fund claims remain blocked. System continues to send reminders for outstanding items. | **Table 21**: Requirements specifications for fund administration | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | **Close-Out Initiation** | **FRFA-CO001:** The system shall automatically generate a close-out record linked to the award when an award is flagged as “*Ready for Close-Out*” from Award and Agreement Management (5.1.1.4), set the award status to "*Close-Out In Progress*," and notify the Grants Manager and Awardee that close-out has been initiated. | Award record with status Ready for Close-Out | Close-out record created and linked to the award; award status set to Close-Out In Progress; notifications dispatched to Grants Manager and Awardee; audit log entry | System (automated) | | | **FRFA-CO002:** The system shall enforce a hard block on all new disbursement requests, fund claims, and milestone submissions against an award once close-out is initiated, displaying an explanatory message to any user attempting to raise such actions. | Close-out initiation event, award record | All new disbursements, fund claims, and milestone submissions are blocked; an explanatory message is displayed on any blocked attempt; an audit log entry | System (automated) | | | **FRFA-CO003:** The system shall automatically trigger close-out initiation and enforce the disbursement block when the configured award end date passes, raising an expiry alert on the award record and notifying the Grants Manager and Program Director, regardless of whether the award has been manually flagged as Ready for Close-Out. | Award end date, system clock | Expiry alert raised on award record; close-out initiated; disbursement block enforced; Grants Manager and Program Director notified; audit log entry | System (automated) | | | **FRFA-CO004:** The system shall display the close-out checklist to the Grants Manager upon opening the close-out record, pre-configured for the funding type of the award, listing all mandatory items that must be completed before formal closure is possible. | Close-out record, funding type, close-out checklist template configuration | Funding-type-specific close-out checklist displayed to Grants Manager with all mandatory items listed and current completion status shown | System (automated), Grants Manager | | **Final Reporting** | **FRFA-CO005:** The system shall notify the Awardee of close-out initiation and request submission of the final narrative report and final financial report, including the configured close-out documentation submission deadline, dispatching the notification by email and in-system alert. | Close-out initiation event, Awardee contact details, submission deadline configuration | Close-out notification with submission deadline dispatched to Awardee; audit log entry | System (automated) | | | **FRFA-CO006:** The system shall allow the Awardee to submit the final narrative report and required supporting outputs through the system portal, validating each uploaded file for format, size, and malware, assigning document IDs, timestamping submissions, and linking all documents to the close-out record. Supporting output types vary by funding type. Grant calls require publications and research outputs; Scholarship calls require academic completion certificates and institutional confirmation; Fellowship calls require fellowship completion reports and output verification; Challenge calls require innovation implementation reports and impact evidence. | Awardee final narrative report and supporting output uploads, file validation rules, and funding type | Validated final narrative report and supporting outputs stored with document IDs and linked to close-out record; Grants Manager notified of submission; audit log entry | Awardee, System (automated) | | | **FRFA-CO007:** The system shall allow the Awardee to submit the final financial report, providing a reconciliation of all disbursed tranches against actual line-item expenditure, storing the report, and notifying the Grants Manager and Finance Officer. | Awardee final financial report upload | Final financial report stored and linked to close-out record; Grants Manager and Finance Officer notified; audit log entry | Awardee, System (automated) | | | **FRFA-CO008:** The system shall allow the Finance Officer to mark the final financial report as “*Financial Report Accepted*” when expenditure reconciles with disbursed amount, and all line items are within approved budget limits, updating the close-out checklist accordingly. | Finance Officer reviews decision, final financial report, disbursement records, and approved budget | Financial report status set to Accepted; close-out checklist item updated to complete; audit log entry | Finance Officer | | | **FRFA-CO009:** The system shall allow the Finance Officer to mark the final financial report as “*Financial Report Queries Raised”* with mandatory written queries when discrepancies exist, notifying the Awardee to respond and holding the relevant close-out checklist item as incomplete until the queries are resolved. | Finance Officer queries, written query details | Financial report status set to Queries Raised; written queries stored; Awardee notified; checklist item held incomplete; audit log entry | Finance Officer, System (automated) | | | **FRFA-CO010:** The system shall allow the Grants Manager to mark the final narrative report as “*Narrative Report Accepted”* when satisfactory, or as “*Narrative Report Revision Required”* with mandatory written feedback when not satisfactory, notifying the Awardee to resubmit before the close-out deadline and holding the relevant checklist item incomplete until accepted. | Grants Manager review decision, written feedback if a revision is required | Narrative report status set to Accepted or Revision Required; checklist item updated accordingly; Awardee notified if revision required; audit log entry | Grants Manager, System (automated) | | | **FRFA-CO011:** The system shall send automated reminder notifications to the Awardee at configurable intervals before and after the close-out documentation submission deadline if final reports have not been submitted, and escalate to the Grants Manager and Program Director after a configurable grace period of non-submission. | Submission deadline, report submission status, configurable reminder, and escalation intervals | Reminder notifications dispatched to Awardee; escalation alert raised to Grants Manager and Program Director after grace period; audit log entries | System (automated) | | **Asset Verification** | **FRFA-CO012:** The system shall allow the Grants Manager to record asset verification outcomes for each declared asset using a structured form, capturing asset description, verification status confirmed present and accounted for, transferred to approved party, or disposed of per award terms and supporting evidence where required. | Grants Manager asset verification inputs, declared asset list from the award record | Asset verification records stored and linked to the close-out record; audit log entry | Grants Manager | | | **FRFA-CO013:** The system shall flag any asset recorded as unaccounted for as an outstanding item on the close-out checklist, preventing the checklist item from being marked complete and blocking formal closure until the discrepancy is resolved and the resolution outcome is documented in the system. | Asset verification record with unaccounted status | Outstanding asset flag raised on close-out checklist; formal closure blocked; Grants Manager notified; audit log entry | System (automated) | | **Checklist Completion and Outstanding Balance Resolution** | **FRFA-CO014:** The system shall enforce that each close-out checklist item can only be marked complete when the required supporting action or document is confirmed recorded in the system, preventing manual override of any mandatory checklist item without the corresponding evidence. | Checklist item completion action, supporting evidence status | Checklist item marked complete with evidence reference, or completion blocked with explanatory message if required evidence is absent | System (automated), Grants Manager | | | **FRFA-CO015:** The system shall detect an unspent balance when the final financial report shows total reported expenditure is less than total disbursed amount, automatically calculate the recovery amount, add recovery confirmation as a mandatory outstanding close-out checklist item, and notify the Finance Officer to raise a recovery request. | Final financial report expenditure total, total disbursed amount | Unspent balance calculated and recorded on close-out record; recovery checklist item added as mandatory; Finance Officer notified; audit log entry | System (automated), Finance Officer | | | **FRFA-CO016:** The system shall allow the Finance Officer to record confirmation of recovery receipt against an outstanding recovery amount, marking the recovery checklist item as complete and storing the payment reference and date. | Finance Officer recovery confirmation, payment reference and date | Recovery checklist item marked complete; payment reference stored on close-out record; audit log entry | Finance Officer | | | **FRFA-CO017:** The system shall allow the Program Director to formally waive a recovery amount with a mandatory written justification, marking the recovery checklist item as complete with the waiver recorded, when recovery is not possible or is approved for write-off. | Program Director waiver action, written justification | Recovery waiver recorded on close-out record with justification; checklist item marked complete; audit log entry | Program Director | | | **FRFA-CO018:** The system shall detect an overspend when total reported expenditure exceeds total disbursed amount, flag the discrepancy on the close-out record, and notify the Grants Manager, Finance Officer, and Program Director to investigate and resolve before close-out can proceed. | Final financial report expenditure total, total disbursed amount | Overspend flag raised on close-out record; Grants Manager, Finance Officer, and Program Director notified; close-out held pending resolution; audit log entry | System (automated) | | | **FRFA-CO019:** The system shall perform a final validation of the close-out checklist when the Grants Manager submits the close-out record for approval, confirming every mandatory item is marked complete, all required documents are linked, and no outstanding flags exist, blocking submission if any item remains unresolved and listing all outstanding items. | Complete close-out checklist, document link status, and outstanding flag status | Validation pass leading to close-out submission, or a summary list of outstanding items with submission blocked | System (automated) | | **Formal Award Closure** | **FRFA-CO020:** The system shall route the close-out record to the Program Director for final approval on submission, notifying them with a summary of the completed checklist, final reports, financial reconciliation, asset verification outcomes, and any waivers or exceptions recorded. | Submitted close-out record, Program Director contact details | Close-out approval notification dispatched to Program Director with full summary; audit log entry | System (automated), Program Director | | | **FRFA-CO021:** The system shall allow the Program Director to approve the close-out, setting the award status to “*Closed*,” locking the award record against any further editing, recording the closure date, and notifying the Grants Manager, Finance Officer, and Awardee of formal closure. | Program Director approval action | Award status set to Closed; award record locked; closure date recorded; notifications dispatched to Grants Manager, Finance Officer, and Awardee; audit log entry with user ID and timestamp | Program Director, System (automated) | | | **FRFA-CO022:** The system shall allow the Program Director to reject the close-out submission with mandatory written reasons, returning the close-out record to “*Close-Out In Progress”* status and notifying the Grants Manager of the rejection reasons and outstanding items requiring resolution. | Program Director rejection action, written reasons | Close-out record returned to Close-Out In Progress; Grants Manager notified with rejection reasons; audit log entry | Program Director, System (automated) | | | **FRFA-CO023:** The system shall allow the Grants Manager to initiate a forced close-out for an award with outstanding items unresolved, for example, where the award end date has passed, and the Awardee is unresponsive, requiring a mandatory written justification and Program Director approval, with the exception recorded in the audit trail. | Grants Manager forced a close-out request, written justification, and Programme Director approval | Forced close-out request stored with justification; routed to Program Director for approval; exception recorded in audit trail on approval; audit log entry | Grants Manager, Program Director, System (automated) | | **Archiving** | **FRFA-CO024:** The system shall archive the complete award record on formal closure including the original application, award letter, signed agreement, all milestone submissions and evidence, all disbursement records, all amendments, final narrative and financial reports, asset verification records, and the close-out record in the document repository, applying the configured retention policy for the funding type. | Closed award record and all linked documents, funding type retention policy configuration | Complete award archive stored in document repository under configured retention policy; archive reference recorded on award record | System (automated) | | | **FRFA-CO025:** The system shall lock all archived award documents against editing or deletion for the duration of the configured retention period, permitting read-only access to authorised users only. | Archived award documents, retention period, user access roles | Archived documents locked against editing and deletion; read-only access enforced for authorised users for retention period duration | System (automated) | | **Funding Record Close-Out** | **FRFA-CO026:** The system shall monitor the closure status of all awards linked to a parent funding record and flag the funding record as “*Ready for Programme Close-Out”* when the last linked award reaches “*Closed*” status, notifying the Grants Manager. | Award closure status across all awards linked to the parent funding record | Funding record flagged as Ready for Programme Close-Out; Grants Manager notified; audit log entry | System (automated) | | | **FRFA-CO027:** The system shall display a funding record close-out summary to the Grants Manager showing total awarded, total disbursed, total recovered, final uncommitted balance, and the status of all linked awards and calls, allowing the Grants Manager to confirm all programme obligations are fulfilled before submitting for programme closure. | Funding record, all linked award and call records, and financial totals | Funding record close-out summary displayed to Grants Manager with all financial totals and linked record statuses | System (automated), Grants Manager | | | **FRFA-CO028:** The system shall route the funding record close-out for Programme Director approval, and on approval, set the funding record status to “*Closed*,” lock the funding record against further calls or amendments, finalise all balance figures, notify all assigned staff, and log the closure in the audit trail. | Grants Manager programme close-out submission, Program Director approval | Funding record status set to Closed; funding record locked; all balance figures finalised; assigned staff notified; audit log entry with user ID and timestamp | Grants Manager, Program Director, System (automated) | | | **FRFA-CO029:** The system shall archive the complete funding record with all linked calls, awards, and close-out records in the document repository under the configured programme retention policy on funding record closure. | Closed funding record and all linked records, programme retention policy configuration | Complete programme archive stored in document repository; archive reference recorded on funding record | System (automated) | | **Audit Trail** | **FRFA-CO030:** The system shall log all actions across all Grant Close-Out sub-processes including close-out initiation, disbursement blocks, checklist updates, report submissions and reviews, asset verifications, recovery and waiver actions, approval and rejection decisions, forced close-outs, archive actions, and funding record closure capturing user ID or system event, timestamp, action type, and previous and new values where applicable. | All user and system actions across Grant Close-Out | Comprehensive audit trail stored and accessible to authorised users | System (automated) | ### Non-Functional Requirements The non-requirements for the fund administration process include; **NFRFA001**: Each grant must have a unique Grant ID. **NFRFA002: **Grant amount must equal total approved budget. **NFRFA003**Reporting frequency must be defined before activation. **NFRFA004**A grant cannot be activated without an assigned Grant Manager. **NFRFA005**Budget revisions must require approval once the grant is active. **NFRFA006**Only authorized administrators can publish or modify calls. **NFRFA007**Eligibility criteria must be defined before publishing. **NFRFA008**At least one guideline document must be uploaded. **NFRFA009**Deadline must be later than the publication date. **NFRFA010**After the deadline passes, no new submissions are allowed. **NFRFA011**All changes must be audit logged. **NFRFA0****12** Applications cannot be modified after submission unless a revision is requested **NFRFA013: **Reviewers cannot see other reviewers’ scores (if blind review is enabled). **NFRFA014: **The final decision must be recorded before notification is sent. **NFRFA015: **All scoring must follow predefined evaluation criteria. # 5.2. Repository (REPO) ## 5.2.1 Module Description The RUFORUM Repository is the network's institutional memory and knowledge archive, hosted at repository.ruforum.org. It serves as the central digital library for storing, preserving, and sharing knowledge products generated through RUFORUM-supported research, capacity building, and innovation activities across 175 member universities in 40 African countries. All shared resources must be Open Access or Open Educational Resources (OER) in line with RUFORUM's knowledge-sharing mandate. In the RUFORUM digital ecosystem, the Repository sits at the centre of the knowledge value chain. RIMS pushes funded research outputs into the Repository upon award completion. The Repository feeds publication counts, digitisation rates, usage metrics, and open-access compliance data into the M&E module as key indicators. SME Hub innovators draw on Repository content to inform product development. REP course developers link Repository resources as Open Educational Resources in their courses. The current system is faced with nine documented challenges that the upgraded Repository must address: lack of search ordering and sorting, no unique author identifier, limited usage statistics, inconsistent feature naming, no integration with other RUFORUM systems, limited AI-powered insights, a cluttered interface, no configurable notification recipients, and no quality assurance workflow for filtering documents before publication. The sub-processes below are structured to close every one of these gaps. **The Repository module is organised around nine sub-processes:** - REPO-SP1: Document Capture and Ingestion - REPO-SP2: Metadata, Classification, and Author Management - REPO-SP3: Search and Retrieval - REPO-SP4: Access Control and Permissions Management - REPO-SP5: Document Versioning and Lifecycle Management - REPO-SP6: Content Review and Quality Assurance - REPO-SP7: Document Collaboration - REPO-SP8: Integration and Ecosystem Linkage - REPO-SP9: Repository Analytics, Reporting, and AI-Powered Insights ## 5.2.2 Sub-Process Descriptions ### REPO-SP1: Document Capture and Ingestion This sub-process covers all pathways through which documents enter the Repository: manual upload by authenticated users, bulk upload, drag-and-drop, email-to-repository ingestion, and API-based ingestion from connected systems such as RIMS. It includes file validation, malware scanning, automatic metadata extraction, and configurable notification dispatch to administrator-defined recipients, directly addressing the documented challenge that administrators cannot currently configure notification recipients. **Table 22:**** **Document Capture and Ingestion Use-Case Narrative | **Use Case: REPO-SP1 Document Capture and Ingestion** | | --- | | **Use Case Name** | REPO-SP1: Document Capture and Ingestion | | **Actor(s)** | Researcher / Author, Administrator, External System (RIMS / REP via API), System | | **Description** | This use case describes how authenticated users and connected systems add documents to the Repository through various ingestion pathways. It covers file selection, validation, metadata pre-population, category assignment, duplicate detection, secure storage, indexing, and configurable notification dispatch. | | **Pre-condition(s)** | i. User is authenticated and holds a role with upload permissions. ii. The target collection or folder exists and is accessible to the user. iii. The administrator has configured supported file formats, size limits, and notification recipients. | | **Main Success Scenario** | 1. User navigates to the Repository and selects 'Upload Document.' System displays the upload interface with drag-and-drop and file-selection options. 2. User selects one or more files. The system displays upload progress in real time. 3. System validates each file: checks format against the configured allowed list, verifies file size does not exceed the configured limit, scans for malware, and checks for file corruption. 4. If validation passes, the system automatically extracts basic metadata: file name, file size, creation date, and, where available, embedded author and title fields. 5. System displays the pre-populated metadata form. User reviews, completes, and enriches the metadata, adding title, abstract, author(s) with ORCID or institutional identifier, document type, subject keywords, language, and licence type. 6. User selects the target collection or folder and assigns tags. 7. System checks for duplicate documents based on file hash. If a potential duplicate is detected, the system alerts the user and offers three options: cancel the upload, upload as a new version of the existing document, or continue as a separate new document. 8. User clicks Submit. The system enforces the completion of all mandatory metadata fields before accepting the submission. 9. System stores the document securely, assigns a unique Document ID, sets version to 1.0, indexes the document for full-text and metadata-based search, and updates the search index. 10. System dispatches upload notifications to the administrator-configured recipient list via email and in-system alert. 11. System displays a success confirmation with the Document ID and a direct link to the document. 12. For API-based ingestion (e.g., from RIMS on award completion): RIMS sends the document and metadata payload to the Repository API. System validates the authentication token and payload, stores the document, and returns a confirmation with the Document ID to RIMS. | | **Alternative Flows** | A1 Bulk Upload: User selects multiple files. The system validates each individually. The system displays a batch summary showing successful uploads and failed items with error reasons. The user may retry failed items. A2 Email Ingestion: The System monitors a configured email inbox. On receiving an email with attachments, the system extracts attachments, parses the subject and body for metadata using configured rules, assigns to the default category, and processes through the standard validation and storage flow. A3 Unsupported File Format: The System rejects the file and displays the allowed format list. Upload is blocked. A4 File Exceeds Size Limit: The System rejects the file and displays the configured size limit. User must reduce file size before retrying. A5 Missing Mandatory Metadata: The System highlights incomplete fields and blocks submission until all required fields are completed. A6 Malware Detected: The system rejects the file, does not store it, logs the event, and alerts the administrator. | | **Post-condition(s)** | Document stored securely with a unique Document ID and version 1.0. All metadata indexed for search and retrieval. Duplicate detection result recorded. Upload notification dispatched to configured recipients. Audit log entry recorded with user ID, file details, and timestamp. Document available for review workflow (REPO-SP6) before public visibility if QA workflow is enabled. | **Table 23**: Functional Requirements Document Capture and Ingestion | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Manual Upload** | **FRREP-DCI001**: The system shall allow authenticated users to upload single documents through a file selection interface and a drag-and-drop area. | User file selection or drop | Upload initiated; progress displayed | Researcher / Author | | **Bulk Upload** | **FRREP-DCI002**: The system shall allow users to upload multiple documents simultaneously in a single transaction, validating each file individually and generating a batch summary report of successful and failed uploads. | Multiple file selection | Batch summary report with individual file outcomes; failed items available for retry | Researcher / Administrator | | **Real-Time Progress** | **FRREP-DCI003**: The system shall display real-time upload progress for each file, including percentage complete and estimated time remaining. | Active upload | Progress indicator updated in real time | System (automated) | | **Upload Cancellation** | **FRREP-DCI004**: The system shall allow users to cancel an ongoing upload at any time, aborting the transfer and discarding any partially uploaded data. | User cancel action | Upload aborted; no partial file stored | User, System | | **File Format Validation** | **FRREP-DCI005**: The system shall validate each uploaded file against an administrator-configured list of supported formats (PDF, DOCX, XLSX, JPEG, PNG, and others as configured), rejecting unsupported formats with a specific error message. | Uploaded file | Valid file accepted; invalid file rejected with error message citing allowed formats | System (automated) | | **File Size Validation** | **FRREP-DCI006**: The system shall reject files that exceed the administrator-configured maximum file size, displaying the size limit in the error message. | Uploaded file | Oversized file rejected with size limit displayed | System (automated) | | **Malware Scanning** | **FRREP-DCI007**: The system shall scan every uploaded file for malware before storing it. Files that fail the malware scan shall be rejected, not stored, the event logged, and the administrator notified. | Uploaded file | Clean file accepted; malicious file rejected, not stored, event logged, admin notified | System (automated) | | **Corruption Detection** | **FRREP-DCI008**: The system shall detect and reject corrupted or unreadable files, displaying an appropriate error message to the user. | Uploaded file | Corrupted file rejected with an error message | System (automated) | | **Auto Metadata Extraction** | **FRREP-DCI009**: The system shall automatically extract available metadata from uploaded files, including file name, file size, creation date, and embedded author and title fields and pre-populate the metadata form. | Uploaded file | Metadata form pre-populated with extracted values | System (automated) | | **Mandatory Metadata Enforcement** | **FRREP-DCI010**: The system shall enforce completion of all mandatory metadata fields before a document submission is accepted, highlighting incomplete fields and blocking submission until resolved. | User metadata submission | Submission is accepted only when all mandatory fields are complete | System (automated) | | **Duplicate Detection** | **FRREP-DCI011**: The system shall detect potential duplicate documents based on file hash at the point of upload and alert the user, offering options to cancel, upload as a new version, or continue as a separate document. | Uploaded file hash | Duplicate alert displayed with three action options | System (automated) | | **Email Ingestion** | **FRREP-DCI012**: The system shall monitor a configured email inbox, extract attachments from incoming emails, parse subject and body for metadata using configured rules, assign documents to a default category, and process them through the standard validation and storage flow. | Incoming email with attachments | Documents extracted and stored; metadata mapped from email fields | System (automated) | | **API Ingestion** | **FRREP-DCI013**: The system shall accept document and metadata payloads from authenticated external systems (RIMS, REP) via a documented REST API, validating the authentication token and payload before storing the document and returning a confirmation with the Document ID. | Authenticated API payload | Document stored; Document ID returned to calling system; audit log entry created | System (automated) | | **Configurable Notifications** | **FRREP-DCI014**: The system shall allow administrators to configure the recipient list for upload notifications, specifying individual users and roles, and dispatch email and in-system notifications to those recipients upon each successful document upload. | Upload event; configured recipient list | Notifications dispatched to configured recipients | System (automated), Administrator | | **Unique Document ID** | FRREP-DCI015: The system shall generate and assign a unique Document ID to every successfully stored document, displaying it in the upload confirmation and linking it to all subsequent document records. | Successful storage event | Unique Document ID assigned and displayed | System (automated) | | **Search Indexing** | FRREP-DCI016: The system shall index every uploaded document for full-text search and metadata-based search immediately upon successful storage. | Document stored | Search index updated; document retrievable by keyword and metadata | System (automated) | | **Audit Trail** | FRREP-DCI017: The system shall log all ingestion events including user ID, file name, Document ID, ingestion method, validation outcomes, and timestamp in the audit trail. | Any ingestion event | Audit log entry stored and accessible to authorised administrators | System (automated) | ### REPO-SP2: Metadata, Classification, and Author Management This sub-process covers the management of document metadata and the taxonomy that structures the Repository. It directly addresses two documented challenges: the lack of a unique author identifier, making it impossible to distinguish authors with common names or track authors who change their names; and inconsistencies in feature and category naming, creating confusion. The solution introduces ORCID integration for author identity, a controlled taxonomy with standardised naming, and administrator-governed classification rules. **Table 24: **Metadata, Classification, and Author Management Use Case Narrative | **Use Case: REPO-SP2 Metadata, Classification, and Author Management** | | --- | | **Use Case Name** | REPO-SP2: Metadata, Classification, and Author Management | | **Actor(s)** | Researcher / Author, Administrator, System | | **Description** | This use case describes how document metadata is created, enriched, and managed after ingestion. It covers author identity management using ORCID and institutional identifiers, taxonomy governance by administrators, metadata editing, and auto-classification rule configuration. | | **Pre-condition(s)** | Document has been successfully ingested and assigned a Document ID. The administrator has configured the taxonomy: collections, categories, document types, and subject keywords. For ORCID integration, the ORCID API connection is active. | | **Main Success Scenario** | Following ingestion, the metadata form displays pre-populated fields. User reviews and completes the full metadata record: title, abstract, author(s), document type, subject keywords, language, publication date, licence type, and grant/project linkage. For author entry, the user searches for an author by name. System checks the Author Registry first. If the author exists in the registry, the user selects them, and the author's ORCID, affiliation, and institutional identifier are automatically linked to the document record. If the author is not in the registry, the user enters the author's name, email, affiliation, and ORCID (if available). System creates a new Author Registry entry and links it to the document. User selects a document type from the controlled list: thesis/dissertation, journal article, conference paper, policy brief, technical report, project report, dataset, or other. User selects the target collection and sub-collection from the standardised taxonomy dropdown. System applies any auto-classification rules configured by the administrator based on document type and subject keywords. User assigns subject keyword tags from the controlled vocabulary. Free-text tags may be submitted for administrator review before being added to the controlled vocabulary. User selects the Open Access licence type from the configured list (Creative Commons licences, institutional open access, or restricted). User optionally links the document to a RUFORUM grant or project record in RIMS using the grant linkage field. User submits the metadata record. System validates all mandatory fields and stores the complete metadata record linked to the Document ID. Administrator manages the taxonomy: adding, renaming, merging, or deprecating collections, categories, document types, and subject keywords. All naming follows standardised conventions enforced by the system. | | **Alternative Flows** | A1 Author Not Found in ORCID: User enters author details manually. The system creates an Author Registry entry without an ORCID. The administrator is notified to verify and enrich the entry. A2 Metadata Edit After Submission: Authorised user or administrator edits metadata on a stored document. The system saves the updated record, logs the change with previous and new values in the audit trail, and re-indexes the document. A3 Auto-Classification Conflict: The auto-classification rule produces a category that the user believes is incorrect. User overrides the auto-classification. System logs the override for administrator review. A4 Deprecated Category: User selects a deprecated category. The system warns the user and suggests the replacement category. | | **Post-condition(s)** | i. Complete metadata record stored and linked to the Document ID. ii. Author(s) linked to Author Registry entries with ORCID and institutional identifiers where available. iii. Document classified in the correct taxonomy category. iv. Document indexed for search using full metadata. v. RIMS grant linkage recorded if provided. vi. Audit trail entry recorded for all metadata creation and editing actions. | **Table 25**: Functional Requirements Metadata, Classification, and Author Management | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Author Registry** | FRREP-MCL001: The system shall maintain a centralised Author Registry storing each author's full name, ORCID, institutional affiliation, email address, and institutional identifier, enabling consistent author identification across all documents regardless of name changes. | Author entry or selection | Author Registry record created or retrieved; linked to document record | System, Researcher | | **ORCID Integration** | FRREP-MCL002: The system shall integrate with the ORCID API to verify and retrieve author metadata including name, affiliation, and publication history when an ORCID identifier is provided, pre-populating the Author Registry entry. | ORCID identifier input | ORCID-verified author record created or updated in Author Registry | System (automated) | | **Author Search** | FRREP-MCL003: The system shall allow users to search the Author Registry by name, ORCID, institution, and email when adding authors to a document, displaying matching entries for selection. | Author search query | Matching Author Registry entries displayed | System (automated) | | **Author Name Change Handling** | FRREP-MCL004: The system shall allow administrators to link multiple name variants of the same author in the Author Registry, ensuring all documents contributed under previous names remain mapped to the correct author record. | Admin name variant link action | All name variants linked to a single Author Registry record; historical documents updated | Administrator | | **Controlled Taxonomy** | FRREP-MCL005: The system shall enforce a controlled taxonomy for collections, sub-collections, document types, and subject keywords, managed exclusively by administrators, using standardised naming conventions that prevent inconsistent or duplicate category names. | Administrator taxonomy configuration | Controlled taxonomy is enforced across all document classification | Administrator, System | | **Auto-Classification Rules** | FRREP-MCL006: The system shall allow administrators to configure auto-classification rules that automatically assign documents to collections and categories based on document type, subject keywords, or metadata values, with users able to override auto-assigned classifications. | Document metadata; configured rules | Document auto-classified; override option available | System (automated), Administrator | | **Controlled Vocabulary Tags** | FRREP-MCL007: The system shall allow users to assign subject keyword tags from a controlled vocabulary, and allow free-text tag suggestions that are queued for administrator review and approval before being added to the controlled vocabulary. | User tag assignment or suggestion | Tags assigned from controlled vocabulary; new suggestions queued for admin review | User, Administrator | | **Licence Assignment** | FRREP-MCL008: The system shall require users to select an Open Access licence type from a configured list including Creative Commons licence variants and institutional open access options, before document submission is accepted. | User licence selection | Licence type stored against document record; licence displayed on public document page | User, System | | **RIMS Grant Linkage** | FRREP-MCL009: The system shall allow users to link a document to a RUFORUM grant or project record in RIMS by selecting from a searchable dropdown of active and completed RIMS records, creating a cross-system linkage. | User grant linkage selection | Document-grant linkage stored; linkage visible in both Repository and RIMS | User, System | | **Mandatory Field Enforcement** | FRREP-MCL010: The system shall enforce completion of all mandatory metadata fields title, abstract, at least one author, document type, collection, licence type before a document record is accepted, highlighting incomplete fields. | Metadata submission | Submission accepted only when all mandatory fields are complete | System (automated) | | **Metadata Editing** | FRREP-MCL011: The system shall allow authorised users and administrators to edit document metadata after submission, logging all changes in the audit trail with the user ID, field name, previous value, and new value. | Metadata edit action | Updated metadata stored and re-indexed; audit log entry created | User / Administrator | | **Taxonomy Management** | FRREP-MCL012: The system shall allow administrators to add, rename, merge, deprecate, and reorganise taxonomy elements collections, categories, document types, and subject keywords with system warnings when deprecated elements are selected by users. | Admin taxonomy management action | Taxonomy updated; affected documents re-classified; users warned on deprecated selection | Administrator | | **Audit Trail** | FRREP-MCL013: The system shall log all metadata creation, editing, author registry changes, taxonomy modifications, and classification overrides in the audit trail capturing user ID, action type, timestamp, and previous and new values where applicable. | Any metadata or taxonomy action | Audit log entry stored | System (automated) | ### REPO-SP3: Search and Retrieval This sub-process addresses the most prominently documented challenge: the lack of any ordering or sorting criterion in the current system, which forces all results to display in reverse chronological order with no way to sort by relevance, date, title, or author. Users cannot filter by metadata, save searches, or use advanced multi-field queries. The upgraded search must provide full-text search, metadata-based filtering, advanced multi-field queries, sortable results, and saved search functionality. **Table 26: **Search and Retrieval use case narrative | **Use Case: REPO-SP3 Search and Retrieval** | | --- | | **Use Case Name** | REPO-SP3: Search and Retrieval | | **Actor(s)** | Public User (unauthenticated), Authenticated User, Researcher, System | | **Description** | This use case describes how users find and access documents in the Repository. It covers keyword-based search, metadata-based search, advanced multi-field filtering, result sorting, browsing by collection, and saved search functionality. Public users can search and access Open Access documents without authentication. | | **Pre-condition(s)** | i. Documents are stored, indexed, and available for search. ii. For public access, documents are marked as Open Access. iii. For saved searches, user is authenticated. | | **Main Success Scenario** | User navigates to the Repository search interface. System displays a simple search bar and a 'Browse Collections' option. User enters keywords in the search bar and submits. System performs a full-text search across document titles, abstracts, author names, keywords, and body text, returning ranked results. System displays results as a sortable list with the following sort options: relevance (default), most recent, oldest, title (A–Z, Z–A), author name, and most downloaded. User refines results using the filter panel: document type, collection, author, year range, language, subject keyword, institution, licence type, and grant linkage. User selects a document from the results. System displays the full metadata record, abstract, author(s) with linked Author Registry profiles, licence information, download count, and view count. User downloads the document. System records the download event against the document's usage statistics. For advanced search, the user switches to the advanced search form and enters multiple field-specific queries, e.g., author ORCID, title contains, year range, document type, and submits. System returns filtered and ranked results. User saves the current search query. System stores the query against the user's profile and allows re-running it on future visits with updated results. User browses collections by navigating the taxonomy tree, drilling down from collection to sub-collection to individual documents. The System provides incremental (real-time) search suggestions as the user types in the search bar. | | **Alternative Flows** | A1 No Results Found: The system displays “*No results found*” with suggestions to broaden the search terms, check spelling, or browse collections. A2 Restricted Document: Search results include a restricted document. System displays the metadata record but replaces the download button with a “*Request Access*” option. A3 Saved Search Alert: The user has configured email alerts for a saved search. The system dispatches an email notification when new documents matching the saved search are added to the Repository. | | **Post-condition(s)** | Search results returned, ranked, and sortable. Filter selections applied and displayed to the user. Document view and download events recorded in usage statistics. Saved search stored against the user profile if requested. Search query logged in audit trail for analytics. | **Table 27**: Functional Requirements Search and Retrieval | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Full-Text Search** | FRREP-SR001: The system shall provide a full-text search function that searches across document titles, abstracts, author names, subject keywords, and body text, returning ranked results. | Keyword query | Ranked results list displayed | System (automated) | | **Incremental Search** | FRREP-SR002: The system shall provide real-time incremental search suggestions as the user types in the search bar, drawing from indexed titles, author names, and keywords. | User typing in search bar | Search suggestions displayed in real time | System (automated) | | **Sortable Results** | FRREP-SR003: The system shall display search results in a sortable list, offering sort options for relevance, most recent, oldest, title (A–Z and Z–A), author name, and most downloaded, with relevance as the default. | Search result set | Results re-ordered according to selected sort criterion | System (automated) | | **Metadata Filters** | FRREP-SR004: The system shall provide a filter panel allowing users to refine search results by document type, collection, author, year range, language, subject keyword, institution, licence type, and grant linkage, with filters applied dynamically without a full page reload. | Filter selection | Filtered result set displayed with active filters shown | System (automated) | | **Advanced Search** | FRREP-SR005: The system shall provide an advanced search form supporting multi-field queries including author name, author ORCID, title contains, abstract contains, year range, document type, collection, subject keyword, and licence type. | Multi-field query | Filtered and ranked results matching all specified fields | System (automated) | | **Browse by Collection** | FRREP-SR006: The system shall allow users to browse the Repository by navigating the taxonomy tree from collection to sub-collection to individual documents without using the search bar. | User taxonomy navigation | Collection contents displayed at each level | System | | **Document Detail View** | FRREP-SR007: The system shall display a full document detail page showing title, abstract, author(s) with linked Author Registry profiles, document type, collection, licence, publication date, RIMS grant linkage where applicable, view count, and download count. | User document selection | Full metadata and document detail rendered | System | | **Public Access** | FRREP-SR008: The system shall allow unauthenticated public users to search the Repository and access documents marked as Open Access without requiring account creation or login. | Unauthenticated user search | Open Access documents are searchable and downloadable by the public | System (automated) | | **Restricted Document Handling** | FRREP-SR009: The system shall display metadata records for restricted documents in search results but replace the download action with a 'Request Access' option, routing the request to the document owner or administrator. | User request access action | Access request logged; document owner or administrator notified | System (automated) | | **Saved Searches** | FRREP-SR010: The system shall allow authenticated users to save search queries, re-run them on future visits, and optionally configure email alerts that notify them when new documents matching the saved search are added. | User save search action | Search query stored; alert configured; notification dispatched on new matching documents | System (automated) | | **Download Tracking** | FRREP-SR011: The system shall record every document view and download event against the document's usage statistics, capturing user ID (or anonymous indicator for public users), timestamp, and document ID. | View or download event | Usage statistics record updated | System (automated) | | **Audit Trail** | FRREP-SR012: The system shall log all search queries, filter applications, and saved search configurations in the audit trail to support analytics on search behaviour and repository usage patterns. | Any search or retrieval action | Audit log entry stored | System (automated) | ### REPO-SP4: Access Control and Permissions Management This sub-process governs who can view, download, upload, edit, approve, and administer documents and collections in the Repository. It enforces the Open Access mandate while supporting restricted collections for internal administrative documents, unpublished work awaiting review, and confidential project records. It also addresses the documented 'private area' naming inconsistency by standardising all visibility states under a clear, consistent nomenclature. | **Use Case: REPO-SP4 Access Control and Permissions Management** | | --- | | **Use Case Name** | REPO-SP4: Access Control and Permissions Management | | **Actor(s)** | Administrator, Collection Manager, Authenticated User, Public User, System | | **Description** | This use case describes how access permissions are configured and enforced across the Repository. It covers role-based access, document-level permissions, collection-level restrictions, visibility states, and watermarking for restricted documents. | | **Pre-condition(s)** | Administrator is authenticated and holds the Repository Administrator role. Collections and user accounts are configured in the system. iii. Document records exist in the Repository. | | **Main Success Scenario** | Administrator configures roles and their permissions: Public User (search and view Open Access documents), Authenticated User (upload, edit own documents), Collection Manager (approve, manage assigned collections), Repository Administrator (full system access). Administrator sets the visibility state for a collection: Public Open Access (searchable and downloadable by all), Authenticated Only (requires login to download), Collection-Restricted (accessible only to named users or groups), or Internal (not publicly searchable). For document-level access, the administrator or collection manager sets the visibility state on individual documents, overriding the collection default where necessary. System enforces all configured permissions at search and download time. Restricted documents appear in search results with metadata visible, but download is blocked for unauthorised users. Administrator manages user groups, assigning users to groups and granting groups access to specific collections. Administrator configures watermarking for restricted documents: any download of a restricted document by an authorised user has the user's name and download timestamp embedded as a visible watermark. Authenticated user requests access to a restricted document. System routes the request to the document owner or collection manager, who approves or declines. System notifies the user of the outcome. Administrator reviews and updates permissions as users change roles or leave the organisation. | | **Alternative Flows** | A1 Unauthorised Download Attempt: User attempts to download a document beyond their permission level. The system blocks the download and displays an 'Access Denied' message with a 'Request Access' option. A2 Permission Inheritance: Document inherits the collection's visibility state unless overridden. The system clearly displays the current effective visibility state on each document's detail page. A3 Role Change: The administrator changes a user's role. The system immediately updates all permissions. Active sessions are re-evaluated on the next action. | | **Post-condition(s)** | Role and permission configurations are stored and enforced system-wide. Collection and document visibility states are enforced at all access points. Access requests logged and routed to approvers. Watermarks applied to restricted document downloads. All permission changes and access events logged in the audit trail. | **Table 28**: Functional Requirements Access Control and Permissions Management | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Role-Based Access Control** | FRREP-AC001: The system shall implement role-based access control with at least four roles: Public User, Authenticated User, Collection Manager, and Repository Administrator, each with defined permissions for search, view, download, upload, edit, approve, and administer. | Role configuration | Role permissions stored and enforced across all system functions | Administrator | | **Collection Visibility States** | FRREP-AC002: The system shall support four collection visibility states Public Open Access, Authenticated Only, Collection-Restricted, and Internal each enforcing distinct access rules for search visibility and download permission. | Admin visibility configuration | Visibility state stored on collection; enforced at search and download | Administrator, System | | **Document-Level Permissions** | FRREP-AC003: The system shall allow administrators and collection managers to set visibility permissions on individual documents, overriding the parent collection default where necessary. | Admin or manager permission action | Document-level permission stored; enforced independently of collection default | Administrator / Collection Manager | | **Standardised Visibility Naming** | FRREP-AC004: The system shall use only the four standardised visibility state names defined in REPO-AC002 across all interfaces, eliminating ambiguous or inconsistent labels such as 'private area.' All existing collections shall be migrated to the standardised naming on system deployment. | System configuration | Consistent visibility state labels used across all screens and reports | System (automated) | | **User Groups** | FRREP-AC005: The system shall allow administrators to create user groups, assign users to groups, and grant groups access to specific restricted collections, enabling batch permission management. | Admin group configuration | Group created; member permissions applied; group access to collections enforced | Administrator | | **Access Request Workflow** | FRREP-AC006: The system shall provide an access request workflow allowing authenticated users to request access to restricted documents or collections, routing requests to the document owner or collection manager for approval or rejection, with outcome notifications sent to the requesting user. | User access request | Request routed to approver; outcome notification sent to user; decision logged | System (automated), Collection Manager | | **Watermarking** | FRREP-AC007: The system shall embed a visible watermark on every download of a restricted document by an authorised user, including the downloading user's full name and the download timestamp. | Authorised restricted document download | Watermarked PDF downloaded; download event logged | System (automated) | | **Encryption** | FRREP-AC008: The system shall encrypt all stored documents and metadata at rest and all data in transit using TLS 1.2 or higher. | All storage and transfer events | Data encrypted at rest and in transit | System (automated) | | **Permission Audit Trail** | FRREP-AC009: The system shall log all permission configuration changes, access requests, approvals, rejections, and document download events in the audit trail, capturing user ID, action type, document or collection ID, and timestamp. | Any access or permission event | Audit log entry stored | System (automated) | ### REPO-SP5: Document Versioning and Lifecycle Management This sub-process covers the full document lifecycle: from initial deposit through versioning, retention, archiving, and eventual withdrawal. It ensures that all previous versions of a document remain accessible and traceable, that retention policies are enforced, and that documents linked to RIMS grant records are flagged appropriately when those grants are closed out. **Table 29: **Document Versioning and Lifecycle Management use case narrative | **Use Case: REPO-SP5 Document Versioning and Lifecycle Management** | | --- | | **Use Case Name** | REPO-SP5: Document Versioning and Lifecycle Management | | **Actor(s)** | Author, Administrator, Collection Manager, RIMS System (automated), System | | **Description** | This use case describes how new versions of documents are uploaded and managed, how the full version history is maintained and accessible, how retention policies are applied to collections, and how documents progress through the lifecycle from deposit to archive or withdrawal. | | **Pre-condition(s)** | i. Document exists in the Repository with at least version 1.0. ii. User is authenticated and holds upload or management permissions for the document. iii. Retention policies are configured for collections by the administrator. | | **Main Success Scenario** | Author uploads a revised version of an existing document. System identifies the existing Document ID and prompts the user to confirm they are uploading a new version. System stores the new file, increments the version number (e.g., 1.0 to 2.0), retains all previous versions as accessible archived records, and updates the document's search index with the latest version content. System displays the version history on the document detail page, listing each version with its version number, upload date, uploader, and a link to download that specific version. The most recent version is displayed by default in search results and on the document detail page. Previous versions are accessible via the version history panel. Administrator configures a retention policy for a collection: specifying how long documents are retained before archiving, and under what conditions documents may be withdrawn. System enforces retention policies automatically: flagging documents approaching their retention date, notifying the collection manager, and archiving or withdrawing documents as configured. Collection manager or administrator requests withdrawal of a document (e.g., due to copyright dispute, data error, or policy violation). The system requests a mandatory written withdrawal reason. System sets the document status to 'Withdrawn,' removes it from public search results and download access, retains the metadata record with a 'Withdrawn' status indicator and the withdrawal reason, and notifies any users who have saved the document. For documents linked to RIMS grant records: when RIMS closes a grant, it sends a notification to the Repository API. System flags all documents linked to that grant as 'Grant Closed,' updating their metadata record accordingly. | | **Alternative Flows** | A1 Version Upload Without Confirmation: User uploads a file with the same name as an existing document without selecting “*New Version*”' Duplicate detection triggers and prompts the user to confirm whether this is a new version or a separate document. A2 Withdrawal Appeal: If a document is withdrawn due to an administrative decision, the original uploader may submit an appeal. Administrator reviews and may reinstate the document, with the reinstatement logged in the audit trail. A3 Retention Date Exceeded Without Action: If a document passes its retention date and the collection manager has not taken action, the system escalates a notification to the Repository Administrator. | | **Post-condition(s)** | New document version stored with an incremented version number. Previous versions are retained as accessible archived records with full version history visible. Search index updated to reflect the latest version. Retention policy enforced; documents archived or withdrawn as configured. Withdrawn documents removed from public access with metadata record retained. vi. RIMS grant closure flag applied to linked documents. vii. All versioning and lifecycle actions logged in the audit trail. | **Table 30**: Functional Requirements Document Versioning and Lifecycle Management | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Version Upload** | FRREP-VL001: The system shall allow authorised users to upload a new version of an existing document, linking it to the original Document ID and prompting the user to confirm the new version intent before processing. | New version file upload | Version stored with an incremented version number; previous version retained | Author / Administrator | | **Version Numbering** | FRREP-VL002: The system shall assign sequential version numbers to all document versions (1.0, 2.0, 3.0, etc.) with the option for minor versions (1.1, 1.2) for minor corrections, as configured by the administrator. | Version upload event | Version number assigned and displayed | System (automated) | | **Version History Display** | FRREP-VL003: The system shall display a version history panel on each document detail page, listing all versions with version number, upload date, uploader name, and a download link for each version. | User document detail view | Version history panel displayed with all historical versions accessible | System | | **Latest Version Default** | FRREP-VL004: The system shall display the most recent document version by default in all search results and on the document detail page, with previous versions accessible only through the version history panel. | Search or document view | Latest version displayed by default; previous versions accessible via version history | System (automated) | | **Retention Policy Configuration** | FRREP-VL005: The system shall allow administrators to configure retention policies per collection, specifying retention periods and the action to take on expiry: archive, flag for review, or withdraw, with collection managers notified in advance of upcoming retention dates. | Admin policy configuration | Retention policy stored on collection; enforced automatically at expiry | Administrator, System | | **Retention Enforcement** | FRREP-VL006: The system shall automatically enforce configured retention policies at their trigger date, flagging documents due for action and notifying collection managers with a configurable advance notice period. If no action is taken, the system escalates to the Repository Administrator. | Retention date reached | Document flagged; collection manager notified; escalation if no action taken | System (automated) | | **Document Withdrawal** | FRREP-VL007: The system shall allow administrators and collection managers to withdraw a document, requiring a mandatory written withdrawal reason, setting the document status to Withdrawn, removing it from public search and download access, retaining the metadata record with a Withdrawn status indicator, and notifying users who have saved the document. | Withdrawal request with reason | Document status set to Withdrawn; removed from public access; metadata retained; notifications dispatched | Administrator / Collection Manager | | **Withdrawal Reinstatement** | FRREP-VL008: The system shall allow administrators to reinstate a withdrawn document, restoring its previous visibility state and logging the reinstatement with reason in the audit trail. | Admin reinstatement action | Document status restored; reinstated in search and access; audit log entry created | Administrator | | **RIMS Grant Closure Flag** | FRREP-VL009: The system shall accept grant closure notifications from RIMS via the integration API and apply a 'Grant Closed' metadata flag to all documents linked to the closed grant record. | RIMS grant closure event | Grant Closed flag applied to all linked documents; flag visible on document detail pages | System (automated) | | **Audit Trail** | FRREP-VL010: The system shall log all version uploads, retention policy configurations, retention actions, withdrawals, reinstatements, and RIMS grant closure flag events in the audit trail capturing user ID or system event, action type, and timestamp. | Any versioning or lifecycle event | Audit log entry stored | System (automated) | ### REPO-SP6: Content Review and Quality Assurance This sub-process directly addresses the documented absence of any quality assurance guidelines or workflow for filtering documents before they are published. Since all resources in the RUFORUM Repository must be Open Access or OER, a structured review process is required to verify that submitted documents meet the open access mandate, are of sufficient quality, are not duplicates of existing records, and have complete and accurate metadata. Without this, the repository risks filling with low-quality, non-compliant, or duplicated content. **Table 31: **Content Review and Quality Assurance use case narrative | **Use Case: REPO-SP6 Content Review and Quality Assurance** | | --- | | **Use Case Name** | REPO-SP6: Content Review and Quality Assurance | | **Actor(s)** | Submitter (Author / Researcher), Collection Manager, Repository Administrator, System | | **Description** | This use case describes the quality assurance workflow that a submitted document passes through before it becomes publicly visible in the Repository. It covers automated pre-checks, manual review by a Collection Manager, approval or return with comments, and QA policy configuration by the administrator. | | **Pre-condition(s)** | i. Document has been ingested (REPO-SP1) and metadata has been completed (REPO-SP2). ii. The collection has a QA workflow enabled. iii. At least one Collection Manager is assigned to the collection. | | **Main Success Scenario** | Upon metadata submission, the system runs automated pre-checks: mandatory fields complete, licence type selected, at least one author with a valid identifier linked, file format compliant, and malware scan passed. If all automated pre-checks pass, the system sets the document status to 'Under Review' and assigns it to the Collection Manager of the target collection for manual review. System notifies the Collection Manager of the new submission requiring review, providing a link to the document and metadata record. Collection Manager opens the review interface and evaluates the submission against the published QA checklist: content relevance to RUFORUM's mandate, Open Access or OER compliance, metadata completeness and accuracy, abstract quality, no copyright violation, and no duplication of existing records. Collection Manager selects one of three decisions: Approve, Return for Revision, or Reject. On Approve: system sets document status to 'Published,' makes the document publicly visible and searchable according to its configured visibility settings, notifies the submitter of approval, and triggers the M&E indicator update. On Return for Revision: Collection Manager enters mandatory revision comments. System sets the document status to 'Revision Required,' notifies the submitter with the comments, and allows the submitter to revise and resubmit. On Reject: Collection Manager enters a mandatory rejection reason. System sets document status to 'Rejected,' notifies the submitter with the reason, and retains the submission record in the administrator's view. 9. Administrator configures QA policies: enabling or disabling the QA workflow per collection, setting maximum review turnaround times, and configuring escalation rules if a review is not completed within the turnaround period. | | **Alternative Flows** | A1 Automated Pre-Check Failure: Document fails one or more automated pre-checks. System returns the submission to the submitter immediately with a specific list of failed checks. Document does not enter the manual review queue. A2 Review Turnaround Exceeded: Collection Manager does not complete the review within the configured turnaround period. System escalates the review to the Repository Administrator and notifies both parties. A3 Resubmission After Revision: Submitter revises the document and metadata and resubmits. System creates a new review task for the Collection Manager. Collection Manager can view the previous review history alongside the revised submission. A4 QA Workflow Disabled: If a collection has the QA workflow disabled, submitted documents proceed directly to 'Published' status after automated pre-checks pass. | | **Post-condition(s)** | i. Document assigned a QA status: Under Review, Revision Required, Rejected, or Published. ii. Approved documents publicly visible and indexed according to visibility settings. iii. Submitter notified of review outcome with comments where applicable. iv. M&E indicator updated on document publication. v. All review decisions, comments, and timestamps logged in the audit trail. | **Table 32: **Functional Requirements Content Review and Quality Assurance | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Automated Pre-Checks** | **FRREP-QA001**: The system shall run automated pre-checks on every document submission before it enters manual review, verifying: all mandatory metadata fields are complete, a licence type is selected, at least one author with a valid identifier is linked, the file format is compliant, and the malware scan has passed. | Document submission event | Pre-check results generated; document advanced to review queue or returned to submitter with specific failure list | System (automated) | | **QA Workflow Assignment** | **FRREP-QA002**: The system shall automatically assign documents that pass automated pre-checks to the Collection Manager of the target collection for manual review, setting the document status to 'Under Review' and notifying the Collection Manager. | Pre-check pass event | Document assigned to Collection Manager; status set to Under Review; notification sent | System (automated) | | **QA Checklist** | **FRREP-QA003**: The system shall provide Collection Managers with a structured QA checklist covering: content relevance to RUFORUM mandate, Open Access or OER compliance, metadata completeness and accuracy, abstract quality, absence of copyright violation, and absence of duplication of existing records. | Collection Manager review action | Checklist displayed alongside the document and metadata for review | System | | **Review Decision** | **FRREP-QA004**: The system shall allow Collection Managers to record one of three review decisions: Approve, Return for Revision, or Reject, with mandatory written comments required for Return for Revision and Reject decisions. | Collection Manager decision | Decision recorded; document status updated; submitter notified with decision and comments | Collection Manager, System | | **Approval and Publication** | **FRREP-QA005**: The system shall set document status to Published, make the document publicly visible and searchable according to its configured visibility settings, and notify the submitter when a Collection Manager approves the submission. | Approval decision | Document status set to Published; public visibility enforced; submitter notified; M&E indicator triggered | System (automated) | | **Return for Revision** | **FRREP-QA006**: The system shall set document status to 'Revision Required,' notify the submitter with the Collection Manager's revision comments, and allow the submitter to edit the document and metadata and resubmit, creating a new review task. | Return decision with comments | Document status set to Revision Required; submitter notified; resubmission enabled | System (automated) | | **Rejection** | **FRREP-QA007**: The system shall set document status to 'Rejected,' notify the submitter with the mandatory rejection reason, and retain the submission record and all review history in the administrator's view. | Reject the decision with a reason | Document status set to Rejected; submitter notified; submission record retained | System (automated) | | **Review Turnaround Policy** | **FRREP-QA008**: The system shall allow administrators to configure a maximum review turnaround period per collection and escalate overdue reviews to the Repository Administrator, notifying both the Collection Manager and the Administrator when the turnaround period is exceeded. | Configured turnaround period; review age | Escalation notification sent to Collection Manager and Administrator | System (automated) | | **QA Policy Configuration** | **FRREP-QA009**: The system shall allow administrators to enable or disable the QA workflow per collection. When disabled, documents proceed directly to Published status after automated pre-checks pass. | Admin policy configuration | QA workflow enabled or disabled on collection; enforcement adjusted accordingly | Administrator | | **Resubmission History** | **FRREP-QA010**: The system shall display the full review history, all previous decisions, comments, and submission timestamps to the Collection Manager when reviewing a resubmission, enabling informed comparison between the original and revised versions. | Collection Manager review of resubmission | Full review history displayed alongside the revised document and metadata | System | | **M****&****E Feed** | **FRREP-QA011**: The system shall trigger the M&E module to record a document publication indicator upon each approved publication, passing document ID, collection, document type, licence type, author institution, and publication date. | Publication approval event | M&E indicator record updated | System (automated) | | **Audit Trail** | **FRREP-QA012**: The system shall log all automated pre-check results, review assignments, review decisions, revision requests, rejections, resubmissions, and QA policy changes in the audit trail capturing user ID, action type, document ID, and timestamp. | Any QA workflow event | Audit log entry stored | System (automated) | ### REPO-SP7: Document Collaboration This sub-process covers collaborative features that allow multiple users to work on documents together, sharing documents for comment, adding annotations, assigning review tasks, and co-authoring working documents before formal deposit. This sub-process existed as a blank placeholder in the existing requirements document and is now fully specified. **Table 33: **Document Collaboration use case narrative | **Use Case: REPO-SP7 Document Collaboration** | | --- | | **Use Case Name** | REPO-SP7: Document Collaboration | | **Actor(s)** | Author, Collaborator, Reviewer, Collection Manager, System | | **Description** | This use case describes how users collaborate around documents in the Repository, sharing documents for review and comment, annotating documents, assigning review tasks to named collaborators, and managing collaborative working drafts before formal deposit. | | **Pre-condition(s)** | i. Document exists in the Repository or is in working draft state. ii. Author or document owner holds sharing permissions. iii. Collaborators are registered users with valid accounts. | | **Main Success Scenario** | The author opens a document and selects “*Share for Review*.” The author enters the email addresses or usernames of collaborators and sets the permission level: View Only, Comment, or Edit. System dispatches share notifications to the invited collaborators with a direct link to the document and the permission level granted. Collaborator opens the shared document. System displays the document with the collaboration toolbar enabled based on the collaborator's permission level. Collaborator with Comment permission adds annotations and inline comments to specific sections of the document. Comments are timestamped and linked to the collaborator's user account. Author receives a notification when new comments are added. The author reviews comments in the annotation panel, which groups all comments by section. Author marks comments as Resolved or requires further discussion, maintaining a clear record of what has been addressed. Author assigns a formal review task to a collaborator: specifying the review scope, due date, and instructions. System tracks the task status Pending, In Progress, Completed, and sends reminders as the due date approaches. On task completion, the collaborator marks the task as complete. System notifies the author and updates the task status. When the collaborative process is complete, the author deposits the final version as a formal repository submission through REPO-SP1. | | **Alternative Flows** | A1 Collaborator Removes Access: The author revokes a collaborator's access. The system immediately removes the collaborator's view, comment, and edit permissions. Any unresolved comments remain visible to the author. A2 Edit Conflict: Two collaborators with Edit permissions save changes to the same section simultaneously. System detects the conflict, preserves both versions, and notifies both collaborators to resolve the conflict manually. A3 Review Task Overdue: Review task passes its due date without completion. The system sends an overdue notification to the collaborator and a reminder to the author. | | **Post-condition(s)** | Collaboration permissions stored and enforced for all invited collaborators. Annotations and comments stored against the document with collaborator identities and timestamps. Review tasks created, tracked, and completed with full task history. All collaboration events logged in the audit trail. | **Table 17: Functional** Requirements specifications for Collaboration | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Document Sharing** | FRREP-COL001: The system shall allow document owners to share documents with named registered users by email or username, assigning one of three permission levels: View Only, Comment, or Edit. | Owner share action | Share record created; collaborator permissions set; notification dispatched | Author / Owner | | **Share Notifications** | FRREP-COL002: The system shall dispatch share notifications to invited collaborators containing a direct link to the document and the permission level granted. | Share event | Notification dispatched to all invited collaborators | System (automated) | | **Inline Annotations** | FRREP-COL003: The system shall allow collaborators with Comment or Edit permissions to add inline annotations and comments to specific sections of a document, with each comment timestamped and linked to the commenter's user account. | Collaborator comment action | Comment stored and displayed in annotation panel; author notified | Collaborator, System | | **Comment Resolution** | **FRREP-COL004**: The system shall allow document owners to mark individual comments as Resolved or flag them for further discussion, maintaining a clear record of comment status in the annotation panel. | Owner comment resolution | Comment status updated; annotation panel reflects resolution | Author / Owner | | **Review Task Assignment** | **FRREP-COL005**: The system shall allow document owners to assign formal review tasks to collaborators, specifying review scope, due date, and instructions, with the system tracking task status as Pending, In Progress, or Completed. | Owner task creation | Review task created; collaborator notified; task tracking initiated | Author / Owner, System | | **Task Reminders** | **FRREP-COL006**: The system shall send configurable reminder notifications to collaborators as review task due dates approach, and overdue notifications to both the collaborator and the document owner when a task passes its due date without completion. | Task due date event | Reminder or overdue notifications dispatched | System (automated) | | **Access Revocation** | FRREP-COL007: The system shall allow document owners to revoke a collaborator's access at any time, immediately removing all collaboration permissions while retaining any comments and annotations already recorded. | Owner revocation action | Collaborator permissions removed; existing comments retained | Author / Owner, System | | **Edit Conflict Detection** | FRREP-COL008: The system shall detect simultaneous edit conflicts when two collaborators with Edit permissions save changes to the same document section, preserving both versions and notifying both collaborators to resolve the conflict manually. | Simultaneous edit event | Conflict detected; both versions preserved; both collaborators notified | System (automated) | | **Audit Trail** | FRREP-COL009: The system shall log all sharing actions, permission changes, annotation events, comment resolutions, task assignments, task completions, and access revocations in the audit trail. | Any collaboration event | Audit log entry stored | System (automated) | ### REPO-SP8: Integration and Ecosystem Linkage This sub-process directly addresses the documented challenge that the Repository has no interface with other RUFORUM systems, resulting in missed outputs and disconnected data. In the RUFORUM ecosystem, the Repository is both a receiver taking research outputs from RIMS and a provider supplying publication counts, usage data, and open access metrics to M&E. It also makes OER content available to REP and provides research context to SME Hub innovators. **Table 34: **Integration and Ecosystem Linkage Use Case Narrative | **Use Case: REPO-SP8 Integration and Ecosystem Linkage** | | --- | | **Use Case Name** | REPO-SP8: Integration and Ecosystem Linkage | | **Actor(s)** | RIMS System, M&E Module, REP Platform, SME Hub, Repository Administrator, System | | **Description** | This use case describes the data flows between the Repository and the other RUFORUM systems. It covers RIMS pushing funded research outputs into the Repository, the Repository feeding publication and usage indicators into M&E, REP linking Repository OER content in courses, and SME Hub referencing Repository research documents. | | **Pre-condition(s)** | i. RIMS-Repository API integration is active and authenticated. ii. M&E-Repository API integration is active. iii. REP and SME Hub integration configurations are set by the administrator. | | **Main Success Scenario** | RIMS Grant Closeout Integration: When a RIMS administrator closes a grant or award, RIMS sends a document submission payload to the Repository API containing: researcher name, ORCID if available, document type, title, abstract, grant reference number, and attached final report file. Repository validates the payload and authentication token, ingests the document through the standard REPO-SP1 flow, links the document to the RIMS grant record, and returns a confirmation with the Document ID to RIMS. The ingested document enters the REPO-SP6 QA workflow for collection manager review before public publication. M&E Data Feed: Repository pushes aggregated publication statistics to the M&E module on a configured daily schedule and on key events such as document publication. The data payload includes: total documents by type and collection, new publications in the period, open access compliance rate, download counts, unique user access counts, and top accessed documents. M&E module maps the Repository data to the defined indicator set: number of publications, percentage of outputs digitised and uploaded, repository usage rate, percentage of outputs openly accessible, and citation and dissemination metrics. REP OER Linkage: REP instructors can search the Repository from within the REP course editor and link Repository documents directly as course resources, with the link type recorded as 'OER from Repository.' When a Repository document is accessed via an REP course link, the access event is recorded as both a Repository download event and an REP resource access event. SME Hub Integration: SME Hub users can search a curated subset of the Repository research publications, technical reports, and innovation documents from within the SME Hub interface, supporting research-based business development. The administrator monitors all integration endpoints from the integration status dashboard, showing last successful sync time, data volume transferred, and any failed events. | | **Alternative Flows** | A1 RIMS Payload Validation Failure: Repository API returns a validation error to RIMS with a specific error code. RIMS logs the failure and alerts the Grants Manager. The document is not stored until the payload is corrected and resubmitted. A2 M&E Feed Failure: Repository logs the failed push event and retries on the next scheduled cycle. Repository Administrator is notified if failures persist across two consecutive cycles. A3 REP Link to Withdrawn Document: A Repository document linked in a REP course is subsequently withdrawn. Repository notifies REP of the withdrawal. REP displays a broken link warning to learners and notifies the instructor. | | **Post-condition(s)** | RIMS-pushed documents ingested, linked to grant records, and entered into QA workflow. M&E module updated with Repository publication and usage indicators on schedule. REP course links to Repository documents recorded and tracked. SME Hub search of Repository content, active and logged. All integration events logged in the audit trail with success or failure status. | **Table REPO-SP8-FR: Functional Requirements Integration and Ecosystem Linkage** | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **RIMS API Ingestion** | FRREP-INT001: The system shall provide a documented REST API endpoint that accepts authenticated document submission payloads from RIMS on grant closeout, validating the authentication token and payload before ingesting the document through the standard capture and ingestion flow and returning the assigned Document ID to RIMS. | RIMS grant closeout payload | Document ingested; Document ID returned to RIMS; grant linkage stored; QA workflow triggered | RIMS System, System | | **RIMS Grant Linkage** | FRREP-INT002: The system shall store the RIMS grant reference number on every document ingested via RIMS API, creating a searchable cross-system linkage visible on the document detail page and searchable in the Repository. | RIMS grant reference in payload | Grant linkage stored; linkage displayed on document detail; searchable by grant reference | System (automated) | | **M****&****E Publication Indicators** | FRREP-INT003: The system shall push aggregated publication statistics to the M&E module on a configured daily schedule and on each document publication event, including: total documents by type, new publications in the period, open access compliance rate, download counts by document, and unique user access counts. | Scheduled trigger or publication event | Publication indicator payload sent to M&E; receipt confirmed and logged | System (automated) | | **M****&****E Indicator Mapping** | FRREP-INT004: The system shall map Repository data to the RUFORUM M&E indicator set including: number of publications, percentage of outputs digitised and uploaded, repository usage rate, percentage of outputs openly accessible, and number of dissemination events. | M&E data push | Indicators correctly mapped and available in M&E module | System (automated) | | **REP OER Search** | FRREP-INT005: The system shall expose a search API enabling REP instructors to search the Repository for Open Access documents from within the REP course editor and link selected documents directly as course resources, with the link type recorded as 'OER from Repository.' | REP search and link action | Document linked in REP course; linkage recorded in both systems | REP Platform, System | | **REP Access Tracking** | FRREP-INT006: The system shall record every document access event originating from an REP course link as both a Repository usage event and an REP resource access event, enabling cross-system analytics. | REP-originated document access | Dual access event recorded in Repository and REP analytics | System (automated) | | **Withdrawn Document Notification to REP** | FRREP-INT007: The system shall notify REP via API when a Repository document linked in a REP course is withdrawn, enabling REP to display a broken link warning to learners and notify the relevant instructor. | Document withdrawal event | REP notified; REP displays broken link warning; instructor notified | System (automated) | | **SME Hub Research Search** | FRREP-INT008: The system shall expose a curated search interface for the SME Hub enabling SME Hub users to search a subset of Repository content research publications, technical reports, and innovation documents from within the SME Hub interface. | SME Hub search query | Matching Repository documents returned and displayed within SME Hub | SME Hub, System | | **Integration Status Dashboard** | FRREP-INT009: The system shall provide administrators with an integration status dashboard showing the last successful sync time, data volume transferred, and any failed events for each connected system (RIMS, M&E, REP, SME Hub). | Admin dashboard access | Integration status rendered with connection health, last sync, and failure log | System (automated) | | **Audit Trail** | FRREP-INT010: The system shall log all integration events including API calls received, payloads processed, data pushed to M&E, REP link events, and SME Hub search events in the audit trail capturing system ID, action type, payload summary, and timestamp. | Any integration event | Audit log entry stored | System (automated) | ### REPO-SP9: Repository Analytics, Reporting, and AI-Powered Insights This sub-process addresses two documented challenges simultaneously: the limited statistics problem (only read counts are currently available) and the absence of machine learning-powered advanced insights. The upgraded system must provide comprehensive usage analytics, downloadable reports, and AI-driven capabilities including automated document classification, intelligent metadata extraction, document summarisation, and predictive research trend analytics. | **Use Case: REPO-SP9 Repository Analytics, Reporting, and AI-Powered Insights** | | --- | | **Use Case Name** | REPO-SP9: Repository Analytics, Reporting, and AI-Powered Insights | | **Actor(s)** | Repository Administrator, Collection Manager, M&E Officer, Researcher, AI Engine, System | | **Description** | This use case describes how administrators, managers, and researchers access usage analytics and AI-generated insights about the Repository's content and impact. It covers usage dashboards, report generation, automated document classification, intelligent metadata extraction, document summarisation, and predictive analytics on research trends. | | **Pre-condition(s)** | i. User is authenticated with Administrator, Collection Manager, or Researcher role. ii. Sufficient document and usage data exists to generate meaningful analytics. iii. AI models are configured and operational. | | **Main Success Scenario** | 1. Administrator navigates to the Analytics dashboard. System displays summary metrics: total documents by type, total downloads in the period, unique user visits, most downloaded documents, top search queries, new documents added, and open access compliance percentage. 2. User applies filters: date range, collection, document type, institution, country, and author. 3. System renders detailed analytics: per-document download counts, view counts, search click-through rates, geographic access distribution, user engagement trends, and collection growth over time. 4. User generates a report by selecting report type (usage summary, collection report, author impact report, open access compliance report), scope, and date range. System generates the report as PDF or CSV/Excel. 5. AI-Powered Document Classification: When a new document is uploaded without a collection assignment, the AI engine analyses the document content and suggests the most appropriate collection and subject keywords based on the trained classification model. The user may accept or override the suggestion. 6. AI-Powered Metadata Extraction: For documents where metadata is sparse, the AI engine extracts key information from the document body identifying author names, publication dates, funding sources, and key themes and pre-populates the metadata form with these extracted values, flagged as AI-suggested for user verification. 7. AI-Powered Summarisation: On the document detail page, the system displays an AI-generated abstract summary for documents where no human-authored abstract is available, clearly labelled as 'AI-Generated Summary.' 8. Predictive Research Trend Analytics: The AI engine analyses the Repository's document corpus and generates a research trend report identifying emerging topic clusters, high-growth research areas, and potential research gaps available to administrators and collection managers. 9. Author Impact Analytics: Researcher views their own author impact dashboard showing: total documents, total downloads, total views, download trend over time, and top accessed documents. Administrators can view author impact for any registered author. | | **Alternative Flows** | A1 Insufficient Data for AI Classification: If a document is too short or lacks sufficient text for reliable AI classification, the AI engine flags the document as 'Classification Uncertain' and prompts the user to assign the collection manually. A2 Report Generation Timeout: For large datasets, system queues the report and notifies the user by email when the report is ready for download. A3 AI Model Retraining: When the document corpus grows significantly, the administrator can trigger a model retraining job. System notifies the administrator when retraining is complete and the new model is active. | | **Post-condition(s)** | i. Analytics dashboards rendered with current Repository data. ii. Reports generated and available for download. iii. AI-suggested classifications and metadata available for user review and acceptance. iv. AI-generated summaries displayed on document detail pages. v. Research trend reports generated and available to administrators. vi. Author impact dashboards available to researchers and administrators. vii. All analytics access and report generation events logged in audit trail. | **Table REPO-SP9-FR: Functional Requirements Repository Analytics, Reporting, and AI-Powered Insights** > **Note on identifiers:** Repository SP9 uses the `FRREPO-AR*` prefix. The REP module's Learning Analytics & Reporting (REP-SP10) uses `FRREP-AR*` (single 'P'). Earlier drafts of this PRD used `FRREP-AR*` for both — disambiguated 2026-05-04. Code in `apps/repository/` references `FRREPO-AR*`; code in `apps/rep/` references `FRREP-AR*`. | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Usage Analytics Dashboard** | FRREPO-AR001: The system shall provide an administrator-level analytics dashboard displaying: total documents by type, total downloads, total unique user visits, most downloaded documents, top search queries, new documents added, and open access compliance percentage, all filterable by date range, collection, document type, institution, and country. | Admin dashboard access | Analytics dashboard rendered with current data | System (automated) | | **Per-Document Statistics** | FRREPO-AR002: The system shall track and display per-document statistics including download count, view count, search click-through rate, and geographic access distribution, updated in real time on each access event. | Document access event | Per-document statistics updated and displayed | System (automated) | | **Author Impact Dashboard** | FRREPO-AR003: The system shall provide each registered author with a personal impact dashboard showing total documents, total downloads, total views, download trend over time, and top accessed documents. Administrators shall be able to view the impact dashboard for any registered author. | Author or admin dashboard access | Author impact dashboard rendered | System (automated) | | **Open Access Compliance Report** | FRREPO-AR004: The system shall generate open access compliance reports showing the percentage of documents by collection, institution, and document type that carry an Open Access or OER licence, supporting RUFORUM's knowledge-sharing mandate reporting. | Report generation request | Open access compliance report generated | System (automated) | | **Collection Analytics** | FRREPO-AR005: The system shall provide collection-level analytics showing collection growth over time, most active submitters, most accessed documents, QA approval rates, and average time from submission to publication. | Admin or manager analytics access | Collection analytics rendered | System (automated) | | **Report Export** | FRREPO-AR006: The system shall allow administrators and collection managers to generate and download usage, collection, author impact, and open access compliance reports in PDF and CSV/Excel formats. | Report generation request | Report generated and available for download | System (automated) | | **AI Document Classification** | FRREPO-AR007: The system shall use an AI classification engine to analyse the content of newly uploaded documents and suggest the most appropriate collection and subject keywords, with confidence scores, for user review and acceptance or override. | Document upload without collection assignment | AI classification suggestion with confidence score displayed; user acceptance or override recorded | System (AI Engine) | | **AI Metadata Extraction** | FRREPO-AR008: The system shall use AI to extract key metadata from document body text including author names, publication dates, funding sources, and key themes and pre-populate the metadata form with these AI-suggested values, clearly labelled as AI-suggested for user verification. | Document upload with sparse metadata | AI-extracted metadata pre-populated in metadata form; values flagged as AI-suggested | System (AI Engine) | | **AI Document Summarisation** | FRREPO-AR009: The system shall use AI to generate an abstract summary for documents where no human-authored abstract is available, displaying the AI-generated summary on the document detail page with a clear 'AI-Generated Summary' label. | Document publication without abstract | AI-generated summary displayed on document detail page with label | System (AI Engine) | | **Research Trend Analytics** | FRREPO-AR010: The system shall use AI to analyse the Repository's document corpus and generate a research trend report identifying emerging topic clusters, high-growth research areas, and potential research gaps, available to administrators and collection managers. | Admin or manager report request | Research trend report generated with topic clusters and growth analysis | System (AI Engine) | | **Search Behaviour Analytics** | FRREPO-AR011: The system shall analyse search query logs to identify the most frequent search terms, zero-result queries, and search-to-download conversion rates, reporting these to administrators to inform collection development and metadata improvement. | Search log data | Search behaviour analytics report rendered | System (automated) | | **M****&****E Feed** | FRREPO-AR012: The system shall push Repository analytics indicators to the M&E module on a configured daily schedule including: repository usage rate, number of documents by type, open access compliance rate, and download volume, mapped to the RUFORUM M&E indicator framework. | Scheduled trigger | Indicators sent to M&E; receipt confirmed and logged | System (automated) | | **Audit Trail** | FRREPO-AR013: The system shall log all analytics dashboard access, report generation, AI classification events, AI metadata extraction events, and AI model retraining events in the audit trail capturing user ID, action type, and timestamp. | Any analytics or AI event | Audit log entry stored | System (automated) | 5.5. SME HUB SUBPROCESS **Table 35: Use case narrative for Onboarding and Business Registration** | **Use case name** | Onboarding and Business Registration | | --- | --- | | **Actor** | Prospective User (Entrepreneur, Mentor, Investor, Service Provider, Partner), SME Hub Administrator, M&E Module | | **Description ** | This use case describes the end-to-end onboarding journey of a new user into the SME Hub from self-registration through role assignment, administrator verification, business profile creation, and AIH/university affiliation. | | **Pre-condition** | The SME Hub registration portal is accessible. The AIH and RUFORUM partner university directory is populated within the system. Where an existing programme linkage is expected, the relevant beneficiary record already exists in the RIMS module. | | **Main success scenario** | The prospective user navigates to the SME Hub registration page. The user enters their details full name, email, country, organisation/institution, phone number and selects their role: Entrepreneur, Mentor, Investor, Service Provider, or Partner. The system immediately saves the registration record to the database and sends a verification email For users registering as Entrepreneur, the system checks whether a matching beneficiary profile already exists in the grants module using the email address as the matching key. If a matching beneficiary record is found, the system presents it to the user for confirmation and pre-populates the entrepreneur profile with the matched data eliminating re-entry. The entrepreneur reviews and confirms or corrects the pre-populated details, then submits their profile. The system flags the account as Pending Verification and notifies the administrator. The administrator reviews the pending entrepreneur from the verification queue, inspects the submitted profile and any supporting documents, and verifies the entrepreneur . If the entrepreneur is verified, the entrepreneur is notified. The entrepreneur completes the business registration form, providing the business name, sector, sub-sector, business stage, founding date, country, location, product/service description, target market, number of employees, and estimated revenue range The system assigns a unique Business ID, sets the status to Pending Admin Review, and notifies the administrator. The administrator reviews and verifies the business from the admin dashboard. The system prompts the entrepreneur to complete AIH/university affiliation, selecting their affiliated institution from the system directory and indicating their nature of affiliation and programme of origin. If the entrepreneur selects a grant-funded programme as their origin, the system resolves the linkage to the corresponding RIMS grant, scholarship, or innovation challenge record within the RIMS module and records the cross-reference. | | Alternative flow | A1 Verification Email Not Received: The user requests a resend. The system uses the already-saved registration record to resend without requiring re-entry of details. A2 No Matching RIMS Record: The system finds no existing RIMS beneficiary record for the email entered. The entrepreneur completes their profile manually with no pre-population. A3 Entrepreneur Rejected at Verification: The administrator rejects with a stated reason. The entrepreneur is notified and may resubmit with corrections. The profile is retained in the system. A4 Administrator Requests More Information: The administrator flags the profile as Pending More Information and messages the entrepreneur directly through the system. The profile stays in the verification queue until resubmitted. A6 Business Revoked: The administrator can revoke a verified business at any time, recording a reason in the audit trail. The entrepreneur is notified and the business is removed from matchmaking and programme eligibility. A7 RIMS Programme Linkage Ambiguous: If the system finds more than one potential RIMS record match, it presents the options to the entrepreneur to select the correct one, or escalates to the administrator for resolution. A8 Administrator Backend Registration: The administrator can manually register a user or business from the backend for assisted or bulk cohort onboarding, bypassing the self-registration flow. A9 Non-Entrepreneur Roles: For Mentors, Investors, Service Providers, and Partners, the journey ends at step 8. Profile completion for these roles follows their respective onboarding flows but does not include business registration or M&E baseline capture. | | **Post condition** | **Success:** User account is created, verified, and role-configured. Entrepreneur profile is verified. RIMS module linkage established where a matching record existed. Business profile is created, verified, and assigned a unique Business ID. AIH/university affiliation is recorded and linked to the relevant RIMS programme record where applicable. M&E baseline snapshot stored and M&E module tracking record initialised. Audit trail updated throughout. **Failure:** If email verification fails, registration data is retained, and a resend is available; no data is lost. If entrepreneur verification is rejected, the profile is retained with the rejection reason recorded. If RIMS linkage cannot be resolved, onboarding proceeds without the linkage, and the case is flagged for administrator review. No data is permanently lost at any stage of the process. | **Table 36: Broad View of Data Requirements SP1: Onboarding ****&**** Business Registration** | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | User Registration | FRSME-OBR001: The system shall allow any prospective user to self-register by completing a registration form capturing: full name, email address, password, country, organisation/institution, and phone number. | Full name, email, password, country, organisation, phone number | Registration form submitted; registration record created | Prospective User | | | FRSME-OBR002: The system shall immediately save the registration record to the database upon form submission, before dispatching the verification email, to ensure no data is lost if email delivery is delayed or the user closes their browser. | Submitted registration form data | Registration record persisted in the database; verification email dispatched | System (automated) | | | FRSME-OBR003: The system shall require the user to select a role during registration from the following options: Entrepreneur, Mentor, Investor, Service Provider, or Partner. | Selected role | Role stored against registration record; role-based access permissions configured upon account activation | Prospective User | | | FRSME-OBR004: The system shall validate that the email address provided during registration is not already associated with an existing account, and display a clear duplicate email message with options to log in or reset the password if a match is found. | Registration email, existing user records | Duplicate email warning displayed; registration blocked until unique email provided | System (automated) | | | FRSME-OBR005: The system shall validate all mandatory registration fields before form submission, highlighting incomplete fields and preventing submission until all required data is provided. | Registration form data, mandatory field definitions | Inline field-level error indicators; submission blocked if validation fails | System (automated) | | | FRSME-OBR006: The system shall allow the administrator to manually register a user from the backend, bypassing the self-registration and email verification flow for assisted or bulk cohort onboarding, with the manual registration flagged in the audit trail. | User details entered by the administrator | User account created and activated; manual registration flagged in audit log | Administrator | | Email Verification | FRSME-OBR007: The system shall send a time-limited email verification link to the registered email address immediately upon submission of a valid registration form. | Registered email address, verification token | Verification email dispatched; verification token stored against registration record with expiry timestamp | System (automated) | | | FRSME-OBR008: The system shall activate the user account, assign role-based access permissions, and redirect the user to their role-specific dashboard when the verification link is clicked within the valid time window. | Clicked verification link, registration record | Account activated; role-based permissions assigned; user redirected to dashboard; welcome notification sent; audit log entry created | System (automated) | | | FRSME-OBR009: The system shall allow the user to request a resend of the verification email at any time, using the already-persisted registration record to generate a new link without requiring re-entry of registration details. | Resend request | New verification email dispatched with fresh time-limited link; previous link invalidated | System (automated) | | | FRSME-OBR010: The system shall display a clear expired-link message and prompt the user to request a new verification email if an expired verification link is clicked, retaining the registration record throughout. | Expired verification link click | Expired-link message displayed; resend option presented; registration record retained | System (automated) | | Entrepreneur Profile Completion | FRSME-OBR011: The system shall check, upon registration as an Entrepreneur, whether a matching beneficiary record exists in the RIMS module using the registered email address as the matching key, and present any matched record to the user for confirmation. | Registered email address, RIMS module beneficiary records | Matched RIMS record presented to entrepreneur for confirmation, or no-match result returned | System (automated), RIMS Module | | | FRSME-OBR012: The system shall pre-populate the entrepreneur profile form with data from a confirmed RIMS match, including name, institution, programme, and country, reducing re-entry and ensuring consistency across modules. | Confirmed RIMS beneficiary record | Entrepreneur profile form pre-populated with matched data; the entrepreneur can review and correct before submission | System (automated), Entrepreneur | | | FRSME-OBR013: The system shall allow the entrepreneur to complete their profile manually with no pre-population where no matching RIMS record is found, without blocking or penalising the registration process. | No RIMS match result, manual profile data | Entrepreneur profile completed manually; profile saved; status set to Pending Verification | Entrepreneur | | | FRSME-OBR014: The system shall flag the account as Pending Verification and notify the administrator upon submission of the entrepreneur profile, placing it in the verification queue. | Submitted entrepreneur profile | Account flagged as Pending Verification; administrator notified; profile placed in verification queue; audit log entry created | System (automated) | | Administrator Verification | FRSME-OBR015: The system shall display all entrepreneur profiles awaiting verification in a verification queue on the administrator dashboard, filterable by submission date, country, and institution. | Pending entrepreneur profiles, filter selections | Filtered verification queue displayed | Administrator | | | FRSME-OBR016: The system shall allow the administrator to review the full entrepreneur profile including submitted details, supporting documents, and institutional affiliation before making a verification decision. | Entrepreneur profile record, supporting documents | Full profile displayed to administrator in review view | Administrator | | | FRSME-OBR017: The system shall allow the administrator to verify an entrepreneur profile, triggering a status change to Verified, expanding the entrepreneur's dashboard access to include business registration and programme application features, and dispatching a verification confirmation notification to the entrepreneur. | Administrator verification action | Entrepreneur status set to Verified; dashboard access expanded; entrepreneur notified; audit log entry created | Administrator, System (automated) | | | FRSME-OBR018: The system shall allow the administrator to reject an entrepreneur profile with a mandatory written reason, triggering a status change to Rejected and dispatching a rejection notification to the entrepreneur that includes the reason and an option to resubmit with corrections. | Administrator rejection action, written rejection reason | Entrepreneur status set to Rejected; rejection reason stored against profile; entrepreneur notified with reason and resubmission guidance | Administrator, System (automated) | | | FRSME-OBR019: The system shall allow the administrator to flag an entrepreneur profile as Pending More Information and send a targeted message to the entrepreneur specifying what additional details or documents are required, retaining the profile in the verification queue until resubmitted. | Administrator flag action, message to entrepreneur | Profile status set to Pending More Information; message sent to entrepreneur; profile retained in queue | Administrator, System (automated) | | | FRSME-OBR020: The system shall allow the administrator to bulk-verify a selected list of entrepreneur profiles for example during managed RUFORUM programme cohort onboarding applying the Verified status to all selected profiles simultaneously. | Selected entrepreneur profile list, bulk verification action | All selected profiles set to Verified; entrepreneurs notified; audit log entries created | Administrator, System (automated) | | Business Profile Creation | FRSME-OBR021: The system shall restrict business registration to entrepreneurs whose profiles have been set to Verified status, blocking the business registration interface for all unverified entrepreneurs with a clear status message. | Entrepreneur verification status | Business registration interface displayed to verified entrepreneurs only; blocked with status message for unverified | System (automated) | | | FRSME-OBR022: The system shall allow a verified entrepreneur to register a business by completing a structured form capturing: business name, sector, sub-sector, business stage, founding date, country, location, product or service description, and target market. | Business registration form data | Business profile record created; status set to Pending Admin Review; administrator notified; audit log entry created | Entrepreneur | | | FRSME-OBR023: The system shall capture M&E baseline fields as part of the business registration form including current full-time employee count, current part-time employee count, estimated monthly revenue range, primary target market, and geographic reach which will serve as the baseline data point for the entrepreneur's M&E tracking record. | M&E baseline field data | M&E baseline fields stored against business profile record | Entrepreneur | | | FRSME-OBR024: The system shall assign a unique Business ID to each registered business upon submission and set the status to Pending Admin Review. | Submitted business registration form | Unique Business ID assigned; status set to Pending Admin Review; audit log entry created | System (automated) | | | FRSME-OBR025: The system shall allow a verified entrepreneur to register more than one business, with each business assigned its own unique Business ID and M&E baseline record, tracked independently. | Additional business registration submissions | Each business created as an independent record with unique ID and baseline; all linked to the entrepreneur profile | Entrepreneur, System (automated) | | Business Verification | FRSME-OBR026: The system shall display all business profiles awaiting verification on the administrator dashboard, filterable by submission date, sector, business stage, and country. | Pending business profiles, filter selections | Filtered business verification queue displayed | Administrator | | | FRSME-OBR027: The system shall allow the administrator to verify a business profile, setting the status to Verified, making the business available for programme applications and matchmaking, and notifying the entrepreneur. | Administrator verification action | Business status set to Verified; business available for programme applications and matchmaking; entrepreneur notified; audit log entry created | Administrator, System (automated) | | | FRSME-OBR028: The system shall allow the administrator to reject a business profile with a mandatory written reason, setting the status to Rejected and notifying the entrepreneur with the reason and guidance for resubmission. | Administrator rejection action, written reason | Business status set to Rejected; reason stored; entrepreneur notified | Administrator, System (automated) | | | FRSME-OBR029: The system shall allow the administrator to revoke a previously verified business at any time for example if found to be fraudulent or no longer active recording a mandatory reason in the audit trail and notifying the entrepreneur. The business is removed from matchmaking and programme eligibility upon revocation. | Administrator revocation action, reason | Business status set to Revoked; reason recorded in audit trail; entrepreneur notified; business removed from matchmaking and programme eligibility | Administrator, System (automated) | | AIH / University Affiliation | FRSME-OBR030: The system shall prompt the entrepreneur to complete AIH or partner university affiliation following business verification, presenting a dropdown of registered institutions from the system directory. | Verified business record, institution directory | Affiliation form displayed with institution dropdown | System (automated), Entrepreneur | | | FRSME-OBR031: The system shall require the entrepreneur to indicate their nature of affiliation student, alumni, faculty, or external community entrepreneur and their programme of origin when completing affiliation. | Nature of affiliation selection, programme of origin selection | Affiliation details stored against business profile | Entrepreneur | | | FRSME-OBR032: The system shall allow the entrepreneur to indicate a RIMS-funded programme as their programme of origin and resolve the linkage to the corresponding RIMS grant, scholarship, or innovation challenge record within the RIMS module, creating a cross-reference linkage. | RIMS programme selection, RIMS module records | RIMS programme linkage resolved and cross-reference record created; linkage stored against business and entrepreneur profiles | System (automated), RIMS Module | | | FRSME-OBR033: The system shall allow an entrepreneur to record affiliation with more than one AIH or partner university, designating one as primary, for cases where an entrepreneur has connections to multiple institutions. | Multiple institution selections, primary designation | Multiple affiliation records created; primary affiliation flagged | Entrepreneur | | | FRSME-OBR034: The system shall allow the administrator to set or correct an entrepreneur’s AIH affiliation from the backend, for example during bulk cohort onboarding or where the entrepreneur cannot complete affiliation independently. | Administrator affiliation entry | Affiliation record created or updated; flagged as administrator-entered in audit trail | Administrator | | M&E Baseline Capture | FRSME-OBR035: The system shall capture and store the M&E baseline snapshot upon completion of AIH affiliation recording: date of entry into the SME Hub, business stage at entry, employee count at entry, revenue range at entry, sector, and geographic location as the starting point for all subsequent M&E tracking. | Verified business profile, affiliation record, M&E baseline fields | M&E baseline snapshot stored with timestamp; baseline record linked to entrepreneur and business profiles | System (automated) | | | FRSME-OBR036: The system shall trigger the M&E module to initialise a tracking record for the entrepreneur and their business upon successful baseline capture, making the entrepreneur visible in the M&E dashboard from the point of entry. | M&E baseline snapshot, entrepreneur and business profile identifiers | M&E module tracking record initialised; entrepreneur visible in M&E portfolio dashboard | System (automated), M&E Module | | | FRSME-OBR037: The system shall notify the M&E Officer when a new entrepreneur M&E tracking record is initialised, enabling real-time visibility of new entrants into the portfolio. | New M&E tracking record creation event | Notification dispatched to M&E Officer; new entrant visible on M&E dashboard | System (automated), M&E Officer | | --- | --- | --- | --- | --- | **Table 37: Use case narrative for incubation Programme Management** | **Use case name** | Incubation Programme Management | | --- | --- | | **Actor** | Administrator, Programme Officer, Entrepreneur, Judge, Mentor, E-Learning Module, M&E Module | | **Description** | This use case describes the full lifecycle of an incubation programme within the SME Hub from the administrator designing and publishing a call for incubation, through entrepreneur application, automated eligibility screening, judge-led scoring and selection, cohort formation, training delivery linked to the E-Learning module, mentorship assignment and session management, and finally certificate issuance and M&E progress update. | | **Pre-condition** | The administrator is logged in with programme management rights. The entrepreneur is registered, verified, and has at least one verified business profile (SP1 complete). Mentors are registered and have completed their profiles in the system. Where training content is to be delivered through the E-Learning module, the relevant courses exist and are published there. | | **Main success scenario** | The administrator navigates to Incubation Programmes and selects Create New Programme. The administrator defines the programme details: title, objectives, target sector(s), cohort size, duration, AIH location(s), eligibility criteria (business stage, sector, geographic focus), application deadline, and selection method. The administrator configures the judging panel, selecting judges from registered users with the Judge role and defines the scoring rubric: assessment sections, weighting, and scoring instructions. The scoring rubric is fully functional and mandatory before publication, resolving the current system gap where this feature is non-operational. The administrator links the programme to one or more E-Learning module courses that enrolled entrepreneurs will be required to complete during incubation. The administrator saves the programme as Draft, previews it, and publishes it. The system sets the status to Published, displays the programme to eligible entrepreneurs on their dashboards, and dispatches automated notifications to registered entrepreneurs who meet the eligibility criteria resolving the current gap where users only hear about opportunities through informal channels. The entrepreneur views the published call, reviews the eligibility requirements and programme details, and applies. The system performs an automated eligibility check against the entrepreneur's verified business profile sector, stage, AIH affiliation, and geographic location. If ineligible, the system immediately displays a clear reason and does not permit submission, preventing late-stage rejection frustration that exists in the current process. If eligible, the system creates a unique Application ID, sets status to Draft, and opens the application form. The entrepreneur completes the application: business description, problem being solved, current traction, funding needs, and support sought from incubation and uploads required documents. The system auto-saves progress throughout. The entrepreneur reviews and submits the application. The system validates completeness and required attachments, changes status to Submitted, records the timestamp, and sends a confirmation notification. The application enters the review queue. The programme officer performs a first-level completeness check and either passes the application to scoring or returns it to the entrepreneur with a request for missing information. The system assigns the application to the configured judges. Each judge receives a notification and accesses the application through their dashboard. Each judge scores the application against the defined sections and weighting, enters comments, and submits their review. The system records each submission with a timestamp. Once all assigned judges have submitted, the system automatically calculates a weighted average score and ranks all applications in descending order on the administrator's selection dashboard. The administrator reviews the ranked list, applies any additional programme-level criteria, and confirms the selected cohort. The system sets accepted applications to Accepted and unsuccessful ones to Rejected. All applicants are notified with their outcome and, for rejected applicants, a reason. The administrator creates the incubation cohort from the accepted applicants, setting the cohort start date, schedule, and venue details. The system enrols all cohort members into the linked E-Learning module courses and notifies them of their enrolment and course access. The administrator assigns a mentor to each entrepreneur or business within the cohort based on sector alignment and mentor availability. The system records the assignment and notifies both parties. Throughout the programme, mentors and entrepreneurs conduct sessions physical or virtual. The system provides a scheduling interface for booking sessions, recording session notes, and tracking session history. The entrepreneur accesses and progresses through the linked E-Learning courses. Completion data is resolved from the E-Learning module into the SME Hub, updating the entrepreneur's programme progress record. The administrator monitors cohort progress through a programme dashboard showing each entrepreneur's training completion status, mentorship sessions conducted, and overall engagement. Upon satisfying all programme completion criteria defined attendance, training completion, and mentorship sessions the system automatically marks the entrepreneur as Programme Complete, generates a certificate of completion, and makes it available for download. The system triggers the M&E module to update the entrepreneur's progress record, recording programme completion date, training modules completed, mentorship sessions attended, and measurable business growth indicators advancing the M&E tracking record initialised in SP1. All actions throughout the process are logged in the system audit trail. | | **Alternative flow** | A1 Application Returned for Correction: The programme officer identifies missing documents. The system returns the application to the entrepreneur with a specified list of gaps. The entrepreneur corrects and resubmits within the deadline. A2 Deadline Passes Before Submission: The system closes the application portal at the configured deadline. Applications in Draft status are automatically marked Not Submitted and the entrepreneur is notified. A3 Judge Does Not Submit Score: The system sends automated reminders. The administrator can reassign the application to another judge or override the requirement. A4 Insufficient Applicants for Cohort: The administrator can extend the deadline, reduce the minimum cohort size, or cancel and republish with revised criteria. A5 Mentor Unavailable During Programme: The administrator reassigns the entrepreneur to another compatible mentor. The system retains prior session history and continues the record under the new assignment. A6 Entrepreneur Drops Out: The administrator marks the entrepreneur as Withdrawn. Their data is retained for M&E and audit purposes but removed from active programme tracking. A7 Training Delivered Without E-Learning Module: The administrator manually records attendance and training completion for in-person-only programmes. Certification and M&E update follow the same path as the main flow. | | **Post-condition** | **Success:** Programme record created, published, and archived with full application, scoring, and selection history. Cohort formed with all members enrolled in E-Learning courses and assigned mentors. All programme completion records stored against each entrepreneur's profile. Certificates generated and accessible to completing entrepreneurs. M&E module updated with programme completion and business progress data. Full audit trail maintained throughout. **Failure:** If judge scoring is incomplete at the selection deadline, the system prevents automated ranking until the administrator resolves it. If E-Learning enrolment fails for a cohort member, the system flags it for administrator action without blocking the rest of the cohort. iii. No application or scoring data is permanently lost at any stage. | **Table 38: Requirements specifications for Fund Management** | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | **Programme Setup** | **FRSME-INC001: **The system shall allow authenticated users with the Administrator or Programme Officer role to create a new incubation programme record. | User credentials, role permissions | Blank programme setup form displayed | Administrator, Programme Officer | | | **FRSME-INC002: **The system shall require the following fields to be completed before a programme can be published: title, objectives, target sector(s), cohort size, duration, eligibility criteria, application deadline, and at least one assigned judge. | Programme setup form data | Validation check on mandatory fields; publication blocked if any field is absent, with an inline error message | System (automated) | | | **FRSME-INC003: **The system shall allow a programme record to be saved as a Draft at any point during data entry without requiring all mandatory fields to be complete. | Partially completed programme form | Draft programme record saved; status set to Draft; audit log entry created | Administrator, Programme Officer | | | **FRSME-INC004: **The system shall allow the administrator to configure a scoring rubric for each programme defining assessment sections, weighting per section, maximum marks, and judging instructions before publication. | Assessment sections, weightings, max marks, judging instructions | Scoring rubric stored against programme record; publication blocked if rubric is absent | Administrator | | | **FRSME-INC005: **The system shall allow the administrator to link one or more E-Learning module courses to a programme record, which enrolled cohort members will be required to complete during incubation. | E-Learning course IDs selected from system directory | Linked course records stored against programme; courses activated for cohort enrolment upon programme publication | Administrator, E-Learning Module | | | **FRSME-INC006: **The system shall publish a programme record and make it visible to eligible entrepreneurs on their dashboards when the administrator selects Publish, provided all mandatory fields and the scoring rubric are complete. | Validated programme record | Programme status set to Published; eligible entrepreneur dashboards updated; audit log entry created | Administrator, System (automated) | | | **FRSME-INC007: **The system shall automatically dispatch notifications to all registered entrepreneurs whose verified business profiles match the programme eligibility criteria (sector, business stage, geographic location) upon programme publication. | Published programme record, entrepreneur profile data | Notification sent to all matching entrepreneurs via the system dashboard and email; notification log stored | System (automated) | | **Application Submission** | **FRSME-INC008: **The system shall perform an automated eligibility check against the entrepreneur's verified business profile sector, business stage, AIH affiliation, and geographic location before permitting an application to be started. | Entrepreneur business profile, programme eligibility criteria | Eligibility confirmed and application form opened, or eligibility failed with a clear reason displayed, and submission blocked | System (automated), Entrepreneur | | | **FRSME-INC009: **The system shall create a unique Application ID and set the application status to Draft when an eligible entrepreneur initiates an application against a published programme. | Entrepreneur credentials, active programme record | Application record created with unique Application ID; status set to Draft; audit log entry created | System (automated) | | | **FRSME-INC010: **The system shall provide a structured application form capturing: business description, problem being solved, current traction, funding needs, support sought from incubation, and document upload fields for required attachments. | Application form data, uploaded documents | Application data saved against Application ID; documents linked to application record with document IDs assigned | Entrepreneur | | | **FRSME-INC011: **The system shall automatically save application form progress at configurable intervals to prevent data loss during entry. | In-progress application form data | Auto-saved application draft; no data loss on session interruption | System (automated) | | | **FRSME-INC012: **The system shall validate completeness of mandatory fields and required document uploads when the entrepreneur selects Submit, displaying inline errors and blocking submission until all requirements are met. | Completed application form, mandatory field definitions, required document list | Validation pass or field-level error indicators; submission blocked if validation fails | System (automated) | | | **FRSME-INC013: **The system shall change the application status to Submitted, record the submission timestamp, and send a confirmation notification to the entrepreneur upon successful submission. | Validated and submitted application record | Application status set to Submitted; timestamp recorded; confirmation notification sent to entrepreneur; application enters review queue | System (automated), Entrepreneur | | | **FRSME-INC014: **The system shall prevent submission of applications after the published programme deadline has passed and display a clear deadline-expired message to the entrepreneur. | Application submission attempt, programme deadline | Submission blocked; deadline-expired message displayed; application retained as Draft | System (automated) | | **First-Level Review** | **FRSME-INC015: **The system shall display all submitted applications for a programme in a review queue on the Programme Officer's dashboard, filterable by submission date, sector, and application status. | Submitted application records, filter selections | Filtered application review queue displayed | Programme Officer | | | **FRSME-INC016: **The system shall allow the Programme Officer to mark an application as Passed First-Level Review, routing it to the judge scoring stage, or to return it to the entrepreneur with a documented list of missing or incomplete items. | Application review decision, list of gaps (if returned) | Application status updated to Under Review or Returned to Applicant; entrepreneur notified if returned; gaps documented against application record | Programme Officer, System (automated) | | **Judge Scoring** | **FRSME-INC017: **The system shall assign applications that pass first-level review to the judges configured on the programme record, and notify each judge via dashboard and email. | Application records in Under Review status, programme judge list | Applications assigned to judges; judge notification sent; assignment records created with timestamp | System (automated), Judge | | | **FRSME-INC018: **The system shall provide each judge with a structured scoring interface displaying the application content, the scoring rubric sections, weighting, maximum marks, and a comments field per section. | Application record, programme scoring rubric | Scoring interface displayed to judge with all sections and weightings | Judge | | | **FRSME-INC019: **The system shall record each judge's scores and comments per rubric section and store them against the application record with the judge's ID and submission timestamp. | Judge scores per section, comments, submission action | Judge scoring record stored against application; submission timestamp logged; audit entry created | Judge, System (automated) | | | **FRSME-INC020: **The system shall automatically calculate a weighted average score for each application once all assigned judges have submitted their scores, and rank all applications in descending order on the administrator's selection dashboard. | All judge scores for an application, rubric weightings | Weighted average score calculated per application; ranked applicant list generated and displayed on administrator dashboard | System (automated) | | | **FRSME-INC021: **The system shall send automated reminders to judges who have not submitted scores by a configurable number of days before the scoring deadline. | Judge assignment records, scoring deadline, current date | Reminder notification sent to pending judges; reminder log stored | System (automated) | | **Cohort Selection ****&**** Notification** | **FRSME-INC022: **The system shall allow the administrator to review the ranked applicant list, apply any additional selection criteria, and confirm the selected cohort by marking applications as Accepted. | Ranked applicant list, administrator selection decisions | Accepted applications set to Accepted status; cohort record initialised; audit log entry created | Administrator | | | **FRSME-INC023: **The system shall set all non-selected applications to Rejected status and automatically dispatch notifications to all applicants accepted and rejected with their outcome and, for rejected applicants, a reason. | Selection decisions, rejection reasons | Rejected applications set to Rejected status; notifications dispatched to all applicants; notification log stored | System (automated), Administrator | | **E-Learning Enrolment** | **FRSME-INC024: **The system shall automatically enrol all accepted cohort members into the E-Learning module courses linked to the programme upon cohort confirmation. | Accepted cohort member list, linked E-Learning course IDs | Cohort members enrolled in linked E-Learning courses; enrolment records created; access notifications sent to entrepreneurs | System (automated), E-Learning Module | | | **FRSME-INC025: **The system shall flag any failed E-Learning enrolments for administrator review and action without blocking the enrolment of other cohort members. | Enrolment attempt results | Failed enrolment flagged on administrator dashboard; successful enrolments unaffected | System (automated), Administrator | | **Mentor Assignment** | **FRSME-INC026: **The system shall allow the administrator to assign a mentor to each entrepreneur or business within the cohort by selecting from registered and verified mentor profiles, filtered by sector alignment and availability. | Cohort member list, mentor profiles, sector alignment data | Mentorship assignment record created linking mentor and entrepreneur; both parties notified; assignment stored against programme record | Administrator | | | **FRSME-INC027: **The system shall allow the administrator to reassign a mentor during the programme if the originally assigned mentor becomes unavailable, retaining all prior session records under the new assignment. | Reassignment request, new mentor selection, existing session history | New mentorship assignment created; prior session history retained and linked to the entrepreneur record; both parties notified | Administrator, System (automated) | | **Session Management** | **FRSME-INC028: **The system shall provide a session scheduling interface allowing the mentor or entrepreneur to book a mentorship session, specifying session type (physical or virtual), date, time, duration, and agenda. | Session type, date, time, duration, agenda | Session record created; calendar notifications sent to both mentor and entrepreneur | Mentor, Entrepreneur | | | **FRSME-INC029: **The system shall allow the mentor to record session notes and mark a session as Completed after it has taken place, storing the notes and completion status against the session record. | Session notes, completion confirmation | Session record updated with notes and Completed status; session history updated; audit log entry created | Mentor | | | **FRSME-INC030: **The system shall display a running session history for each mentor-entrepreneur assignment on both the mentor's and administrator's dashboards, showing session count, dates, statuses, and cumulative notes. | Session records for a mentorship assignment | Session history dashboard view displayed to the mentor and administrator | Mentor, Administrator | | **Training Completion Sync** | **FRSME-INC031: **The system shall receive and process E-Learning module completion data for linked courses and update each enrolled entrepreneur's programme progress record accordingly. | E-Learning course completion data, enrolment records | Entrepreneur programme progress record updated with course completion status and date | System (automated), E-Learning Module | | | **FRSME-INC032: **The system shall allow the administrator to manually record training completion for an entrepreneur where training was delivered in-person and not tracked through the E-Learning module. | Administrator manual completion entry, training details | Manual completion record stored against entrepreneur's programme progress; flagged as manually entered in audit trail | Administrator | | **Completion ****&**** Certification** | **FRSME-INC033: **The system shall evaluate programme completion criteria defined attendance threshold, E-Learning course completions, and minimum mentorship sessions and automatically set an entrepreneur's status to Programme Complete when all criteria are satisfied. | Attendance records, training completion status, mentorship session count, completion criteria configuration | Entrepreneur programme status set to Programme Complete; completion date recorded; audit log entry created | System (automated) | | | **FRSME-INC034: **The system shall generate a certificate of completion for each entrepreneur who achieves Programme Complete status, using a configurable certificate template populated with the entrepreneur's name, programme title, cohort name, and completion date. | Entrepreneur profile data, programme record, certificate template | Certificate generated in PDF format; made available for download on the entrepreneur's dashboard; certificate record stored | System (automated), Entrepreneur | | | **FRSME-INC035: **The system shall allow the administrator to manually mark an entrepreneur as Programme Complete and trigger certificate generation where system-tracked completion data is unavailable, with a mandatory reason recorded in the audit trail. | Administrator manual override action, reason for override | Programme Complete status set; certificate generated; manual override and reason recorded in audit trail | Administrator | | **M****&****E Progress Update** | **FRSME-INC036: **The system shall trigger the M&E module to update the entrepreneur's tracking record upon programme completion, passing: programme completion date, E-Learning courses completed, mentorship sessions attended, cohort name, AIH affiliation, and any business growth indicators captured during the programme. | Programme completion record, E-Learning completion data, session records, business growth data | M&E module tracking record updated with SP2 completion data; baseline-to-completion progress stored for impact reporting | System (automated), M&E Module | | | **FRSME-INC037: **The system shall update the entrepreneur's M&E tracking record at each key milestone within SP2 application submission, cohort selection, E-Learning completion, and programme completion, not only at completion, enabling longitudinal progress monitoring. | Milestone event triggers from SP2 subprocesses | M&E tracking record updated at each milestone; longitudinal progress data available for real-time monitoring | System (automated), M&E Module | **Table 39**: Use case narrative for Market and Partner Linkage | **Use case name** | Market and Partner Linkage | | --- | --- | | **Actor** | Entrepreneur, Administrator, Partner Organisation, Buyer/Off-taker, Service Provider, M&E Module | | **Description** | This use case describes how a verified, incubated entrepreneur connects to the external ecosystem, i.e., government agencies, corporates, NGOs, universities, buyers, off-takers, and professional service providers, through a structured set of directories, matchmaking tools, and connection management workflows. | | **Pre-condition** | The entrepreneur is registered, verified, and has at least one verified business profile. The Partner Directory, Buyer Registry, and Service Provider Directory are populated with verified organisations. The entrepreneur has ideally completed at least one incubation programme (SP2), though SP3 is accessible to all verified entrepreneurs. | | **Main success scenario** | The administrator navigates to Market & Partner Linkage and manages the three directories: Partner Directory (government agencies, corporates, NGOs, universities), Buyer and Off-taker Registry, and Service Provider Directory (legal, finance, certification, packaging, QA, IP firms). Each entry is created with structured profile data, organisation name, type, sector focus, geographic coverage, contact details, and areas of interest or service offering. Partners, buyers, and service providers registered in the system complete their own profiles through their respective dashboards, subject to administrator verification before appearing in search results. The verified entrepreneur navigates to the Market & Partner Linkage section from their dashboard. The system displays the three directories with search and filter capabilities by sector, organisation type, geography, and need. The entrepreneur searches for relevant partners, buyers, or service providers using a keyword or advanced filter search. The system also presents AI-assisted recommendations based on the entrepreneur's verified business profile, sector, and stage, surfacing the most relevant connections without requiring manual browsing. The entrepreneur views a partner, buyer, or service provider profile and clicks Express Interest or Request Connection. The system notifies the target organisation of the connection request, including the entrepreneur's business profile summary. The target organisation reviews the request on their dashboard and either accepts or declines. If accepted, the system creates a Connection Record linking both parties and notifying the entrepreneur. For partner connections, the administrator can facilitate the formalisation of the relationship by initiating an MoU or collaboration document through the system's document management interface. Both parties receive the draft, can annotate or comment, and confirm acceptance. The system stores the signed MoU against the connection record. For buyer connections, the entrepreneur can list their products or services in the system's Product and Market Catalogue, making them discoverable by buyers browsing the registry. Buyers can post market demand listings problems, tenders, or procurement needs that entrepreneurs can respond to. For service provider connections, the entrepreneur can book an advisory session directly from the service provider's profile, selecting from available time slots. The system confirms the booking, sends calendar notifications to both parties, and stores the session record. All connection activity requests made, accepted, declined, MoUs signed, sessions booked is logged against the entrepreneur's profile and feeds into the M&E module as partnership and market linkage indicators. The administrator monitors all connection activity through a linkage dashboard, which shows volume of connections made, sectors involved, geographic spread, and MoUs formalised, for programme reporting and M&E purposes. | | **Alternative flow** | A1 Connection Request Declined: The target organisation declines the request. The entrepreneur is notified with an optional reason. The declined request is logged but the entrepreneur may approach other organisations. A2 Organisation Not in Directory: If the entrepreneur cannot find a relevant partner or buyer, they can submit a recommendation for a new organisation to be added. The administrator reviews and adds it to the directory if appropriate. A3 Market Demand Listing Response: An entrepreneur responds to a buyer's posted market demand listing. The system notifies the buyer of the response, and the buyer can initiate a connection from there. A4 Service Provider Booking Cancelled: Either party cancels a booked advisory session. The system notifies the other party and the slot is released. The entrepreneur may rebook. A5 MoU Amendment: Either party requests an amendment to a signed MoU. The administrator facilitates a new version through the document interface. The original version is retained in the audit trail. | | **Post-condition** | **Success:** Connection records created between entrepreneur and partner, buyer, or service provider. MoUs formalised and stored against connection records where applicable. Product and market catalogue entries created and discoverable. Advisory session bookings confirmed and recorded. All connection activity logged against entrepreneur profile and passed to M&E module. Audit trail updated throughout. **Failure:** If a connection request is declined, no connection record is created. The request is logged as declined. If a directory organisation is unverified, it does not appear in search results until administrator verification is complete. | **Table 40****: **Requirements specifications for Market and Partner Linkage | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | Directory Management | FRSME-MPL001: The system shall allow the administrator to create, edit, and deactivate entries in the Partner Directory, Buyer/Off-taker Registry, and Service Provider Directory, capturing for each: organisation name, type, sector focus, geographic coverage, contact details, and areas of interest or service offering. | Organisation profile data | Directory entry created or updated; status set to Pending Verification; audit log entry created | Administrator | | | FRSME-MPL002: The system shall allow registered partners, buyers, and service providers to complete and update their own directory profiles through their respective dashboards, subject to administrator verification before the profile appears in search results. | Organisation self-submitted profile data | Profile saved as Pending Verification; administrator notified for review | Partner / Buyer / Service Provider | | | FRSME-MPL003: The system shall allow the administrator to verify or reject a directory profile submission, with rejection requiring a documented reason sent to the submitting organisation. | Administrator review decision, rejection reason if applicable | Profile status set to Verified or Rejected; submitting organisation notified; audit log entry created | Administrator | | Search & Matchmaking | FRSME-MPL004: The system shall provide keyword and advanced filter search across all three directories Partner, Buyer, and Service Provider filterable by sector, organisation type, geographic coverage, and service offering. | Search query, filter selections | Filtered directory results displayed ranked by relevance | Entrepreneur | | | FRSME-MPL005: The system shall generate AI-assisted connection recommendations for each entrepreneur based on their verified business profile sector, stage, location, and programme history surfacing the most relevant partners, buyers, and service providers on their dashboard without requiring manual search. | Entrepreneur business profile, programme history, directory records | Ranked recommendation list displayed on entrepreneur dashboard | System (automated), Entrepreneur | | | FRSME-MPL006: The system shall update AI-generated recommendations dynamically as the entrepreneur's profile is enriched through SP2, SP3, SP4, and SP5 activity. | Updated entrepreneur profile and activity data | Refreshed recommendation list reflecting current profile and progress | System (automated) | | Connection Request | FRSME-MPL007: The system shall allow an entrepreneur to express interest in or request a connection with a verified partner, buyer, or service provider, attaching a brief message and a summary of their business profile. | Entrepreneur profile summary, connection request message, target organisation | Connection request record created; target organisation notified via dashboard and email | Entrepreneur, System (automated) | | | FRSME-MPL008: The system shall prevent an entrepreneur from submitting a duplicate connection request to an organisation with whom an active or pending connection already exists. | Existing connection records, new request attempt | Duplicate request blocked; existing connection status displayed to entrepreneur | System (automated) | | Connection Acceptance | FRSME-MPL009: The system shall allow the target organisation to accept or decline a connection request from their dashboard, with a declined request requiring an optional reason. | Organisation decision, optional decline reason | Connection record created if accepted; entrepreneur notified; or request logged as Declined with reason; audit log entry created | Partner / Buyer / Service Provider, System (automated) | | | FRSME-MPL010: The system shall notify the entrepreneur immediately upon acceptance or decline of a connection request. | Connection decision | Notification dispatched to entrepreneur via dashboard and email | System (automated) | | MoU Facilitation | FRSME-MPL011: The system shall allow the administrator to initiate an MoU or collaboration document against an accepted connection record, uploading a draft document and making it accessible to both parties for review and comment. | Accepted connection record, draft MoU document | MoU draft stored against connection record; both parties notified and given access | Administrator | | | FRSME-MPL012: The system shall allow both parties to annotate and comment on an MoU draft within the system's document management interface, with all comments stored and versioned. | Annotations and comments from both parties | Comment records stored against MoU document; version history maintained | Entrepreneur, Partner Organisation | | | FRSME-MPL013: The system shall allow the administrator to upload the signed MoU and record the agreement as Formalised against the connection record upon confirmation from both parties. | Signed the MoU document, confirmation from both parties | Signed MoU stored against connection record; status set to Formalised; both parties notified; audit log entry created | Administrator | | Product & Market Catalogue | FRSME-MPL014: The system shall allow a verified entrepreneur to create product or service listings in the Market Catalogue, capturing: product/service name, description, sector, pricing, availability, and supporting media. | Product/service listing data, supporting media uploads | Listing published in Market Catalogue; discoverable by buyers browsing the registry | Entrepreneur | | | FRSME-MPL015: The system shall allow a verified buyer to post market demand listings, problems, tenders, or procurement needs that are visible to entrepreneurs whose business profiles match the demand criteria. | Demand listing data, sector, and geographic targeting criteria | Demand listing published and surfaced to matching entrepreneurs on their dashboards | Buyer / Off-taker | | | FRSME-MPL016: The system shall allow an entrepreneur to respond to a market demand listing, notifying the posting buyer and creating a response record linked to both the demand listing and the entrepreneur's profile. | Entrepreneur response, demand listing record | Response record created; buyer notified; response linked to entrepreneur profile | Entrepreneur, System (automated) | | Advisory Session Booking | FRSME-MPL017: The system shall allow an entrepreneur to book an advisory session with a connected service provider directly from the service provider's profile, selecting from available time slots displayed by the system. | Available time slots, session type selection, and booking request | Session booking confirmed; calendar notifications sent to entrepreneur and service provider; session record created | Entrepreneur, Service Provider | | | FRSME-MPL018: The system shall allow either party to cancel a booked advisory session, notifying the other party and releasing the slot for rebooking. | Cancellation action | Session record updated to Cancelled; other party notified; time slot released | Entrepreneur / Service Provider, System (automated) | | | FRSME-MPL019: The system shall allow the service provider to record session notes and mark a session as Completed, storing the record against the entrepreneur's connection history. | Session notes, completion confirmation | Session record updated with notes and Completed status; audit log entry created | Service Provider | | M&E Linkage Feed | FRSME-MPL020: The system shall trigger the M&E module to record a partnership or market linkage indicator each time a connection request is accepted, an MoU is formalised, a market demand listing is responded to, or an advisory session is completed. | Connection acceptance events, MoU formalisation events, session completion events | M&E tracking record updated with partnership and market linkage indicators; data available for SP6 reporting | System (automated), M&E Module | **Table 41**: SP4 Innovation Showcasing & Deal Management | **Use case name** | Innovation Showcasing & Deal Management | | --- | --- | | **Actor** | Administrator, Entrepreneur, Investor, Partner Organisation, Buyer, Judge/Evaluator, M&E Module | | **Description** | This use case describes how the SME Hub creates structured visibility moments for entrepreneur innovations through demo days, pitch events, innovation challenges, and virtual or physical showcases and how deal rooms are used to formalise agreements that emerge from those interactions. It is the commercialisation front door of the SME Hub: the moment where an entrepreneur's incubated, market-connected business is presented to the wider ecosystem of investors, partners, and buyers. It addresses the complete absence of any showcasing infrastructure in the current system, and the non-operational status of the judging and scoring tools that are needed to run competitive innovation challenges. | | **Pre-condition** | The administrator is logged in with event management rights. The entrepreneur has a verified business profile and at least one innovation or product listed in their profile. Investors, partners, and buyers are registered in the system and can browse the Innovation Showcase. | | **Main success scenario** | The administrator navigates to Innovation Showcasing & Deal Management and selects Create Showcase Event or Launch Innovation Challenge. For a Showcase Event demo day, pitch event, or virtual/physical exhibition the administrator defines the event name, format (virtual, physical, or hybrid), date, target sectors, eligibility criteria for participating entrepreneurs, and the judging or evaluation panel if awards are involved. For an Innovation Challenge or Call, the administrator follows the same call setup process used in SP2 (incubation calls), defining eligibility, application requirements, judging rubric, and timeline. The system reuses the call management infrastructure, keeping the process consistent. The system publishes the event or challenge and notifies eligible entrepreneurs through their dashboards and by email. The eligible entrepreneur applies to participate submitting their business profile, innovation description, product/service details, traction data, and any required pitch materials or documents. The system auto-saves progress and validates completeness on submission. The administrator reviews applications and confirms the list of participating entrepreneurs. Confirmed participants are notified with event logistics, schedules, and preparation guidelines. The entrepreneur's innovation or product is listed in the system's Innovation Showcase a discoverable catalogue of innovations available to investors, partners, and buyers browsing the platform. The event or challenge takes place. For virtual events, the system provides integrated video conferencing links. The administrator and facilitators record attendance, pitch scores where applicable, and event outcomes through the system. Following the event, the administrator opens Deal Rooms structured private negotiation spaces between interested parties (investors, partners, buyers) and specific entrepreneurs. Each Deal Room is linked to the entrepreneur's business and innovation profile. Within the Deal Room, both parties can exchange documents, proposals, term sheets, and messages in a structured, documented environment. The system maintains a full message and document history for each Deal Room. When both parties reach agreement, the administrator facilitates formalisation uploading a signed agreement or MoU to the Deal Room. The agreement is stored against the entrepreneur's profile and the connection record. The system notifies the M&E module of the showcase participation, deal room creation, and any signed agreements recording these as commercialisation and deal-making indicators in the entrepreneur's M&E tracking record. | | **Alternative flow** | A1 Entrepreneur Application Not Selected: The administrator does not select an entrepreneur for the event. The entrepreneur is notified. Their innovation remains in the Showcase Catalogue for ongoing discoverability. A2 Virtual Event Technical Failure: If the integrated video link fails, the administrator can reschedule the session or provide an alternative link. The event record is retained. A3 Deal Room Expired Without Agreement: If no agreement is reached within the Deal Room's defined timeframe, the administrator can extend the room or close it. The exchange history is retained for audit purposes. A4 Multiple Interested Parties: An entrepreneur may have more than one Deal Room open simultaneously with different investors or partners. Each Deal Room is independent and managed separately. A5 Challenge Winner Selection: For scored innovation challenges, the system ranks entries by judge scores and the administrator confirms winners. Winners receive system-generated recognition certificates and their profiles are flagged as Challenge Winner. | | **Post-condition** | **Success:** Showcase event or challenge record created, published, and archived. Entrepreneur innovation profile published in the Innovation Showcase catalogue. Event attendance, pitch scores, and outcomes recorded. Deal Rooms created with full exchange history and signed agreements stored. M&E module updated with showcase participation, deal creation, and agreement indicators. Audit trail maintained throughout. **Failure:** If a deal room exchange produces no agreement, the history is retained but no agreement record is created. If an entrepreneur is not selected for a showcase, their innovation catalogue entry remains active. No application, pitch, or deal room data is permanently lost. | **Table 42: ** Innovation Showcasing and Deal Management use case narrative | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | Event / Challenge Setup | FRSME-ISD001: The system shall allow the administrator to create a Showcase Event record defining event name, format (virtual, physical, or hybrid), date, target sectors, eligibility criteria for participating entrepreneurs, and an evaluation panel where awards are involved. | Event configuration data | Showcase Event record created as Draft; audit log entry created | Administrator | | | FRSME-ISD002: The system shall allow the administrator to create an Innovation Challenge using the same call management infrastructure as SP2, defining eligibility, application requirements, judging rubric, and timeline. | Challenge configuration data, judging rubric | Innovation Challenge record created as Draft; scoring rubric stored against challenge record | Administrator | | | FRSME-ISD003: The system shall publish a Showcase Event or Innovation Challenge and dispatch notifications to eligible entrepreneurs whose business profiles match the defined eligibility criteria. | Published event or challenge record, entrepreneur profile data | Status set to Published; notifications dispatched to matching entrepreneurs via dashboard and email | System (automated) | | Participation Application | FRSME-ISD004: The system shall allow eligible entrepreneurs to apply to participate in a published Showcase Event or Innovation Challenge, submitting their business profile, innovation description, product details, traction data, and required pitch materials. | Application form data, uploaded pitch materials | Application record created with unique Application ID; auto-save active; status set to Draft | Entrepreneur, System (automated) | | | FRSME-ISD005: The system shall validate completeness of mandatory application fields and required document uploads on submission, blocking submission with inline errors until all requirements are met. | Application form, mandatory field definitions, required document list | Validation pass or field-level error indicators; submission blocked if incomplete | System (automated) | | | FRSME-ISD006: The system shall prevent application submission after the event or challenge deadline and display a clear deadline-expired message. | Application submission attempt, event deadline | Submission blocked; deadline-expired message displayed | System (automated) | | Participant Selection | FRSME-ISD007: The system shall allow the administrator to review submitted applications and confirm the participant list for a Showcase Event, notifying confirmed participants with event logistics and non-selected applicants with their outcome. | Submitted applications, administrator selection decisions | Confirmed participant list created; notifications dispatched to all applicants | Administrator, System (automated) | | | FRSME-ISD008: The system shall use the same judge scoring workflow as SP2 for Innovation Challenges assigning applications to judges, collecting weighted scores, calculating ranked averages, and surfacing the ranked list to the administrator for final selection. | Applications, judge assignments, scoring rubric | Judge scores recorded; weighted averages calculated; ranked list displayed to administrator | Judge, System (automated), Administrator | | Innovation Catalogue | FRSME-ISD009: The system shall publish each confirmed participant's innovation or product as an entry in the Innovation Showcase Catalogue a discoverable directory of innovations accessible to investors, partners, and buyers browsing the platform. | Business profile, innovation name, description, sector, stage, product or service details | Innovation Catalogue entry published; discoverable by investors, partners, and buyers | Entrepreneur, System (automated) | | | FRSME-ISD010: The system shall allow an entrepreneur to update their Innovation Catalogue entry at any time to reflect current product status, traction, and supporting materials, subject to the entry remaining published. | Updated innovation details | Innovation Catalogue entry updated; version history maintained | Entrepreneur | | Event Delivery & Scoring | FRSME-ISD011: The system shall provide integrated video conferencing links for virtual or hybrid Showcase Events, generated and distributed to confirmed participants and evaluators through the system. | Event record, confirmed participant list, evaluator list | Video conferencing links generated and distributed; access log maintained | System (automated), Administrator | | | FRSME-ISD012: The system shall allow the administrator or facilitator to record attendance against each confirmed participant during or after an event. | Participant list, attendance confirmation | Attendance records stored against event record; non-attendance flagged | Administrator | | | FRSME-ISD013: The system shall allow evaluators to score pitches during a Showcase Event using a configurable scoring form, with scores stored against each entrepreneur's event participation record. | Evaluator scores, scoring form configuration | Pitch scores recorded per entrepreneur; event scoring record stored | Evaluator / Judge | | Deal Room Creation | FRSME-ISD014: The system shall allow the administrator to open a Deal Room between an entrepreneur and an interested party investor, partner, or buyer following a Showcase Event or Innovation Challenge, linking the Deal Room to the entrepreneur's business and innovation profile. | Entrepreneur profile, interested party profile, administrator action | Deal Room created; both parties notified; Deal Room linked to the entrepreneur and business records | Administrator | | | FRSME-ISD015: The system shall assign a unique Deal Room ID to each Deal Room and set its status to Open upon creation. | Deal Room creation action | Unique Deal Room ID assigned; status set to Open; creation timestamp recorded; audit log entry created | System (automated) | | | FRSME-ISD016: The system shall allow the administrator to set an expiry date on a Deal Room, after which the room is automatically closed if no agreement has been formalised, with both parties notified. | Deal Room expiry date configuration | Deal Room status set to Expired on expiry date if no agreement recorded; both parties notified | System (automated), Administrator | | Deal Room Exchange | FRSME-ISD017: The system shall allow both parties within a Deal Room to exchange documents, proposals, term sheets, and messages in a structured, threaded interface, with all exchanges stored and versioned. | Documents, proposals, term sheets, messages | Full exchange history stored in Deal Room; version history maintained for all documents | Entrepreneur, Investor / Partner / Buyer | | | FRSME-ISD018: The system shall notify both parties of any new message or document upload within their Deal Room via dashboard notification and email. | New exchange activity in Deal Room | Notification dispatched to the other party; notification log stored | System (automated) | | Agreement Formalisation | FRSME-ISD019: The system shall allow the administrator to upload a signed agreement or MoU to a Deal Room upon confirmation from both parties, setting the Deal Room status to Agreement Reached and storing the document against the entrepreneur's profile and the connection record. | Signed agreement document, confirmation from both parties | Signed agreement stored in Deal Room and against the entrepreneur profile; Deal Room status set to Agreement Reached; both parties notified; audit log entry created | Administrator | | M&E Commercialisation Feed | FRSME-ISD020: The system shall trigger the M&E module to record commercialisation indicators upon: showcase event participation confirmed, Innovation Challenge entry ranked or awarded, Deal Room opened, and agreement formalised, passing the relevant event and entrepreneur identifiers. | Showcase participation, challenge outcome, Deal Room creation, agreement formalisation events | M&E tracking record updated with commercialisation and deal-making indicators; data available for SP6 reporting | System (automated), M&E Module | **Table 43**: SP5 Investment & Funding Access | **Use case name** | Investment & Funding Access | | --- | --- | | **Actor** | Entrepreneur, Administrator, Investor, Funder/Donor, M&E Module | | **Description** | This use case describes how the SME Hub connects entrepreneurs with investors and funding opportunities through a maintained investor and funder database, published funding calls, AI-assisted investor-entrepreneur matchmaking, SME performance dashboards for due diligence, and deal room facilitation for funding negotiations. | | **Pre-condition** | The entrepreneur is registered, verified, and has a complete business profile (SP1 complete). The Investor and Funder Database is populated with verified investor and funder profiles. The entrepreneur's SME Performance Dashboard has data populated from SP1 through SP4 baseline, incubation, market linkage, and showcasing history. Funding calls are published and active where applicable. | | **Main success scenario** | The administrator manages the Investor and Funder Database a registry of investors (angel investors, venture capital, development finance institutions) and funders (donors, foundations, government programmes) registered in the system. Each entry captures organisation name, type, investment focus, geographic preference, ticket size, and contact details. The administrator publishes Funding Calls and Grant Listings in the system covering seed funding, proof-of-concept grants, growth capital, and challenge fund opportunities. Each listing includes eligibility criteria, funding amount, application requirements, and deadline. The system notifies eligible entrepreneurs of new funding opportunities based on their business profile sector, stage, location, and performance data resolving the current gap where entrepreneurs only learn of opportunities informally. The entrepreneur browses the Funding Opportunities section of their dashboard, views available investor profiles and funding calls, and selects those relevant to their business stage and needs. For Funding Calls with a formal application process, the entrepreneur submits an application, business plan, financial projections, funding request details, and supporting documents. The system manages the application workflow using the same process as SP2 (call management infrastructure), ensuring consistency. For direct Investor Matching, the system presents the entrepreneur with a ranked list of investors whose focus, ticket size, and geographic preference align with their business profile and stage. This matching is driven by the structured profile data captured in SP1 and the progress data accumulated through SP2, SP3, and SP4. The entrepreneur's SME Performance Dashboard, automatically compiled from their SP1 baseline, SP2 programme completion, SP3 connections, and SP4 deals, is made available to investors conducting due diligence. This dashboard shows: business stage and growth trajectory, training and incubation completed, partnerships formed, market connections made, deals closed, jobs created, and revenue progression. The entrepreneur sends a connection or pitch request to a matched investor through the system. The investor receives the request along with access to the entrepreneur's performance dashboard. The investor reviews the entrepreneur's profile and dashboard, and either accepts the connection, opening a Deal Room, or declines with an optional reason. Funding outcomes applications submitted, investor connections made, and funding secured are recorded in the system and passed to the M&E module as investment and financing indicators, completing the entrepreneur's journey data from baseline (SP1) through to capital raised. | | **Alternative flow** | A1 Funding Call Application Unsuccessful: The entrepreneur is notified of the outcome. Their application record and performance dashboard remain intact for future funding pursuits. A2 Investor Declines Connection: The entrepreneur is notified. The system logs the declined request, and the entrepreneur may approach other matched investors. A3 Entrepreneur Not Yet Investment-Ready: The system flags an entrepreneur whose performance dashboard does not yet meet typical investor thresholds and recommends further SP2 or SP3 engagement before applying for investment. A4 New Investor Registration: An investor self-registers through the system's investor onboarding flow. The administrator verifies the investor profile before it appears in the matching engine. A5 Funding Secured Outside System: Where an entrepreneur secures funding through a channel not managed in the system (e.g. a personal connection), the administrator can manually record the funding event against the entrepreneur's profile to ensure the M&E record is complete. | | **Post-condition** | **Success:** Investor and funder profiles maintained and verified in the database. Funding calls published and matched entrepreneurs notified. Funding applications submitted and managed through the call workflow. Investor-entrepreneur matches surfaced and connection requests processed. SME Performance Dashboards compiled and shared for due diligence. Deal Rooms opened for accepted investor connections. Funding outcomes recorded against entrepreneur profiles and passed to the M&E module. Audit trail updated throughout. **Failure:** If a funding application is unsuccessful, the record is retained with the outcome noted. If an investor declines a connection, no Deal Room is created. The declined request is logged. No funding application or investor connection data is permanently lost. | **Table 44**: SP5 Investment & Funding Access | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | Investor & Funder Database | FRSME-INV001: The system shall allow the administrator to create, edit, and deactivate entries in the Investor and Funder Database, capturing: organisation name, type (angel investor, venture capital, development finance institution, donor, foundation, government programme), investment focus, geographic preference, ticket size range, and contact details. | Investor/funder profile data | Database entry created or updated; audit log entry created | Administrator | | | FRSME-INV002: The system shall allow investors and funders to self-register and complete their profiles through a dedicated onboarding flow, subject to administrator verification before the profile is activated in the matching engine. | Self-submitted investor/funder profile data | Profile saved as Pending Verification; administrator notified | Investor / Funder | | | FRSME-INV003: The system shall allow the administrator to verify or reject an investor/funder profile, with rejection requiring a documented reason communicated to the applicant. | Administrator review decision | Profile status set to Verified or Rejected; applicant notified; audit log entry created | Administrator | | Funding Call Publication | FRSME-INV004: The system shall allow the administrator to publish Funding Call and Grant Listing records covering seed funding, proof-of-concept grants, growth capital, and challenge fund opportunities using the same call management infrastructure as SP2, with eligibility criteria, funding amount, application requirements, and deadline defined. | Funding call configuration data | Funding call published; eligible entrepreneur notifications dispatched based on business profile matching | Administrator, System (automated) | | | FRSME-INV005: The system shall automatically notify entrepreneurs whose verified business profiles match the eligibility criteria of a newly published funding call, resolving the current gap where entrepreneurs only learn of opportunities informally. | Published funding call, entrepreneur profile data | Targeted notifications dispatched to matching entrepreneurs via dashboard and email | System (automated) | | Funding Application | FRSME-INV006: The system shall allow eligible entrepreneurs to submit funding applications capturing business plan, financial projections, funding request amount, and supporting documents managed through the same application workflow as SP2. | Application form data, uploaded documents | Application record created and managed through call workflow; confirmation sent to the entrepreneur | Entrepreneur, System (automated) | | | FRSME-INV007: The system shall notify the entrepreneur of their funding application outcome, successful or unsuccessful, with a reason provided for unsuccessful outcomes. | Application review decision, outcome reason | Notification dispatched to the entrepreneur; application record updated with outcome and reason | System (automated), Administrator | | Investor Matchmaking | FRSME-INV008: The system shall generate a ranked list of matched investors for each entrepreneur based on alignment between the entrepreneur's business sector, stage, location, and performance data (from SP1–SP4) and each investor's investment focus, ticket size preference, and geographic coverage. | Entrepreneur business profile and performance data, investor database records | The ranked investor match list is displayed on the entrepreneur dashboard | System (automated) | | | FRSME-INV009: The system shall refresh investor match recommendations dynamically as the entrepreneur's performance data is updated through SP2, SP3, SP4, and SP5 activity, ensuring recommendations reflect current business maturity. | Updated entrepreneur performance data | Refreshed investor match list | System (automated) | | | FRSME-INV010: The system shall flag an entrepreneur as Not Yet Investment-Ready on the matchmaking dashboard if their SME Performance Dashboard data does not meet configurable minimum thresholds, recommending specific SP2 or SP3 actions to strengthen their profile before pursuing investment. | Entrepreneur performance data, investment-readiness threshold configuration | Investment-readiness flag displayed; recommended actions surfaced on the dashboard | System (automated) | | SME Performance Dashboard | FRSME-INV011: The system shall compile and display an SME Performance Dashboard for each entrepreneur, automatically aggregating data from: SP1 baseline (stage, employees, revenue at entry), SP2 (programmes completed, training, mentorship sessions), SP3 (connections made, MoUs signed), SP4 (showcases participated in, deals closed), and SP5 (funding applications, investment secured). | SP1–SP5 data for the entrepreneur | SME Performance Dashboard compiled and displayed on the entrepreneur profile | System (automated) | | | FRSME-INV012: The system shall make the SME Performance Dashboard accessible to a matched investor during due diligence review, upon acceptance of a connection request, displaying: business stage and growth trajectory, incubation history, partnerships formed, market connections, deals closed, jobs created, and revenue progression. | Investor connection acceptance, entrepreneur performance dashboard | Performance dashboard shared with investor in read-only view; access log recorded | System (automated), Investor | | Investor Connection Request | FRSME-INV013: The system shall allow an entrepreneur to send a connection or pitch request to a matched investor through the system, attaching a summary of their business profile and a link to their SME Performance Dashboard. | Entrepreneur profile summary, performance dashboard link, connection request | Connection request sent to investor; investor notified via dashboard and email | Entrepreneur, System (automated) | | | FRSME-INV014: The system shall allow the investor to accept or decline an entrepreneur's connection request, with a declined request requiring an optional reason communicated to the entrepreneur. | Investor decision, optional decline reason | Connection record created if accepted and Deal Room opened as per SP4; or request logged as Declined with reason; entrepreneur notified | Investor, System (automated) | | Deal Room (Investment) | FRSME-INV015: The system shall open a Deal Room between the entrepreneur and investor upon connection acceptance, using the same Deal Room infrastructure as SP4, providing a structured environment for exchanging investment proposals, term sheets, and due diligence documents. | Accepted investor connection, entrepreneur, and investor profiles | Deal Room created and linked to the entrepreneur and investor records; both parties were notified | System (automated), Administrator | | Manual Funding Record | FRSME-INV016: The system shall allow the administrator to manually record a funding event against an entrepreneur's profile capturing funder name, funding type, amount, and date where funding was secured through a channel not managed within the system, ensuring M&E completeness. | Manual funding event data entered by administrator | Funding event record stored against entrepreneur profile; flagged as manually entered in audit trail | Administrator | | M&E Investment Feed | FRSME-INV017: The system shall trigger the M&E module to record investment and financing indicators upon: funding application submitted, funding application outcome confirmed, investor connection accepted, Deal Room opened, and funding secured, passing the relevant entrepreneur, funder, and amount identifiers. | Investment activity events from SP5 | M&E tracking record updated with investment and financing indicators; entrepreneur journey data complete from baseline (SP1) through to capital raised | System (automated), M&E Module | **Table 45**: SP6 Monitoring, Learning & Impact | **Use case name** | Monitoring, Learning & Impact | | --- | --- | | **Actor** | M&E Officer, Administrator, Programme Officer, Donor, RUFORUM Management, Entrepreneur (as feedback provider) | | **Description** | This use case describes how the SME Hub's Monitoring, Learning & Impact subprocess operates as a continuous, cross-cutting data collection, analysis, and reporting layer running across all other subprocesses (SP1–SP5). | | **Pre-condition** | The M&E results hierarchy and indicator targets have been configured for the relevant programme or cohort. The SME Hub subprocesses SP1–SP5 are operational and generating structured data that feeds into the M&E module. iii. The M&E Officer has appropriate role-based access to the M&E dashboard and reporting tools. | | **Main success scenario** | The M&E module automatically initialises a tracking record for each entrepreneur at the point of business verification and AIH affiliation in SP1, capturing the baseline: date of entry, business stage, employee count, revenue range, and geographic location. This is the starting point against which all subsequent progress is measured. As the entrepreneur moves through SP2 (incubation), SP3 (market linkage), SP4 (showcasing), and SP5 (investment), the M&E module continuously receives structured data feeds from each subprocess training completions, mentorship sessions, partnerships formed, deals signed, funding secured automatically updating the entrepreneur's tracking record without requiring manual data entry from programme staff. The M&E Officer navigates to the M&E Dashboard and views the SME Hub results hierarchy structured from Impact level (jobs created, enterprises sustained, community benefits) down to Outcome level (entrepreneurs completing incubation, businesses reaching market), Output level (training programmes delivered, partnerships formed, deals closed), and Activity level (sessions conducted, calls published, showcases held). The M&E Officer reviews indicator performance against defined targets for example, number of verified businesses registered, percentage of incubated businesses reaching the market linkage stage, number of investment deals closed, total jobs created across the portfolio using real-time dashboards with drill-down capability by cohort, sector, AIH, country, or time period. The M&E Officer identifies entrepreneurs or businesses whose progress has stalled for example, those who completed SP2 but have not yet engaged with SP3. The system surfaces these gaps automatically through progress tracking flags, enabling proactive follow-up rather than retrospective reporting. The administrator uses the system's reporting tools to generate structured donor reports automatically compiled from the M&E tracking records, showing inputs, outputs, outcomes, and impact indicators in the format required by the programme's results framework. Beneficiary feedback is collected through the system at defined points in the entrepreneur journey post-incubation, post-connection, and post-deal through configurable survey tools. Feedback responses are stored against the entrepreneur's record and aggregated for programme improvement analysis. The M&E module generates periodic Learning Reports synthesising patterns across the portfolio: which sectors are producing the most market-ready businesses, which AIHs have the highest completion rates, which types of partnerships lead to the highest deal conversion, and which bottlenecks are causing entrepreneurs to disengage. These insights inform RUFORUM's programme design and investment priorities. The M&E Officer can export any report, dashboard view, or data subset to standard formats for external sharing with donors, partners, and RUFORUM management. | | **Alternative flow** | A1 Manual Data Entry: Where an indicator cannot be automatically captured from system activity, for example, a business milestone achieved offline, The M&E Officer manually enters the data point against the relevant entrepreneur record. The manual entries are flagged as such in the audit trail. A2 Indicator Target Revision: If programme targets need to be revised mid-cycle (e.g., due to external factors), The M&E Officer can update targets in the results hierarchy. The system logs the revision with the reason and date, preserving the original target for audit purposes. A3 Feedback Survey Non-Response: If an entrepreneur does not complete a feedback survey within the defined response window, the system sends a reminder. Non-responses are recorded, and the non-response rate is tracked as a data quality indicator. A4 Cross-System Reporting: The M&E module can draw data not only from the SME Hub subprocesses but also from RIMS (funded programme participation), E-Learning (course completions), and the Repository (research outputs linked to incubated businesses), enabling truly integrated impact reporting across the full RUFORUM ecosystem. | | **Post-condition** | **Success:** Entrepreneur tracking records are maintained with real-time data from all SME Hub subprocesses. Results hierarchy and indicator targets configured and monitored against actuals. Progress stalling flagged automatically for administrator follow-up. Donor reports generated automatically from consolidated M&E records. Beneficiary feedback collected, stored, and aggregated. Learning reports generated to inform programme design. All M&E data exportable in standard formats. Audit trail updated throughout. **Failure:** If automated data feeds from a subprocess fail, the M&E module flags the gap and allows manual entry to maintain record completeness. If a feedback survey is not completed, the non-response is recorded as a data quality flag, not a system error. No M&E data is permanently lost. | **Table xxx: SP6 Monitoring, Learning ****&**** Impact** | **Sub-Process Name** | **Functional Requirement** | **Inputs** | **Outputs** | **Person Concerned** | | --- | --- | --- | --- | --- | | Baseline Initialisation | FRSME-MEI001: The system shall automatically initialise an M&E tracking record for each entrepreneur at the point of business verification and AIH affiliation in SP1, capturing: date of entry, business stage, full-time employee count, part-time employee count, estimated revenue range, sector, and geographic location as the baseline snapshot. | Verified business profile and AIH affiliation data from SP1 | M&E tracking record initialised; baseline snapshot stored with timestamp; audit log entry created | System (automated), M&E Module | | | FRSME-MEI002: The system shall prevent an entrepreneur from progressing to programme applications (SP2) if their M&E baseline record has not been successfully initialised, flagging the gap for administrator resolution. | SP1 completion status, M&E tracking record status | Programme application access blocked if baseline absent; administrator notified | System (automated) | | Subprocess Data Feeds | FRSME-MEI003: The system shall receive and process structured data feeds from SP2 upon each of the following events: application submitted, cohort selected, E-Learning course completed, mentorship session completed, and programme complete updating the entrepreneur's M&E tracking record at each milestone. | SP2 milestone event triggers | M&E tracking record updated with SP2 milestone data; longitudinal progress data maintained | System (automated), M&E Module | | | FRSME-MEI004: The system shall receive and process structured data feeds from SP3 upon each of the following events: connection request accepted, MoU formalised, market demand listing responded to, and advisory session completed, recording these as partnership and market linkage indicators in the entrepreneur's M&E tracking record. | SP3 event triggers | M&E tracking record updated with SP3 partnership and market linkage indicators | System (automated), M&E Module | | | FRSME-MEI005: The system shall receive and process structured data feeds from SP4 upon each of the following events: showcase participation confirmed, innovation challenge entry ranked or awarded, Deal Room opened, and agreement formalised, recording these as commercialisation indicators. | SP4 event triggers | M&E tracking record updated with SP4 commercialisation indicators | System (automated), M&E Module | | | FRSME-MEI006: The system shall receive and process structured data feeds from SP5 upon each of the following events: funding application submitted, funding outcome confirmed, investor connection accepted, and funding secured recording these as investment and financing indicators. | SP5 event triggers | M&E tracking record updated with SP5 investment indicators; entrepreneur journey record complete from baseline to capital raised | System (automated), M&E Module | | | FRSME-MEI007: The system shall flag any failed subprocess data feed for administrator review, allowing the M&E Officer to manually enter the missing data point with a mandatory reason recorded in the audit trail. | Failed data feed notification, manual entry data | Failed feed flagged on M&E dashboard; manual entry recorded and flagged as manually entered | System (automated), M&E Officer | | Results Hierarchy Management | FRSME-MEI008: The system shall allow the M&E Officer to configure the Results Hierarchy for a programme, defining Impact, Outcome, Output, and Activity level statements, linking indicators to each level, and setting baseline values and annual and end-of-programme targets. | Results hierarchy statements, indicator definitions, baseline values, targets | Results Hierarchy stored in M&E module; Indicator Reference Sheets generated; audit log entry created | M&E Officer | | | FRSME-MEI009: The system shall validate logical linkage within the Results Hierarchy requiring each Output to be linked to an Outcome and each Outcome to be linked to the Impact and block saving of an incomplete hierarchy. | Results hierarchy data, linkage validation rules | Validation pass or linkage error displayed; save blocked if hierarchy is incomplete | System (automated) | | | FRSME-MEI010: The system shall allow the M&E Officer to revise indicator targets mid-cycle, logging the revision with the original target, new target, reason, and date, preserving the original for audit and donor reporting purposes. | Revised target values, revision reason | Revised targets stored; original targets retained in version history; audit log entry created | M&E Officer | | Indicator Monitoring | FRSME-MEI011: The system shall provide a real-time M&E dashboard displaying indicator performance against configured targets, with drill-down capability by cohort, sector, AIH, country, and time period. | Entrepreneur M&E tracking records, results hierarchy targets | Real-time indicator performance dashboard displayed; drill-down views available | M&E Officer, Administrator | | | FRSME-MEI012: The system shall automatically flag entrepreneurs or businesses whose progress has stalled, defined as no M&E tracking record update within a configurable number of days since their last milestone and surface these flags on the administrator and M&E Officer dashboards. | M&E tracking record timestamps, stall threshold configuration | Progress stalling flags displayed on dashboard; administrator and M&E Officer notified | System (automated) | | | FRSME-MEI013: The system shall display a portfolio-level summary on the M&E dashboard showing aggregate indicators across all active programmes including total businesses registered, total incubation completions, total partnerships formed, total deals closed, total jobs created, and total funding secured. | Aggregated M&E tracking data across all entrepreneurs and programmes | Portfolio-level summary dashboard displayed | M&E Officer, RUFORUM Management | | Donor Reporting | FRSME-MEI014: The system shall allow the M&E Officer to generate a structured donor report for a specified programme and reporting period, automatically compiled from consolidated M&E tracking records and formatted against the programme's results framework. | Programme selection, reporting period, results framework, M&E tracking data | Donor report generated; exportable to PDF, Word, and Excel formats | M&E Officer | | | FRSME-MEI015: The system shall allow the M&E Officer to configure report templates defining which indicators, narrative sections, and visualisations appear in a report and save templates for reuse across reporting cycles. | Report template configuration | Report template stored; available for selection in report generation | M&E Officer | | | FRSME-MEI016: The system shall log all report generation actions, recording the user, report type, programme, reporting period, and generation timestamp in the audit trail. | Report generation action | Audit log entry created; report generation history accessible to authorised users | System (automated) | | Beneficiary Feedback | FRSME-MEI017: The system shall allow the M&E Officer to configure feedback surveys, defining questions, response types, and trigger events (post-incubation, post-connection, post-deal) at which the system automatically dispatches surveys to the relevant entrepreneurs. | Survey configuration, trigger event definitions | Survey stored and activated; dispatched to entrepreneurs upon trigger event | M&E Officer, System (automated) | | | FRSME-MEI018: The system shall store all submitted survey responses against the entrepreneur's M&E record and aggregate responses across the portfolio for programme improvement analysis. | Submitted survey responses | Responses stored against entrepreneur record; aggregate analysis available on M&E dashboard | System (automated), M&E Officer | | | FRSME-MEI019: The system shall send automated reminders to entrepreneurs who have not completed a feedback survey within a configurable response window, and record non-responses as a data quality indicator in the M&E tracking record. | Survey dispatch records, response window configuration, current date | Reminder sent to non-responding entrepreneurs; non-response rate tracked as data quality metric | System (automated) | | Learning Report | FRSME-MEI020: The system shall generate periodic Learning Reports synthesising portfolio-wide patterns including sector performance, AIH completion rates, partnership-to-deal conversion rates, and entrepreneur dropout analysis with configurable parameters for programme, cohort, time period, and geographic scope. | Portfolio-wide M&E tracking data, report parameter selections | Learning Report generated; exportable to standard formats | M&E Officer, RUFORUM Management | | Cross-System Reporting | FRSME-MEI021: The system shall draw data from the RIMS module (funded programme participation), E-Learning module (course completions), and Repository module (research outputs linked to incubated businesses) in addition to SME Hub SP1–SP5 data to enable integrated impact reports covering the full RUFORUM ecosystem journey from funding to enterprise creation. | RIMS, E-Learning, Repository, and SME Hub module data | Integrated cross-system impact report generated; exportable to standard formats | M&E Officer, RUFORUM Management | | | FRSME-MEI022: The system shall log all M&E data entries, indicator updates, report generations, target revisions, and feedback submissions in the audit trail capturing user ID, action type, timestamp, and where applicable the previous and new values. | All M&E module user actions | Audit trail entries stored; accessible to authorised users | System (automated) | ## M&E and feedback (MFL) ### Module Description The module will consist of the following submodules - **Results hierarchy management**: This is a continuous process of planning, tracking, and managing the causal chain of an intervention from inputs to impact to ensure that project activities lead to intended, measurable changes for beneficiaries. It focuses on achieving outcomes rather than just tracking activities.  - **Indicator management**: This involves outlining specific quantitative and qualitative metrics, also known as indicators, to measure progress, performance, and impact - **Reporting and Compliance**: Generates real-time reports, tracks budgets, and provides an audit trail for accountability and compliance. - **Data entry and validation: **This is the process of inputting raw data into a digital system, while data validation checks the quality and accuracy of this data against predefined rules. The validation process starts with setting the rules - **Reporting and visualization: **Involves transforming collected and analysed data into clear, actionable information for stakeholders. This process consolidates data from activity tracking, output monitoring, outcome assessment, and financial management, linking it to the results hierarchy to demonstrate how project inputs and activities contribute to outputs, outcomes, and long-term impact. Reports are generated in various formats, including dashboards, charts, graphs, tables, and narrative summaries, highlighting performance trends, variances, and key achievements. Visualization enhances understanding by presenting complex data in intuitive ways, allowing stakeholders to quickly grasp progress, identify areas of concern, and making evidence-based decisions. The process also ensures transparency and accountability by maintaining an audit trail of reported data, facilitating real-time monitoring, and supporting communication with donors, project managers, and other key actors. ### Use-case narratives **Table 46**: Use Case for result hierarchy management | **Use Case Element** | **Description** | | --- | --- | | **Use Case Name** | Results Hierarchy Management | | **Actors** | M&E Officer, Project Manager, Program Staff, Beneficiaries, Donors/Stakeholders | | **Preconditions** | Project objectives and activities defined; indicators for outputs, outcomes, and impact identified; baseline data available. | | **Triggers** | Initiation of a project phase, need for performance tracking, or scheduled M&E reporting period. | | **Normal flow** | **Conduct results planning ** Identify the long-term change the project seeks to achieve. Clarify impact indicators to measure progress toward these goals. Align impact with organizational strategy, donor requirements, or sustainable development objectives. Identify Expected Outcomes Specify short- to medium-term changes expected as a result of the project. Make outcomes SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Link each outcome to the corresponding impact it contributes toward. Determine Outputs Define tangible deliverables or services produced by project activities. Outputs are typically direct results of project implementation, such as reports, trainings conducted, or infrastructure built. Ensure each output clearly contributes to one or more outcomes. Outline Activities List the actions or tasks that will generate the outputs. Include timelines, resources, responsible staff, and dependencies. Activities should be directly linked to specific outputs. Define Inputs Identify resources needed to perform activities: funding, staff, equipment, materials, and technical expertise. Inputs are the foundation of the results chain—they enable activities to happen. Establish Logical Links Map causal relationships: Inputs → Activities → Outputs → Outcomes → Impact. Ensure the hierarchy demonstrates how project actions lead to measurable change. Validate that each step contributes to achieving the higher-level objectives. Define Indicators For each level (output, outcome, impact), determine quantitative or qualitative indicators to measure progress. Ensure indicators are measurable and feasible to track in the M&E system. Set Baselines and Targets Collect baseline data to understand starting points. Set performance targets for each indicator over the project timeline. Document and Review Record the results hierarchy in the M&E system for transparency and traceability. Review with stakeholders to confirm alignment with project goals and feasibility. Integration into Monitoring System Configure the M&E system to track activities, outputs, outcomes, and impacts according to the hierarchy. Enable automated reporting, alerts, and performance visualization **Indicator Definition and Target Setting ( Identify measurable indicators and set performance targets)** Review Project Objectives and Results Hierarchy to understand which objectives need measurable evidence of progress. Identify Key Areas for Measurement Determine what aspects of performance or outcomes need to be tracked. Focus on indicators that reflect change or results, not just activity completion. Define Indicators Specify quantitative and qualitative metrics that will measure progress toward outputs, outcomes, and impact. Ensure each indicator is SMART: Specific – clearly defined Measurable – can be quantified or assessed qualitatively Achievable – realistic given resources and data collection capacity Relevant – aligned with objectives Time-bound – tracked over a defined timeframe Determine Data Sources Identify where and how data will be collected (e.g., surveys, administrative records, field reports, observations). Assign responsibility for data collection to specific staff or units. Define Calculation Method and Units Specify how the indicator will be calculated. Define the unit of measurement (e.g., number of beneficiaries, percentage change, qualitative rating). Set Baselines Collect baseline data to understand the starting point for each indicator. Baseline provides a reference for measuring progress. Set Targets Determine expected performance or results at specific time intervals (monthly, quarterly, annually). Targets should reflect realistic, evidence-based expectations aligned with project objectives. Validate Indicators Review indicators with stakeholders and experts to ensure relevance, feasibility, and clarity. Make adjustments if indicators are not measurable or don’t capture meaningful change. Document Indicators and Targets Enter the defined indicators, data sources, baselines, and targets into the M&E system. Include metadata such as the responsible person, collection frequency, and verification method. Integrate into Monitoring & Reporting Ensure indicators are linked to reporting templates, dashboards, and analysis workflows in the M&E system. Configure alerts or dashboards to track progress toward targets in real-time. Activity Tracking ( Monitor completion of project activities against the planned schedule). Define Activities and Schedule Review the project plan and results hierarchy to list all activities. Record start dates, end dates, milestones, and dependencies for each activity. Assign responsible staff or teams for implementation. Integrate Activities into M&E System Enter the activity list, schedules, and responsible actors into the M&E system. Link each activity to the corresponding outputs, outcomes, and indicators. Collect Progress Data Gather status updates from responsible staff, project teams, or automated systems. Examples of data include completion percentage, milestones achieved, delays, or notes on issues. Update Activity Status Record updates in real-time or at predefined intervals (daily, weekly, monthly). Mark activities as planned, in progress, completed, delayed, or canceled. Compare Against Planned Schedule Assess whether each activity is on track, ahead, or behind schedule. Identify deviations from the original plan. Flag Issues and Deviations Automatically or manually generate alerts for delayed or blocked activities. Track reasons for delays or changes to facilitate corrective actions. Link Activities to Outputs and Outcomes Ensure that completed activities contribute to planned outputs. Verify alignment with higher-level outcomes in the results hierarchy. Generate Reports and Dashboards Produce real-time activity tracking reports showing status, progress percentage, delays, and completion. Visualize progress using Gantt charts, dashboards, or heatmaps for easier interpretation. Conduct Review and Corrective Actions Review activity status in team meetings or M&E sessions. Reallocate resources, reschedule, or adjust plans for activities that are off track. **Output Monitoring to track immediate deliverables from activities.** 1. Collect Output Data Gather data on completed deliverables from field reports, activity logs, or automated systems. Include verification data like receipts, attendance sheets, inspection reports, or photos as evidence. Validate and Verify Outputs Check that reported outputs meet the defined quality standards and criteria. Flag any discrepancies or incomplete deliverables. Update Output Status Record whether each output is completed, in progress, partially completed, or delayed. Track percentage of target achieved for each output. Analyze Output Performance Compare actual outputs against planned targets. Identify shortfalls or overachievements. Link Outputs to Outcomes Verify that outputs contribute to the expected short- and medium-term outcomes. Ensure logical alignment in the results hierarchy. Generate Reports and Dashboards Produce periodic output monitoring reports for project teams and stakeholders. Use dashboards to visualize output completion, delays, and variances. Review and Implement Corrective Actions Conduct performance review sessions to address gaps. Adjust resources, timelines, or activities to ensure outputs are delivered as planned. **Outcome Assessment to measure short- and medium-term changes resulting from outputs** Collect Outcome Data Gather data from relevant sources on the changes or results achieved. Include qualitative evidence such as beneficiary feedback, case studies, or observations. Validate and Verify Data Check accuracy and reliability of the collected data. Cross-verify with multiple sources where possible. Analyze Outcome Performance Compare actual outcomes against targets and baseline values. Identify gaps, progress trends, or unexpected results. Interpret Findings Determine the extent to which outputs have contributed to desired outcomes. Assess effectiveness, efficiency, and relevance of project interventions. Report Outcome Results Generate outcome reports and dashboards for stakeholders. Highlight achievements, shortfalls, and recommendations for improvement. Inform Decision-Making Use outcome assessment results to adjust activities, reallocate resources, or refine strategies. Feed lessons learned into future project planning. **Impact Evaluation to assess long-term changes and benefits for beneficiaries.** Define Evaluation Objectives Clarify the purpose of the impact evaluation, such as measuring long-term social, economic, or environmental changes. Identify key questions the evaluation seeks to answer about effectiveness, sustainability, and relevance. Identify Outcomes and Impacts Review the results hierarchy to distinguish between short-/medium-term outcomes and long-term impacts. Specify which changes in beneficiaries, communities, or systems are considered impact-level results. Select Impact Indicators Define quantitative and qualitative indicators that measure long-term changes. Indicators should be SMART and aligned with project objectives and donor requirements. Establish Baselines and Counterfactuals Gather baseline data for comparison. If possible, identify control or comparison groups to assess what would have happened without the intervention. Design Data Collection Plan Determine methods for collecting impact data, such as surveys, interviews, case studies, longitudinal studies, or secondary data sources. Decide on timing and frequency, often after completion of project outputs and outcomes. Collect and Verify Data Gather evidence on changes among beneficiaries or systems. Ensure data is accurate, reliable, and representative of the target population. Include qualitative insights for context and explanation of results. Analyze Data Compare results against baselines, targets, and counterfactuals. Use statistical or qualitative methods to attribute changes to project interventions. Assess magnitude, sustainability, and equity of impact. Interpret Findings Determine the extent and significance of long-term benefits for beneficiaries. Identify unintended outcomes (positive or negative) and lessons learned. Report Results Prepare comprehensive impact evaluation reports with evidence, charts, and recommendations. Share findings with stakeholders, donors, and decision-makers. Inform Strategic Decisions Use evaluation findings to improve future program design, resource allocation, and policy decisions. Incorporate lessons learned into the M&E system for adaptive management. **Variance Analysis and Adjustment – Compare planned vs actual results and adjust interventions if necessary** Collect Actual Performance Data Gather real-time or periodic data from activities, outputs, outcomes, financials, and indicators. Ensure data is validated and verified for accuracy. Retrieve Planned Targets Access the planned values, schedules, and targets recorded in the M&E system for outputs, outcomes, and budgeted activities. Calculate Variances Compute the difference between actual and planned values for each indicator, activity, or budget item. Express variance as absolute numbers, percentages, or qualitative ratings as appropriate. Analyze Causes of Variance Investigate why actual performance differs from planned targets. Identify contributing factors, such as resource delays, implementation issues, external events, or data errors. Prioritize Significant Variances Determine which deviations require immediate attention versus those within acceptable thresholds. Focus on variances that affect critical outcomes or budget compliance. Develop Corrective Actions Propose adjustments to activities, resource allocation, timelines, or strategies to address variances. Ensure that corrective actions are practical, feasible, and aligned with project objectives. Implement Adjustments Update project plans, schedules, budgets, or outputs in the M&E system. Communicate changes to responsible staff and stakeholders. Monitor Post-Adjustment Performance Track whether adjustments bring performance back on track toward planned targets. Reassess variances after implementing corrective measures. Document and Report Maintain a record of variances, causes, decisions, and actions taken in the M&E system. Generate reports for management, stakeholders, and auditors. Review and Update Thresholds Based on lessons learned, adjust variance thresholds, planning assumptions, or monitoring parameters for future cycles. **Reporting and Communication to prepare reports showing the causal chain and achieved results for stakeholders** Define Reporting Requirements Identify stakeholders (donors, management, project teams, beneficiaries) and their information needs. Determine the reporting frequency, format, and level of detail required. Collect and Consolidate Data: Gather data from all relevant sources, including: Activity tracking, Output monitoring, Outcome assessments, Financial and budget records Validate and clean data to ensure accuracy and consistency. Link Data to Results Hierarchy Map activities, outputs, outcomes, and impacts to the results hierarchy. Ensure the report clearly shows the causal chain from inputs → activities → outputs → outcomes → impact. Analyze Performance Compare actual results against planned targets and baselines. Highlight achievements, deviations, trends, and areas requiring attention. Include variance analyses where relevant. Visualize Results Use charts, dashboards, graphs, and tables to make the information clear and actionable. Show progress along the results chain and the contribution of activities to outcomes. Prepare Narrative and Insights Summarize key findings, lessons learned, and implications for stakeholders. Explain reasons for deviations and highlight success stories or challenges. Generate Reports Produce reports in the required formats (PDF, dashboard, presentation, online portal). Ensure reports include all required indicators, metrics, and evidence. Distribute to Stakeholders Share reports via email, dashboards, M&E system portals, or meetings. Tailor the level of detail based on audience needs. Solicit Feedback Gather input from stakeholders to improve report relevance, clarity, and usefulness. Use feedback to refine future reporting cycles. Maintain Documentation Store reports, underlying data, and supporting documents in the M&E system. Ensure an audit trail for accountability and reference during evaluations. Inform Decision-Making Ensure reporting feeds into strategic planning, corrective actions, resource allocation, and adaptive management | | **Postconditions** | Updated results hierarchy with tracked performance; actionable insights for project improvement; evidence of outcomes and impact achieved. | | **Alternate Flows** | Indicators not measurable : revise the indicator or collect proxy data. Activities delayed Re-plan or reallocate resources. Outcomes not achieved, investigate causes and adjust interventions. | **Table 47: **Use case narrative for indicator management | **Use Case Name** | Indicator Management | | --- | --- | | **Actors** | M&E Officer, Project Manager, Program Staff, Data Analyst, Donors/Stakeholders | | **Goal / Objective** | Define, manage, and monitor quantitative and qualitative indicators to measure project progress, performance, and impact, supporting outcome-focused decision-making. | | **Preconditions** | Project objectives, results hierarchy, and baseline data are defined; access to historical data and reporting templates. | | **Triggers** | Project initiation, planning new interventions, periodic monitoring, or reporting cycles. | | **Sub-Processes** | 1. Identify measurable indicators for outputs, outcomes, and impact. 2. Categorize indicators as quantitative or qualitative. 3. Establish baseline values and performance targets. **Data Collection Planning – Define methods, frequency, and responsible parties for collecting indicator data** Review Indicators and Results Framework Examine the results hierarchy (outputs, outcomes, impact) and associated indicators. Identify what data is needed to measure each indicator accurately. Select Data Collection Methods Determine the most appropriate methods for each indicator, such as Surveys or questionnaires, Interviews or focus groups, Observation or site visits, Administrative records or existing databases, Remote sensing or sensor-based data Ensure methods are feasible, cost-effective, and appropriate for the context. Define Data Sources Identify where the data will come from, e.g., beneficiaries, project staff, government records, field reports. Verify the reliability and accessibility of each data source. Assign Responsibilities Designate who will collect the data for each indicator. Specify roles for data collectors, supervisors, and data validators. Determine Frequency and Timing Decide how often data will be collected (daily, weekly, monthly, quarterly, annually). Align collection frequency with reporting requirements and project milestones. Establish Data Collection Tools Develop or adapt standardized tools and templates (forms, mobile apps, spreadsheets, or software modules). Ensure tools capture all required fields, metadata, and validation checks. Plan Data Quality Assurance Define procedures for verifying accuracy, completeness, and consistency of collected data. Include supervision, validation, and spot checks. Document the Data Collection Plan Create a formal plan including: Indicators Data sources Methods Frequency Responsible staff Tools/templates Quality assurance procedures Integrate with M&E System Configure the M&E system to schedule data collection, assign tasks, and store collected data. Enable alerts or reminders for upcoming data collection tasks. Review and Approve Plan Have the plan reviewed by the M&E team and project management. Adjust based on resource availability, feasibility, and stakeholder input 5. Gather and validate indicator data from activities and interventions. 6. Compare actual values against targets; perform trend analysis. 7. Reporting and Communication 8. Update indicators or targets based on lessons learned, changing conditions, or new priorities. | | **Postconditions** | Updated and validated set of indicators; performance and impact insights available; evidence-based decision-making supported. | | **Exceptions / Alternate Flows** | - Indicator data unavailable, Use proxy indicators or estimate values. - Targets not achievable, Adjust targets and notify stakeholders. Data quality issues trigger verification and correction processes. | **Table 48: Use case narrative for Reporting and Compliance** | **Use Case Element** | **Description** | | --- | --- | | **Use Case Name** | Reporting and Compliance | | **Actors** | Finance Officer, Project Manager, M&E Officer, Auditor, Project Sponsor, Donors/Stakeholders | | **Preconditions** | Project plans, budgets, results hierarchy, activity and transaction data, and baseline performance metrics are available. | | **Triggers** | Scheduled reporting periods, audit requests, budget reviews, stakeholder inquiries, or compliance checks. | | **Sub-Processes** | 1. **Data Consolidation** – Collect financial, activity, and performance data from multiple sources. 2. **Report Generation** – Produce real-time dashboards and periodic reports showing progress against targets, budget usage, and outcomes. 3. **Variance and Compliance Analysis** – Compare actual results with plans, budgets, and regulatory requirements; flag deviations. Retrieve Planned Values and Regulatory Requirements Access planned targets, budgets, schedules, and regulatory standards from the project plan or compliance framework. Include donor requirements, government regulations, and internal policies. Calculate Variances Compare actual results vs planned targets for: Activities and outputs Outcomes and impact indicators Budgeted vs actual expenditures Express variances as absolute values, percentages, or qualitative ratings. Assess Compliance Check if activities, outputs, outcomes, and financial expenditures meet regulatory and contractual requirements. Identify instances of non-compliance, errors, or breaches. Identify and Prioritize Deviations Highlight significant deviations that may impact outcomes, budgets, or compliance obligations. Categorize deviations by severity, urgency, and potential impact. Analyze Causes of Variances Investigate the root causes of deviations: Implementation delays Resource constraints Errors in planning External factors (policy changes, market fluctuations) Generate Alerts and Notifications Configure the M&E system to flag deviations automatically for responsible staff. Send notifications or reports to project managers, finance officers, or compliance officers. Document Findings Record variance and compliance analysis results, including causes, responsible actors, and evidence. Maintain audit trails for accountability and future reference. Recommend Corrective Actions Suggest adjustments to activities, budgets, or procedures to address deviations. Prioritize actions based on impact and feasibility. Monitor Corrective Actions Track implementation of corrective measures. Reassess performance post-adjustment to ensure alignment with targets and compliance requirements. 5. Stakeholder Communication – Share reports and insights with donors, project sponsors, and management. 6. Corrective Actions – Identify gaps or compliance issues and recommend adjustments. | | **Postconditions** | Up-to-date reports reflecting outcomes, budget status, and compliance; audit trail maintained; actionable insights for decision-making. | | **Exceptions / Alternate Flows** | Data gaps system flags missing information for validation. Compliance breaches system alerts and escalates to management. Report generation fails , retry or manual extraction from source systems. | ### 5.3.3. Functional requirements The functional requirements are as follows: - | **Process Name** | **Functional Requirements** | **Inputs** | **Outputs** | **Actor** | | --- | --- | --- | --- | --- | | Conduct Results Planning | **FR****MFL001:** The system shall provide an interface for documenting long-term impacts, outcomes, outputs, activities, and inputs in a results hierarchy. **FR****MFL002:**The system shall link each output to corresponding outcomes and each outcome to impacts. **FR****MFL003: **The system shall demonstrate the hierarchical causal relationships **FR****MFL004: **The system shall record the results hierarchy for review and traceability. | Project objectives, organizational strategy, donor requirements, and available resources | Results hierarchy (Inputs → Activities → Outputs → Outcomes → Impact) | M&E Officer, Project Manager | | Indicator Definition and Target Setting | **FR****MFL005: **The system shall provide an interface for documenting SMART indicators for outputs, outcomes, and impacts. **FR****MFL006: **The system shall specify data sources, calculation methods, and units. **FR****MFL007: **The system shall provide an interface for setting baselines and performance targets. **FR****MFL008: **The system provide an interface for documenting indicators and targets **FR****MFL009: **The system shall integrate indicators into monitoring and reporting workflows. | Results hierarchy, project objectives, baseline data | Defined indicators, baselines, targets, metadata | M&E Officer, Data Analyst | | Activity Tracking | **FR****MFL009: **The system shall track all project activities against planned schedules. **FR****MFL010: **The system shall provide an interface for updating activity status in real-time or predefined intervals. **FR****MFL011: **The system shall flag deviations and generate alerts for delayed or blocked activities. **FR****MFL012**The system shall link activities to outputs and outcomes. **FR****MFL013:**The system shall generate reports and dashboards for review. | Project plan, activity schedule, assigned staff, outputs | Activity progress status, alerts, reports, dashboards | Project Team, M&E Officer | | Output Monitoring | **FR****MFL014: **The system shall provide an interface for collecting and validating data on completed deliverables. **FR****MFL015: ** The system shall track the percentage of target achieved for each output. **FR****MFL016: **The system shall analyze performance against planned targets. **FR****MFL017: **The system shall link outputs to expected outcomes. **FR****MFL018: ** The system shall generate periodic output monitoring reports. **FR****MFL019:**The system shall support corrective action implementation. | Activity completion data, verification evidence | Output status reports, performance analysis, dashboards | Project Team, M&E Officer | | Outcome Assessment | **FR****MFL020: **The system shall provide an interface for collecting, validating, and analyzing outcome data. **FR****MFL021: **The system shall compare actual outcomes against targets and baselines. **FR****MFL022: **The system shall interpret findings on contribution of outputs to outcomes. **FR****MFL023: **The system shall generate outcome reports and dashboards. | Output data, baseline data, target values, stakeholder feedback | Outcome performance reports, insights, recommendations | M&E Officer, Project Manager, Data Analyst | | Impact Evaluation | **FR****MFL024: **The system shall provide an interface for defining evaluation objectives and select impact indicators. **FR****MFL025:**The system shall provide an interface for establishing baselines and counterfactuals. **FR****MFL026: **The system shall validate, and analyze data to measure long-term changes. **FR****MFL027: **The system shall interpret findings and generate comprehensive impact evaluation reports. | Outcome data, baseline data, comparison groups, evaluation objectives | Impact evaluation reports, insights, recommendations | M&E Officer, Evaluation Specialist, Project Manager | | Variance Analysis & Adjustment | **FR****MFL028: **The system shall collect actual performance data and retrieve planned targets. **FR****MFL029: **The system shall calculate variances and analyze causes of deviations. **FR****MFL030: **The system shall prioritize significant variances and propose corrective actions. **FR****MFL031: ** The system shall provide an interface for implementing adjustments and monitor post-adjustment performance. The system shall document and report variances. | Actual performance data, planned targets, budgets | Variance reports, corrective action plans, updated plans | M&E Officer, Project Manager, Finance Officer | | Reporting and Communication | **FR****MFL032: **The system shall map data to the results hierarchy and analyze performance against targets. **FR****MFL033: **The system shall visualize results using charts, dashboards, and tables. The system shall distribute to stakeholders and solicit feedback | Activity, output, outcome, impact data, financial data, stakeholder requirements | Reports, dashboards, visualizations, performance summaries | M&E Officer, Project Manager, Stakeholders | ### 5.3.4. Non-functional requirements - Each output must link to at least one outcome. - Each outcome must link to one goal. - Each indicator must follow SMART criteria. - Baseline must be entered before targets can be finalized. - All indicators must specify reporting frequency. - Only one Impact per project (unless multi-impact projects are enabled). - All Outcomes must align with the Impact. - Outputs must logically contribute to Outcomes. - Activities cannot exist without an Output. - Deleting a parent requires handling or reassignment of children. - Version history must be maintained for all modifications ## Finance Management (FM) ### 5.4.1 Finance Management Module Description The RUFORUM Finance Module is designed to provide a centralized and transparent platform for managing all financial transactions, grants, and funding activities across the consortium’s programs and projects. It enables efficient tracking of budget allocations, expenditures, and disbursements, ensuring that funds are used in accordance with approved plans and donor requirements. The module will support the following submodules:- - **Budget and financial management**: This includes budget setup and revisions, budget analysis showing budgeted compared to actual tracking, line-item expenditure tracking, variance analysis, Multi-year budget tracking, and multi-currency support - **Disbursement and payment**: These include payment scheduling and tracking, disbursement requests and approvals, and payment tracking - ** Financial reporting**: This is the systematic tracking, analysis, and communication of a project’s income, expenditures, and cash flow against its budget. It involves creating, updating, and presenting reports (e.g., variance analysis, cost-value reconciliation) to stakeholders, allowing them to monitor financial health, predict future needs, and ensure budget compliance ### Finance Management sub-process descriptions **Table 49: **Use case narrative for finance management** ** | | | | --- | --- | | **Use Case Name** | Budget and Financial Management | | **Primary Actor** | Finance Officer / Budget Manager | | **Supporting Actors** | Project Managers, Program Coordinators, Management, Auditors | | **System** | RUFORUM Finance Module | | **Use Case Description** | Enables planning, monitoring, and control of RUFORUM financial resources across projects and programs. Supports budget setup and revisions, budget vs actual analysis, line-item expenditure tracking, variance analysis, multi-year budget tracking, and multi-currency support. | | **Preconditions** | Finance Module is operational Projects/programs defined - User roles and permissions established | | **Postconditions** | Budgets established and revised with an audit trail Expenditures tracked at the line-item level Variances identified and reported- Multi-year and multi-currency budgets maintained | | **Main Flow / Steps** | **Budget Setup:** Create project/Programme budgets with line items, fiscal year, and multi-year allocations. 1. **Define Objectives and Scope** Clearly outline the project or programme goals. Identify expected outputs, activities, and timelines. Determine whether it’s a single-year or multi-year initiative. 2. **Identify Budget Line Items** Break down the project into cost categories (line items), such as: Personnel (salaries, consultants) Operations (transport, utilities) Equipment and supplies Training and workshops Ensure each line item is specific and measurable. 3. **Estimate Costs** Assign realistic costs to each line item. Use historical data, vendor quotes, or market rates. Consider inflation, contingencies, and risk factors. 4. **Define Fiscal Year Structure** Allocate the budget within the relevant fiscal year(s) Align with your organization’s financial calendar. Split costs appropriately if activities span across fiscal periods. 5. **Plan Multi-Year Allocations (if applicable)** Distribute the total budget across multiple years. Identify: Year-by-year funding requirements Timing of major expenses Ensure sustainability and funding availability across all years. 6. **Assign Funding Sources** Identify where funds will come from: Internal funds Donors or grants Loans or external financing Link each budget line to a specific funding source. 7. **Set Budget Controls and Limits** Define spending limits per line item or category. Establish approval workflows and authorization levels. Include contingency reserves for unexpected costs. 8. **Input Budget into Financial System** Enter all data into your finance management system: Line items Amounts Time periods (monthly, quarterly, yearly) Ensure correct coding (accounts, cost centers, projects). 9. **Review and Validate** Cross-check totals, allocations, and assumptions. Ensure alignment with organizational strategy and funding agreements. Validate compliance with financial policies. 10. **Approval and Finalization** Submit the budget for internal approval (finance team, management, board). Make revisions if required. Lock or finalize the approved budget in the system. 11. **Monitoring and Adjustments** Track actual spending against the budget. Generate variance reports. Revise (reforecast) the budget if needed over time. 2. **Budget Revisions:** Update budgets as required, with versioning for audit. 3. **Track Expenditure:** Record all expenditures against line items. 4. **Budget vs Actual Analysis:** Compare actual spending against budgeted amounts. 5. **Variance Analysis:** Identify and analyze discrepancies; generate alerts. 6. **Multi-Year Budget Tracking:** Aggregate budgets across fiscal years for long-term projects. 7. **Multi-Currency Support:** Record and consolidate transactions in multiple currencies for global programs. | | **Alternate Flows** | **Budget Revision Rejection:** If revision exceeds authority limits, approval is required. **Data Entry Errors:** Invalid data triggers prompts for correction. | | **Key Reports Generated** | Budget Setup and Revision Report Budget vs Actual Comparison Report- Line-Item Expenditure Report Variance Analysis Report- Multi Year Budget Overview Multi-Currency Consolidated Financial Report | | **Success Criteria ** | Accurate, real-time budget and expenditure tracking Variances detected promptly Multi-year and multi Currency budgets consolidated correctly Reports support informed decision-making and financial accountability | **Table 50: **Use case narrative for disbursement and Payment** ** | **Use Case Name** | Disbursement and Payment | | --- | --- | | **Primary Actor** | Finance Officer / Accounts Team | | **Supporting Actors** | Project Manager, Program Coordinator, Management, Auditors | | **System** | RUFORUM Finance Module | | **Use Case Description** | Manages the scheduling, approval, execution, and tracking of payments for RUFORUM projects and programs. Supports payment scheduling, disbursement requests, approvals, and payment tracking to ensure timely, accurate, and auditable financial transactions. | | **Preconditions** | Finance Module is operational Budgets are approved - User roles and permissions configured | | **Postconditions** | Payments are executed according to schedule Disbursement approvals are logged - Payment statuses tracked and reported | | **Main Flow ** | **Payment Scheduling:** Plan payments for approved budgets, including dates, amounts, and methods 1. **Confirm Approved Budget and Commitments** Verify that the budget has been approved and funds are available. Check related commitments (e.g., contracts, purchase orders, grant agreements). 2. **Identify Payable Items** List all payments to be made, such as: Supplier invoices Staff salaries or allowances Contractor payments Link each payable to the correct budget line item. 3. **Define Payment Details** For each payment, capture: **Amount** to be paid **Payee/vendor details** **Purpose/description** Supporting documents (invoice, contract, etc.) 4. **Set Payment Dates** Determine when each payment should be made: Based on due dates, contract terms, or cash flow plans Schedule: One-time payments Recurring payments (e.g., monthly salaries) 5. **Select Payment Methods** Choose how payments will be executed: Bank transfer Mobile money Cheque Cash (if applicable) Ensure the method aligns with organizational policy and vendor preferences. 6. **Assign Funding Source and Accounts** Link each scheduled payment to: Correct account codes Cost centers or projects Funding sources (e.g., donor, internal funds) 7. **Cash Flow Validation** Check available cash balances against scheduled payments. Ensure there are no liquidity gaps. Adjust timing if necessary to maintain financial stability. 8. **Set Approval Workflow** Route scheduled payments for authorization: Finance officer review Management approval Apply internal controls (segregation of duties). 9. **Enter into Financial System** Record payment schedules in the system: Dates Amounts Payees Payment methods Generate payment batches if applicable. 10. **Notification and Reminders** Set alerts for upcoming payments. Notify responsible staff before due dates. 11. **Execute Payments** Process payments on scheduled dates. Update system status (e.g., “paid,” “pending”). 12. **Reconciliation and Tracking** Match payments with bank statements. Track: Paid vs. scheduled amounts Delays or failed transactions Maintain audit trail for accountability. 13. **Adjust and Reschedule (if needed)** Modify schedules due to: Cash flow changes Budget revisions Delays in approvals or deliverables ** Disbursement Requests and approval: Project managers submit payment requests with supporting documentation** 1. **Initiate Disbursement Request** The authorized staff creates a disbursement request in the system. He or she selects the relevant: Project/programme Budget line item Activity or expense category 2. **Enter Request Details** Officer capture key information such as: Requested amount Purpose of the payment Payee (vendor, staff, contractor) Payment method (bank transfer, mobile money, etc.) Expected payment date 3. **Attach Supporting Documentation** Upload required documents to justify the request, for example: Supplier invoices Contracts or agreements Purchase orders Delivery notes or receipts 4. **Budget Availability Check** System or finance team verifies: Funds are available under the selected budget line The request does not exceed allocated limits Flags any over-budget or invalid requests. 5. **Compliance and Policy Validation** Check that the request complies with: Organizational financial policies Donor or funding requirements Confirm procurement procedures were followed (if applicable). 6. **Submission for Approval** The request is formally submitted to the approval workflow. Status changes from *draft* to *pending approval*. 7. **Multi-Level Review and Approval** Routed through designated approvers, such as: Line manager Finance officer Program director Each reviewer may: Approve Reject Request clarification or edits 8. **Revision (if required)** If issues are identified: The request is returned to the project manager Corrections or additional documents are added Resubmitted for approval. 9. **Final Approval and Authorization** Once all approvals are completed: The request is marked as **approved** Authorization triggers the next stage (payment scheduling or processing). 10. **System Recording and Audit Trail** The system logs: Who submitted and approved the request Dates and changes made Ensures transparency and traceability for audits. 11. **Forward to Payment Processing** Approved request is sent to: Payment scheduling module or Accounts payable team Prepares for actual disbursement. 12. **Status Tracking and Notifications** The requester can track progress (e.g., pending, approved, rejected, paid). Notifications are sent at each stage ** Payment Execution/Tracking to execute approved payments, record status, and reconcile with accounts** 1. **Retrieve Approved Payment Instructions** Pull approved payments from: Disbursement requests Payment schedules Confirm all approvals and required documents are in place. 2. **Prepare Payment Batch** Group payments (if applicable) into batches for efficiency. Verify details: Payee information Amounts Payment methods Assign batch reference numbers. 3. **Validate Payment Details** Reconfirm: Bank account or mobile money details Available cash balance Correct account codes and funding sources Prevent errors or duplicate payments. 4. **Execute Payments** Process payments using selected methods: Bank transfers (via bank integration or upload files) Mobile money payments Cheques or cash disbursements Capture transaction reference numbers from the payment platform. 5. **Record Payment in the System** Update each transaction as: Paid / Completed Record: Payment date Transaction ID/reference Actual amount paid Automatically generate accounting entries (e.g., debit expense, credit cash/bank). 6. **Update Payment Status** Change status in the system: Pending → Processed → Paid Handle exceptions: Failed Reversed Cancelled 7. **Generate Payment Documentation** Produce: Payment vouchers Receipts or confirmations Store documents for audit and reporting purposes. 8. **Notify Stakeholders** Send notifications to: Payees (payment confirmation) Project managers Finance team 9. **Bank and Cash Reconciliation** Match recorded payments with: Bank statements Mobile money statements Identify: Missing transactions Duplicates Bank charges or variances 10. **Resolve Discrepancies** Investigate mismatches: Incorrect amounts Failed or delayed payments Make corrections or adjustments in the system. 11. **Update General Ledger** Ensure all payments are properly posted to: General ledger accounts Project or cost center records Maintain accurate financial statements. 12. **Audit Trail and Reporting** Maintain logs of: Who executed the payment When and how it was processed Generate reports: Payment summaries Cash flow reports Budget vs actual analysis 13. **Ongoing Tracking and Monitoring** Continuously monitor: Payment status Outstanding or failed transactions Support financial oversight and decision-making. **Reporting:** **Generate payment tracking and status reports for stakeholders** | | **Alternate Flows** | - **Disbursement Rejection:** Requests exceeding authority limits are returned for correction or additional approval. - **Payment Failure:** Failed transactions trigger alerts and corrective action procedures. | | **Key Reports Generated** | Payment Schedule Report Disbursement Request Status Report Payment Execution and Tracking Report - Exception/Failed Payment Report | | **Success Criteria ** | Timely and accurate payment execution Transparent approval and tracking process Audit-ready payment records - Stakeholders can monitor payment status effectively | **Table 51: **Use case narrative for financial reporting** ** | **Use Case Name** | Financial Reporting | | --- | --- | | **Primary Actor** | Finance Officer / Accounts Team | | **Supporting Actors** | Project Managers, Program Coordinators, Management, Auditors | | **System** | RUFORUM Finance Module | | **Use Case Description** | Manages the systematic tracking, analysis, and communication of project income, expenditures, and cash flow against approved budgets. Supports creating, updating, and presenting financial reports, including variance analysis, cost-value reconciliation, and cash flow forecasts to stakeholders to enable monitoring of financial health, predicting future funding needs, and ensuring budget compliance. | | **Preconditions** | Finance Module is operational Budget and expenditure data recorded - User roles and permissions configured | | **Postconditions** | Accurate and up-to-date financial reports generated Stakeholders have visibility into project financial health - Variances and anomalies are identified and communicated for corrective action | | **Main Flow / Steps** | **Financial Data Collection:** Gather income, expenditure, and cash flow data from all projects. **Data Consolidation:** Combine and validate data for accuracy. **Budget vs Actual Analysis:** Compare actual expenditures and income against approved budgets **Variance ****&**** Cost-Value Analysis:** Identify discrepancies and reconcile costs with project value delivered. **Report Creation ****&**** Updating:** Prepare financial reports and update them regularly as new data is available. **Stakeholder Communication:** Distribute reports to relevant stakeholders via dashboards, email, or portals. **Forecasting:** Analyze trends to predict future budget needs and cash flow requirements. | | **Alternate Flows** | **Data Inconsistencies:** Invalid or missing financial data triggers alerts and requires correction. **Report Review Rejection:** Reports flagged by management or auditors for errors must be revised before dissemination. | | **Key Reports Generated** | Budget vs Actual Report Variance Analysis Report Cost-Value Reconciliation Report Cash Flow Forecast Report Stakeholder Financial Dashboard | | **Success Criteria / Outcome** | Stakeholders have timely and reliable visibility into financial health Financial variances and risks are identified and managed proactively. Accurate forecasts support informed decision-making. Reports meet compliance and audit requirements. | ### 5.4.3. Functional requirements for financial management **Table 52: requirements specifications for budget and financial management ** | **Process Name** | **Functional Requirements** | **Inputs** | **Outputs** | **Actor** | | --- | --- | --- | --- | --- | | **Budget Setup** | **FRFM001**: The system shall allow users to define project objectives, scope, timelines, and expected outputs. | Project concept notes, strategic plans | Defined project scope and objectives | Project Manager | | | **FRFM002: **The system shall allow creation of budget line items categorized by cost types. | Cost categories, activity plans | Structured budget line items | Finance Officer | | | **FRFM003: **The system shall allow users to estimate and assign costs to each budget line item. | Historical data, vendor quotes | Costed budget lines | Finance Officer | | | **FRFM004: **The system shall support allocation of budgets across fiscal years, including multi-year budget planning and annualized distribution. | Financial calendar, multi-year projections | Fiscal year budget allocation, annualized budget distribution | Finance Officer / Finance Manager | | | **FRFM005: **The system shall allow assignment of funding sources to each budget line. | Funding agreements, donor info | Linked funding sources | Finance Officer | | | **FRFM006: **The system shall enforce budget controls, limits, and approval workflows. | Budget policies | Controlled and validated budget | Finance Manager | | | **FRFM007: **The system shall allow entry and coding of budget data into financial modules. | Budget details | Recorded the budget in the system | Finance Officer | | | **FRFM008: **The system shall validate budget accuracy and compliance before approval. | Budget entries | Validated budget | Finance Manager | | | **FRFM009: **The system shall support approval and finalization of budgets. | Reviewed budget | Approved budget | Management | | | **FRFM010: **The system shall track budget performance and allow revisions. | Actual expenditures | Updated budgets, variance reports | Finance Officer | | **Budget Revisions** | **FRFM011: **The system shall allow updating of approved budgets with version control. | Approved budget, revision requests | Revised budget versions | Finance Manager | | **Track Expenditure** | **FRFM012: **The system shall record all expenditures against budget line items. | Expense transactions | Updated expenditure records | Finance Officer | | **Budget vs Actual Analysis** | **FRFM013: **The system shall compare actual expenditures against budgeted amounts. | Budget data, actual expenses | Comparison reports | Finance Analyst | | **Variance Analysis** | **FRFM014: **The system shall identify variances and generate alerts for discrepancies. | Budget vs actual data | Variance reports, alerts | Finance Analyst | | **Multi-Year Budget Tracking** | **FRFM015: **The system shall aggregate and track budgets across multiple fiscal years. | Multi-year budgets | Consolidated budget view | Finance Manager | | **Multi-Currency Support** | **FRFM016: **The system shall support recording and conversion of multiple currencies. | Foreign currency transactions | Consolidated financial data | Finance Officer | | **Payment Scheduling** | **FRFM017: **The system shall verify approved budgets and commitments before scheduling payments. | Approved budgets, contracts | Validated payment basis | Finance Officer | | | **FRFM018: **The system shall allow identification and listing of payable items. | Invoices, payroll data | Payable list | Accounts Officer | | | **FRFM019: **The system shall capture payment details, including amount, payee, and purpose. | Payment requests | Detailed payment records | Accounts Officer | | | **FRFM020: **The system shall allow scheduling of payment dates and recurring payments. | Payment terms | Payment schedule | Finance Officer | | | **FRFM021: **The system shall support the selection of multiple payment methods. | Payment options | Selected payment method | Finance Officer | | | **FRFM022: **The system shall link payments to accounts, cost centers, and funding sources. | Chart of accounts | Allocated payments | Finance Officer | | | **FRFM023: **The system shall validate cash flow before confirming schedules. | Cash balances | Cash flow status | Finance Manager | | | **FRFM024: **The system shall enforce approval workflows for scheduled payments. | Payment schedule | Approved payments | Management | | | **FRFM025: **The system shall record payment schedules in the system. | Payment data | Stored schedules | Finance Officer | | | **FRFM026: **The system shall generate alerts and reminders for due payments. | Payment schedule | Notifications | System | | | **FRFM027: **The system shall support updating and rescheduling of payments. | Revised plans | Updated schedules | Finance Officer | | **Disbursement Requests ****&**** Approval** | **FRFM028: **The system shall allow users to create and submit disbursement requests. | Request details | Submitted requests | Project Manager | | | **FRFM029: **The system shall capture detailed payment request information. | Payment data | Complete request record | Project Manager | | | **FRFM030: **The system shall allow attachment of supporting documents. | Invoices, contracts | Documented request | Project Manager | | | **FRFM031: **The system shall validate budget availability before approval. | Budget data | Validation status | System | | | **FRFM032: **The system shall enforce compliance with financial and donor policies. | Policies, guidelines | Compliance status | Finance Officer | | | **FRFM033: **The system shall route requests through approval workflows. | Submitted request | Approval status | System | | | **FRFM034: **The system shall support multi-level approvals and feedback. | Approval inputs | Approved/rejected request | Approvers | | | **FRFM035: **The system shall allow revision and resubmission of requests. | Rejected request | Updated request | Project Manager | | | **FRFM036: **The system shall log all actions for audit trail purposes. | User actions | Audit logs | System | | | **FRFM037: **The system shall forward approved requests for payment processing. | Approved request | Payment instruction | System | | | **FRFM038: **The system shall provide status tracking and notifications. | Request status | Status updates | System | | **Payment Execution ****&**** Tracking** | **FRFM039: **The system shall retrieve approved payment instructions for processing. | Approved requests | Payment list | Finance Officer | | | **FRFM040: **The system shall group payments into batches for execution. | Payment list | Payment batches | Finance Officer | | | **FRFM041: **The system shall validate payment details before execution. | Payment data | Verified payments | Finance Officer | | | **FRFM042: **The system shall execute payments using selected methods. | Payment instructions | Completed transactions | Finance Officer | | | **FRFM043: **The system shall record executed payments and generate accounting entries. | Payment results | Updated financial records | System | | | **FRFM044: **The system shall update payment statuses and handle exceptions. | Payment outcomes | Status updates | System | | | **FRFM045: **The system shall generate payment documentation and confirmations. | Payment data | Vouchers, receipts | System | | | **FRFM046: **The system shall notify stakeholders of payment completion. | Payment status | Notifications | System | | | **FRFM047: **The system shall reconcile payments with bank and cash statements. | Bank statements | Reconciliation reports | Finance Officer | | | **FRFM048: **The system shall detect and provide an interface for personnel to resolve discrepancies. | Reconciliation data | Adjusted records | Finance Officer | | | **FRFM049: **The system shall update the general ledger automatically. | Payment entries | Updated ledger | System | | | **FRFM050: **The system shall maintain audit trails and generate financial reports. | Transaction logs | Reports | System | | **Reporting** | **FRFM051: **The system shall generate payment tracking and status reports . | Payment and budget data | Reports and dashboards | Finance Manager | ### Non-functional requirements for financial management The financial management module has the following non-functional requirements **NFRFM001**: Expenditures must not exceed approved budget line items **NFRFM002: ** Multi-currency transactions converted using standardized exchange rates **NFRFM003: ** All revisions tracked for audit and compliance **NFRFM004:** Alerts MUST be generated in case significant variances in expenditures are submitted **NFRFM005: **Disbursements must be approved according to the authorization hierarchy **NFRFM006: ** Payments must not exceed approved budget allocations **NFRFM007: **All disbursement and payment actions must be logged for audit **NFRFM008: **All reports must align with approved budgets and accounting policies. **NFRFM009: **Data accuracy and integrity are mandatory. **NFRFM010: **Reports must be auditable and traceable. ## 5.5. Regional E-Learning Platform (REP) ## 5.5.1 Module Description The Regional E-Learning Platform (REP) is a Moodle-based Learning Management System that serves as RUFORUM's primary platform for delivering structured online training, professional development, and entrepreneurship education to scholars, researchers, faculty, and SME entrepreneurs across 175 member universities in 40 African countries. The upgraded REP goes beyond a conventional LMS. In line with the contract requirements, it is designed to function simultaneously as a digital school, a professional networking hub, a career transition support system, and a gateway to the SME-Hub ecosystem. It delivers demonstrable learning outcomes, fosters community, enables smoother transitions between learning and enterprise, and generates learning analytics that feed directly into the RUFORUM M&E framework. **The REP module is organised around ten sub-processes:** - REP-SP1: User Registration and Profile Management - REP-SP2: Course and Programme Management - REP-SP3: Enrolment and Access Management - REP-SP4: Learning Delivery and Engagement - REP-SP5: Assessment and Grading Management - REP-SP6: Certification and Credential Management - REP-SP7: Learner Networking and Community Management - REP-SP8: Transition Support and Career Services - REP-SP9: Personalisation and Adaptive Learning - REP-SP10: Learning Analytics and Reporting ## 5.5.2 Sub-Process Descriptions ### REP-SP1: User Registration and Profile Management This sub-process covers how all platform users, learners, instructors, facilitators, and administrators register on the REP, verify their accounts, and manage their profiles. The current system requires users to type institution names freely, creating data inconsistencies, and mandates registration before any platform content is visible, creating barriers for potential learners. The upgraded system introduces standardised institution dropdowns, a guest preview mode, streamlined registration, enhanced professional profiles, and role-based access. **Table 53: **User Registration and Profile Management use case narrative | **Use Case: REP-SP1 User Registration and Profile Management** | | --- | | **Use Case Name** | REP-SP1: User Registration and Profile Management | | **Actor(s)** | New User (Learner / Instructor / Facilitator), Administrator, System | | **Description** | This use case describes how a new user self-registers on the REP, verifies their account, completes their professional profile, and is assigned the appropriate role. It also covers administrator-managed registration for bulk onboarding and profile updates over time. | | **Pre-condition(s)** | The REP platform is accessible via a web browser and a mobile device. The institution list (RUFORUM partner universities and TVETs) is current and loaded in the system. The email verification service is operational. | | **Main Success Scenario** | User navigates to the REP landing page. System displays a guest preview of available courses and programmes without requiring registration. User selects 'Register.' The system displays a streamlined registration form User enters first name, last name, email address, and password. User selects their institution from a standardised dropdown (RUFORUM partner list) or enters a non-partner institution via a validated free-text field. User selects their primary role: Learner, Instructor, or Facilitator. System validates all mandatory fields and checks for duplicate email addresses. On successful validation, the system creates the account, sends a verification email, and displays a confirmation message prompting the user to verify. User clicks the verification link. System activates the account and redirects the user to complete their professional profile. User completes the profile: academic qualifications, professional background, areas of interest, country, and a brief biography. (Profile photo upload is optional) System saves the profile and grants the user access based on their selected role. Administrator can view, edit, verify, deactivate, or bulk-import user accounts from the administration dashboard. Existing users can update their profiles at any time from their account settings. | | **Alternative Flows** | A1 Duplicate Email: System detects email already registered. System displays an inline error and offers a “*Forgot Password*” link. Registration is blocked. A2 Non-partner Institution: User enters an institution not in the dropdown. System flags the entry for administrator review before full access is granted. User receives a notification once approved. A3 Verification Link Expired: User clicks on an expired link. The system displays an option to resend the verification email. A4 Bulk Administrator Registration: The administrator uploads a validated CSV file. System processes the file, creates accounts, and dispatches activation emails to each new user. Errors are reported in a summary. | | **Post-condition(s)** | User account created, verified, and active in the system. Professional profile stored and searchable by other users (subject to privacy settings). User assigned correct role with appropriate platform access. Full audit trail of registration and profile updates recorded. User data available for M&E reporting on enrolment and platform demographics. | **Table 54**: Functional Requirements User Registration and Profile Management | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Guest Preview** | FRREP-UR001: The system shall allow unauthenticated users to browse a public-facing catalogue of available courses and programmes without requiring account creation. | Unauthenticated user visit | Course catalogue displayed; no personal data collected | System (automated) | | **Registration Form** | FRREP-UR002: The system shall provide a registration form collecting first name, last name, email address, password, institution (from a standardised dropdown), and primary role. | User input | Account record created in draft state pending verification | New User | | **Institution Dropdown** | FRREP-UR003: The system shall provide a standardised institution dropdown populated from the RUFORUM partner university and TVET list, with a validated free-text option for non-partner institutions requiring administrator approval. | User selection | Institution field stored with standardised value | New User, System | | **Duplicate Detection** | FRREP-UR004: The system shall detect duplicate email addresses at the point of submission and display an inline error with a 'Forgot Password' link, blocking duplicate registration. | Submitted email | Error message displayed; registration blocked | System (automated) | | **Email Verification** | FRREP-UR005: The system shall send a time-limited email verification link upon successful registration and activate the account only upon link confirmation. | Submitted registration form | Verification email sent; account activated on link click | System (automated) | | **Profile Completion** | FRREP-UR006: The system shall prompt newly verified users to complete a professional profile, including academic qualifications, professional background, areas of interest, country, and biography. | Verified user | Profile record stored and linked to the user account | Learner / Instructor | | **Profile Photo** | FRREP-UR007: The system shall allow users to upload a profile photo in standard image formats (JPEG, PNG), with a maximum file size of 2MB. | Image file upload | Photo stored and displayed on the user profile | User | | **Role Assignment** | **FRREP-UR008**: The system shall assign role-based platform access (Learner, Instructor, Facilitator, Administrator) upon account activation based on the role selected at registration. | Verified account with selected role | Role-based permissions applied | System (automated) | | **Profile Update** | **FRREP-UR009**: The system shall allow authenticated users to update their profile information at any time, logging all changes in the audit trail. | Updated profile fields | Updated profile saved; audit entry created | User | | **Admin User Management** | **FRREP-UR010**: The system shall provide administrators with an interface to view, search, filter, edit, activate, deactivate, and delete user accounts. | Administrator action | User account updated; audit log entry recorded | Administrator | | **Bulk Import** | **FRREP-UR011**: The system shall allow administrators to bulk-import user accounts via a validated CSV template, reporting on successful and failed imports. | Validated CSV file | Accounts created; activation emails sent; error report generated | Administrator, System | | **Privacy Settings** | **FRREP-UR012**: The system shall allow users to configure profile visibility settings, controlling which profile fields are visible to other platform users. | User privacy preferences | Visibility settings applied and enforced | User | | **Audit Trail** | **FRREP-UR013**: The system shall log all registration events, profile updates, role changes, and account status changes in the audit trail, capturing user ID, action type, and timestamp. | Any user or admin account action | Audit log entry stored and accessible to authorised administrators | System (automated) | ### REP-SP2: Course and Programme Management This sub-process covers the creation, configuration, structuring, publishing, and lifecycle management of courses and training programmes on the REP. Instructors and administrators build courses using a variety of content types, such as documents, videos, interactive H5P content, SCORM packages, and web resources, and organise them into structured programmes linked to RUFORUM's funded projects in RIMS. **Table 55: **Course and Programme Management use case narrative | **Use Case: REP-SP2 Course and Programme Management** | | --- | | **Use Case Name** | REP-SP2: Course and Programme Management | | **Actor(s)** | Instructor, Programme Manager, Administrator, System | | **Description** | This use case describes how an authorised Instructor or Programme Manager creates, structures, configures, and publishes a course or training programme on the REP. It covers content organisation, resource uploads, course settings, linking to RUFORUM programmes, and lifecycle management, including archiving. | | **Pre-condition(s)** | The user is authenticated and holds the Instructor, Programme Manager, or Administrator role. The RUFORUM programme or project record exists in RIMS (if the course is to be linked). Content files are ready and in supported formats. | | **Main Success Scenario** | Instructor selects “*Create New Course*.” The system displays the course setup form. Instructor enters course title, short description, full description, category, language, start date, end date, and maximum enrolment (if applicable). Instructor optionally links the course to a RUFORUM programme or grant record in RIMS by selecting from a linked programme dropdown. System saves the course record, assigns a unique Course ID, and sets the status to “*Draft*.” Instructor structures the course into topics or weekly sections using the course editor. Nested subsections are available to reduce clutter and improve navigation. Instructor adds content resources to each section: files (PDF, DOCX, XLSX), pages, books, URLs, H5P interactive content, SCORM/AICC packages, video embeds, and labels. Instructor configures activities within the course: forums, wikis, assignments, quizzes, workshops, lessons, feedback surveys, and glossaries. The instructor sets completion criteria for the course activity completion requirements that determine when a learner is considered to have completed the course. Instructor previews the course in learner view to verify layout and content. Instructor submits the course for administrator review (if approval workflow is enabled) or publishes directly. Administrator reviews and approves or returns with comments. On approval, system sets course status to “*Active*” and makes it available to learners according to enrolment settings. The instructor can edit the course content at any time. Changes are version-tracked. Enrolled learners are notified of significant updates. At the end of the course lifecycle, the administrator archives the course. Archived courses remain accessible to enrolled learners but are closed to new enrolments. | | **Alternative Flows** | A1 Unsupported File Format: Upload rejected. The system displays an error specifying allowed formats. Instructor corrects and re-uploads. A2 File Exceeds Size Limit: System rejects the file and displays the configured size limit. The instructor must compress or split the content. A3 RIMS Link Unavailable: If RIMS integration is unavailable, the instructor can save the course without a programme link and add the link later. A4 Course Returned by Administrator: The administrator returns the course with comments. Instructor revises and resubmits. A5 Duplicate Course Title: The system warns if a course with the same title exists in the same category. The instructor may proceed or rename. | | **Post-condition(s)** | i. Course record stored with unique Course ID, status, and all configured settings. ii. Course linked to the RUFORUM programme in RIMS where applicable. iii. Content resources uploaded, validated, and indexed for search. iv. Completion criteria configured and enforceable by the system. v. Course visible to learners based on enrolment settings and start date. vi. Audit trail of all course creation, editing, approval, and archiving actions recorded. | **Table 56: **Functional Requirements Course and Programme Management | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Course Creation** | FRREP-CM001: The system shall allow authorised instructors and programme managers to create a new course by providing a title, description, category, language, start and end dates, and enrolment limits. | Instructor input | Course record created with unique Course ID; status set to Draft | Instructor / Programme Manager | | **RIMS Programme Link** | FRREP-CM002: The system shall allow instructors to link a course to a RUFORUM programme or grant record in RIMS using a linked programme dropdown, enabling cross-system tracking. | Selected RIMS programme record | Course-programme relationship stored; linkage visible on both systems | Instructor, System | | **Content Structuring** | FRREP-CM003: The system shall allow instructors to structure courses into topics or weekly sections with nested, collapsible subsections for content organisation. | Instructor configuration | Course structure saved and rendered for learners | Instructor | | **Resource Upload** | FRREP-CM004: The system shall allow instructors to upload and embed content resources including PDF, DOCX, XLSX, video, H5P interactive packages, SCORM/AICC packages, and external URLs. | Content file or URL | Resource stored, indexed, and available within the course | Instructor | | **File Validation** | FRREP-CM005: The system shall validate uploaded files for format compliance, size limits, and malware before storing them, rejecting non-compliant files with a specific error message. | Uploaded file | Valid file stored; invalid file rejected with error message | System (automated) | | **Activity Configuration** | FRREP-CM006: The system shall allow instructors to add and configure interactive activities within courses, including forums, wikis, assignments, quizzes, workshops, lessons, feedback surveys, and glossaries. | Instructor configuration | Activities configured, saved, and linked to the course gradebook | Instructor | | **Completion Criteria** | FRREP-CM007: The system shall allow instructors to define course completion criteria based on activity completion, minimum grade thresholds, or a combination of both. | Instructor-defined criteria | Completion criteria are stored and enforced by the system for each learner | Instructor, System | | **Approval Workflow** | FRREP-CM008: The system shall support an optional administrator review and approval workflow before a course is published, allowing administrators to approve or return courses with comments. | Course submitted for review | Course approved and published, or returned with comments | Administrator | | **Version Tracking** | FRREP-CM009: The system shall version-track all changes to course content and settings, retaining the previous version and logging the change with user ID and timestamp. | Content or settings edit | Version record created; change logged in audit trail | System (automated) | | **Learner Notification** | FRREP-CM010: The system shall notify enrolled learners when significant course updates are made, including new content additions, deadline changes, or assessment modifications. | Course update event | Notification dispatched to enrolled learners | System (automated) | | **Course Archiving** | FRREP-CM011: The system shall allow administrators to archive completed courses, preserving access for previously enrolled learners while closing new enrolments. | Administrator archive action | Course status set to Archived; enrolment portal closed; existing access preserved | Administrator | | **Audit Trail** | FRREP-CM012: The system shall log all course creation, editing, approval, publishing, and archiving actions in the audit trail, capturing user ID, action type, and timestamp. | Any course management action | Audit log entry stored and accessible to authorised administrators | System (automated) | ### REP-SP3: Enrolment and Access Management This sub-process manages how learners gain access to courses through self-enrolment, administrator-managed enrolment, cohort-based enrolment, or automatic enrolment triggered by RIMS when a beneficiary is awarded a scholarship or grant that includes a mandatory training component. It also covers prerequisites, access restrictions, and enrolment reporting. **Table 57: **Enrolment and Access Management use case narrative | **Use Case: REP-SP3 Enrolment and Access Management** | | --- | | **Use Case Name** | REP-SP3: Enrolment and Access Management | | **Actor(s)** | Learner, Administrator, RIMS System (automated), Instructor | | **Description** | This use case describes the various pathways through which learners are enrolled in courses on the REP. It covers self-enrolment by learners, manual enrolment by administrators, cohort-based enrolment, and automated enrolment triggered by RIMS when a beneficiary record is linked to a course. It also covers prerequisite checking and access restriction management. | | **Pre-condition(s)** | i. The course is published and active on the REP. ii. The learner has a verified REP account. iii. For RIMS-triggered enrolment, the RIMS-REP integration is active, and the beneficiary record is linked to the course. | | **Main Success Scenario** | Learner browses the course catalogue and selects a course of interest. System checks the learner's eligibility based on configured prerequisites (completed prior courses, required qualifications, or programme membership). If eligible, learner selects “*Enrol*.” If a self-enrolment key is required, the learner enters the key. System enrols the learner, sets enrolment status to “*Active*,” and grants access to course content. System sends an enrolment confirmation notification to the learner. System logs the enrolment event and updates the M&E module with the enrolment indicator. For RIMS-triggered enrolment: upon award confirmation in RIMS, RIMS sends an automated enrolment trigger to REP via the integration API. System auto-enrolls the beneficiary in the linked course without requiring learner action. For cohort enrolment: the administrator creates or updates a cohort and assigns the cohort to a course. The s++ystem enrols all cohort members simultaneously. For manual enrolment: the administrator searches for a user and enrols them directly in a course, selecting the enrolment role. Administrator can view all enrolments for a course, filter by status, and generate enrolment reports. | | **Alternative Flows** | A1 Prerequisite Not Met: System displays the unmet prerequisite and blocks enrolment. The learner is directed to complete the prerequisite course first. A2 Course Full: The system displays “Course Full' and offers a waitlist option. Learner added to waitlist and notified when space becomes available. A3 Incorrect Enrolment Key: System displays an error and allows a retry. After three failed attempts, the system locks the key field and directs the learner to contact the instructor. A4 RIMS Integration Failure: If RIMS trigger fails, the system logs the failure, alerts the administrator, and allows manual enrolment as a fallback. A5 Learner Withdraws: Learner or administrator withdraws enrolment. System sets status to “*Withdrawn*,” retains completion data up to that point, and logs the event. | | **Post-condition(s)** | i. Learner enrolment record created with status 'Active' and linked to the course and learner account. ii. Learner has access to course content according to configured restrictions. iii. Enrolment confirmation notification sent to learner. iv. M&E module updated with enrolment indicator data. v. Audit trail entry recorded for the enrolment event. vi. Enrolment data available for administrator reporting. | **Table 58**: Functional Requirements Enrolment and Access Management | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Self-Enrolment** | FRREP-EN001: The system shall allow eligible learners to self-enrol in published courses through the course catalogue, with optional enrolment key protection configured by the instructor. | Learner enrolment action | Enrolment record created; access granted; confirmation notification sent | Learner, System | | **Prerequisite Checking** | FRREP-EN002: The system shall automatically check configured prerequisites before allowing enrolment, blocking enrolment, and displaying the unmet prerequisite if conditions are not satisfied. | Enrolment attempt | Prerequisites verified; enrolment allowed or blocked with reason displayed | System (automated) | | **RIMS Auto-Enrolment** | FRREP-EN003: The system shall accept automated enrolment triggers from RIMS via the integration API, enrolling beneficiaries in linked courses upon award confirmation without requiring learner action. | RIMS award confirmation event | Beneficiary enrolled; enrolment record created; notification sent; M&E updated | RIMS System (automated) | | **Cohort Enrolment** | FRREP-EN004: The system shall allow administrators to create learner cohorts and enrol all cohort members in a course simultaneously. | Administrator cohort assignment | All cohort members enrolled; individual enrolment records created | Administrator | | **Manual Enrolment** | FRREP-EN005: The system shall allow administrators and instructors to manually enrol individual learners in courses, selecting the enrolment role. | Administrator enrolment action | Enrolment record created; access granted; notification sent | Administrator / Instructor | | **Waitlist Management** | FRREP-EN006: The system shall manage a waitlist for courses that have reached maximum enrolment, automatically enrolling waitlisted learners and notifying them when space becomes available. | Course capacity reached | Waitlist record created; learner notified of position; auto-enrolment on space availability | System (automated) | | **Access Restrictions** | FRREP-EN007: The system shall allow instructors to configure date-based, grade-based, and activity completion-based access restrictions on course sections and resources. | Instructor restriction configuration | Restrictions stored and enforced; restricted content hidden or greyed out for ineligible learners | Instructor, System | | **Enrolment Withdrawal** | FRREP-EN008: The system shall allow learners and administrators to withdraw from a course, retaining all completion data up to the point of withdrawal and logging the event. | Withdrawal request | Enrolment status set to Withdrawn; data retained; audit log entry created | Learner / Administrator | | **Enrolment Reporting** | FRREP-EN009: The system shall provide administrators and instructors with enrolment reports showing total enrolments per course, active vs withdrawn, cohort breakdowns, and RIMS-triggered vs self-enrolled counts, exportable to CSV and PDF. | Report generation request | Enrolment report generated and available for download | Administrator / Instructor | | **M****&****E Feed** | FRREP-EN010: The system shall trigger the M&E module to record an enrolment indicator each time a learner is enrolled in a course, passing the course ID, learner ID, programme linkage, and enrolment date. | Enrolment event | M&E indicator record updated; data available for reporting | System (automated) | | **Audit Trail** | FRREP-EN011: The system shall log all enrolment, withdrawal, cohort assignment, and access restriction changes in the audit trail, capturing user ID, action type, and timestamp. | Any enrolment management action | Audit log entry stored and accessible to authorised administrators | System (automated) | ### REP-SP4: Learning Delivery and Engagement This sub-process covers the actual delivery of learning experiences, both synchronous and asynchronous, and the interactive tools that promote active participation, collaboration, and knowledge sharing. It encompasses live virtual classes, asynchronous content consumption, collaborative tools, surveys, and peer interaction features. This is the core learner-facing experience of the REP. **Table 59: **Learning Delivery and Engagement Use Case Narrative | **Use Case: REP-SP4 Learning Delivery and Engagement** | | --- | | **Use Case Name** | REP-SP4: Learning Delivery and Engagement | | **Actor(s)** | Learner, Instructor, Facilitator, System | | **Description** | This use case describes how learners access and engage with course content and interactive activities within the REP. It covers asynchronous content consumption (videos, readings, H5P, SCORM), synchronous live sessions via BigBlueButton, collaborative tools (forums, wikis, glossaries), and learner feedback tools. | | **Pre-condition(s)** | Learner is enrolled and has active access to the course. Course content and activities are configured and published by the instructor. For live sessions, BigBlueButton is operational. | | **Main Success Scenario** | Learner accesses the course from their dashboard. System displays course sections and content based on configured access restrictions and completion progress. Learner accesses asynchronous content: pages, books, PDFs, videos, H5P interactive activities, SCORM packages, and external URL resources. The System tracks learner activity content viewed, time spent, H5P/SCORM scores, and updates the learner's completion progress. Instructor schedules a live virtual class using BigBlueButton. System notifies enrolled learners with the session date, time, and join link. At session time, the learner joins the live class. Session features include real-time video/audio, screen sharing, breakout rooms, multi-user whiteboard, live polls, and recording. After the session, the recording is made available in the course for learners who could not attend. Learner participates in discussion forums: creates new threads, replies to existing posts, and receives notifications on followed threads. Learner collaborates in a course wiki, contributing to shared content for group projects or collaborative note-taking. Learner responds to a feedback survey created by the instructor to provide non-graded qualitative and quantitative feedback on the course or specific sessions. Learner uses the choice activity to participate in polls or vote on course topics. Instructor monitors learner engagement from the instructor dashboard, viewing activity completion, last access, and participation in interactive tools. | | **Alternative Flows** | A1 Content Not Yet Available: The System displays a message explaining the access restriction reason (e.g., 'Available from [date]' or 'Complete [activity] first'). A2 Live Session Connection Failure: The System displays a reconnection prompt. Session recording remains available after the session ends. A3 SCORM Package Error: The System logs the error and displays a message to the learner to contact the instructor. Instructor is notified. A4 Forum Post Flagged: Learner or system flags a post as inappropriate. The administrator is notified for moderation. | | **Post-condition(s)** | i. Learner activity and progress data recorded in the system. ii. Completion status updated based on configured criteria. iii. Live session recording stored and linked to the course. iv. Forum, wiki, and survey contributions stored and associated with the learner. v. Engagement data available for instructor dashboard and M&E analytics feed. | **Table 60**: Functional Requirements Learning Delivery and Engagement | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Content Access** | FRREP-LD001: The system shall display course sections and content to enrolled learners according to configured access restrictions, showing clear messages when content is not yet available. | Learner course access | Content displayed or a restriction message shown with the reason | System (automated) | | **Progress Tracking** | FRREP-LD002: The system shall automatically track and record learner activity, including pages viewed, time spent on resources, H5P interaction scores, and SCORM completion status. | Learner content interaction | Progress record updated; completion criteria evaluated | System (automated) | | **Live Virtual Classes** | FRREP-LD003: The system shall allow instructors to schedule, launch, and manage live virtual classes using BigBlueButton, supporting video/audio conferencing, screen sharing, breakout rooms, multi-user whiteboards, live polls, and session recording. | Instructor session creation | Live session created; learner notifications sent; recording stored post-session | Instructor, System | | **Session Recording** | FRREP-LD004: The system shall store live session recordings and make them available within the course for enrolled learners after the session ends. | Session end event | Recording stored and linked to the course; learner notification sent | System (automated) | | **Discussion Forums** | FRREP-LD005: The system shall provide threaded discussion forums within courses, supporting new thread creation, replies, subscriptions, post tracking, and file attachments. | Learner or instructor forum action | Post stored; notifications sent to subscribers; forum index updated | Learner / Instructor | | **Collaborative Wiki** | FRREP-LD006: The system shall provide a collaborative wiki within courses, allowing multiple learners to create, edit, and link content pages for group projects and shared note-taking. | Learner wiki edit | Wiki content saved; edit history retained; changes visible to all wiki members | Learner | | **Feedback Surveys** | FRREP-LD007: The system shall allow instructors to create non-graded feedback surveys with multiple question types, including multiple choice, rating scale, short answer, and essay, with an option for anonymous responses. | Learner survey response | Response stored; instructor survey results aggregated and available for review | Instructor, Learner | | **Interactive Content** | FRREP-LD008: The system shall support H5P interactive content types, including interactive video, quizzes, presentations, and games, with learner attempt data sent to the gradebook. | Learner H5P interaction | Attempt data stored; score sent to gradebook; completion updated | System (automated) | | **SCORM Delivery** | FRREP-LD009: The system shall deliver SCORM and AICC-compliant e-learning packages, tracking learner progress, completion status, time spent, and quiz responses, sending results to the gradebook. | Learner SCORM interaction | SCORM session data recorded; completion and grade sent to gradebook | System (automated) | | **Mobile Delivery** | FRREP-LD010: The system shall deliver all content types and interactive activities in a fully responsive interface that is functional on mobile devices and tablets without loss of features. | Learner mobile device access | Content and activities rendered correctly on the mobile screen | System | | **Engagement Dashboard** | FRREP-LD011: The system shall provide instructors with an engagement dashboard showing per-learner activity metrics, including last access, content viewed, time spent, and forum participation. | Instructor dashboard access | Engagement report rendered with per-learner metrics | System (automated) | | **Audit Trail** | FRREP-LD012: The system shall log all learner content access, activity completions, live session attendance, and forum/wiki contributions in the audit trail. | Learner engagement event | Audit log entry stored | System (automated) | ### REP-SP5: Assessment and Grading Management This sub-process covers the full assessment lifecycle, creating assessments, managing submissions, grading, providing feedback, managing the gradebook, and supporting peer assessment. It ensures that assessment is rigorous, fair, and transparent, with results feeding into completion tracking and M&E reporting. | **Use Case: REP-SP5 Assessment and Grading Management** | | --- | | **Use Case Name** | REP-SP5: Assessment and Grading Management | | **Actor(s)** | Instructor, Learner, System, Administrator | | **Description** | This use case describes how instructors create and configure assessments, how learners submit their work, how grading and feedback are managed, and how grades are recorded in the gradebook. It covers quizzes, assignments, and peer assessment through the Workshop module. | | **Pre-condition(s)** | Course is published, and learners are enrolled. Instructor holds the Instructor or Facilitator role for the course. The Question bank is populated for quiz-based assessments. | | **Main Success Scenario** | The instructor creates a quiz using the quiz editor. Instructor selects questions from the Question Bank, configuring question types, marks, time limits, attempt limits, and feedback settings. The instructor configures question randomisation and sets the quiz availability window. Learner accesses the quiz during the availability window and completes the assessment. System auto-grades objective questions (multiple choice, true/false, matching) and records scores. Manual questions (essay) are flagged for instructor review. After the attempt, the system displays feedback to the learner as configured by the instructor immediately, after the deadline, or after manual marking. Instructor creates an assignment activity, configuring submission type (file upload, online text, or both), deadline, late submission rules, and grading criteria. Learner submits the assignment before the deadline. System confirms submission and notifies the instructor. Instructor grades the submission, entering a mark and written feedback. The instructor may annotate uploaded files directly in the grading interface. System records the grade in the gradebook and notifies the learner. For peer assessment, the instructor configures a Workshop activity with submission, peer review, and grading phases. Learners submit their work, then review and grade assigned peers' submissions against instructor-defined criteria. System aggregates peer grades and calculates final Workshop grades Gradebook displays all assessment grades for each learner, with running totals, weighted averages, and the course total grade. | | **Alternative Flows** | A1 Learner Misses Deadline: The system marks the submission as late. If late submissions are allowed, learners can still submit with a configurable grade penalty applied. If not allowed, submission is locked. **A2 Quiz Time Expires: ** The system auto-submits the quiz at the time limit. The learner receives confirmation of auto-submission. A3 Grade Override: The instructor may override a system-calculated grade, entering a manual grade with a mandatory reason recorded in the audit trail. A4 Grade Appeal: The learner disputes a grade through a structured appeal process. The instructor reviews and updates or upholds the grade, with all actions logged. | | **Post-condition(s)** | Assessment submissions stored securely and linked to learner and course records. Grades recorded in the gradebook with instructor feedback. Completion criteria evaluated and updated based on grade thresholds. Learner notified of grade and feedback. v. Grade data available for M&E analytics and reporting. vi. Full audit trail of all grading and grade modification actions recorded. | **Table 61**: Functional Requirements Assessment and Grading Management | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Quiz Creation** | FRREP-AG001: The system shall allow instructors to create quizzes with questions drawn from the Question Bank, supporting question types including multiple choice, true/false, short answer, matching, drag-and-drop, and essay. | Instructor quiz configuration | Quiz activity created and linked to the course | Instructor | | **Question Bank** | FRREP-AG002: The system shall provide a centralised Question Bank allowing instructors to create, organise by category and topic, tag, and reuse questions across multiple quizzes, with support for question randomisation. | Instructor question creation | Question stored in bank; available for quiz selection | Instructor | | **Quiz Settings** | FRREP-AG003: The system shall allow instructors to configure quiz availability windows, time limits, attempt limits, shuffle settings, and feedback display timing. | Instructor settings configuration | Quiz settings are stored and enforced at learner access | Instructor, System | | **Auto-Grading** | FRREP-AG004: The system shall automatically grade objective quiz questions upon submission, recording scores in the gradebook, and flag essay questions for manual instructor marking. | Learner quiz submission | Objective scores recorded; essay questions marked as pending; learner notified | System (automated) | | **Assignment Submission** | FRREP-AG005: The system shall allow learners to submit assignments as file uploads (PDF, DOCX, and other configured formats), online text, or both, before the configured deadline. | Learner submission action | Submission stored; confirmation notification sent to learner and instructor | Learner, System | | **Late Submission Handling** | FRREP-AG006: The system shall apply configurable late submission rules allowing or blocking late submissions with an optional grade penalty and record the submission timestamp. | Submission after deadline | Late submission recorded with timestamp; penalty applied if configured | System (automated) | | **Instructor Grading** | FRREP-AG007: The system shall provide an instructor grading interface supporting numeric and scale grades, written feedback, and direct annotation of uploaded assignment files. | Instructor grading action | Grade and feedback stored; learner notified; gradebook updated | Instructor | | **Workshop / Peer Assessment** | FRREP-AG008: The system shall support peer assessment through the Workshop module, managing submission, peer review allocation, grading, and grade aggregation phases with instructor-defined assessment criteria. | Learner and instructor workshop actions | Peer grades collected and aggregated; Workshop grades recorded in the gradebook | Instructor, Learner, System | | **Gradebook** | FRREP-AG009: The system shall maintain a gradebook for each course displaying all assessment grades per learner, with configurable weighting, running course totals, and exportable grade reports. | Grade recording event | Gradebook updated; course total recalculated | System (automated) | | **Grade Override** | FRREP-AG010: The system shall allow instructors to override system-calculated grades, requiring a mandatory reason, logging the override in the audit trail with previous and new values. | Instructor grade override | Grade updated; audit log entry recording original grade, new grade, and reason | Instructor | | **Learner Grade View** | FRREP-AG011: The system shall provide learners with a personal gradebook view showing their grades, feedback, and standing relative to course completion requirements. | Learner gradebook access | Personalised grade summary displayed | System (automated) | | **M****&****E Feed** | FRREP-AG012: The system shall trigger the M&E module to record assessment performance indicators on quiz completion and assignment grading events, passing learner ID, course ID, assessment type, score, and date. | Assessment completion event | M&E indicator record updated | System (automated) | | **Audit Trail** | FRREP-AG013: The system shall log all quiz attempts, assignment submissions, grading actions, and grade overrides in the audit trail, capturing user ID, action type, timestamp, and where applicable previous and new values. | Any assessment or grading event | Audit log entry stored | System (automated) | ### REP-SP6: Certification and Credential Management This sub-process covers the design, automated issuance, delivery, and verification of digital certificates upon course completion. Using the customcert plugin, the system generates personalised PDF certificates, enables QR code verification by third parties, and maintains a full record of certificates issued per learner. Certification rates are a key M&E indicator for RUFORUM. **Table 62: **Certification and Credential Management use case narrative | **Use Case: REP-SP6 Certification and Credential Management** | | --- | | **Use Case Name** | REP-SP6: Certification and Credential Management | | **Actor(s)** | Administrator, Instructor, Learner, System, External Verifier | | **Description** | This use case describes how certificate templates are designed and configured, how certificates are automatically generated and delivered to learners upon meeting course completion criteria, how learners access their certificates, and how external parties verify certificate authenticity. | | **Pre-condition(s)** | i. Course completion criteria are configured and active. ii. At least one certificate template has been created for the course. iii. RUFORUM branding assets (logo, colours, signatures) are uploaded. | | **Main Success Scenario** | Administrator or instructor opens the certificate editor for a course. The editor provides a drag-and-drop interface for designing the certificate layout. Instructor adds dynamic elements to the template: learner name, course name, completion date, grade, instructor name, RUFORUM logo, authorising signature, and QR code for verification. Instructor configures the completion conditions that trigger certificate issuance, e.g., course marked as complete, minimum grade of X%, or specific activities completed. Instructor saves the template. The administrator may promote it to a site-wide template for reuse across courses. When a learner meets the configured completion conditions, the system automatically generates a personalised PDF certificate. The system assigns the certificate a unique verification code and stores the certificate record linked to the learner and course. The System dispatches an email to the learner with the certificate as a PDF attachment and a verification link. Learner accesses “*My Certificates*” from their profile to view and download all certificates received. External verifier (employer, institution) visits the certificate verification URL or scans the QR code. The system displays the certificate details confirming authenticity. Instructors can view, download, or revoke certificates for their course. Revoked certificates display a 'Revoked' status at the verification URL. | | **Alternative Flows** | A1 Completion Criteria Not Met: Certificate is not generated. The system does not notify the learner of a pending certificate until the criteria are met. A2 Email Delivery Failure: The system retries email delivery and logs the failure. The learner can access the certificate from 'My Certificates' regardless. A3 Certificate Revocation: The instructor revokes the certificate with a mandatory reason. Revocation recorded in the audit trail. Verification URL displays revoked status. A4 Template Not Configured: If no certificate template is configured, the system alerts the instructor. No certificate is auto-generated until a template is set. | | **Post-condition(s)** | Certificate generated as a personalised PDF with a unique verification code. Certificate stored and accessible from the learner’s “*My Certificates*” page. Certificate emailed to the learner. Verification URL active and returning correct certificate details to external verifiers. Certificate issuance recorded in audit trail. M&E module updated with course completion and certification indicator. | **Table REP-SP6-FR: Functional Requirements Certification and Credential Management** | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Certificate Template Design** | FRREP-CC001: The system shall provide a drag-and-drop certificate editor allowing instructors and administrators to design certificate templates with configurable elements, including learner name, course name, date, grade, instructor name, RUFORUM logo, signature, and QR code. | Instructor/admin template design action | Certificate template saved and linked to the course | Instructor / Administrator | | **Dynamic Element Population** | FRREP-CC002: The system shall automatically populate all dynamic elements in the certificate template with learner-specific data at the point of generation. | Certificate generation trigger | Personalised certificate generated with accurate learner data | System (automated) | | **Completion Trigger** | FRREP-CC003: The system shall automatically generate and issue a certificate when a learner meets the configured completion criteria for the course. | Learner completion event | Certificate generated; unique verification code assigned; certificate stored | System (automated) | | **Unique Verification Code** | FRREP-CC004: The system shall assign each generated certificate a unique verification code and create a publicly accessible verification URL returning the certificate's authenticity status and details. | Certificate generation | Verification code assigned; verification URL active | System (automated) | | **QR Code** | FRREP-CC005: The system shall embed a QR code on each certificate that, when scanned, directs the scanner to the certificate's verification URL. | Certificate generation | QR code embedded on PDF certificate | System (automated) | | **Certificate Email** | FRREP-CC006: The system shall automatically email the learner their certificate as a PDF attachment with the verification link upon certificate issuance. | Certificate issuance event | Email dispatched with PDF attachment and verification link | System (automated) | | **My Certificates** | FRREP-CC007: The system shall provide each learner with a 'My Certificates' section in their profile where they can view, download, and share all certificates received. | Learner access | Certificates listed with course name, date, and download link | System (automated) | | **Site-Wide Templates** | FRREP-CC008: The system shall allow administrators to promote certificate templates to site-wide templates, making them available to all instructors for use in their courses. | Admin promotion action | Template available in the site-wide template library | Administrator | | **Certificate Revocation** | FRREP-CC009: The system shall allow instructors and administrators to revoke a certificate, requiring a mandatory written reason, updating the verification URL to display 'Revoked' status, and logging the action in the audit trail. | Instructor/admin revocation action | Certificate status set to Revoked; verification URL updated; audit log entry recorded | Instructor / Administrator | | **Instructor Certificate View** | FRREP-CC010: The system shall provide instructors with a list of all certificates issued for their course, with options to view, download, or revoke individual certificates. | Instructor access | Certificate list rendered with learner names, dates, and actions | Instructor | | **M****&****E Feed** | FRREP-CC011: The system shall trigger the M&E module to record a course completion and certification indicator upon each certificate issuance, passing the learner ID, course ID, programme linkage, and date. | Certificate issuance event | M&E indicator record updated | System (automated) | | **Audit Trail** | FRREP-CC012: The system shall log all certificate generation, email delivery, revocation, and template modification actions in the audit trail capturing user ID, action type, and timestamp. | Any certification action | Audit log entry stored | System (automated) | ### REP-SP7: Learner Networking and Community Management This sub-process covers the social and networking features of the REP. The contract explicitly requires enhanced user profiles with professional background and expertise, social features including chat and groups, and tools to connect learners with peers, mentors, alumni, and industry professionals. This sub-process moves the REP beyond a conventional LMS toward a professional learning community. | **Use Case: REP-SP7 Learner Networking and Community Management** | | --- | | **Use Case Name** | REP-SP7: Learner Networking and Community Management | | **Actor(s)** | Learner, Instructor, Mentor, Administrator, System | | **Description** | This use case describes how learners discover and connect with peers, mentors, alumni, and industry professionals on the REP. It covers profile discovery, connection requests, direct messaging, learning groups, community forums, and mentor matching. | | **Pre-condition(s)** | i. User is authenticated and has a completed professional profile. ii. Profile visibility settings allow the user to appear in search and discovery. iii. For mentor matching, a verified mentor pool is available in the system. | | **Main Success Scenario** | 1. Learner navigates to the 'Network' section. System displays a discovery feed of platform users filtered by course membership, institution, area of interest, and country. 2. Learner searches for a specific user by name, institution, or area of expertise. 3. Learner sends a connection request to another user. The recipient receives a notification and may accept or decline. 4. Upon acceptance, both users are added to each other's connections list. System updates the connection count on both profiles. 5. Connected users can exchange direct messages through the platform messaging system. Messages support text, file attachments, and emoji. 6. Learner joins or creates a learning group around a shared interest, course, or programme. Group features include a discussion feed, shared resources, and a member directory. 7. The instructor or administrator creates a mentorship opportunity. Learners can apply for mentorship and are matched with available mentors based on area of interest and expertise. 8. Matched learner and mentor can communicate via the platform messaging system and schedule virtual sessions. 9. Platform surfaces networking recommendations to other users with similar interests, course co-enrollees, and alumni from the same institution or programme. | | **Alternative Flows** | A1 Connection Request Declined: Declined request is removed. No further action. The requesting user is not notified of the reason. A2 Message Blocked: User has blocked messaging from a specific connection. System notifies the sender that messages cannot be delivered to this user. A3 Inappropriate Content Report: User reports a message or group post. The administrator is notified and reviews. Content may be removed, and the user account flagged. A4 No Mentor Available: System displays a message that no mentors are currently available in the selected area. Learners can register interest and be notified when a mentor becomes available. | | **Post-condition(s)** | i. Connection records are stored and linked to both user profiles. ii. Messages stored securely and accessible to the conversation participants. iii. Group memberships, posts, and shared resources stored. iv. Mentor-learner match record created and tracked. v. All networking actions logged in the audit trail. | **Table REP-SP7-FR: Functional Requirements Learner Networking and Community Management** | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **User Discovery** | FRREP-NW001: The system shall provide a user discovery feature allowing authenticated users to search for and browse other platform users by name, institution, area of interest, country, and course enrolment. | User search query | Filtered user list displayed based on privacy settings | System (automated) | | **Connection Requests** | FRREP-NW002: The system shall allow users to send, receive, accept, and decline connection requests, with notifications to the recipient and confirmation to the sender upon acceptance. | Connection request action | Connection record created; both users added to each other's connection list | User, System | | **Direct Messaging** | FRREP-NW003: The system shall provide a direct messaging system allowing connected users to exchange text messages and file attachments, with message delivery notifications. | User message send action | Message stored; notification sent to recipient | User, System | | **Learning Groups** | FRREP-NW004: The system shall allow users to create and join learning groups with a discussion feed, shared file resources, and a group member directory. | User group creation or join action | Group record created or membership added; group feed accessible | User, Administrator | | **Mentor Matching** | FRREP-NW005: The system shall support a mentorship matching feature allowing administrators to publish mentorship opportunities and match learners with mentors based on area of interest and expertise. | Mentorship application and admin match action | Mentor-learner match record created; notification sent to both parties | Administrator, System | | **Networking Recommendations** | FRREP-NW006: The system shall surface networking recommendations to users based on shared course enrolments, institution, area of interest, and programme membership. | User profile and activity data | Recommended connections displayed on the user's network feed | System (automated) | | **Message Moderation** | FRREP-NW007: The system shall allow users to report messages and group posts as inappropriate. Administrators shall be notified and provided tools to review, remove content, and take action on the reporting user's account. | User report action | Report logged; administrator notified; moderation interface updated | User, Administrator | | **Privacy Controls** | FRREP-NW008: The system shall allow users to configure networking privacy settings, including whether they appear in user discovery, who can send them connection requests, and who can message them. | User privacy settings update | Privacy preferences are applied and enforced across networking features | User | | **Audit Trail** | FRREP-NW009: The system shall log all connection events, group creation, membership changes, and moderation actions in the audit trail. | Any networking management action | Audit log entry stored | System (automated) | ### REP-SP8: Transition Support and Career Services This sub-process is explicitly required by the contract under 'Transition Support (to be linked to the Alumni Platform).' It covers career guidance resources, a job and internship board, and CV/resume building tools. It is the primary integration point between the REP and the Alumni module, ensuring that learners have access to career transition support from within the learning platform. | **Use Case: REP-SP8 Transition Support and Career Services** | | --- | | **Use Case Name** | REP-SP8: Transition Support and Career Services | | **Actor(s)** | Learner, Administrator, Employer / Partner Organisation, Alumni Module, System | | **Description** | This use case describes how learners access career guidance resources, search and apply for job and internship opportunities posted by employers and partner organisations, and build their CVs using the REP's CV builder. It also covers how this sub-process links to the Alumni module for post-graduation tracking. | | **Pre-condition(s)** | i. Learner is authenticated and enrolled in at least one active course or programme. ii. Career resources and job listings are configured and published by administrators. iii. The Alumni module integration is active for post-graduation data sharing. | | **Main Success Scenario** | 1. Learner navigates to the 'Career Services' section. System displays a curated library of career guidance resources: articles, videos, and guides on career transitions, professional development, and job search strategies. 2. Learner browses or searches the job and internship board. Listings are posted by employers, partner organisations, and RUFORUM network institutions. 3. Learner filters job listings by type (full-time, internship, consultancy), sector, country, and required qualifications. 4. Learner views a job listing and selects 'Apply.' System redirects to the employer's application portal or facilitates an in-platform application. 5. Learner opens the CV builder. System provides a structured template with sections for personal information, education, work experience, skills, publications, and references. 6. Learner completes the CV builder, pre-populated where possible from their REP profile data. Learner can download the completed CV as a PDF. 7. Administrator posts a new job or internship listing by entering employer name, opportunity title, description, required qualifications, deadline, and application link. 8. Upon course or programme completion, the system passes the learner's profile and completion data to the Alumni module for post-graduation tracking. 9. Employer or partner organisation can submit job listings for administrator approval before publication. | | **Alternative Flows** | A1 Job Listing Expired: System removes expired listings from the active board automatically at the posting deadline. A2 CV Download Failure: System retries PDF generation. Learner is notified if the download fails and prompted to try again. A3 In-Platform Application: If the employer has configured in-platform applications, learner's application and attached CV are submitted within the REP. Administrator notified. | | **Post-condition(s)** | i. Career resource access logged for analytics. ii. Job and internship listings stored and searchable on the platform. iii. CV data stored against the learner's profile and downloadable as PDF. iv. Learner completion and profile data passed to the Alumni module upon graduation. v. Employer-submitted listings reviewed and published by administrator. vi. All career services actions logged in the audit trail. | **Table REP-SP8-FR: Functional Requirements Transition Support and Career Services** | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Career Resource Library** | FRREP-TS001: The system shall provide a searchable library of career guidance resources including articles, videos, and guides, organised by career stage, sector, and topic. | Learner resource access | Resource displayed; access logged for analytics | System (automated) | | **Job and Internship Board** | FRREP-TS002: The system shall provide a job and internship board displaying listings posted by employers and partner organisations, with filters for type, sector, country, and qualification requirements. | Learner or admin access | Job listings displayed and filterable | System | | **Job Listing Management** | FRREP-TS003: The system shall allow administrators and authorised employers to post, edit, and remove job and internship listings, with an optional administrator approval workflow before publication. | Admin or employer listing action | Listing created, approved, and published or returned with comments | Administrator / Employer | | **Listing Expiry** | FRREP-TS004: The system shall automatically remove or archive job listings at their configured application deadline. | Deadline event | Listing status set to Expired and removed from the active board | System (automated) | | **CV Builder** | FRREP-TS005: The system shall provide a structured CV builder with sections for personal information, education, work experience, skills, publications, and references, pre-populated from the learner's REP profile where data is available. | Learner CV builder access | CV data stored against the learner profile | Learner | | **CV PDF Download** | FRREP-TS006: The system shall allow learners to download their completed CV as a formatted PDF at any time. | Learner download action | PDF generated from CV data and downloaded | System (automated) | | **Alumni Module Handoff** | FRREP-TS007: The system shall, upon a learner's programme completion, pass the learner's profile, completion records, and certification data to the Alumni module for post-graduation tracking. | Programme completion event | Data payload sent to Alumni module; transfer confirmed and logged | System (automated) | | **Application Tracking** | FRREP-TS008: The system shall allow learners to save job listings and track their application status for in-platform applications. | Learner application action | Application record created; status trackable by learner | Learner, System | | **Audit Trail** | FRREP-TS009: The system shall log all career resource access, job listing management, CV builder activity, and alumni handoff events in the audit trail. | Any career services action | Audit log entry stored | System (automated) | ### REP-SP9: Personalisation and Adaptive Learning This sub-process addresses the contract requirement for personalised course and resource recommendations using machine learning algorithms and adaptive learning features that tailor content based on individual learning styles and needs. It also supports the scope requirement for AI-based features in the IILMP. | **Use Case: REP-SP9 Personalisation and Adaptive Learning** | | --- | | **Use Case Name** | REP-SP9: Personalisation and Adaptive Learning | | **Actor(s)** | Learner, System (AI Engine), Administrator, Instructor | | **Description** | This use case describes how the REP personalises the learning experience for each learner through course recommendations, adaptive content sequencing based on performance, and a personalised learner dashboard. It covers the AI recommendation engine and the adaptive lesson features. | | **Pre-condition(s)** | Learner has a completed profile with areas of interest and prior qualifications. Learner has engaged with the platform (enrolled in at least one course or completed onboarding). iii. Sufficient learner activity data is available to drive recommendations. | | **Main Success Scenario** | Learner logs in. System displays a personalised dashboard with recommended courses, resources, and learning activities based on the learner's profile, interests, programme membership, and activity history. Recommendation engine analyses the learner's completed courses, assessment performance, areas of interest, and peer engagement to generate ranked course and resource recommendations. Learner selects a recommended course and enrols. System tracks the recommendation-to-enrolment conversion. Within a course, adaptive content sequencing is active. Learner completes a lesson or quiz. If the learner scores below a configured threshold, the system presents additional reinforcement content before allowing progression to the next topic. If the learner scores above a configured mastery threshold, the system offers an option to skip foundational content and progress to advanced material. System continuously updates the learner's recommendation profile based on new activity, completions, and engagement patterns. Instructor can configure adaptive branching within a Lesson activity setting conditions under which learners are directed to different content paths based on their responses. 8. Administrator can view recommendation engine performance metrics, recommendation acceptance rates, and completion rates for recommended courses. | | **Alternative Flows** | A1: Insufficient Data for Recommendations: If a new learner has insufficient activity data, the system displays popular courses and courses linked to the learner's declared programme until sufficient data is collected. A2 Learner Dismisses Recommendations: Learner marks a recommendation as ‘Not Interested.’ System record from the feed and updates the recommendation model. A3 Adaptive Path Disabled: Instructor may disable adaptive sequencing for a specific course, making all content available in standard linear order. | | **Post-condition(s)** | Personalised recommendations displayed on the learner dashboard and refreshed on each login. Adaptive content path followed and progress recorded based on learner performance. Recommendation-to-enrolment conversion data available for administrator analytics. Learner recommendation preferences updated based on interaction. v. All recommendations and adaptive learning events logged in the audit trail. | **Table REP-SP9-FR: Functional Requirements Personalisation and Adaptive Learning** | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Personalised Dashboard** | FRREP-PL001: The system shall display a personalised learner dashboard on login, showing recommended courses, in-progress courses, upcoming deadlines, and suggested resources based on the learner's profile and activity history. | Learner login event | Personalised dashboard rendered with current recommendations | System (automated) | | **Course Recommendations** | FRREP-PL002: The system shall use a machine learning recommendation engine to generate ranked course and resource recommendations for each learner based on completed courses, assessment performance, stated interests, programme membership, and peer engagement patterns. | Learner activity and profile data | Ranked recommendations generated and displayed to learner | System (AI Engine) | | **Recommendation Feedback** | FRREP-PL003: The system shall allow learners to dismiss recommendations and mark them as 'Not Interested,' updating the recommendation model accordingly. | Learner dismissal action | Recommendation removed from feed; model updated | System (automated) | | **Recommendation Tracking** | FRREP-PL004: The system shall track recommendation-to-enrolment conversion rates and make this data available to administrators for engine performance monitoring. | Enrolment from recommendation | Conversion event logged; analytics data updated | System (automated) | | **Adaptive Content Sequencing** | FRREP-PL005: The system shall support adaptive content sequencing within courses, allowing instructors to configure score thresholds that trigger reinforcement content for under-performing learners or allow advanced learners to skip foundational material. | Assessment completion event | Next content path determined and presented based on score vs threshold | System (automated), Instructor | | **Lesson Branching** | FRREP-PL006: The system shall support instructor-configured adaptive branching within Lesson activities, directing learners to different content pages based on their responses to questions. | Learner lesson response | Next page displayed according to branching logic | System (automated) | | **New Learner Fallback** | FRREP-PL007: The system shall display programme-linked courses and most popular courses on the learner dashboard when insufficient activity data is available to generate personalised recommendations. | New learner login | Fallback recommendations displayed | System (automated) | | **Audit Trail** | FRREP-PL008: The system shall log all recommendation events, adaptive path decisions, and learner feedback on recommendations in the audit trail. | Any personalisation event | Audit log entry stored | System (automated) | ### REP-SP10: Learning Analytics and Reporting This sub-process covers the generation, visualisation, and export of learning analytics data. It serves instructors, programme managers, administrators, and the M&E module. The contract requires learning analytics tools to track learner engagement, progress, and performance. The M&E framework identifies LMS analytics as the primary data source for REP-related indicators, including postgraduate completion rates, digital competency scores, enrolment growth, and programme accreditation data. **Table 63: **Learning Analytics and Reporting Use Case Narrative | **Use Case: REP-SP10 Learning Analytics and Reporting** | | --- | | **Use Case Name** | REP-SP10: Learning Analytics and Reporting | | **Actor(s)** | Administrator, Programme Manager, Instructor, M&E Officer, System | | **Description** | This use case describes how authorised users access learning analytics dashboards and generate reports on platform usage, learner engagement, course completion, and assessment performance. It also covers the automated data feed from REP to the M&E module. | | **Pre-condition(s)** | i. User is authenticated with Administrator, Programme Manager, or Instructor role. ii. Sufficient platform activity data exists to generate meaningful analytics. iii. M&E module integration is active for cross-system reporting. | | **Main Success Scenario** | Administrator or Programme Manager navigates to the Analytics dashboard. System displays summary metrics: total active learners, total enrolments, overall course completion rate, and platform usage trend. User drills down by course, programme, institution, country, or date range using filter controls. System renders detailed analytics: per-course completion rates, average assessment scores, learner engagement scores (login frequency, time on platform, activity completion), and drop-off points. Instructor accesses course-level analytics showing per-learner progress, assessment performance, last access, and engagement with specific activities. Programme Manager accesses programme-level analytics showing cohort completion rates, average time-to-completion, and RIMS-linked beneficiary performance. User generates a report by selecting the report type, scope, and date range. System generates the report in the selected format (PDF or CSV/Excel). System automatically pushes aggregated completion, enrolment, and performance indicators to the M&E module on a configured schedule and upon key events (e.g., course completion, certificate issuance). M&E Officer accesses the REP-sourced indicators within the M&E module for integration into cross-system impact reports. | | **Alternative Flows** | A1 No Data for Selected Filters: The system displays 'No data available for the selected period and scope' with a suggestion to broaden the filter. A2 Report Generation Timeout: For large datasets, the system queues the report and notifies the user by email when ready. A3 M&E Feed Failure: System logs the failure and retries. Administrator is notified if repeated failures occur. | | **Post-condition(s)** | i. Analytics dashboards rendered with current platform data. ii. Reports generated and available for download. iii. M&E module updated with REP-sourced indicators. iv. All report generation and data export actions are logged in the audit trail. | **Table 64**: Functional Requirements Learning Analytics and Reporting | **Process** | **Requirement** | **Input** | **Output** | **Actor** | | --- | --- | --- | --- | --- | | **Summary Analytics Dashboard** | FRREP-AR001: The system shall provide an administrator-level analytics dashboard displaying platform-wide summary metrics, including total active learners, total enrolments, overall course completion rate, and platform usage trend over a configurable time period. | Admin dashboard access | Summary analytics dashboard rendered with current data | System (automated) | | **Drill-Down Filtering** | FRREP-AR002: The system shall allow users to filter analytics data by course, programme, institution, country, cohort, and date range, updating all dashboard metrics dynamically. | User filter selection | Filtered analytics data rendered | System (automated) | | **Learner Engagement Metrics** | FRREP-AR003: The system shall calculate and display learner engagement metrics, including login frequency, average time spent on the platform per session, activity completion rate, and forum participation rate. | Activity data | Engagement metrics calculated and displayed per learner and in aggregate | System (automated) | | **Course Completion Analytics** | FRREP-AR004: The system shall display course completion rates per course, programme, and cohort, including the percentage of learners who completed, are in progress, or withdrew. | Enrolment and completion data | Completion rates displayed by course, programme, and cohort | System (automated) | | **Assessment Performance Analytics** | FRREP-AR005: The system shall display assessment performance analytics, including average scores, score distributions, and pass/fail rates per assessment and per course. | Grading data | Assessment analytics rendered | System (automated) | | **Instructor Course Analytics** | FRREP-AR006: The system shall provide instructors with a course-level analytics view showing per-learner progress, last access, assessment scores, and engagement with specific activities. | Instructor analytics access | Per-learner course analytics rendered | System (automated) | | **Programme Analytics** | FRREP-AR007: The system shall provide programme managers with programme-level analytics showing cohort completion rates, average time-to-completion, and performance of RIMS-linked beneficiaries. | Programme manager analytics access | Programme analytics rendered | System (automated) | | **Report Generation** | FRREP-AR008: The system shall allow authorised users to generate downloadable reports on enrolment, completion, engagement, and assessment performance, exportable in PDF and CSV/Excel formats. | Report generation request | Report generated and available for download | System (automated) | | **Scheduled M****&****E Data Push** | FRREP-AR009: The system shall automatically push aggregated enrolment, completion, certification, and assessment performance indicators to the M&E module on a configured daily schedule and upon key completion and certification events. | Scheduled trigger or key event | Indicators updated in M&E module; push event logged | System (automated) | | **M****&****E Indicator Mapping** | FRREP-AR010: The system shall map REP-generated data to the defined RUFORUM M&E indicator set, including postgraduate completion rate, digital competency score, enrolment growth, women and youth participation rate, and scholarship enrolment records. | M&E data push | Indicators correctly mapped and available in the M&E module | System (automated) | | **Drop-Off Analysis** | FRREP-AR011: The system shall identify and report on course drop-off points, the specific activities or sections where learners disengage or withdraw, to support course quality improvement. | Engagement and withdrawal data | Drop-off report generated by course section | System (automated) | | **Audit Trail** | FRREP-AR012: The system shall log all report generation, analytics data export, and M&E data push actions in the audit trail, capturing user ID, report type, date range, and timestamp. | Any analytics or reporting action | Audit log entry stored | System (automated) | ## General system features - **Automated Notification**: Automates email notifications, document collection, and workflow tasks to reduce administrative burden. - **Workflow and approval**: This includes approval routing, sequential/parallel workflows, notifications & reminders, escalation rules, and digital signatures # Integration Requirements ## Objectives and outcomes of integration This section defines what capabilities the integration must deliver. The integration seeks to achieve the following objectives - The primary objective of integrating the SME Hub, Alumni System, RIMS, and E-learning Platform is to establish a **cohesive** and efficient digital ecosystem that enhances data accessibility, operational efficiency, and decision-making. This will be achieved through the following specific objectives: The Outcomes of Systems Integration include:- - **Improved operational efficiency across departments: **Administrative processes such as registration, research tracking, and alumni updates are streamlined, reducing duplication of effort across academic, research, and entrepreneurship units. - **Real-time access to user lifecycle data: **Stakeholders can track a student’s journey from enrolment (E-learning), to research (RIMS), to entrepreneurship (SME Hub), and post-graduation engagement (Alumni system) in real time. - **Reduced data duplication across platforms: **Student and user information is entered once and shared across all systems, eliminating repeated data entry in SME-Hub, RIMS, Alumni, and E-learning systems. - **Enhanced graduate tracking and employability insights: **Integration enables seamless transition of student data into the Alumni system, improving tracking of employment outcomes, entrepreneurial activities, and further research contributions. - **Improved research and innovation visibility: **Research outputs from RIMS can be linked to student profiles and SME Hub activities, providing a clearer picture of innovation and commercialization efforts. - **Integrated reporting and analytics: **Management can generate comprehensive reports combining: - Academic performance (E-learning) - Research output (RIMS) - Business/innovation activity (SME Hub) - Alumni outcomes (Alumni system) - **Automated student-to-alumni transition: **Upon graduation, student records are automatically transferred and updated in the Alumni system without manual intervention. - **Enhanced collaboration between units: **Academic departments, research units, and business incubation centers can share data seamlessly, improving coordination and program effectiveness. - **Improved user experience through unified access: **Students, researchers, and alumni can access multiple services through a unified identity (e.g., single sign-on), reducing login complexity. - **Better monitoring of entrepreneurial activities: **Student participation in SME Hub initiatives can be linked with academic and research data, enabling better evaluation of entrepreneurship programs. - **Stronger data governance and accountability: **Clear data ownership and standardized data management practices improve accountability across systems. - **Faster and more accurate decision-making: **Leadership gains access to reliable, cross-system data for planning, policy formulation, and performance evaluation. - **Reduced errors and data inconsistencies: **Automated synchronization minimizes human errors associated with manual data entry and updates. - **Scalable digital ecosystem for future expansion: **The integrated platform provides a foundation for adding new systems (e.g., finance, HR, or external partner platforms) in the future. ## API and Interface Requirements To enable seamless integration of RUFORUM systems, including the Alumni platform, E-learning platform, RIMS, SME-Hub, and Monitoring and Evaluation (MEL) system, - All systems must expose RESTful APIs. These APIs will serve as the primary mechanism for communication and data exchange between platforms, ensuring interoperability regardless of the underlying technologies used by each system. By adopting RESTful standards, RUFORUM can achieve a flexible and scalable integration architecture where systems can exchange data in a consistent and efficient manner, typically using lightweight formats such as **JSON**. This approach also supports future expansion, allowing additional systems or external partners to integrate without significant reconfiguration. - In addition to API availability**, robust API authentication methods** must be implemented to ensure secure access to data and services. Authentication mechanisms such **as OAuth 2.0, API keys, or token-based authentication** should be used depending on the sensitivity of the data and the level of access required. For example, OAuth 2.0 can be used to enable secure, delegated access between systems without exposing user credentials, while API keys may be suitable for controlled system-to-system communication. These measures are essential to protect sensitive information such as student records, research data, and alumni profiles, while also enforcing proper access control across integrated platforms. - The integration will also require clearly defined **API endpoints** to support specific data exchange needs across the systems. Common endpoints should include user and identity management (e.g., creating, updating, and retrieving user profiles), course and enrollment data from the E-learning platform, research outputs and project data from RIMS, business and innovation data from the SME-Hub, and performance indicators from the M&E system. Standardizing these endpoints ensures that all systems can reliably request and share the necessary data, supporting use cases such as unified student profiles, automated transitions from student to alumni, and consolidated reporting across RUFORUM programs. - Finally**, rate limits and usage constraints** must be established to maintain system performance and stability. Rate limiting controls the number of API requests that can be made within a specific time frame, preventing system overload and ensuring fair usage across all integrated platforms. Usage constraints may also include restrictions on data volume, access frequency, and concurrency levels. Implementing these controls helps protect system resources, ensures consistent performance for all users, and reduces the risk of service disruptions, particularly as the number of users and integrated services grows. **Table 65: Rate Limits and Usage Constraints** | **No.** | **Category** | **Requirement** | **Description** | | --- | --- | --- | --- | | 1 | API Request Rate Limit | 100–300 requests per minute per client | Standard request threshold for normal system operations | | 2 | High-Volume Endpoints | 50–100 requests per minute | Applies to reporting and analytics endpoints | | 3 | Bulk Operations | 10–20 requests per minute | For large data transfers such as batch uploads | | 4 | Burst Limit | Up to 500 requests per minute (short bursts) | Temporary spikes allowed but subject to throttling | | 5 | Concurrent Connections | 10–20 simultaneous requests per client | Prevents system overload from too many parallel requests | | 6 | Payload Size (Standard) | 1–5 MB per request | Recommended size for typical API requests | | 7 | Payload Size (Bulk) | 10–20 MB per request | For file uploads or large data exchanges | | 8 | Pagination (Default) | 50–100 records per request | Standard number of records returned per API call | | 9 | Pagination (Maximum) | 200–500 records per request | Upper limit to control response size | | 10 | Data Synchronization Frequency | Real-time / 5–15 min / Hourly–Daily | Depends on data type and system requirements | | 11 | API Access Quotas | System-specific quotas | Limits assigned per system (e.g., SME-Hub, RIMS, E-learning) | | 12 | Read vs Write Limits | Higher read limits than write limits | Ensures system stability and prevents excessive updates | | 13 | API Timeout | 30–60 seconds | Maximum time allowed per request | | 14 | Retry Policy | Maximum 3 retries with exponential backoff | Handles temporary failures | | 15 | Error Handling | HTTP 429, 503 | Standard error codes for rate limiting and system overload | | 16 | Authentication Attempts | Max 5 failed attempts per minute | Prevents brute-force attacks | | 17 | Token Expiry | 1 hour | Applies to OAuth or token-based authentication | | 18 | Monitoring & Logging | Mandatory logging of all API activity | Supports auditing, debugging, and performance tracking | | 19 | Usage Monitoring | Track request volume, errors, and response times | Enables proactive system management | | 20 | IP Restrictions | Restrict access to trusted IPs (where applicable) | Enhances API security | ## Data Integration Requirements ### 6.3.1 Data Formats All systems must support standardized data formats to ensure compatibility and ease of integration. - Primary Formats: - JSON: Preferred for RESTful API exchanges due to lightweight structure and readability. - XML: Supported for systems that require hierarchical data or legacy integrations. - CSV/Excel: Allowed for batch uploads or exports, especially for large datasets or reporting purposes. Data format consistency ensures that fields such as student IDs, course codes, research outputs, and enterprise records are interpreted uniformly across all systems. Example: User data exchanged between E-learning and Alumni systems should consistently use JSON with fields like user_id, first_name, last_name, email, and status. ### 6.3.2. Data Mapping Rules Between Systems The purpose of data mapping is to define how data elements in one system correspond to data elements in another system, avoiding misalignment or duplication. - Student/Alumni Data: - E-learning.user_id → Alumni.user_id - E-learning.program_code → RIMS.program_code - Research Data (RIMS → M&E/SME-Hub): - RIMS.project_id → M&E.project_id - RIMS.research_output → SME-Hub.innovation_output - SME-Hub Business Records → Alumni: - SME-Hub.participant_id → Alumni.user_id - SME-Hub.business_type → Alumni.entrepreneurship_activity_type Mapping rules should include data type conversions (e.g., date formats, numeric IDs), mandatory vs optional fields, and default values for missing data. Regular validation checks must be implemented to ensure mapped data remains consistent across systems. ### Master Data Definition (Source of Truth) The master data definition established a single authoritative system for each type of critical data, preventing conflicting or outdated records. - Master Data Assignments: - Student/Alumni Profiles: The e-learning platform is the source of truth, while the Alumni system reflects updates post-graduation. - Research Projects and Outputs: RIMS is the authoritative system for all research-related data. - Entrepreneurial and SME Activities: SME-Hub is the source for all innovation and business engagement records. - Monitoring & Evaluation Metrics: M&E system consolidates performance and impact data from all other systems for reporting. - All integrated systems should synchronize with the master source during updates, and downstream systems must respect the master data authority to avoid inconsistencies. If a student updates their contact information in the E-learning platform, the change should propagate automatically to the Alumni system, while the Alumni system does not overwrite the master record. ## Error Handling & Monitoring Error handling is a critical aspect of system integration, ensuring that any disruptions in data flow across RUFORUM systems are detected, communicated, and corrected promptly to maintain data integrity, system reliability, and operational efficiency. By implementing these error-handling requirements, RUFORUM ensures that: - All integration failures are recorded and traceable - Relevant staff are notified promptly of issues - Transient errors are automatically retried without data loss - System performance and health are continuously monitored Below are the error-handling requirements - **Logging of integration errors**: - All errors occurring during integration processes must be automatically logged in a centralized repository accessible to IT administrators. - Logs must capture detailed information to facilitate troubleshooting, including: - Timestamp of the failure - Originating system and endpoint - Data records or payload affected - Error type or code (e.g., validation error, network timeout) - Status of the transaction (failed, retried, escalated) - Logs should be retained for auditing purposes and comply with RUFORUM’s data retention and security policies. For example “The system shall log all failed API transactions with timestamp, system, endpoint, data record ID, and error description for audit and troubleshooting purposes.” - **Alerts / Notifications for Issues** - The integration system must notify relevant personnel immediately when errors occur, ensuring rapid response and resolution. - Alerts should include sufficient context to identify the affected system, endpoint, and transaction details. - Notification channels may include: - Email alerts - System-generated dashboard notifications - Optional SMS or messaging tools for critical failures - **Retry Mechanisms for Failed Transactions** - The integration platform must implement automatic retry mechanisms for transient errors (e.g., network interruptions) to prevent data loss or inconsistencies. Retry requirements include: - Maximum of 3 retry attempts per failed transaction - Exponential back-off intervals (e.g., 1 minute, 2 minutes, 4 minutes) between attempts - Transactions that fail after all retries must be escalated via alerts and logged as persistent errors - Retry logic must be idempotent, ensuring that repeated attempts do not create duplicate or inconsistent records. - **Dashboard for Monitoring Integration Health** - A centralized integration monitoring dashboard must provide visibility into the status, performance, and reliability of all integrated systems. Dashboard features should include: - Success and failure rates of recent transactions - Real-time tracking of pending retries - System and endpoint performance metrics (response times, throughput) - Historical error trends to identify recurring issues - Alerts summary and escalation status **Table 66: Error-Handling Integration Requirements for RUFORUM Systems** | **Requirement Area** | **Requirement Description** | **Notes ** | | --- | --- | --- | | Logging of Integration Failures | All integration errors must be automatically logged in a centralized repository. | Include timestamp, source system, endpoint, affected record, error code/type, and status. | | Alerts / Notifications | Generate immediate notifications to relevant personnel when failures occur. | Channels: email, dashboard alerts, and optional SMS. Include system, endpoint, and transaction details. | | Retry Mechanisms | Automatic retries for failed transactions with a maximum of 3 attempts. | Use exponential backoff intervals (1, 2, 4 min). Ensure idempotency to avoid duplicate records. | | Escalation of Persistent Failures | Failures after all retries must be escalated to support/admin staff and logged as persistent errors. | Escalation ensures unresolved issues are addressed promptly. | | Dashboard for Monitoring Health | Centralized dashboard showing real-time integration status, success/failure rates, pending retries, and alerts. | Provides visibility into system performance and recurring errors; supports proactive maintenance. | | Audit & Compliance | Logs and dashboard data must be retained according to RUFORUM policies for auditing and regulatory purposes. | Ensures accountability and transparency across all integrated systems. | | Error Categorization | Integration errors should be classified by type (e.g., validation, connectivity, API timeout). | Facilitates quicker troubleshooting and reporting. | | Monitoring of Retry Performance | Track retry success/failure rates and time to resolution. | Ensures retry mechanisms are effective and identifies problematic endpoints. | ## 7.1 Data Domains and Data Structures # Reports Generated by the System for Decision-Making The integrated reporting system for RUFORUM plays a critical role in enabling **data-driven decision-making, operational efficiency, and strategic oversight** across all programs and platforms. By consolidating information from the SME-Hub, RIMS/fund management, Alumni, E-learning, and Repository systems, these reports provide stakeholders with a **comprehensive and real-time view** of student progress, research outputs, entrepreneurial activities, graduate outcomes, and overall program performance. Regular and automated reporting ensures that administrators, faculty, researchers, and secretariat have timely access to **accurate, actionable, and standardized data**, supporting monitoring, evaluation, and continuous improvement of RUFORUM initiatives. Furthermore, the combination of dashboards, PDFs, and Excel reports, distributed through appropriate channels, enhances transparency, accountability, and stakeholder engagement, while also providing a historical record for auditing, compliance, and strategic planning purposes. Table 59 shows a high-level system reports **Table 67: **High-level System reports | **Report Name** | **Stakeholder** | **Description** | **Frequency** | **Report Format** | **Distribution Channels** | | --- | --- | --- | --- | --- | --- | | Student Profile and Enrollment Report | Academic Departments, Admin | Consolidated view of student profiles, enrollment status, program details, and academic progression. | Monthly / Real-time | PDF / Excel / Dashboard | Email, System Dashboard | | Course Completion and Performance | Faculty, Academic Departments | Lists students’ course completion, grades, and performance metrics from the E-learning platform. | Monthly / Per Semester | PDF / Excel / Dashboard | Email, System Dashboard | | Alumni Employment and Engagement | Alumni Office, Management | Tracks graduate employment status, entrepreneurship activity, further studies, and engagement with RUFORUM | Quarterly / Annual | PDF / Excel / Dashboard | Email, Alumni Portal, Dashboard | | Research Project Status | Research Coordinators, Funders | Tracks RIMS projects, funding status, milestones, outputs, and associated researchers. | Monthly / Quarterly | PDF / Excel / Dashboard | Email, System Dashboard | | Fund Utilization and Grant Reports | Finance Department, Funders | Monitors allocation and expenditure of grants, funding utilization, and pending disbursements. | Quarterly / Annual | PDF / Excel | Email, Finance Portal | | SME-Hub Business and Innovation Report | Incubation Center, Management | Captures student/researcher entrepreneurial activity, startups created, and commercialization outcomes. | Monthly / Quarterly | PDF / Excel / Dashboard | Email, Dashboard | | Integrated Student Journey Report | Management, Monitoring & Evaluation (M&E) | Provides a holistic view from enrollment → research → entrepreneurship → graduation → alumni engagement. | Quarterly | PDF / Excel / Dashboard | Email, System Dashboard | | Repository Access and Usage Report | Librarians, Researchers | Monitors digital repository usage, downloads, uploads, and contributions from students, faculty, and alumni | Monthly | PDF / Excel / Dashboard | Email, Repository Portal | | Performance and KPI Dashboard | Management, M&E | Aggregated key performance indicators from all systems, including research outputs, student outcomes, and SME activity | Real-time / Monthly | Dashboard | System Dashboard | | Graduation and Status Transition Report | Academic Departments, Alumni Office | Tracks students’ transition from active learners to alumni, including final grades and program completion | Semester / Annual | PDF / Excel / Dashboard | Email, Alumni Portal, Dashboard | | Compliance and Audit Report | Internal Audit, M&E, Management | Tracks adherence to data governance, system usage policies, and integration-related errors/failures | Quarterly / Annual | PDF / Excel | Email, System Dashboard | | Stakeholder Engagement Report | Management, Development Office | Summarizes alumni, partners, and industry engagement across RUFORUM initiatives | Quarterly | PDF / Excel / Dashboard | Email, Dashboard | | Research Output and Publications Report | Researchers, Management | Tracks published papers, patents, innovations, and project deliverables linked to RIMS and repositories | Quarterly / Annual | PDF / Excel / Dashboard | Email, Repository Portal, Dashboard | | Data Synchronization & Error Report | IT / System Administrators | Highlights failed integrations, retries, and data consistency issues across systems | Daily / Weekly | PDF / Excel / Dashboard | Email, IT Dashboard | # General Functional Requirements Other general functional requirements include; - Security of the system data shall be ensured at all levels through user authentication, activity logging, and the use of access controls - The system shall provide interfaces for migrating data from other systems, such as Excel and other electronic systems. - The system shall support user management services, including changing passwords, editing profiles, managing user levels, etc - The system should enable employees to generate customized reports ## General Non-Functional Requirements Additional general Non-Functional requirements represent the restrictions within which the system should perform, i.e., constraints on the functions or tasks that the system. - Enablement of offline and online working modes. - Users shall only be allowed to access information that they are supposed to access, even when they are logged in. ## General Data Requirements Below are the data requirements: - - The accuracy of data fed into the system shall be checked and validated by the system to ensure it is accurate. For instance, the system shall not make follow-ups of the user whose records are not in the system. Also, form validation techniques shall be used to ensure that wrongly typed errors that can be caught are communicated to the user before form submission - Forms shall not be submitted if incomplete data is provided. The system shall inform users which fields are missing and prompt them to enter these fields - There shall be a mandatory unique way of identifying every record to distinguish it from other records. For instance, staff members shall be uniquely identified by file numbers, and no other staff member shall get the same file number - The system shall use a messaging approach to manage the timely submission of information and ensure that the information is submitted during its period of validity - Duplicates shall not be allowed in the system. For a given record, there shall be unique identifiers to avoid the submission of duplicates in the system - The data shall conform to standard formats expected by the Records and Information Division - For consistency, database tables shall start with a uniform prefix, which shall be agreed upon by the design team - Variable names shall all start with small letters and should be in the form of a meaningful word - In case a data value requires a unit of measurement, the unit shall be specified during data entry and during the display of reports. This will help to avoid ambiguities. - Invalid information shall be categorised as archive and separated from the up-to-date information to reports that can help in decision making. - All dates shall be stored in the standard MySQL database management system. The date formats displayed in reports shall be the same across the whole system, although it may not be the standard MySQL format. - Only data within the allowed set of values shall be accepted by the interface - All passwords shall be encrypted ## General Quality Requirements ### Reliability - The number of bugs in the system should be minimal. By the time the system is rolled out, testing must have been done, and feedback incorporated to ensure that the system is free of bugs - Servers on which the system is installed should be available 24 hours a day. In this case, the system can be accessed over the Internet. Because the Internet is sometimes a challenge, the system users should be able to work even without the Internet. Offline versions of the software with minimum capabilities shall be provided to facilitate access to the features of the software even without Internet, so that when users connect to the Internet, their work is synchronized with the online database. - Computations made by the system shall be accurate. During the evaluation sub-process, especially in the award of scores, the system shall make various computations that will determine the ranks of the bidders. Failure to give correct results can lead to serious consequences - To avoid cases of loss of data, the system shall have a daily scheduled backup of the database. The backups shall be named after the date and time of creation. In case of damage to the system, the latest copy of back up shall be used. Backups shall be kept on a different computer to further enable reliability. - The system shall undergo rigorous testing to avoid constant breakdowns - Data fed into the system shall be validated before submission. For example, names shall be expected to contain only characters. To further reduce the probability of submitting wrong data, controls like using selection boxes instead of fill-in boxes shall be used where necessary to help restrict users to specific known values. Numeric data shall also be tested for limits. - A module for auditing users while using the system shall be implemented to ensure that the tracking of activities of users is made. This will help ensure that the data entered is right because users will be tracked. - The system shall keep bids secure before the evaluation date. - Sensitive data shall be encrypted to avoid access and use by unauthorized persons ### User Interface Requirements - Categorization of similar features shall be made. This shall facilitate groupings of features to ease the use of the system in terms of locating features through system navigation. - Sub menus shall not exceed seven levels. This shall help users memorize easily categories under which they can find the required functions. - Most commonly used menus shall be put in areas of the Interface that are easy to access. For example, at the top of the page, at the left, etc. The system shall have means of tracking frequency of access to menus so that they appear later in strategic locations the next time the system is used. - The system shall prevent users from making unnecessary errors using a variety of interface designs, including: - - Using selection boxes instead of filling in data where there are certain ranges of known values - First, confirming actions like deleting data and submission of passwords. This will ensure that the action performed was intended. Actions like deleting data shall not be easily accessible. - During confirmation of actions like deleting data, the default selection shall be one that will cancel the actions - Various kinds of users are expected to use the system. Each menu shall have an icon that shall pop up a label when pointed at. This shall make the system capture the interests of various users. - Features for undoing dangerous operations shall be provided to avoid the complete loss of data. - A wise selection of colours shall be made. This will be in terms of communicating important aspects like error messages and sections that need specific attention by using an outstanding colour. Few colours shall be used. - To improve the learning curve of the system, context help shall be provided at different sections of the system - Navigation shall be made easy. This shall be through marking sections when a user is at a given instant, and offering options to move back and forth. - The system shall use simple language. Where clarity shall be required, help shall be provided in terms of a manual, which shall be searched by keywords - The system shall use the recommended RUFORUM colours, including green, red, and black on its interfaces. ### Performance - The system user database is expected to grow within a short time. The database should be able to store huge volumes of data even as it grows. Therefore, the server space should be sufficient. - Results of computations shall be provided instantaneously the instant the values are produced. Computations shall take less than a second - To enhance performance in terms of speed, caching of form inputs shall be done so that data is not committed to the database in bits but is committed as a whole from the cache. This will also help to save the bandwidth ### Maintainability - A modular approach to system design shall be undertaken to incorporate upgrades into the system. In case of failure, the whole system shall not go down, but only the specific concerned module. Also, the addition of new features to the system shall be made easy through the addition and deletion of modules. - Good programming practices, like commenting and indenting, shall be used. This will help make the programs more readable for new people - Reusability of code shall be emphasized by using programming constructs like functions. ### Flexibility - The system should make it possible to modify processes and assign permissions to other users in case of the absence of the actual users # References # APPENDIX A: Interview Guide # APPENDIX B: Requirements Elicitation Guide The Regional Universities Forum for Capacity Building in Agriculture (RUFORUM) has grown its network to 175 universities across 40 African countries. The network supports functions including management, grants, learning, project management, and alumni management, among others. These systems generate massive amounts of data, which is stored on a distributed infrastructure. There is currently no holistic view of the performance of the member institutions and RUFORUM, and its members are hence faced with the following challenges: - - Lack of an accurate picture of their performance: Accessing data is hard, which impedes and delays decision-making. - Inaccurate and Incomplete Reporting: Data extraction, consolidation, and analysis are time-consuming and error-prone. Moreover, the resulting reports may be inaccurate or incomplete, which hampers decision-making. Hence, the inability to identify trends, track performance, and seize opportunities. - Operational Inefficiencies: In case integrated reports are required, these are manually generated through manual transfer of data between systems. What is your job title/position? - Data duplication: Data is duplicated across systems. This may include user information and other project data, which is required for use across different systems This study is therefore to establish the challenges and requirements that will form the basis for the development of an IILMP for RUFORUM. It is hoped that the IILMP will address the identified issues and improve the effectiveness and efficiency of the RUFORUM processes. The information you give in this interview will be handled with at utmost confidentiality. - What is your job title/position? - What unit/department do you belong to? - What duties do you perform? **User Needs Assessment**: - What tasks do you perform that this system should support? - What challenges do you face with the current process? - What are the key outputs or results you expect from the system? - Who else do you collaborate with when doing your work? **System Process understanding:** - What steps do you go through to perform this task (step-by-step)? (Give process description) - What tools or systems are you currently using? - What problems or inefficiencies do you face with the current system? - What information do you currently collect or use? - Which data sources/documents/forms do you rely on? - What forms, documents, reports, or records should the system generate? **User Roles ****&**** Access:** - What different levels of access are needed and for which users? - What actions should each user role be allowed to perform? - Which information should be restricted based on user roles? **Data Requirements** - What data do you collect? - What new data should the system capture? - What data fields are mandatory? - Where does your data come from (manual entry, imports, external systems)? **Reporting ****&**** Analytics** - What reports do you currently generate? - How frequently do you need these reports? - What additional reports would be useful? - Who is currently using these reports? - What performance indicators (KPIs) does the current system track? **Workflow ****&**** Business Rules** - What approvals are required in your processes? - What steps must happen before a task is completed? - Are there deadlines, thresholds, or rules the system must enforce? - What exceptions occur in your workflow? **Integration Requirements** - Which other systems should your system integrate with (finance, HR, SMS, email, etc.)? - What data should be exchanged between systems? - How often should the integration happen? (e.g. Always or on demand) SRS Document Version 1