12 KiB
12 KiB
Software Requirements Specification (SRS)
| Document field | Value |
|---|---|
| Document | Software Requirements Specification |
| Project | BRN WMS |
| Project code | 200-WMS-26-001-00 |
| Title | Software Requirements Recording and Summary Document (Software Requirements Specification) |
| Project period | 05/01/26–24/08/26 |
| Release | 17/08/26 V1.0 |
| Standard | ISO/IEC 29110 Basic Profile |
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
| Recorder | Thanakorn Sathitwitayakul — Developer |
| Status | Final — reformulates the approved Customer Requirements into technical software requirements |
Objective
To restate the approved Customer Requirements as technical software requirements — standards, structure, elements, relationships, performance, interfaces, security, database, and error handling — so they can drive Software Design, Software Components, Test Cases, and Traceability.
Basis and scaling note
The example reference package (200-TAS-25-001-00) enumerates one SR row per screen/CRUD action because that project is a small brochure site with ~6 modules. BRN WMS is a multi-domain warehouse/ERP system with 31 backend manager classes and 17 top-level application areas (Section 3 below). Reproducing CRUD-button-level granularity would create hundreds of near-duplicate rows without adding traceability value. This SRS therefore keeps the same category structure (SR01–SR09) as the example but sets granularity at the same level already approved in the Customer Requirements (FR-001–FR-024, NFR-001–NFR-010), one SR row per requirement or tight requirement group. Every SR row's Remark links back to its Customer Requirements ID.
SR01: Standards of Software
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR01:001 | The system shall be developed in alignment with ISO/IEC 29110 Basic Profile documentation and traceability practice. | A | NFR-009 |
| SR01:002 | The system shall use PHP 8+ for the application layer, MySQL/MariaDB for data storage, and Node.js for real-time/scheduled services. | A | NFR-008 |
| SR01:003 | The system shall be deployable on a Linux server, either via manual LAMP-style installation (setup.php) or the provided Docker Compose stack (php-apache, mariadb, node/pm2). |
A | NFR-004 |
| SR01:004 | User passwords shall be hashed with PASSWORD_BCRYPT (PHP default cost factor); plaintext passwords shall never be stored or logged. |
A | NFR-002 |
| SR01:005 | Configuration secrets (app/config.php, .env) shall be excluded from source control and generated at deployment time. |
A | NFR-001 |
SR02: Software Structure Considerations
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR02:001 | The system shall be a browser-based, multi-page PHP web application (not a single native client). | A | FR-002, operational context |
| SR02:002 | The user interface shall be responsive across desktop and warehouse-floor (tablet/mobile) viewports. | A | NFR-005 |
| SR02:003 | Application logic shall be organized as PHP manager/service classes invoked by page controllers, separated from page presentation. | A | NFR-007 |
| SR02:004 | Data access shall be encapsulated through manager classes rather than inline SQL scattered across pages, where practical. | A | NFR-007 |
| SR02:005 | The system shall be deployable as a container stack (Docker Compose: php-apache, mariadb, node/pm2) in addition to manual installation. | A | NFR-004 |
SR03: Software Elements (Modules)
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR03:001 | Identity/access module: registration, onboarding, authentication, role (Owner/Admin/Staff/Viewer) and application-access management (app/login/, UserManager, PasswordManager, PasswordResetManager). |
A | FR-001–FR-004 |
| SR03:002 | Company/system configuration module: company profile, SMTP, system settings (app/setting/, CompanyProfileManager, CompanySettingManager, SmtpManager). |
A | FR-004 |
| SR03:003 | Master data module: warehouses, storage/bins, product categories, products, contacts (app/inventory/, app/contact/, WarehouseManager, ProductManager, ContactManager). |
A | FR-005, FR-006 |
| SR03:004 | Inventory/warehouse operations module: stock-in, stock-out, transfer, lot/serial/expiry, barcode labels (app/ics/, StockManager, StockSourceManager, BarcodeManager). |
A | FR-007–FR-012 |
| SR03:005 | Sales module: quotation, order, invoice, return, credit note (app/order/, app/revenue/, QuotationManager, OrderManager, InvoiceManager, ReturnManager). |
A | FR-013 |
| SR03:006 | Purchasing module: purchase request, purchase order, purchase invoice, supplier return (app/po/, PurchaseRequestManager, PurchaseOrderManager, SupplierReturnManager). |
A | FR-014 |
| SR03:007 | Finance module: receipt billing, receipts, payment billing, payments (app/finance/, ReceiptBillingManager, ReceiptManager, PaymentBillingManager, PaymentManager). |
A | FR-015 |
| SR03:008 | Accounting module: chart of accounts, departments, account formulas, journals, general ledger (app/accounting/, app/journal/, PostingManager). |
A | FR-016 |
| SR03:009 | Reporting/dashboard module: stock, financial, and operational reports and dashboards (app/reports/, app/dashboard/, app/ac_dashboard/, app/revenue/, app/expense/, ReportManager). |
A | FR-011, FR-017, FR-020 |
| SR03:010 | Document-control module: controlled document numbering and lifecycle/status (DocumentNumberManager). |
A | FR-018 |
| SR03:011 | Notification/scheduler services: Socket.IO notifications and scheduled aggregate/alert jobs (nodejs/server.js, nodejs/scheduler.js, app/cron/, EtlStockManager). |
A | FR-021, FR-022 |
SR04: Software Elements Relationship
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR04:001 | Every operational module shall be reachable only through the identity/access module's authentication and role/application-access checks. | A | FR-002, FR-024 |
| SR04:002 | Sales, purchasing, and finance modules shall post related stock and general-ledger effects through the inventory and accounting modules rather than duplicating their logic. | A | FR-013–FR-016 |
| SR04:003 | The reporting module shall read from, and never bypass, the authorization scope enforced by the master-data and inventory modules (company/warehouse isolation). | A | FR-024 |
| SR04:004 | The notification/scheduler services shall relay events from the PHP application through a secret-protected internal endpoint, not directly from the browser to internal services. | A | NFR-002 |
| SR04:005 | Document-control numbering shall be invoked by every module that creates a controlled business document (order, invoice, receipt, payment, journal, etc.). | A | FR-018 |
SR05: Performance Characteristics
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR05:001 | Representative daily operations (screen loads, list/search, document creation) shall complete within practical operational time on the agreed environment. | A | NFR-006 |
| SR05:002 | Stock, GL, and dashboard aggregates shall be maintained on a schedule (ETL/summary tables) so dashboard and report queries do not require full recomputation on each request. | A | NFR-006, FR-022 |
| SR05:003 | The system shall support the representative concurrent-user and data-volume levels agreed for the production environment. | A | NFR-006 |
SR06: Software Interfaces
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR06:001 | The PHP application shall connect to two MariaDB databases: wms (identity/company) and wms2 (WMS/accounting). |
A | Operational context, SR08 |
| SR06:002 | The application shall be usable on current standards-based browsers (Chrome, Edge, Firefox). | A | NFR-008 |
| SR06:003 | The application shall support mobile/tablet browser access through the responsive UI. | A | NFR-005 |
| SR06:004 | The PHP application shall relay events to the Node.js service over an internal, secret-protected HTTP endpoint (NODE_EMIT_URL, NODE_EMIT_SECRET). |
A | NFR-002 |
| SR06:005 | The browser shall connect to the Node.js Socket.IO endpoint (NODE_PUBLIC_URL) for real-time notification delivery. |
A | FR-021 |
SR07: Security Characteristics
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR07:001 | Production deployment shall terminate the client connection over HTTPS/TLS. | A | NFR-001 |
| SR07:002 | Server-side actions shall validate input and enforce authentication, authorization, and tenant (company/warehouse) scope. | A | NFR-002 |
| SR07:003 | The system shall enforce single active-session (block concurrent login) behavior per the implemented login policy. | A | NFR-002 |
| SR07:004 | The system shall protect against SQL injection and cross-site scripting in server-side input handling and output rendering. | A | NFR-002 |
| SR07:005 | Role-based access control (Owner/Admin/Staff/Viewer) shall restrict server-side actions, not only UI visibility. | A | FR-002, NFR-002 |
SR08: Database Design Requirements
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR08:001 | Identity/company database (wms): user, company_list, company_map_user, company_setting, company_smtp, company_usage, whitelist. |
A | FR-001–FR-004 |
| SR08:002 | Master-data tables in the WMS database (wms2): md_warehouse, md_storage, md_bin, md_product, md_product_category, md_contact, md_contact_type, md_account, md_account_formula, md_account_formula_item, md_department, md_barcode, md_sku_barcode_label, md_lot, md_lock_operation. |
A | FR-005, FR-006, FR-010, FR-012, FR-016 |
| SR08:003 | Transaction-data tables (td_*): td_stock, td_order/td_order_item, td_quotation/_item, td_invoice/_item, td_return/_item, td_purchase_request/_item, td_purchase_order/_item, td_supplier_return/_item, td_receipt/_item, td_receipt_billing/_item, td_payment/_item, td_payment_billing/_item, td_gl/td_gl_item, td_batch_action, td_bin_log. |
A | FR-007–FR-018 |
| SR08:004 | Aggregate/document-control tables: etl_stock_summary, etl_gl_summary, document_number_sequences, document_types, schema_migrations. |
A | FR-018, FR-022 |
| SR08:005 | All tables created by the delivered setup.php shall be reproducible in a fresh environment without manual schema editing. |
A | NFR-004 |
SR09: Error Handling and Recovery Attributes
| ID | Requirement | Result* | Remark |
|---|---|---|---|
| SR09:001 | Destructive actions (delete, void, cancel of a controlled record) shall require an explicit confirmation step. | A | Usability practice; not a numbered CR/FR but implemented consistently across modules |
| SR09:002 | Errors shall present a usable message to the user rather than an unhandled fatal error, for the primary operational workflows. | A | NFR-006 |
| SR09:003 | Related database changes (e.g., document + stock + GL postings) shall be transactional where required to avoid partial/inconsistent updates. | A | NFR-003 |
Remark:
- * Result: A = Accepted (implemented and evidenced in the current codebase), U = Unaccepted, N/A = Not Applicable. No SR row in this document is marked A without an identifiable implementing module, class, or table.
- This SRS restates already-approved Customer Requirements; it does not introduce new scope. Any SR row without a direct FR/NFR precedent must be raised through the Change Report before being treated as binding.
Approval
Prepared by
Name: Thanakorn Sathitwitayakul
Role: Developer
Signature: ______________________________________________
Date: ___________________________________________________
Reviewed by
Name: Apirach Supattaratpateep
Role: Project Manager
Signature: ______________________________________________
Date: ___________________________________________________
Reviewed and authorized by
Name: Seri Viriyasakultorn
Project roles: Project Sponsor / Customer Representative / Authorized Approver
Position: Managing Director
Company: B.R.N. Enterprise Co., Ltd.
Signature: ______________________________________________
Date: ___________________________________________________