wms-app/sdlc/1-PM Process (10 Work Product)/2.Project Plan/3-Customer Requirement/200-WMS-26-001-00 Customer Requirements 25690112 V1.0 Final.md

Customer Requirements

Document field	Value
Document	Customer Requirements
Project	BRN WMS
Project code	200-WMS-26-001-00
Title	Document Recording and Summarizing Customer Requirements
Project period	05/01/26–24/08/26
Release	12/01/26 V1.0 Final
Standard	ISO/IEC 29110 Basic Profile
Project Manager	Apirach Supattaratpateep
System Analyst	Noppong Chareunsook
Developer	Thanakorn Sathitwitayakul
Project Sponsor / Customer Representative	Seri Viriyasakultorn
Status	Final — ready for review and authorized approval

1. Purpose

This document records the customer-level functional and non-functional requirements for BRN WMS. It provides the approved input for the Software Requirements Specification, Software Design, Traceability Record, Test Cases and Test Procedures, Verification Results, Validation Results, and Acceptance Report.

The System Analyst records the technical interpretation, and the Project Sponsor acting as Customer Representative reviews the operational accuracy and authorizes the baseline.

2. Business need

B.R.N. Enterprise Co., Ltd. requires a centralized warehouse management system to improve inventory accuracy, transaction control, operational visibility, and auditability. The system must support multiple companies and warehouses while restricting users to authorized data and functions.

The expected business outcomes are:

• Timely and accurate stock information.
• Traceable receipts, issues, transfers, lots, serial numbers, and expiry dates.
• Controlled sales, purchasing, finance, and accounting documents.
• Reduced manual error and duplicate data handling.
• Faster operational and management reporting.
• Stronger access control, company-data isolation, and accountability.
• Maintainable deployment, configuration, backup, and recovery procedures.

3. Stakeholders

Stakeholder	Project role	Responsibility and interest
Seri Viriyasakultorn	Project Sponsor / Customer Representative / Authorized Approver	Represent customer needs and approve project scope, strategic decisions, requirement baseline, acceptance, and closure.
Apirach Supattaratpateep	Project Manager	Plan and coordinate requirement activities, resolve issues, control changes, and maintain the approved baseline.
Noppong Chareunsook	System Analyst	Analyze customer needs, specify system behavior, and maintain technical traceability.
Thanakorn Sathitwitayakul	Developer	Design and implement the solution.
Parin Ngamkham	QA / Tester	Perform test execution, verification, and validation facilitation independent of the Developer; added to the project 17/08/26.
Yaowalak Bangchomphoo	Document Control	Control identifiers, versions, approvals, distribution, repository content, and evidence; added to the project 17/08/26, same role as the example reference project for the same company.
Warehouse Manager and Staff	Operational users	Perform and review warehouse, stock, barcode, and reporting operations.
Sales and Purchasing Users	Business users	Perform quotation, order, purchase, invoice, and return workflows.
Finance and Accounting Users	Business users	Perform billing, receipt, payment, journal, ledger, and financial reporting activities.
System Administrator	Supporting user	Configure the environment, company, users, services, monitoring, backup, and recovery.
Management / Auditor	Information consumer	Review controlled records, transaction history, exceptions, and management information.

4. Operational context

BRN WMS is a browser-based application composed of:

• A PHP web application providing user interfaces and operational APIs.
• A MySQL/MariaDB identity and company database.
• A MySQL/MariaDB WMS and accounting database.
• A Node.js/Socket.IO service for real-time notifications.
• A Node.js scheduler for aggregate maintenance and operational alerts.
• A controlled Git repository for source and configuration templates.

Users access the system through current standards-based browsers. The application and scheduled services operate using the Asia/Bangkok time zone.

5. Assumptions and constraints

• The application is deployed in a controlled PHP 8+, MySQL/MariaDB, and Node.js environment.
• B.R.N. provides authorized users, representative operational data, and availability for review and validation.
• Required network, server, barcode, printing, and endpoint hardware is available or procured separately.
• Legacy-data migration is excluded unless assessed and approved through change control.
• External ERP, bank, shipping, tax, or other third-party integration is excluded unless formally added.
• Local credentials, passwords, tokens, and secrets are not stored in the source repository.
• “Must” requirements are acceptance-critical. A “Should” requirement may only be deferred through documented disposition.

6. Requirement interpretation

Term	Meaning
Must	Mandatory for acceptance unless the Project Sponsor authorizes a documented exception.
Should	Expected within the agreed solution; deferral requires documented review and disposition.
User	An authenticated person acting in an authorized company and role context.
Company	A tenant whose data must be isolated from other companies.
Warehouse location	A warehouse, storage area, and/or bin used to identify stock location.
Controlled document	A business or project record with identifier, status, history, and applicable authorization.

7. Functional requirements

7.1 Identity and access

ID	Requirement	Priority	Acceptance intent
FR-001	The system shall support registration and onboarding of a company owner and onboarding of invited users.	Must	An authorized user can complete the applicable onboarding flow and access the assigned company.
FR-002	The system shall authenticate users and enforce the Owner, Admin, Staff, and Viewer roles.	Must	Each role can access only its permitted screens and server-side actions.
FR-003	The system shall support password recovery, session control, and applicable OTP verification.	Must	Recovery and verification operate without exposing credentials; concurrent-session rules are enforced.
FR-004	The system shall allow authorized administrators to manage company profile, SMTP, system settings, users, and application access.	Must	Authorized changes are saved and unauthorized users are rejected.

7.2 Master data

ID	Requirement	Priority	Acceptance intent
FR-005	The system shall maintain warehouses, storage areas/bins, product categories, products, contact types, and contacts.	Must	Authorized users can create, view, update, and appropriately deactivate supported records.
FR-006	The system should support both simple and layered warehouse-location models.	Should	A company can use a basic warehouse model or configured warehouse/storage/bin levels.

7.3 Inventory and warehouse operations

ID	Requirement	Priority	Acceptance intent
FR-007	The system shall record stock-in using product, quantity, warehouse/location, document, and applicable traceability attributes.	Must	A valid receipt creates the expected movement and balance; invalid input is rejected.
FR-008	The system shall record stock-out with authorization and available-balance validation.	Must	An authorized issue reduces the correct balance and cannot issue an invalid quantity.
FR-009	The system shall transfer stock between authorized warehouse locations.	Must	Source and destination movements remain balanced and traceable as one transfer.
FR-010	The system shall track lot, serial number, and expiry date where applicable.	Must	Relevant stock and reports retain and display the required traceability attributes.
FR-011	The system shall display stock overview, movement history, capacity/occupancy, low-stock, expired-stock, and product-lot information.	Must	Reports reflect authorized operational data and applicable filters.
FR-012	The system should generate SKU and location barcode labels and support scanning workflows.	Should	Labels contain usable identifiers and supported screens accept scanned values.

7.4 Sales and purchasing

ID	Requirement	Priority	Acceptance intent
FR-013	The system shall create and manage quotations, sales orders, invoices, returns, and credit notes.	Must	Authorized users can complete valid document lifecycles and related stock/financial effects.
FR-014	The system shall create and manage purchase requests, purchase orders, purchase invoices, and supplier returns.	Must	Authorized users can complete valid purchasing lifecycles and related stock/financial effects.

7.5 Finance and accounting

ID	Requirement	Priority	Acceptance intent
FR-015	The system shall create and manage receipt billing, receipts, payment billing, and payments.	Must	Authorized financial transactions retain document linkage, amount, status, and history.
FR-016	The system shall maintain chart of accounts, departments, account formulas, journals, and general-ledger entries.	Must	Authorized users can maintain structures and post balanced, traceable entries.
FR-017	The system shall provide trial balance, profit-and-loss, balance-sheet, VAT, journal, and GL-movement reports.	Must	Reports use authorized data and produce consistent totals for the selected period.

7.6 Documents, reports, and automation

ID	Requirement	Priority	Acceptance intent
FR-018	The system shall generate controlled document numbers and manage document lifecycle/status.	Must	Document numbers follow the configured sequence and invalid status transitions are rejected.
FR-019	The system should allow permitted file attachments on supported records.	Should	Allowed files can be uploaded and retrieved only by authorized users.
FR-020	The system shall allow authorized users to filter, view, print, and/or export supported operational and management reports.	Must	Report output matches the selected scope and filters.
FR-021	The system should notify authorized users of relevant status transitions and operational alerts.	Should	Relevant recipients receive only notifications within their authorized context.
FR-022	The system should maintain stock/GL summaries and generate low-stock and overdue-invoice alerts on schedule.	Should	Scheduled jobs complete without duplicate or unauthorized results.
FR-023	The system shall preserve creator, updater, status, and transaction history required for operational review.	Must	A reviewer can identify material record ownership and lifecycle events.
FR-024	The system shall restrict company and warehouse data to the current authorized user context.	Must	Cross-company and unauthorized warehouse access is prevented in UI and server-side actions.

8. Non-functional requirements

ID	Area	Requirement	Priority	Acceptance intent
NFR-001	Security	Configuration secrets shall be protected from source control and direct public web access.	Must	Repository and deployment review find no committed active secret or publicly exposed protected configuration.
NFR-002	Security	Server-side actions shall validate input and enforce authentication, authorization, and tenant scope.	Must	Negative authorization and invalid-input tests are rejected without unauthorized data change.
NFR-003	Integrity	Related database changes shall be transactional where required and prevent invalid negative or duplicate movements.	Must	Failure/rollback and concurrency-oriented tests preserve consistent balances and records.
NFR-004	Availability	Installation, configuration, backup, and recovery procedures shall be documented.	Must	An authorized administrator can follow the documentation in the supported environment.
NFR-005	Usability	The user interface should be responsive and usable on desktop and warehouse-floor devices.	Should	Representative screens remain usable at the agreed desktop and mobile viewport sizes.
NFR-006	Performance	Daily operations should respond within practical operational time, and aggregates should support dashboards and reports.	Should	Representative operations complete acceptably on the agreed environment and data volume.
NFR-007	Maintainability	The software should use modular managers/APIs, centralized helpers, configuration templates, and version control.	Should	Maintenance review can locate responsibilities and change configuration without modifying unrelated modules.
NFR-008	Compatibility	The system shall run on PHP 8+, MySQL/MariaDB, Node.js where used, and current standards-based browsers.	Must	Installation and representative workflows succeed on the supported platform.
NFR-009	Traceability	Every approved requirement shall link to design, component, and verification evidence.	Must	The Traceability Record has no unexplained gap for an approved Must requirement.
NFR-010	Time	Application and scheduled services shall use Asia/Bangkok consistently.	Must	Stored/displayed operational times and scheduled execution follow the configured time zone.

9. Data requirements

• Company data must remain logically isolated from other companies.
• Warehouse data must remain limited to warehouses authorized for the current user.
• Identifiers and relationships must preserve referential integrity.
• Stock movements must retain sufficient product, quantity, location, status, and traceability information.
• Financial and accounting records must retain document linkage, amount, posting status, period, and audit information.
• Soft deletion or inactive status must not silently destroy required transaction history.
• Demo/test data must be distinguishable from approved production data.

10. Interface requirements

10.1 User interface

• Browser-based responsive screens.
• Navigation and available actions appropriate to the current role and application access.
• Clear validation, status, success, and error feedback.
• Printable business documents and barcode labels where supported.

10.2 Internal service interfaces

• PHP application access to two configured MySQL/MariaDB databases.
• Authenticated or secret-protected event relay to the Node.js notification service.
• Browser Socket.IO connection to the configured public notification endpoint.
• Controlled scheduler invocation of approved PHP maintenance and alert jobs.

10.3 File interfaces

• Supported file attachment upload and retrieval.
• Export/print output for supported operational and management reports.
• Configuration templates that do not contain live secrets.

11. Operational scenarios for validation

Scenario	Expected outcome
User onboarding and access	The user enters the correct company and sees only functions permitted by role and application access.
Warehouse setup	Authorized users configure warehouse/location and product data required for operations.
Stock receipt	A valid receipt updates traceable stock at the selected location.
Stock issue	A valid issue reduces available stock; an invalid or excessive issue is rejected.
Stock transfer	Source and destination movements remain balanced and traceable.
Lot/serial/expiry control	Required attributes remain associated with stock and appear in applicable reports.
Sales lifecycle	Quotation/order/invoice/return actions follow permitted statuses and create expected related effects.
Purchasing lifecycle	Request/order/invoice/return actions follow permitted statuses and create expected related effects.
Finance and accounting	Receipt/payment and journal/GL results remain balanced and reportable.
Reporting	Authorized filters return consistent operational and financial results.
Notification and scheduler	Relevant events and scheduled alerts reach only appropriate recipients without duplication.
Tenant isolation	Attempts to access another company or unauthorized warehouse are denied.

12. Acceptance criteria

The requirements baseline is satisfied when:

• Every Must requirement is implemented and traced to one or more test cases and results.
• Representative end-to-end validation scenarios pass in the agreed environment.
• No unresolved critical defect remains in security, tenant isolation, inventory integrity, transaction integrity, or core workflows.
• Any deferred Should requirement has a documented and authorized disposition.
• User, operation, configuration, and maintenance documentation covers the delivered system.
• The Project Sponsor acting as Customer Representative confirms that the requirements reflect intended use.
• The Project Sponsor authorizes the requirement baseline and applicable acceptance result.

13. Requirement change control

After authorization, a requirement change must:

1. Receive a unique Change Report reference.
2. Identify the requested change and business reason.
3. Analyze scope, schedule, design, implementation, test, security, and documentation impact.
4. Receive Project Sponsor authorization before baseline modification.
5. Update the SRS, design, traceability, tests, plan, and affected records.
6. Be implemented, verified, validated where applicable, and formally closed.

14. Traceability rule

Each requirement ID in this document must appear in the Traceability Record with links to:

• The corresponding SRS requirement.
• One or more Software Design elements.
• Implementing component(s), configuration, or operational control.
• Verification method and Test Case ID(s).
• Test result and defect/correction reference where applicable.
• Validation or acceptance evidence for customer-facing requirements.

15. Approval

Prepared by

Name: Thanakorn Sathitwitayakul

Role: Developer

Signature: ______________________________________________

Date: ___________________________________________________

Reviewed by

Name: Apirach Supattaratpateep

Role: Project Manager

Signature: ______________________________________________

Date: ___________________________________________________

Reviewed, confirmed, 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: ___________________________________________________