Total Rows
110 exact requirement rows reproduced from sections 3.1 to 4.6.
PMIS Exact Requirements Register
This page reproduces the signed URS requirements as a source-exact register, preserving the requirement wording, priority, and notes or acceptance criteria from the PDF as faithfully as possible in HTML form.
Source of truth: this register is derived directly from the signed PDF layout and is intended to mirror the requirement rows, not reinterpret them for implementation planning.
Document inconsistency: the PDF summary table states 108 total requirements, but the source sections 3.1 to 4.6 contain 110 requirement rows when reproduced exactly.
Sections
18 requirement sections across functional and non-functional domains.
Use This For
Verifying exact requirement wording, priority, and acceptance notes before planning or backlog mapping.
Filter Register
Showing 110 of 110 requirements
3.1 User Access and Security Management
7 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| UAM-01 | The system shall support role-based access control (RBAC), limiting each user to screens and functions permitted for their role. | Must Have | No user can access functions outside their assigned role. |
| UAM-02 | The system requires a unique username and strong password for each user. Default passwords must be changed on first login. | Must Have | Minimum 8 characters; enforce complexity rules. |
| UAM-03 | The system shall support two-factor authentication (2FA) for privileged roles (Administrator, Pharmacist-in-Charge, Finance Officer). | Should Have | SMS or authenticator app token accepted. |
| UAM-04 | Sessions shall time out after a configurable period of inactivity (default: `5 minutes). | Must Have | Configurable by administrator. |
| UAM-05 | The system shall log every login, failed login attempt, and logout with timestamp, username, and IP address. | Must Have | Audit trail cannot be deleted by any user. |
| UAM-06 | User accounts shall be created, modified, suspended, or deleted only by the System Administrator. | Must Have | Suspended accounts cannot log in, but records are retained. |
| 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 Have | Essential for Waterloo Rural and Lamina Sanko sites. |
3.2 Medicine Formulary and Product Catalogue
7 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| DFC-01 | The system shall maintain a central drug formulary / product catalogue covering all medicines, consumables, and sundries dispensed or sold. | Must Have | Catalogue is shared across both sites. |
| 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 Have | |
| DFC-03 | The system shall support multiple units of measurement per product (e.g., bottles, tablets, vials) with configurable conversion factors. | Must Have | E.g., 1 bottle = 100 tablets. |
| DFC-04 | Each product shall be assigned a unique SKU/barcode. The system shall support barcode scanning for product lookup. | Must Have | Barcode scanner hardware required at dispensing and GRN points. |
| DFC-05 | The system shall flag products classified as controlled medicine and enforce additional recording requirements for those items. | Must Have | Linked to controlled drug register (Section 3.8). |
| DFC-06 | The formulary shall be editable only by the Pharmacist-in-Charge or Administrator; changes shall be logged with user and timestamp. | Must Have | |
| DFC-07 | The system shall support product substitution: the ability to link a generic drug to acceptable brand alternatives. | Should Have | Supports dispensing flexibility. |
3.3 Procurement and Supplier Management
7 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| PRO-01 | The system shall maintain a supplier database including name, contact details, address, payment terms, and lead time. | Must Have | |
| 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 Have | |
| PRO-03 | PRs shall require authorization by the Pharmacist-in-Charge or Centre Manager before submission to the Inventory Manager. | Must Have | Dual-authorization workflow for orders above a configurable financial threshold. |
| PRO-04 | The system shall track PR status: Draft, Submitted, Partially Received, Fully Received, Cancelled. | Must Have | |
| 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 Have | Alert displayed on dashboard and sent by email/SMS if configured. |
| PRO-06 | The system shall produce a suggested order list based on reorder levels, average consumption rates, and supplier lead times. | Should Have | Reduces manual effort in procurement planning. |
| PRO-07 | The system shall record supplier performance data: on-time delivery rate, rejection/return rate, and pricing history. | Should Have | Supports supplier evaluation. |
3.4 Goods Receipt and Stock Intake
7 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| GRN-01 | On delivery of goods, the system shall allow creation of a Goods Received Note (GRN) linked to the originating PR. | Must Have | Quantity received vs. ordered is reconciled. |
| GRN-02 | Each GRN line shall capture product, batch number, manufacturer, quantity received, unit cost, selling price, expiry date, and storage location. | Must Have | Mandatory fields: system blocks GRN save if any are blank. |
| GRN-03 | The system shall automatically update stock on hand upon GRN confirmation. | Must Have | GRN confirmation is a separate, authorized step from GRN creation. |
| GRN-04 | The system shall support partial deliveries: a single PR may have multiple GRNs until the order is fully received. | Must Have | |
| 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 Have | Prevents inadvertent acceptance of near-expired stock. |
| GRN-06 | The system shall support recording of supplier invoices against GRNs for accounts payable reconciliation. | Must Have | Invoice number, date, and amount recorded. |
| GRN-07 | GRNs shall be editable only before confirmation; post-confirmation corrections must be handled via a documented stock adjustment with reason code. | Must Have | Preserves audit trail integrity. |
3.5 Inventory Management and Stock Control
9 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| INV-01 | The system shall maintain a perpetual inventory, updating SOH in real time after every transaction (receipt, dispensing, return, adjustment, transfer). | Must Have | |
| INV-02 | The system shall apply FEFO (First Expiry, First Out) logic automatically when selecting batch for dispensing. | Must Have | Reduces expiry losses. |
| INV-03 | The system shall generate an expiry alert list for products expiring within a configurable period (default: 3 months). | Must Have | Alert visible on daily dashboard; exportable to Excel/PDF. |
| 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 Have | Transferring SOH decreases; receiving site SOH increases on confirmation. |
| 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 Have | Variance above a configurable threshold requires authorization to post. |
| INV-06 | Stock adjustments (write-offs, breakages, pilferage) shall require a reason code and dual authorization (Pharmacist-in-Charge + Administrator). | Must Have | All adjustments are immutably logged. |
| INV-07 | The system shall calculate and display stock valuation using weighted average cost or configurable costing method. | Must Have | Required for financial reporting. |
| INV-08 | The system shall produce a daily stock movement report showing opening balance, receipts, dispensed, adjusted, transfers, and closing balance per product. | Must Have | |
| INV-09 | The system shall flag negative stock levels and prevent dispensing below zero SOH. | Must Have | Override only by Pharmacist-in-Charge with documented reason. |
3.6 Prescription Management and Dispensing
10 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| 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 Have | |
| 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 Have | |
| RXD-03 | The system shall check for drug interactions and allergy flags at point of dispensing and alert the pharmacist. | Should Have | Interaction database must be updated regularly. |
| RXD-04 | The system should enforce quantity limits: the dispensed quantity cannot exceed the prescribed quantity without an override with documented reason. | Must Have | |
| RXD-05 | Upon dispensing, the system shall automatically deduct the dispensed quantity from the relevant batch's SOH (FEFO applied). | Must Have | |
| 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 Have | Label printer required as peripheral. |
| RXD-07 | The system shall support repeat dispensing for chronic disease patients, linking each dispensing to the original prescription and tracking remaining quantity. | Should Have | |
| RXD-08 | The system shall support OTC (over the counter) sales without a formal prescription, linked to a walk-in patient record. | Must Have | |
| RXD-09 | Dispensed items shall be linked to a billing transaction automatically (Section 3.7). | Must Have | |
| RXD-10 | The system shall record who dispensed each item with timestamp, and support supervisory review. | Must Have |
3.7 Point of Sale, Billing, and Payments
10 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| 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 Have | |
| BIL-02 | The system shall support multiple payment methods per transaction: cash, insurance claim, organizational credit (for staff/wards), and mobile money. | Must Have | Payment method recorded against every transaction. |
| BIL-03 | For cash transactions, the system shall calculate, and display change due. | Must Have | |
| BIL-04 | The system shall support configurable pricing tiers: e.g., standard patient price, staff price, bulk/institutional price. | Should Have | |
| BIL-05 | The system shall support discount authorization: discounts above a configurable threshold require approval by the Pharmacist-in-Charge or Manager. | Must Have | |
| BIL-06 | The system shall support insurance claim processing: generate claim forms/data, track claim submission, approval, and payment by insurance company. | Must Have | Critical for insurance clients. Sierra Leone public insurance billing. |
| BIL-07 | The system shall support credit accounts for institutional clients (e.g., wards, NGOs), tracking outstanding balances and credit limits. | Must Have | |
| BIL-08 | The system shall perform an end-of-day cash reconciliation: total cash sales vs. cash declared by cashier, flagging discrepancies. | Must Have | Reconciliation is a mandatory close-of-day step; supervisor sign-off required. |
| BIL-09 | Invoices shall be numbered sequentially and non-editable once issued; cancellations require a credit note with reason. | Must Have | Audit integrity requirement. |
| BIL-10 | The system shall support printing of receipts on a standard POS receipt printer. | Must Have |
3.8 Controlled Medicines Register
6 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| CDR-01 | The system shall maintain a separate electronic controlled medicine register for each product classified as a controlled substance. | Must Have | Meets PBSL requirements. |
| 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 Have | |
| CDR-03 | The balance in the controlled medicine register shall always reconcile with the stock module; discrepancies shall generate an immediate alert. | Must Have | |
| CDR-04 | The controlled medicine register shall be exportable in a format suitable for regulatory submission. | Must Have | |
| CDR-05 | Access to create or modify controlled medicine register entries shall be restricted to licensed pharmacists only. | Must Have | |
| CDR-06 | The system shall flag and prevent the dispensing of a controlled medicine if no valid prescription has been recorded. | Must Have |
3.9 Expiry Management and Returns
5 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| 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 Have | |
| 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 Have | Write-off requires dual authorization and reason code. |
| EXP-03 | The system shall support recording of returns to supplier: quantity, reason, credit note reference, and adjustment to stock and accounts payable. | Must Have | |
| 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 Have | Quarantine prevents returned stock being re-dispensed without pharmacist review. |
| EXP-05 | The system shall report on total value of stock written off by reason code per month. | Must Have | Key financial accountability metric. |
3.10 Financial Reporting and Accounts
9 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| FIN-01 | The system shall produce a Daily Revenue Summary: total sales by payment method, discounts given, and net revenue per site. | Must Have | |
| FIN-02 | The system shall produce a Monthly Profit and Loss view: revenue, cost of goods sold (COGS), gross margin, and write-offs. | Must Have | Requires accurate stock valuation. |
| FIN-03 | The system shall maintain an Accounts Receivable ledger for credit clients, showing invoiced amounts, payments received, and outstanding balances. | Must Have | |
| FIN-04 | The system shall produce an Aged Debtors Report, categorizing outstanding balances by 0–30, 31–60, 61–90, and 90+ days. | Must Have | |
| FIN-05 | The system shall produce a Stock Valuation Report at any point in time, by site and in aggregate. | Must Have | |
| FIN-06 | The system shall produce a Procurement Spend Report: total spend by supplier and by therapeutic category per period. | Should Have | |
| FIN-07 | All financial reports shall be exportable to PDF and Excel. | Must Have | |
| FIN-08 | The system shall support configurable financial periods (monthly, quarterly, annual) for report generation. | Should Have | |
| FIN-09 | The system shall produce a consolidated report combining data from both sites for senior management review. | Must Have |
3.11 Audit Trail and Compliance
5 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| 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 Have | Cannot be deleted or modified by any user including Administrator. |
| AUD-02 | The audit log shall be searchable and filterable by user, date range, action type, and product. | Must Have | |
| AUD-03 | The audit log shall be exportable to PDF and Excel for external audit purposes. | Must Have | |
| AUD-04 | The system shall support document attachment: scanned LPOs, PRs, supplier invoices, GRNs, and prescriptions can be uploaded and linked to transactions. | Should Have | Supports paperless documentation. |
| AUD-05 | The system shall flag and report on any transaction where a price override, quantity override, or authorization bypass was applied. | Must Have |
3.12 Dashboard and Management Information
5 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| DSH-01 | The system shall provide a role-appropriate home dashboard displaying key performance indicators relevant to that user's responsibilities. | Must Have | |
| 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 Have | |
| DSH-03 | Dashboard KPIs shall be visualized with charts and color-coded status indicators (green/amber/red). | Should Have | |
| DSH-04 | The system shall support ad-hoc report generation: users select date range, site, product category, and generate tabular output. | Should Have | |
| DSH-05 | The system shall support scheduling of automated reports to be emailed to configured recipients at set intervals (daily, weekly, monthly). | Nice to Have |
4.1 Performance
3 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| NFR-P01 | Any screen, report, or transaction must load and complete within 5 seconds under normal operating conditions. | Must Have | Tested with realistic concurrent user load. |
| NFR-P02 | The system must support a minimum of 5 concurrent users per site without degradation. | Must Have | |
| NFR-P03 | System availability shall be no less than 99% during operating hours (6:00 AM – 10:00 PM local time). | Must Have | Excludes pre-scheduled maintenance windows. |
4.2 Reliability and Offline Capability
4 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| 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 Have | Critical given connectivity challenges. |
| NFR-R02 | No data entered offline shall be lost in the event of a synchronization conflict; conflicts shall be flagged for manual review. | Must Have | |
| 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 Have | |
| NFR-R04 | The system shall support recovery from hardware failure within 4 hours using the most recent backup. | Must Have | Recovery Time Objective (RTO) requirement. |
4.3 Security
4 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| NFR-S01 | All data transmitted between client and server shall be encrypted using TLS 1.2 or higher. | Must Have | |
| NFR-S02 | The database shall be encrypted at rest. | Must Have | |
| NFR-S03 | No patient or financial data shall be stored unencrypted on local devices. | Must Have | |
| 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 Have |
4.4 Usability
4 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| NFR-U01 | The system shall be operable in English language. | Must Have | |
| NFR-U02 | The interface shall be operable on Windows laptops or Android tablets as well as desktop PCs. | Must Have | |
| NFR-U03 | New users shall be able to complete core dispensing and billing tasks after no more than 2 days of training. | Must Have | System must be intuitive; vendor to provide training. |
| NFR-U04 | All screens shall display contextual help text or a help function accessible without leaving the screen. | Should Have |
4.5 Integration
5 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| NFR-I01 | The system shall provide or support integration with MSSL’s Electronic Health Record (EHR) to link prescription records. | Must Have | Integration specification to be confirmed by EHR administrator in LSO. |
| NFR-I02 | The system shall export data in standard formats (CSV, Excel, PDF) for use in external accounting software if required. | Must Have | |
| NFR-I03 | The system shall support barcode and QR code scanning via USB or Bluetooth scanners. | Must Have | |
| NFR-I04 | The system shall support printing with standard laser/inkjet printers and POS thermal receipt printers. | Must Have | |
| NFR-I05 | The system should provide an API or data export capability to support insurance electronic claim submission. | Should Have | Subject to insurance clients requirements. |
4.6 Scalability and Maintainability
3 requirements
| ID | Requirement | Priority | Notes / Acceptance Criteria |
|---|---|---|---|
| NFR-M01 | The system architecture shall support the addition of further sites without architectural changes. | Must Have | MSSL may open additional centres. |
| 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 Have | |
| NFR-M03 | System configuration (formulary, pricing, user roles, report parameters) shall be manageable by the System Administrator without vendor involvement. | Must Have |