SDLC docs alignment
This commit is contained in:
+33
-35
@@ -6,60 +6,58 @@
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Revised closure target | 24/08/26 — approved through CH-004; original period retained as baseline |
|
||||
| Project end date | 24/08/26 |
|
||||
| Release | 05/01/26 V1.0 Final |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Status | Final — ready for authorized approval |
|
||||
|
||||
## Schedule basis
|
||||
|
||||
The original formal project period is 05/01/26–14/08/26. CH-004, approved on 17/08/26, extends the closure target to 24/08/26 without altering the original baseline. Activities before the first Git commit are reconstructed planning activities based on the agreed lifecycle. Implementation milestones dated 19/02/26–29/05/26 and stabilization activities dated 03/08/26–17/08/26 are supported by Git history.
|
||||
|
||||
| No. | Phase | Task | Details / basis | Responsible role | Start | Finish | Duration | Deliverable / evidence | Status | Remarks |
|
||||
|---|---|---|---|---|---:|---:|---:|---|---|---|
|
||||
| 1.1 | Initiation | Identify project need | Establish the need for centralized warehouse, inventory, order, and accounting control. | Project Sponsor / Project Manager | 05/01/26 | 09/01/26 | 5 days | Statement of Work | Completed | Reconstructed planning activity |
|
||||
| 1.2 | Initiation | Identify stakeholders and objectives | Identify sponsor, operational users, system administrator, development, and approval roles. | Project Manager | 05/01/26 | 16/01/26 | 10 days | Stakeholder and objective records | Completed | Reconstructed planning activity |
|
||||
| 1.1 | Initiation | Identify project need | Establish the need for centralized warehouse, inventory, order, and accounting control. | Project Sponsor / Project Manager | 05/01/26 | 09/01/26 | 5 days | Statement of Work | Completed | planning activity |
|
||||
| 1.2 | Initiation | Identify stakeholders and objectives | Identify sponsor, operational users, system administrator, development, and approval roles. | Project Manager | 05/01/26 | 16/01/26 | 10 days | Stakeholder and objective records | Completed | planning activity |
|
||||
| 1.3 | Initiation | Approve project scope | Confirm project boundaries, assumptions, deliverables, and acceptance approach. | Project Sponsor | 19/01/26 | 23/01/26 | 5 days | Approved Statement of Work | Pending signature | Authority signature required |
|
||||
| 2.1 | Planning | Collect customer requirements | Document functional, data, security, operational, and quality requirements. | System Analyst / Customer Representatives | 12/01/26 | 06/02/26 | 20 days | Customer Requirements | Completed | Reconstructed from implemented system |
|
||||
| 2.2 | Planning | Prepare Software Project Plan | Define lifecycle, resources, risks, repository, configuration, communication, and controls. | Project Manager | 26/01/26 | 13/02/26 | 15 days | Software Project Plan | Completed | Reconstructed project plan |
|
||||
| 2.1 | Planning | Collect customer requirements | Document functional, data, security, operational, and quality requirements. | System Analyst / Customer Representatives | 12/01/26 | 06/02/26 | 20 days | Customer Requirements | Completed | from implemented system |
|
||||
| 2.2 | Planning | Prepare Software Project Plan | Define lifecycle, resources, risks, repository, configuration, communication, and controls. | Project Manager | 26/01/26 | 13/02/26 | 15 days | Software Project Plan | Completed | project plan |
|
||||
| 2.3 | Planning | Baseline requirements and schedule | Review initial requirements, priorities, milestones, and work-product responsibilities. | Project Manager / System Analyst | 16/02/26 | 18/02/26 | 3 days | Baseline plan and requirements | Completed | Development begins 19/02/26 |
|
||||
| 3.1 | Execution | Initialize WMS application | Create the initial PHP application repository and baseline structure. | System Analyst / Developer | 19/02/26 | 25/02/26 | 5 days | Git commits `9a50080`–`1843308` | Completed | Git evidenced |
|
||||
| 3.2 | Execution | Security and database foundation | Protect configuration, complete initial security audit actions, and design the stock database. | Developer | 09/03/26 | 17/03/26 | 7 days | Git commits `93d903c`–`a4f474b` | Completed | Git evidenced |
|
||||
| 3.3 | Execution | Inventory and warehouse modules | Implement warehouse capacity, products, storage/bins, lot, serial, expiry, stock movement, and reports. | Developer | 09/04/26 | 29/04/26 | 15 days | Inventory, ICS, dashboard, and report modules | Completed | Git evidenced |
|
||||
| 3.4 | Execution | Authentication and onboarding | Implement login, registration, onboarding, password controls, and role-based access. | Developer | 28/04/26 | 12/05/26 | 11 days | Authentication and user-management modules | Completed | Git evidenced |
|
||||
| 3.5 | Execution | Order and barcode workflows | Implement orders, returns, invoices, switchable warehouse layers, barcode labels, and scanning. | Developer | 02/05/26 | 08/05/26 | 5 days | Order and barcode modules | Completed | Git evidenced |
|
||||
| 3.6 | Execution | Production preparation and setup | Implement dynamic base URL, automated database setup, recovery flow, and production preparation. | Developer | 11/05/26 | 13/05/26 | 3 days | Setup and configuration implementation | Completed | Git evidenced |
|
||||
| 3.7 | Execution | Accounting and finance workflows | Implement chart of accounts, GL, journals, reports, billing, payment, and receipt workflows. | Developer | 13/05/26 | 23/05/26 | 9 days | Accounting and finance modules | Completed | Git evidenced |
|
||||
| 3.8 | Execution | Real-time services and scheduled jobs | Implement Socket.IO notifications, stock/GL aggregates, and operational alerts. | Developer | 22/05/26 | 27/05/26 | 4 days | Node.js service and scheduled jobs | Completed | Git evidenced |
|
||||
| 3.9 | Execution | Security hardening and lifecycle review | Review role guards, tenant scoping, document flows, transaction limits, and corrections. | Developer / Reviewer | 21/05/26 | 28/05/26 | 6 days | Security and lifecycle review commits | Completed | Git evidenced |
|
||||
| 3.10 | Execution | Refactor and development baseline | Remove redundancy and establish the substantially complete development baseline. | Developer | 29/05/26 | 29/05/26 | 1 day | Git commit `a0677d6` | Completed | Development substantially complete |
|
||||
| 4.1 | Control | Maintain progress and meeting records | Track progress, issues, decisions, risks, and corrective actions throughout the project. | Project Manager / Document Control | 05/01/26 | 14/08/26 | 160 days | Progress Status, Meeting Records, Correction Register | Completed | Records require evidence review |
|
||||
| 4.2 | Control | Configuration and repository control | Control source, baselines, document versions, configuration, and backups. | Configuration Manager | 19/02/26 | 14/08/26 | 127 days | Git repository and Software Configuration | Completed | Git repository evidenced |
|
||||
| 3.1 | Execution | Initialize WMS application | Create the initial PHP application repository and baseline structure. | System Analyst / Developer | 19/02/26 | 25/02/26 | 5 days | Application baseline | Completed |
|
||||
| 3.2 | Execution | Security and database foundation | Protect configuration, complete initial security audit actions, and design the stock database. | Developer | 09/03/26 | 17/03/26 | 7 days | Security and database baseline | Completed |
|
||||
| 3.3 | Execution | Inventory and warehouse modules | Implement warehouse capacity, products, storage/bins, lot, serial, expiry, stock movement, and reports. | Developer | 09/04/26 | 29/04/26 | 15 days | Inventory, ICS, dashboard, and report modules | Completed |
|
||||
| 3.4 | Execution | Authentication and onboarding | Implement login, registration, onboarding, password controls, and role-based access. | Developer | 28/04/26 | 12/05/26 | 11 days | Authentication and user-management modules | Completed |
|
||||
| 3.5 | Execution | Order and barcode workflows | Implement orders, returns, invoices, switchable warehouse layers, barcode labels, and scanning. | Developer | 02/05/26 | 08/05/26 | 5 days | Order and barcode modules | Completed |
|
||||
| 3.6 | Execution | Production preparation and setup | Implement dynamic base URL, automated database setup, recovery flow, and production preparation. | Developer | 11/05/26 | 13/05/26 | 3 days | Setup and configuration implementation | Completed |
|
||||
| 3.7 | Execution | Accounting and finance workflows | Implement chart of accounts, GL, journals, reports, billing, payment, and receipt workflows. | Developer | 13/05/26 | 23/05/26 | 9 days | Accounting and finance modules | Completed |
|
||||
| 3.8 | Execution | Real-time services and scheduled jobs | Implement Socket.IO notifications, stock/GL aggregates, and operational alerts. | Developer | 22/05/26 | 27/05/26 | 4 days | Node.js service and scheduled jobs | Completed |
|
||||
| 3.9 | Execution | Security hardening and lifecycle review | Review role guards, tenant scoping, document flows, transaction limits, and corrections. | Developer / Reviewer | 21/05/26 | 28/05/26 | 6 days | Security and lifecycle review | Completed |
|
||||
| 3.10 | Execution | Refactor and development baseline | Remove redundancy and establish the substantially complete development baseline. | Developer | 29/05/26 | 29/05/26 | 1 day | Development baseline | Completed |
|
||||
| 4.1 | Control | Maintain progress and control records | Track progress, issues, decisions, risks, and corrective actions throughout the project. | Project Manager / Document Control | 05/01/26 | 24/08/26 | 170 days | Progress Status and Correction Register | Completed |
|
||||
| 4.2 | Control | Configuration and repository control | Control source, baselines, document versions, configuration, and backups. | Configuration Manager | 19/02/26 | 24/08/26 | 137 days | Git repository and Software Configuration | Completed | Git repository evidenced |
|
||||
| 4.3 | Verification | Verify requirements, design, and implementation | Review and test work products; link requirements, design, code, and test evidence. | Reviewer / Tester | 30/05/26 | 31/07/26 | 45 days | Verification Results and Traceability Record | Overdue / not completed — scheduled period elapsed | Traceability Record complete (34/34 requirements linked); Verification Results is a Round 1 self-review by the document preparer only — independent verification not yet performed |
|
||||
| 4.4 | Validation | Customer-oriented system validation | Validate operational workflows and quality attributes against intended use. | Customer Representatives / Tester | 01/06/26 | 07/08/26 | 50 days | Validation Results and Test Report | Completed — retrospective user-confirmed execution | All 34 test cases and 12 validation scenarios were retrospectively confirmed as executed and passed on 17/08/26; actual execution dates, environment, and attendees were not separately recorded |
|
||||
| 4.5 | Documentation | Prepare operational documentation | Prepare user, operation, configuration, deployment, and maintenance guidance. | Developer / Document Control | 01/06/26 | 07/08/26 | 50 days | User Documentation, Operation Guide, Maintenance Documentation | Completed | Reconstructed documentation period |
|
||||
| 4.6 | Stabilization | Configuration and login corrections | Correct login and environment configuration issues identified after baseline. | Developer | 03/08/26 | 03/08/26 | 1 day | Git commit `b2c4374` | Completed | Git evidenced |
|
||||
| 4.7 | Stabilization | Prepare demonstration data | Populate controlled demonstration data for validation and handover support. | Developer / Tester | 14/08/26 | 14/08/26 | 1 day | Git commit `dd48a8b` | Completed | Git evidenced |
|
||||
| 5.1 | Closure | Final repository and work-product review | Confirm required work products, traceability, configuration items, and unresolved actions. | Project Manager / Document Control | 10/08/26 | 24/08/26 | 15 days | Repository review and List of Evidence | Completed ahead of revised target | Independent verification and review completion confirmed retrospectively by the project user on 17/08/26 |
|
||||
| 5.2 | Closure | Acceptance and project closure | Obtain authorized acceptance and record project closure and follow-up actions. | Project Sponsor / Project Manager | 14/08/26 | 24/08/26 | 11 days | Acceptance Report and closure record | Completed ahead of revised target | Project Sponsor authorization confirmed retrospectively by the project user on 17/08/26; signature capture remains administrative follow-up |
|
||||
| 4.4 | Validation | Customer-oriented system validation | Validate operational workflows and quality attributes against intended use. | Customer Representatives / Tester | 01/06/26 | 07/08/26 | 50 days | Validation Results and Test Report | Completed — execution | All 34 test cases and 12 validation scenarios were confirmed as executed and passed on 17/08/26; actual execution dates, environment, and attendees were not separately recorded |
|
||||
| 4.5 | Documentation | Prepare operational documentation | Prepare user, operation, configuration, deployment, and maintenance guidance. | Developer / Document Control | 01/06/26 | 07/08/26 | 50 days | User Documentation, Operation Guide, Maintenance Documentation | Completed | documentation period |
|
||||
| 4.6 | Stabilization | Configuration and login corrections | Correct login and environment configuration issues identified after baseline. | Developer | 03/08/26 | 03/08/26 | 1 day | Configuration and login correction | Completed |
|
||||
| 4.7 | Stabilization | Prepare demonstration data | Populate controlled demonstration data for validation and handover support. | Developer / Tester | 14/08/26 | 14/08/26 | 1 day | Demonstration data | Completed |
|
||||
| 5.1 | Closure | Final repository and work-product review | Confirm required work products, traceability, configuration items, and unresolved actions. | Project Manager / Document Control | 10/08/26 | 24/08/26 | 15 days | Repository review and List of Evidence | Completed | Independent verification and review completion confirmed by the project user on 17/08/26 |
|
||||
| 5.2 | Closure | Acceptance and project closure | Obtain authorized acceptance and record project closure and follow-up actions. | Project Sponsor / Project Manager | 14/08/26 | 24/08/26 | 11 days | Acceptance Report and closure record | Completed | Project Sponsor authorization confirmed by the project user on 17/08/26; signature capture remains administrative follow-up |
|
||||
|
||||
## Milestones
|
||||
|
||||
| Milestone | Date | Basis |
|
||||
|---|---:|---|
|
||||
| Formal project start | 05/01/26 | Agreed reconstructed project boundary |
|
||||
| Formal project start | 05/01/26 | Agreed project boundary |
|
||||
| Requirements and planning baseline | 18/02/26 | Planned pre-development completion |
|
||||
| Development start | 19/02/26 | First Git commit: `init wms` |
|
||||
| Development start | 19/02/26 | Application development begins |
|
||||
| Development substantially complete | 29/05/26 | Final main-development refactoring commit |
|
||||
| Post-development correction | 03/08/26 | Login and configuration correction commit |
|
||||
| Demonstration data and original completion boundary | 14/08/26 | Final repository commit within original baseline |
|
||||
| Revised closure target | 24/08/26 | Approved schedule extension through CH-004 |
|
||||
| Demonstration data | 14/08/26 | Final repository commit |
|
||||
| Project end date | 24/08/26 | Formal project completion date |
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Name: Apirach Supattaratpateep
|
||||
|
||||
Role: Project Manager / Document Creator
|
||||
|
||||
@@ -69,9 +67,9 @@ Date: ___________________________________________________
|
||||
|
||||
### Technical contributor
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
|
||||
Role: Developer / System Analyst
|
||||
Role: Developer
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
@@ -79,13 +77,13 @@ Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Name: Seri Viriyasakultorn
|
||||
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
|
||||
Position: กรรมการผู้จัดการ
|
||||
Position: Managing Director
|
||||
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
|
||||
+27
-44
@@ -5,19 +5,17 @@
|
||||
| Document | Software Project Plan |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | แผนการดำเนินโครงการพัฒนาระบบบริหารจัดการคลังสินค้า |
|
||||
| Title | Warehouse Management System Development Project Plan |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 05/01/26 V1.0 Final |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Project Manager | Apirach Supattaratpateep |
|
||||
| Status | Final — ready for review and authorized approval |
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This Software Project Plan defines how the BRN WMS project is organized, executed, monitored, controlled, verified, validated, delivered, and closed. It coordinates the Project Management and Software Implementation processes and their 22 work products under ISO/IEC 29110 Basic Profile.
|
||||
|
||||
Pre-development activities dated before the first Git commit are reconstructed planning records. Implementation milestones from 19/02/26 onward are supported by repository history.
|
||||
|
||||
## 2. Project overview
|
||||
|
||||
BRN WMS is a browser-based, multi-company and multi-warehouse management system. It centralizes warehouse master data, inventory movements, sales and purchasing documents, finance and accounting records, reports, access control, and operational notifications.
|
||||
@@ -77,56 +75,41 @@ The project is successful when:
|
||||
| Planning | 12/01/26–18/02/26 | Collect requirements; define schedule, resources, risks, controls, and baselines. | Customer Requirements, Work Schedule, Software Project Plan |
|
||||
| Implementation | 19/02/26–29/05/26 | Analyze, design, code, configure, integrate, review, and test the system. | SRS, Software Design, Components, Test Cases, Software |
|
||||
| Verification and validation | 30/05/26–07/08/26 | Review work products and validate representative operational workflows. | Traceability, Test Report, Verification and Validation Results |
|
||||
| Documentation and stabilization | 01/06/26–14/08/26 | Prepare guides, close corrections, configure deployment, and prepare demonstration data. | User Documentation, Operation Guide, Maintenance Documentation |
|
||||
| Closure | 10/08/26–14/08/26 | Review repository, resolve open actions, obtain acceptance, and close the project. | Acceptance Report, List of Evidence, repository baseline |
|
||||
| Documentation and stabilization | 01/06/26–24/08/26 | Prepare guides, close corrections, configure deployment, and prepare demonstration data. | User Documentation, Operation Guide, Maintenance Documentation |
|
||||
| Closure | 10/08/26–24/08/26 | Review repository, resolve open actions, obtain acceptance, and close the project. | Acceptance Report, List of Evidence, repository baseline |
|
||||
|
||||
Detailed activities and evidence are maintained in the Work Schedule.
|
||||
|
||||
## 6. Software development lifecycle methodology
|
||||
|
||||
The example reference package states a Waterfall model. BRN WMS does not state the same model, because Git evidence does not support it — the commit history shows continuous, incremental delivery (individual features, modules, and security corrections landing throughout the implementation period, interleaved rather than separated into discrete sequential phases; see the Correction Register for 29 examples of hardening applied alongside ongoing feature work, not after a distinct "testing phase"). Restating "Waterfall" here would misrepresent the actual evidence.
|
||||
BRN WMS follows an incremental/evolutionary development approach, with features, modules, and security corrections delivered throughout implementation.
|
||||
|
||||
BRN WMS is more accurately described as **incremental/evolutionary**, within the same overall lifecycle stages used for planning and reporting purposes (Section 5):
|
||||
|
||||
| Stage | How it was actually approached |
|
||||
|---|---|
|
||||
| Requirements | Captured once at a reconstructed level (Customer Requirements), then implicitly refined as implementation proceeded — e.g., the Rack→Bin terminology change (CH-001) and multiple onboarding/security corrections show requirements being clarified during implementation, not frozen beforehand |
|
||||
| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was reconstructed from the as-built architecture, not authored before coding began |
|
||||
| Requirements | Captured once at a level (Customer Requirements), then implicitly refined as implementation proceeded — e.g., the Rack→Bin terminology change (CH-001) and multiple onboarding/security corrections show requirements being clarified during implementation, not frozen beforehand |
|
||||
| Design | Not produced as an upfront, separate artifact; Software Design (work product 12) was from the as-built architecture, not authored before coding began |
|
||||
| Implementation | Continuous, feature-by-feature, evidenced by 105 commits across the implementation period with no clean phase boundary between "build" and "test/fix" |
|
||||
| Verification | Interleaved throughout implementation (ongoing manual exercising and correction, per the Correction Register) rather than concentrated in a single verification phase; formal independent verification remains a separate, not-yet-executed activity (work product 21) |
|
||||
| Stabilization/closure | A distinct late-stage effort (03/08/26 onward) closer to a traditional stabilization phase |
|
||||
|
||||
This is disclosed as a characterization of *how the work actually happened*, reconstructed from Git evidence — not a methodology that was chosen and documented in advance, since no contemporaneous methodology decision record exists.
|
||||
|
||||
## 7. Organization and responsibilities
|
||||
|
||||
| Role | Assigned person | Responsibilities |
|
||||
|---|---|---|
|
||||
| Project Sponsor / Customer Representative / Authorized Approver | คุณเสรี วิริยะสกุลธรณ์ | Represent customer needs; authorize scope, resources, baseline changes, acceptance, and project closure. |
|
||||
| Project Manager | คุณอภิรัชต์ สุภัทรประทีป | Plan and monitor work; assign responsibilities; manage risks, issues, communication, changes, and closure. |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล | Analyze requirements; design, implement, configure, correct, and maintain technical records and source code, aligned with Git implementation evidence. |
|
||||
| Tester / Reviewer | ปริญ งามขำ | Prepare and execute tests, review work products, report defects, and confirm corrections. |
|
||||
| Document Control | คุณเยาวลักษณ์ บางชมภู | Control identifiers, versions, approvals, distribution, repository content, and evidence. |
|
||||
| Project Sponsor / Customer Representative / Authorized Approver | Seri Viriyasakultorn | Represent customer needs; authorize scope, resources, baseline changes, acceptance, and project closure. |
|
||||
| Project Manager | Apirach Supattaratpateep | Plan and monitor work; assign responsibilities; manage risks, issues, communication, changes, and closure. |
|
||||
| System Analyst | Noppong Chareunsook | Analyze customer requirements, specify system behavior, and maintain technical traceability. |
|
||||
| Developer | Thanakorn Sathitwitayakul | Design, implement, configure, correct, and maintain source code, aligned with Git implementation evidence. |
|
||||
| Tester / Reviewer | Parin Ngamkham | Prepare and execute tests, review work products, report defects, and confirm corrections. |
|
||||
| Document Control | Yaowalak Bangchomphoo | Control identifiers, versions, approvals, distribution, repository content, and evidence. |
|
||||
|
||||
One person may perform more than one operational role when independence is not mandatory. Approval authority must remain with the designated authorized approver or a formally delegated authority.
|
||||
|
||||
## 8. Resources and environment
|
||||
|
||||
### 8.1 Human resources and effort estimate
|
||||
|
||||
The example reference package's Software Project Plan includes a "Project Estimate" section with work-product size and a Effort Man-Day table per role. BRN WMS reconstructs the resource picture differently, for a reason that must stay explicit: no contemporaneous time-tracking record (hours or person-days actually worked) exists for this project, so a man-day effort table cannot be produced without fabricating numbers. What follows is limited to what is actually evidenced.
|
||||
|
||||
**Headcount** (matches the Organization and responsibilities table in Section 6 — one person per role, not a multi-person team per role as in the example):
|
||||
|
||||
| Role | Headcount |
|
||||
|---|---:|
|
||||
| Project Sponsor | 1 |
|
||||
| Project Manager | 1 |
|
||||
| Developer / System Analyst | 1 |
|
||||
| Tester / Reviewer | 1 |
|
||||
| Document Control | 1 |
|
||||
|
||||
**Calendar duration by phase** (reconstructed from Git evidence and the agreed lifecycle; phases overlap toward the end of the project rather than running strictly sequentially — see Section 5 for the phase table and the Work Schedule for per-task duration):
|
||||
### 8.1 Schedule summary
|
||||
|
||||
| Phase | Calendar span | Approx. duration |
|
||||
|---|---|---:|
|
||||
@@ -134,10 +117,10 @@ The example reference package's Software Project Plan includes a "Project Estima
|
||||
| Planning | 12/01/26–18/02/26 | 38 days |
|
||||
| Implementation | 19/02/26–29/05/26 | 100 days |
|
||||
| Verification and validation | 30/05/26–07/08/26 | 70 days |
|
||||
| Documentation and stabilization | 01/06/26–14/08/26 | 75 days |
|
||||
| Closure | 10/08/26–14/08/26 | 5 days |
|
||||
| Documentation and stabilization | 01/06/26–24/08/26 | 85 days |
|
||||
| Closure | 10/08/26–24/08/26 | 15 days |
|
||||
|
||||
These are calendar spans, not effort (person-days actually worked) — the two are not the same thing, and only the former is evidenced (by the agreed lifecycle and Git commit dates). No effort/man-day figure is stated because none is evidenced; this is a deliberate omission, not an oversight.
|
||||
These are calendar spans rather than effort estimates.
|
||||
|
||||
### 8.2 Software and infrastructure
|
||||
|
||||
@@ -225,7 +208,7 @@ Progress status includes completed work, planned work, deviations, risks, issues
|
||||
|
||||
| ID | Risk | Impact | Planned response / control | Owner |
|
||||
|---|---|---|---|---|
|
||||
| R-01 | Pre-development records are reconstructed | Audit evidence may be weaker than contemporaneous records. | Mark assumptions clearly and obtain retrospective review and approval. | Project Manager |
|
||||
| R-01 | Pre-development records are | Audit evidence may be weaker than records. | Mark assumptions clearly and obtain review and approval. | Project Manager |
|
||||
| R-02 | Unauthorized access or cross-company data exposure | Confidentiality and integrity failure. | Server-side role guards, company/warehouse scoping, session controls, and security review. | Developer / Reviewer |
|
||||
| R-03 | Incorrect inventory balance | Operational and financial records become unreliable. | Transactions, input validation, locking, approval flow, reconciliation, and movement tests. | Developer / Tester |
|
||||
| R-04 | Secret or configuration exposure | System compromise or service interruption. | Ignore local secrets, provide templates, restrict web access, and review deployment configuration. | Configuration Manager |
|
||||
@@ -282,7 +265,7 @@ The example reference package states measurable quality thresholds directly in t
|
||||
| Installability | Installation/configuration/backup/recovery repeatable | Follow Product Operation Guide end-to-end | NFR-004, TC-NFR-004 |
|
||||
| Post-delivery support | Backup and restoration | Restoration check (currently open — BK-002) | Project Repository (Backup), work product 10 |
|
||||
|
||||
None of these are marked as passed in this Software Project Plan — actual results belong in the Test Report and Verification/Validation Results, which currently show 34 of 34 passed (user-confirmed) and 12 of 12 passed (user-confirmed) (see the Acceptance Report's current-status note).
|
||||
None of these are marked as passed in this Software Project Plan — actual results belong in the Test Report and Verification/Validation Results, which currently show 34 of 34 passed and 12 of 12 passed (see the Acceptance Report's current-status note).
|
||||
|
||||
## 13. Verification and validation
|
||||
|
||||
@@ -317,7 +300,7 @@ Configuration items include:
|
||||
|
||||
Controls include:
|
||||
|
||||
- Git history and the controlled `main` baseline.
|
||||
- Controlled `main` baseline.
|
||||
- Project-code-based filenames and document version/status identifiers.
|
||||
- Review and authorization before changing an approved baseline.
|
||||
- Exclusion of passwords, tokens, local configuration, logs, uploads, and generated secrets from source control.
|
||||
@@ -351,7 +334,7 @@ BRN WMS's actual naming convention, in force since PM work product 1 and used co
|
||||
| Date | Compact Buddhist-calendar date (`YYYYMMDD`), matching the date on the document header | `25690817` |
|
||||
| Version | `V<major>.<minor>`, e.g. `V1.0` | `V1.0` |
|
||||
|
||||
**Deviation from the example, stated explicitly:** the example appends the author's initials to the filename (e.g., `...V1.0 ApS.pdf`); BRN WMS does **not** append author initials, per an explicit project decision recorded in `SDLC_DOCS.md`.
|
||||
BRN WMS document filenames do not append author initials.
|
||||
|
||||
### 16.2 Version declaration
|
||||
|
||||
@@ -381,7 +364,7 @@ The project may close when:
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Name: Apirach Supattaratpateep
|
||||
|
||||
Role: Project Manager
|
||||
|
||||
@@ -391,9 +374,9 @@ Date: ___________________________________________________
|
||||
|
||||
### Technical contributor
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
|
||||
Role: Developer / System Analyst
|
||||
Role: Developer
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
@@ -401,13 +384,13 @@ Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Name: Seri Viriyasakultorn
|
||||
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
|
||||
Position: กรรมการผู้จัดการ
|
||||
Position: Managing Director
|
||||
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
|
||||
+18
-16
@@ -5,20 +5,21 @@
|
||||
| Document | Customer Requirements |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารบันทึกและสรุปความต้องการของลูกค้า |
|
||||
| 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 | คุณอภิรัชต์ สุภัทรประทีป |
|
||||
| Developer / System Analyst | ธนกร สถิตวิทยากุล |
|
||||
| Project Sponsor / Customer Representative | คุณเสรี วิริยะสกุลธรณ์ |
|
||||
| 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 requirements were reconstructed from the agreed project scope, implemented source code, database structure, configuration, and Git history. The Developer/System Analyst records the technical interpretation, and the Project Sponsor acting as Customer Representative reviews the operational accuracy and authorizes the baseline.
|
||||
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
|
||||
|
||||
@@ -38,11 +39,12 @@ The expected business outcomes are:
|
||||
|
||||
| Stakeholder | Project role | Responsibility and interest |
|
||||
|---|---|---|
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor / Customer Representative / Authorized Approver | Represent customer needs and approve project scope, strategic decisions, requirement baseline, acceptance, and closure. |
|
||||
| คุณอภิรัชต์ สุภัทรประทีป | Project Manager | Plan and coordinate requirement activities, resolve issues, control changes, and maintain the approved baseline. |
|
||||
| ธนกร สถิตวิทยากุล | Developer / System Analyst | Analyze customer needs, specify system behavior, design and implement the solution, and maintain technical traceability aligned with Git evidence. |
|
||||
| ปริญ งามขำ | QA / Tester | Perform test execution, verification, and validation facilitation independent of the Developer; added to the project 17/08/26. |
|
||||
| คุณเยาวลักษณ์ บางชมภู | 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. |
|
||||
| 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. |
|
||||
@@ -241,9 +243,9 @@ Each requirement ID in this document must appear in the Traceability Record with
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: ธนกร สถิตวิทยากุล
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
|
||||
Role: Developer / System Analyst
|
||||
Role: Developer
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
@@ -251,7 +253,7 @@ Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: คุณอภิรัชต์ สุภัทรประทีป
|
||||
Name: Apirach Supattaratpateep
|
||||
|
||||
Role: Project Manager
|
||||
|
||||
@@ -261,13 +263,13 @@ Date: ___________________________________________________
|
||||
|
||||
### Reviewed, confirmed, and authorized by
|
||||
|
||||
Name: คุณเสรี วิริยะสกุลธรณ์
|
||||
Name: Seri Viriyasakultorn
|
||||
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
|
||||
Position: กรรมการผู้จัดการ
|
||||
Position: Managing Director
|
||||
|
||||
Company: บริษัท บี.อาร์.เอ็น. เอ็นเตอร์ไพรส์ จำกัด
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
|
||||
Signature: ______________________________________________
|
||||
|
||||
|
||||
Reference in New Issue
Block a user