This matrix now combines the exact requirement wording from the signed PDF with the derived implementation approach used for ERPNext delivery planning.
18 sections with exact requirement text and derived planning fields side by side.
Traceability from signed requirement wording into implementation planning decisions.
Offline sync, EHR integration, controlled medicines compliance, FEFO dispensing, and insurer workflows remain the main risk clusters.
7 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| UAM-01 | The system shall support role-based access control (RBAC), limiting each user to screens and functions permitted for their role. | Must | Config | ERPNext roles, role permissions, user permissions, workspace restriction | Final role matrix per site | Low | P1 |
| UAM-02 | The system requires a unique username and strong password for each user. Default passwords must be changed on first login. | Must | Config | ERPNext user setup with password policy and first-login reset rules | Password policy approval | Low | P1 |
| UAM-03 | The system shall support two-factor authentication (2FA) for privileged roles (Administrator, Pharmacist-in-Charge, Finance Officer). | Should | Config | Enable 2FA for privileged users using authenticator app | Decide SMS vs app-based 2FA | Medium | P1 |
| UAM-04 | Sessions shall time out after a configurable period of inactivity (default: `5 minutes). | Must | Config | Configure session timeout and idle logout in system settings | Timeout policy agreement | Low | P1 |
| UAM-05 | The system shall log every login, failed login attempt, and logout with timestamp, username, and IP address. | Must | Config | Use ERPNext login logs plus restricted audit access | Confirm log retention period | Low | P1 |
| UAM-06 | User accounts shall be created, modified, suspended, or deleted only by the System Administrator. | Must | Config | Restrict user administration to System Administrator role | Admin operating procedure | Low | P1 |
| UAM-07 | The system shall support multi-site configuration: users may be assigned to one or both sites; reports can be filtered by site. | Must | Config | Site-aware permissions, warehouses, cost centers, and report filters | Confirm site model and user assignment rules | Medium | P1 |
7 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| DFC-01 | The system shall maintain a central drug formulary / product catalogue covering all medicines, consumables, and sundries dispensed or sold. | Must | ERPNext | Use shared Item master for medicines, consumables, and sundries | Product classification structure | Low | P1 |
| DFC-02 | Each product record shall include generic name, brand name(s), formulation, strength, dosage form, unit of measure, pack size, therapeutic category, controlled drug status, and storage requirements. | Must | Config | Item master plus custom fields for therapeutic category, controlled status, storage requirements | Final data dictionary for product master | Low | P1 |
| DFC-03 | The system shall support multiple units of measurement per product (e.g., bottles, tablets, vials) with configurable conversion factors. | Must | ERPNext | Use ERPNext UOM conversions per item | Confirm dispensing UOM rules | Low | P1 |
| DFC-04 | Each product shall be assigned a unique SKU/barcode. The system shall support barcode scanning for product lookup. | Must | Config | Use item codes and barcodes with scanner-enabled forms | Hardware model and barcode standard | Low | P1 |
| DFC-05 | The system shall flag products classified as controlled medicine and enforce additional recording requirements for those items. | Must | Config | Controlled medicine flag on Item drives extra workflow rules | Controlled medicines classification list | Medium | P1 |
| DFC-06 | The formulary shall be editable only by the Pharmacist-in-Charge or Administrator; changes shall be logged with user and timestamp. | Must | Config | Restrict item edits to approved roles and rely on versioning/audit logs | Final approval ownership | Low | P1 |
| DFC-07 | The system shall support product substitution: the ability to link a generic drug to acceptable brand alternatives. | Should | Custom | Add substitution mapping between generic and approved brands | Clinical substitution policy | Medium | P2 |
7 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| PRO-01 | The system shall maintain a supplier database including name, contact details, address, payment terms, and lead time. | Must | ERPNext | Use Supplier master with contact, address, terms, and lead time fields | Lead time field placement | Low | P1 |
| PRO-02 | The system shall allow users to raise a Purchase Requisition (PR) from within the system, selecting products, quantities, unit prices, and preferred supplier. | Must | ERPNext | Use Material Request or custom purchase requisition workflow | Decide whether to use standard Material Request or custom PR | Medium | P1 |
| PRO-03 | PRs shall require authorization by the Pharmacist-in-Charge or Centre Manager before submission to the Inventory Manager. | Must | Config | Workflow approval for PR before procurement processing | Final approver chain | Medium | P1 |
| PRO-04 | The system shall track PR status: Draft, Submitted, Partially Received, Fully Received, Cancelled. | Must | Config | Map PR statuses through document workflow and receipt linkage | Final status lifecycle | Low | P1 |
| PRO-05 | The system shall generate re-order alerts when stock on hand falls to or below a configurable reorder level for any product. | Must | ERPNext | Use reorder levels and alerts with dashboard/report exposure | Alert recipients and escalation rules | Low | P1 |
| PRO-06 | The system shall produce a suggested order list based on reorder levels, average consumption rates, and supplier lead times. | Should | Config | Suggested orders from reorder data and consumption reporting | Consumption calculation logic | Medium | P1 |
| PRO-07 | The system shall record supplier performance data: on-time delivery rate, rejection/return rate, and pricing history. | Should | Config | Supplier scorecard/reporting using delivery history, returns, and price history | Define metrics and threshold rules | Medium | P3 |
7 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| GRN-01 | On delivery of goods, the system shall allow creation of a Goods Received Note (GRN) linked to the originating PR. | Must | ERPNext | Use Purchase Receipt linked to PO or approved PR flow | PR to PO to receipt mapping | Low | P1 |
| GRN-02 | Each GRN line shall capture product, batch number, manufacturer, quantity received, unit cost, selling price, expiry date, and storage location. | Must | Config | Require batch, expiry, qty, valuation, price, and location fields at receipt | Decide if manufacturer sits on batch or item-supplier record | Medium | P1 |
| GRN-03 | The system shall automatically update stock on hand upon GRN confirmation. | Must | Config | Separate draft entry from submit/confirm authorization | Approval step and authorized roles | Medium | P1 |
| GRN-04 | The system shall support partial deliveries: a single PR may have multiple GRNs until the order is fully received. | Must | ERPNext | Use partial Purchase Receipts against one order | Order closure rules | Low | P1 |
| GRN-05 | The system shall flag any item received with an expiry date within a configurable short-shelf-life threshold (e.g., less than 6 months) at point of intake. | Must | Custom | Server validation to flag or block short-shelf-life receipts | Shelf-life threshold by item or global setting | Medium | P2 |
| GRN-06 | The system shall support recording of supplier invoices against GRNs for accounts payable reconciliation. | Must | ERPNext | Link supplier invoice to receipt using Purchase Invoice workflow | AP reconciliation approach | Low | P1 |
| GRN-07 | GRNs shall be editable only before confirmation; post-confirmation corrections must be handled via a documented stock adjustment with reason code. | Must | Config | Lock submitted receipts and force stock adjustment/amendment flow with reason | Correction policy | Low | P1 |
9 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| INV-01 | The system shall maintain a perpetual inventory, updating SOH in real time after every transaction (receipt, dispensing, return, adjustment, transfer). | Must | ERPNext | Use ERPNext stock ledger for real-time stock movement | Correct transaction discipline | Low | P1 |
| INV-02 | The system shall apply FEFO (First Expiry, First Out) logic automatically when selecting batch for dispensing. | Must | Custom | Custom FEFO selection logic during dispensing | Batch selection design | High | P2 |
| INV-03 | The system shall generate an expiry alert list for products expiring within a configurable period (default: 3 months). | Must | Config | Near-expiry report and dashboard cards using batch expiry data | Alert window settings | Low | P1 |
| INV-04 | The system shall support inter-site stock transfers between Waterloo Rural and Lamina Sanko, generating a transfer note and updating SOH at both sites. | Must | ERPNext | Use Stock Entry transfer between site warehouses with confirmation controls | Final warehouse topology | Low | P1 |
| INV-05 | The system shall support periodic stock-taking: freeze transactions for a site/product, allow physical count entry, calculate variance, and produce a variance report. | Must | Config | Use stock reconciliation/count process with operational freeze controls | Freeze process detail and variance approval rule | Medium | P1 |
| INV-06 | Stock adjustments (write-offs, breakages, pilferage) shall require a reason code and dual authorization (Pharmacist-in-Charge + Administrator). | Must | Config | Stock adjustment workflow with reason codes and dual approval | Define dual approval mechanics in ERPNext workflow | Medium | P1 |
| INV-07 | The system shall calculate and display stock valuation using weighted average cost or configurable costing method. | Must | ERPNext | Use moving average valuation unless another costing model is approved | Costing method decision | Medium | P1 |
| INV-08 | The system shall produce a daily stock movement report showing opening balance, receipts, dispensed, adjusted, transfers, and closing balance per product. | Must | Config | Custom stock movement report by day, site, and product | Opening/closing balance report format | Low | P1 |
| INV-09 | The system shall flag negative stock levels and prevent dispensing below zero SOH. | Must | Config | Disable negative stock and add controlled override workflow for approved role | Whether override is truly allowed in production | Medium | P2 |
10 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| RXD-01 | The system shall capture patient demographics at the point of dispensing: name, age/date of birth, sex, contact number, and client/case ID (linked to the Centre's patient record where available). | Must | Custom | Create patient capture/linkage in dispensing flow, with optional EHR-linked patient | Source of truth for patient master | High | P2 |
| RXD-02 | The system shall record prescription details: prescriber name, prescriber designation, date, diagnosis (ICD code or free text), and each drug prescribed with dose, frequency, and duration. | Must | Custom | Custom Prescription DocType with prescriber, diagnosis, and drug instructions | Prescription ownership and workflow | High | P2 |
| RXD-03 | The system shall check for drug interactions and allergy flags at point of dispensing and alert the pharmacist. | Should | Integration | Integrate interaction/allergy checks via external clinical dataset or service | Drug interaction data source and licensing | High | P4 |
| RXD-04 | The system should enforce quantity limits: the dispensed quantity cannot exceed the prescribed quantity without an override with documented reason. | Must | Custom | Validation on dispensing quantity against prescription quantity with override reason | Policy for partial fills and overrides | Medium | P2 |
| RXD-05 | Upon dispensing, the system shall automatically deduct the dispensed quantity from the relevant batch's SOH (FEFO applied). | Must | Custom | Dispensing submission deducts stock from selected batch using FEFO | Batch deduction design | High | P2 |
| RXD-06 | The system shall print or display a dispensing label for each item: patient name, drug name, strength, dose instructions, dispensing date, expiry date, and pharmacy name. | Must | Config | Custom print format for dispensing label | Label size, printer type, and language | Low | P2 |
| RXD-07 | The system shall support repeat dispensing for chronic disease patients, linking each dispensing to the original prescription and tracking remaining quantity. | Should | Custom | Repeat-dispense logic tied to original prescription balance | Chronic care refill rules | Medium | P2 |
| RXD-08 | The system shall support OTC (over the counter) sales without a formal prescription, linked to a walk-in patient record. | Must | Custom | OTC sale workflow with walk-in patient and direct billing link | Minimum data capture policy for walk-ins | Medium | P2 |
| RXD-09 | Dispensed items shall be linked to a billing transaction automatically (Section 3.7). | Must | Custom | Auto-create billable transaction from dispensing event | Sales document model for pharmacy | High | P2 |
| RXD-10 | The system shall record who dispensed each item with timestamp, and support supervisory review. | Must | Custom | Track dispenser, timestamps, and supervisory review on dispensing records | Review workflow design | Medium | P2 |
10 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| BIL-01 | The system shall generate an itemized invoice/receipt for every dispensing transaction showing patient name, date, each item dispensed, unit price, quantity, subtotal, any discount applied, tax (if applicable), and total amount due. | Must | Config | Sales Invoice or POS Invoice print format with pharmacy-specific fields | Billing document choice | Low | P1 |
| BIL-02 | The system shall support multiple payment methods per transaction: cash, insurance claim, organizational credit (for staff/wards), and mobile money. | Must | Config | Configure modes of payment and receivable flows for cash, insurance, credit, mobile money | Insurance and organizational credit accounting model | Medium | P1 |
| BIL-03 | For cash transactions, the system shall calculate, and display change due. | Must | ERPNext | Use POS/payment entry behavior to calculate change due | Decide POS vs standard invoice counter flow | Low | P1 |
| BIL-04 | The system shall support configurable pricing tiers: e.g., standard patient price, staff price, bulk/institutional price. | Should | Config | Use price lists and pricing rules by customer or customer group | Pricing governance | Low | P1 |
| BIL-05 | The system shall support discount authorization: discounts above a configurable threshold require approval by the Pharmacist-in-Charge or Manager. | Must | Config | Discount approval workflow and capped discount permissions | Approval thresholds by role | Medium | P3 |
| BIL-06 | The system shall support insurance claim processing: generate claim forms/data, track claim submission, approval, and payment by insurance company. | Must | Custom | Insurance claim tracking DocType and claim lifecycle linked to invoices | Insurer-specific workflow and required forms | High | P3 |
| BIL-07 | The system shall support credit accounts for institutional clients (e.g., wards, NGOs), tracking outstanding balances and credit limits. | Must | ERPNext | Use customer credit limits and receivable tracking for institutional clients | Customer segmentation and credit policy | Low | P1 |
| BIL-08 | The system shall perform an end-of-day cash reconciliation: total cash sales vs. cash declared by cashier, flagging discrepancies. | Must | Config | End-of-day cashier reconciliation using POS closing or custom reconciliation form | Cash office operating procedure | Medium | P3 |
| BIL-09 | Invoices shall be numbered sequentially and non-editable once issued; cancellations require a credit note with reason. | Must | ERPNext | Use naming series, submitted invoices, and credit notes for reversals | Cancellation policy | Low | P1 |
| BIL-10 | The system shall support printing of receipts on a standard POS receipt printer. | Must | Config | POS thermal receipt print format and printer setup | Printer hardware standardization | Low | P1 |
6 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| CDR-01 | The system shall maintain a separate electronic controlled medicine register for each product classified as a controlled substance. | Must | Custom | Create dedicated Controlled Medicine Register DocType or derived ledger view | Confirm regulator format | High | P2 |
| CDR-02 | Each entry in the controlled medicine register shall record date, patient name, prescriber name, prescriber number, quantity in, quantity out, balance, and dispensing pharmacist. | Must | Custom | Auto-populate register entries from receipt and dispensing events with required fields | Legal field list validation | High | P2 |
| CDR-03 | The balance in the controlled medicine register shall always reconcile with the stock module; discrepancies shall generate an immediate alert. | Must | Custom | Reconciliation checks between register and stock ledger with alerting | Reconciliation tolerance and alert ownership | High | P2 |
| CDR-04 | The controlled medicine register shall be exportable in a format suitable for regulatory submission. | Must | Config | Export print/report in regulator-ready format | Final submission template from PBSL | High | P4 |
| CDR-05 | Access to create or modify controlled medicine register entries shall be restricted to licensed pharmacists only. | Must | Config | Restrict register access and actions to licensed pharmacist roles | Licensed pharmacist roster and proof process | Medium | P2 |
| CDR-06 | The system shall flag and prevent the dispensing of a controlled medicine if no valid prescription has been recorded. | Must | Custom | Block controlled dispensing without valid prescription linkage | Definition of valid prescription and exception policy | High | P2 |
5 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| EXP-01 | The system shall produce a monthly near-expiry report listing all products with expiry dates within the configured alert window, showing quantities and estimated cost value. | Must | Config | Monthly near-expiry report with quantity and value by batch/site | Report format | Low | P1 |
| EXP-02 | Expired stock shall be quarantined in the system (marked as 'Quarantined - Expired'), removed from dispensable SOH, and require a formal write-off process. | Must | Config | Quarantine warehouse for expired stock, removed from normal dispensing flow | Quarantine operating model | Medium | P1 |
| EXP-03 | The system shall support recording of returns to supplier: quantity, reason, credit note reference, and adjustment to stock and accounts payable. | Must | Config | Supplier return flow using stock movement and purchase return/credit note linkage | AP return treatment | Medium | P3 |
| EXP-04 | The system shall support patient returns (dispensing errors or unused drugs per organizational policy): transaction reversal, restocking to quarantine, and refund processing. | Should | Custom | Patient return workflow with quarantine restock and refund controls | Policy for allowable patient returns | Medium | P3 |
| EXP-05 | The system shall report on total value of stock written off by reason code per month. | Must | Config | Write-off reporting by reason code and period | Standardized reason codes | Low | P3 |
9 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| FIN-01 | The system shall produce a Daily Revenue Summary: total sales by payment method, discounts given, and net revenue per site. | Must | Config | Daily revenue report by site and payment mode | Site financial segmentation model | Low | P1 |
| FIN-02 | The system shall produce a Monthly Profit and Loss view: revenue, cost of goods sold (COGS), gross margin, and write-offs. | Must | Config | Monthly P&L with COGS and write-offs using ERPNext accounting and stock valuation | Final COA and costing design | Medium | P1 |
| FIN-03 | The system shall maintain an Accounts Receivable ledger for credit clients, showing invoiced amounts, payments received, and outstanding balances. | Must | ERPNext | Accounts receivable ledger using customer receivables | Customer account design | Low | P1 |
| FIN-04 | The system shall produce an Aged Debtors Report, categorizing outstanding balances by 0–30, 31–60, 61–90, and 90+ days. | Must | ERPNext | Aged receivables report per customer class/site | Site tagging on customers and invoices | Low | P1 |
| FIN-05 | The system shall produce a Stock Valuation Report at any point in time, by site and in aggregate. | Must | ERPNext | Stock valuation report by warehouse/site and consolidated | Warehouse model and valuation method | Low | P1 |
| FIN-06 | The system shall produce a Procurement Spend Report: total spend by supplier and by therapeutic category per period. | Should | Config | Procurement spend report by supplier and therapeutic category | Therapeutic category tagging quality | Low | P3 |
| FIN-07 | All financial reports shall be exportable to PDF and Excel. | Must | ERPNext | Use built-in export formats and custom print/report layouts | None significant | Low | P1 |
| FIN-08 | The system shall support configurable financial periods (monthly, quarterly, annual) for report generation. | Should | ERPNext | Use fiscal year and report filters for month, quarter, and year views | Fiscal calendar setup | Low | P1 |
| FIN-09 | The system shall produce a consolidated report combining data from both sites for senior management review. | Must | Config | Consolidated cross-site management reporting | Final reporting hierarchy | Low | P1 |
5 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| AUD-01 | The system shall maintain a comprehensive, immutable audit log of all transactions and system events: user ID, action, timestamp, before/after values. | Must | Config | Use ERPNext versioning, activity logs, and restricted admin rights, with custom logs where needed | Confirm immutability expectations and retention | Medium | P1 |
| AUD-02 | The audit log shall be searchable and filterable by user, date range, action type, and product. | Must | Config | Searchable query reports and audit dashboards | Audit search dimensions | Low | P3 |
| AUD-03 | The audit log shall be exportable to PDF and Excel for external audit purposes. | Must | Config | Exportable audit reports and print layouts | External audit report format | Low | P3 |
| AUD-04 | The system shall support document attachment: scanned LPOs, PRs, supplier invoices, GRNs, and prescriptions can be uploaded and linked to transactions. | Should | ERPNext | Use ERPNext attachments on documents | Attachment retention and size policy | Low | P1 |
| AUD-05 | The system shall flag and report on any transaction where a price override, quantity override, or authorization bypass was applied. | Must | Custom | Explicit override log for price, quantity, and authorization bypass events | Define all override event types | Medium | P3 |
5 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| DSH-01 | The system shall provide a role-appropriate home dashboard displaying key performance indicators relevant to that user's responsibilities. | Must | Config | Role-based workspaces and dashboard cards | Role KPI definitions | Low | P3 |
| DSH-02 | The management dashboard shall include (at minimum) daily sales figure, SOH status (% products below reorder level), number of expiry alerts, outstanding insurance claims value, and top 10 dispensed products. | Must | Config | Management dashboard with custom cards and reports for required KPIs | KPI formulas and data source alignment | Medium | P3 |
| DSH-03 | Dashboard KPIs shall be visualized with charts and color-coded status indicators (green/amber/red). | Should | Config | Charts and color-coded indicators in workspaces | Threshold definitions | Low | P3 |
| DSH-04 | The system shall support ad-hoc report generation: users select date range, site, product category, and generate tabular output. | Should | Config | Query reports and filterable script reports | Report permissions model | Low | P3 |
| DSH-05 | The system shall support scheduling of automated reports to be emailed to configured recipients at set intervals (daily, weekly, monthly). | Nice | Config | Scheduled reports emailed through ERPNext scheduler | Email infrastructure and recipient list | Low | P4 |
3 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| NFR-P01 | Any screen, report, or transaction must load and complete within 5 seconds under normal operating conditions. | Must | Process | Define performance test baseline, optimize reports, indexes, and forms | Hardware sizing and test dataset | Medium | P0 |
| NFR-P02 | The system must support a minimum of 5 concurrent users per site without degradation. | Must | Process | Capacity plan for at least 5 concurrent users per site | Concurrent usage model | Low | P0 |
| NFR-P03 | System availability shall be no less than 99% during operating hours (6:00 AM – 10:00 PM local time). | Must | Process | Hosting, monitoring, backups, and maintenance window controls | Infrastructure ownership and SLA | Medium | P0 |
4 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| NFR-R01 | The system shall support offline operation for core dispensing and stock transactions in the event of internet connectivity loss, synchronizing with the server when connectivity is restored. | Must | Custom | Design offline dispensing/stock capability only after architecture review | Decide whether offline is browser-based, mobile, or local-node | Very High | P4 |
| NFR-R02 | No data entered offline shall be lost in the event of a synchronization conflict; conflicts shall be flagged for manual review. | Must | Custom | Conflict-safe sync queue with manual review screen | Conflict resolution rules | Very High | P4 |
| NFR-R03 | Automated database backups shall occur at minimum daily, with backups stored off-site or in a cloud service. Backup integrity shall be verified automatically. | Must | Process | Automated daily backups with off-site retention and restore checks | Hosting and backup tool choice | Medium | P0 |
| NFR-R04 | The system shall support recovery from hardware failure within 4 hours using the most recent backup. | Must | Process | DR procedure with tested restore within 4 hours | Recovery ownership and infrastructure budget | Medium | P0 |
4 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| NFR-S01 | All data transmitted between client and server shall be encrypted using TLS 1.2 or higher. | Must | Process | Enforce HTTPS/TLS on deployment | Hosting and certificate management | Low | P0 |
| NFR-S02 | The database shall be encrypted at rest. | Must | Process | Use encrypted disks/database host and secure backup storage | Infrastructure platform choice | Medium | P0 |
| NFR-S03 | No patient or financial data shall be stored unencrypted on local devices. | Must | Process | Prevent unsafe local storage and define encrypted offline storage rules if offline is approved | Offline architecture decision | High | P0 |
| NFR-S04 | The system shall comply with applicable Sierra MSI Reproductive Choices Data Regulation Standards, Sierra Leone data protection regulations and, where relevant, international standards such as ISO 27001. | Must | Process | Compliance review against MSSL and Sierra Leone data standards | Formal compliance checklist | High | P0 |
4 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| NFR-U01 | The system shall be operable in English language. | Must | ERPNext | English UI and print formats | None significant | Low | P1 |
| NFR-U02 | The interface shall be operable on Windows laptops or Android tablets as well as desktop PCs. | Must | Process | Browser/device compatibility testing on Windows and Android | Final device shortlist | Medium | P5 |
| NFR-U03 | New users shall be able to complete core dispensing and billing tasks after no more than 2 days of training. | Must | Process | Training plan, simplified workflows, and UAT with real users | Training ownership | Medium | P5 |
| NFR-U04 | All screens shall display contextual help text or a help function accessible without leaving the screen. | Should | Config | Inline help text, field descriptions, and help pages | Documentation ownership | Low | P3 |
5 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| NFR-I01 | The system shall provide or support integration with MSSL’s Electronic Health Record (EHR) to link prescription records. | Must | Integration | EHR integration for patient/prescription linkage | External EHR API/spec and owner | Very High | P4 |
| NFR-I02 | The system shall export data in standard formats (CSV, Excel, PDF) for use in external accounting software if required. | Must | ERPNext | CSV, Excel, and PDF export using ERPNext reports | Target accounting use case | Low | P1 |
| NFR-I03 | The system shall support barcode and QR code scanning via USB or Bluetooth scanners. | Must | Config | Barcode and QR scanning on supported devices and forms | Hardware testing | Low | P1 |
| NFR-I04 | The system shall support printing with standard laser/inkjet printers and POS thermal receipt printers. | Must | Config | Support laser, inkjet, label, and thermal printer formats | Printer rollout plan | Low | P1 |
| NFR-I05 | The system should provide an API or data export capability to support insurance electronic claim submission. | Should | Integration | API or structured export for insurer e-claims | Insurer technical specs | High | P4 |
3 requirements
| ID | Exact Requirement | Priority | Fit | Implementation Approach | Dependency / Decision | Risk | Phase |
|---|---|---|---|---|---|---|---|
| NFR-M01 | The system architecture shall support the addition of further sites without architectural changes. | Must | Process | Use site-scalable warehouse and permission model from day one | Multi-site expansion assumptions | Low | P0 |
| NFR-M02 | The vendor shall provide a clearly documented upgrade pathway and commit to a minimum of 5 years of software support and security patches. | Must | Process | Keep custom code in `pharmacy_app`, avoid ERPNext core edits, define support plan | Internal vs vendor support model | Medium | P0 |
| NFR-M03 | System configuration (formulary, pricing, user roles, report parameters) shall be manageable by the System Administrator without vendor involvement. | Must | Config | Expose manageable settings for formulary, pricing, roles, and report parameters | Final admin operating scope | Low | P1 |